Incident ResponseDec 15, 2024 2 min read
WordPress Compromise: Containment and Recovery
A site owner told me their WordPress site was "acting up." It was an active compromise. I traced the entry point to a vulnerable file-manager component, removed three separate persistence mechanisms, and had the site back on a clean, patched build in about two and a half hours.
Triage summary
Resolved- Disposition
- True positive, resolved
- Reported by
- Site owner ("the site is acting up")
- Entry point
- elFinder file manager in a plugin, CVE-2021-32682
- Persistence
- Webshells, 3 hidden admin accounts, .htaccess rules
- Time to recovery
- About 2.5 hours
- Data exposure
- No PII exposed
Detection and analysis
- ▸Traced the entry point to CVE-2021-32682, a remote code execution flaw in the elFinder file manager that a plugin on the site bundled.
- ▸Found three persistence mechanisms: webshells dropped into theme files, three hidden administrator accounts, and modified .htaccess rules.
- ▸Scoped the impact to the web application. I found no evidence that personal data was accessed or taken.
Containment
- ▸Blocked admin access and disabled the unauthorized accounts.
- ▸Captured copies of the malicious files before deleting anything, so the evidence survived the cleanup.
Eradication and recovery
- ▸Removed the webshells and reverted the .htaccess changes.
- ▸Restored from a clean pre-compromise backup, patched the vulnerable plugin, and reset every credential.
- ▸Added basic monitoring and file-integrity checking so a repeat would be noticed.
Impact
Left in place, the backdoors would have given the attacker ongoing access to the site: enough to disrupt the owner’s operations for months and put the site’s users at risk.
Lessons learned
Treat "the site is acting weird" as a possible incident until proven otherwise. The whole compromise hinged on one unpatched component, the least glamorous and most common way in, which is why patching and file-integrity checks were part of the recovery and not an afterthought.