A real estate marketing agency's portfolio had already been "cleaned" once and kept getting reinfected. Here's what we found when we went looking for the reason — and how we recovered all 263 sites with zero data loss.
A real estate marketing agency managing a portfolio of 263 WordPress sites across three shared hosting servers came to us with a problem that had already been through one round of "cleanup" — sites were still throwing intermittent HTTP 408 errors, a hosting-panel malware scanner had flagged infections, and the agency no longer fully trusted what was and wasn't actually fixed.
The two servers actually showing symptoms held 168 sites between them. A third server on the same account — sharing the same at-risk credentials, though not showing symptoms — was proactively audited as part of the same response.
That instinct turned out to be correct. What we found underneath was a campaign far more sophisticated than the surface symptoms suggested — and it included a persistence technique we don't see written about often: a backdoor hidden not in any file, but inside the database itself.
The entry point was mundane and completely preventable: a shared hosting password, reused across both servers, had been sitting in a plaintext credentials file. Once compromised, it gave the attacker account-level access — not to one WordPress site, but to the entire hosting account and every site on it.
From there, the attacker deployed a layered, self-healing infrastructure designed to survive a normal cleanup:
Silently installed itself as a hidden "must-use" plugin on any site it touched.
Identical byte-for-byte across multiple sites — full file read/write via a browser.
Disguised as real pages (about-us.php, contact-us.php), pulling gambling-spam on every visit.
Randomized names, created across dozens of sites.
Silently re-created the backdoor plugin the moment it was deleted.
This combination is why the account-wide resource usage kept climbing and sites kept timing out even after a first cleanup pass: the malware was designed to heal itself faster than a surface-level scan could keep up.
Deep in the recovery process, one client site became completely inaccessible — not even the hosting panel's own one-click admin login worked. Every conventional check came back clean: no rogue files, no suspicious plugins, correct file permissions, a fully verified WordPress core.
The reason turned out to be something WordPress itself never creates on its own: a database trigger.
The attacker had planted a piece of logic directly inside the site's MySQL database that silently intercepted any attempt to create a new administrator account — allowing only their own disguised account to exist. Once that account was removed during cleanup, the trigger made it permanently impossible to create a replacement admin through any normal means. The site wasn't broken. It was booby-trapped.
Widening the search turned up a second trigger on a handful of other sites: it watched every public blog comment for a specific phrase. The moment that phrase appeared — something any anonymous visitor could submit — the trigger silently created a full administrator account with a password the attacker already controlled.
No login, no file upload, no existing access required — just one public comment.
Because WordPress never uses database triggers, stored procedures, or scheduled events on its own, any presence of one is a red flag — but it's a category of compromise that standard file-based malware scanners simply don't look for. We found and removed these across every affected site. None of the second, comment-activated backdoors had actually been triggered yet — caught in time.
Working across the two affected servers — plus a precautionary full audit of the third — the recovery covered:
The actual reinfection vector was identified and removed — not just the symptoms. A full write-up and evidence trail was delivered to the client for their own records.
If your WordPress site — or your agency's entire portfolio — has ever been "cleaned" and you're still not fully confident it's actually secure, this case is a useful gut-check: file-based malware scans, even thorough ones, do not check your database for triggers, stored procedures, or scheduled events.
That's not a hypothetical gap. It's exactly how a real attacker maintained access on this account — and it's the kind of thing that only gets found when someone goes looking for it specifically.
Send us your details and we will assess your situation and send you a quote — usually within a few hours. WhatsApp is the fastest route.