Recovering 168 Actively-Infected Sites — Plus a Precautionary Audit of 95 More
Client: Real estate marketing agency — 263-site WordPress portfolio across three shared hosting servers
Case Snapshot
01The Problem
The agency had already been through one round of cleanup elsewhere. Sites were still throwing intermittent HTTP 408 errors, a hosting-panel scanner kept flagging infections, and the agency no longer trusted what was actually fixed. The two symptomatic servers held 168 sites between them; a third, sharing the same at-risk credentials, was proactively audited too.
- A reused shared-hosting password sat in a plaintext credentials file — giving account-wide access, not just one site
- A black-hat SEO tool silently installed itself as a hidden must-use plugin on every site it touched
- A file-manager webshell, identical byte-for-byte, gave direct browser-based file access across sites
- A theme-level dropper silently re-created the backdoor plugin the moment it was deleted
Critical issue: one site became completely inaccessible — even the hosting panel's one-click admin login failed. Every conventional check came back clean.
02What Others Missed
The reason the locked-out site broke was something WordPress itself never creates on its own: a MySQL database trigger. It silently intercepted any attempt to create a new admin account — once the attacker's disguised account was removed during cleanup, the trigger made it permanently impossible to create a replacement through any normal means.
A second trigger, found on several other sites, watched every public blog comment for a specific phrase. The moment that phrase appeared — something any anonymous visitor could submit — it silently created a full admin account with a password the attacker already controlled. No login, no file upload, no existing access required.
WordPress never uses database triggers, stored procedures, or scheduled events on its own — but it's a category of compromise standard file-based malware scanners simply don't look for. None of the comment-activated backdoors had been triggered yet — caught in time.
03What We Did
Full Portfolio Cleanup
- Removed every backdoor file, cloaker, and rogue admin account
- Preserved evidence for the client's records
Reinfection Root Cause
- Identified a vulnerable file-manager plugin the attacker was actively exploiting to re-upload payloads
- Removed it account-wide
Database Forensics
- Full audit for hidden triggers, stored procedures, and scheduled events across every site
- Eradicated both backdoor types
Credential & Access Hardening
- Rotated credentials across both hosting accounts
- Set up key-based authentication to close the original entry point
Infrastructure Cleanup
- Resolved file-count and memory pressure independent of the malware
- Verified every site's configured URL against its actual domain
Results
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.
Key Takeaway
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.