← All case studies Security Hardening

The Silent Breach

Professional services firm, active client portal, UK-regulated sector

2.3GB 45MB

Database size after cleanup

11mo 0

Months compromised

The situation

The client ran a professional services website with a client login portal. The site appeared to be functioning perfectly. Traffic was normal. There were no error messages, no defacements, no blacklist warnings, no complaints from clients. Nothing had triggered concern.

The brief was not a crisis response. It was a routine annual security audit, the kind I recommend to every client regardless of symptoms. The client had not experienced any incidents that they were aware of.

The diagnosis

File integrity checking against known-good WordPress core hashes revealed discrepancies in two core files. Both had been modified. This is almost always diagnostic of a compromise — legitimate WordPress updates do not modify core files in place; they replace them wholesale.

Manual inspection of the modified files revealed obfuscated PHP. A base64-encoded payload, decoded, was a file manager backdoor — a script that provided unauthenticated remote access to the server filesystem.

Deeper inspection of the database revealed a set of custom tables that did not belong to any installed plugin. These tables contained approximately 2.3GB of spam link data — the site had been operating as a hidden link farm, injecting thousands of spam URLs into pages served to specific user-agents (Google's crawler, specifically) while showing clean content to human visitors.

Timestamp analysis placed the initial infection approximately eleven months before the audit. The attack vector was a then-unpatched vulnerability in a form plugin that had been updated — and the patch applied — eight months earlier. The attacker had already established persistence before the patch was available.

What this means

For eleven months, every page served to Google's crawler contained thousands of hidden spam links. The client's domain authority was being silently used to boost unrelated spam sites. The client had no knowledge of this and no indication from normal site usage.

The client was also operating under UK regulatory requirements regarding data security. The existence of an authenticated backdoor with eleven months of access represented a potential data breach under UK GDPR, requiring documented investigation of what data, if any, had been accessed or exfiltrated.

The remediation

  • Full file audit

    Every file on the server compared against checksums. All modified or unrecognised files identified and inspected before removal — not just pattern-matched and deleted, which risks removing legitimate customisations.

  • Malware removal

    Backdoor scripts and all injected files removed. Database tables containing spam data dropped. Verified via re-scan post-cleanup.

  • Core and plugin reinstallation

    All WordPress core files replaced with clean copies. All plugins updated to current versions. One outdated plugin with no security maintenance was removed and replaced with a maintained alternative.

  • Hardening implementation

    File editing disabled, XML-RPC locked down, user enumeration blocked, Content Security Policy headers configured, login attempt limiting implemented with monitoring.

  • Breach investigation documentation

    A written assessment of the likely scope of access during the compromise period, for the client's regulatory obligations. No evidence of data exfiltration was found, though this could not be ruled out absolutely given the duration of access.

  • Ongoing monitoring setup

    File integrity monitoring and automated malware scanning configured with alerting, so any future compromise would be detected within hours rather than months.

The outcome

The site was cleaned and hardened. Search Console flagged no manual actions during or after the incident — the spam injection had not yet been formally actioned by Google, though it had certainly been observed. The client submitted a precautionary notification to the ICO as a matter of regulatory compliance.

The client is now on a Technical Assurance Plan with regular security audits. In eighteen months of monitoring since the clean, there has been no re-infection and no further security incidents.

Symptoms are not a reliable indicator of compromise. This site was breached for eleven months and showed none. The only thing that caught it was looking for it.

From the blog

Further reading

All articles →

When did you last audit your WordPress site?

Most compromised sites look and function normally. A forensic security audit costs less than the incident it prevents.