How we removed a self-healing WordPress backdoor a prior contractor missed
- Client
- Anonymized — Southern California contractor's WordPress site
- Engagement
- Emergency incident response + remediation + reputation recovery
Outcomes
- Eradicated a persistent self-healing backdoor that survived a prior cleanup attempt
- Removed 115+ spam posts and cleaned the WordPress database
- Hardened credentials and access controls across admin and hosting
- Delivered a written incident report and 30-day verification scan
The situation
A Southern California contractor came to us after their business website started showing a red "Deceptive site ahead" warning in Google Chrome. Their hosting provider had flagged the account for malicious content and was threatening suspension within 48 hours. A contractor they'd hired a month earlier had told them the site was clean — but the problem came back within two weeks. By the time they reached us, Google Search Console was flooded with manual action notices, organic traffic had dropped by over 60%, and the client had no clear picture of how bad the damage actually was or how it kept recurring.
What the prior contractor missed
The previous cleanup removed the most visible malware — the injected redirect scripts and obvious payload files — but missed the persistence mechanism entirely. The site had a hidden seed file buried in a non-standard directory, disguised with a benign-looking filename and timestamp that matched surrounding legitimate files. This seed file contained an encrypted dropper that would silently regenerate the malicious payloads on a schedule, and it was configured to re-infect any newly uploaded or modified PHP files. Standard file scans based on known signature lists wouldn't catch it because the seed itself didn't match any signatures — it was custom-built for this attack. We found it by running a file integrity diff against a clean WordPress core baseline, then tracing outbound connection attempts in the server access logs to identify the callback timing pattern.
The remediation
Once we identified and isolated the seed file and confirmed the full infection chain, we eradicated every component: the seed, all regenerated payload files, and every database row the malware had injected. The database cleanup alone involved removing over 115 spam posts and SEO-poisoning entries — fabricated content with keyword-stuffed links to third-party sites — that had been silently published to the site and indexed by Google. We then rotated every credential that could have been touched: WordPress admin accounts, FTP/SFTP credentials, the database user password, and any API keys stored in configuration files. File permissions were locked down across the entire server directory to prevent world-writable paths that the dropper had relied on. We also locked down the WordPress admin login path and removed any inactive accounts that could have served as re-entry points.
What we hardened so it can't come back
Eradication without hardening just resets the clock. After cleanup, we deployed a web application firewall with rules targeting the specific request patterns used in this attack class, enabled login lockout with progressive delays and IP-based blocking after repeated failures, and configured file integrity monitoring to alert on any unexpected changes to core files. Scheduled automated scans were set up at the hosting level, separate from WordPress, so a compromised plugin or theme can't disable them. Finally, we wrote a plain-language incident runbook for the client's team: what to check monthly, what warning signs to watch for, and exactly who to call first if anything suspicious recurs. They received a full written incident report along with a 30-day follow-up scan confirming the site remained clean.
Site hacked?
Book an incident response call and we'll assess the damage within one business day.