Methodology
How we investigate and clean up WordPress incidents
We capture the baseline state first, contain the active incident, then systematically review files, database, accounts, and scheduled tasks. Detected malware and persistence mechanisms are removed, integrity is checked against vendor checksums where available, and the site is functionally tested at the end. Every step is documented in the final report.
Our step-by-step approach
This sequence protects evidence from accidental alteration and prevents a site from being handed back without final verification.
- Before any change: back up and capture the baseline state, so the original condition stays provable.
- Containment: stop active damage without prematurely destroying evidence.
- File review: diff against known-clean sources, look for injected or altered files.
- Database review: search for injected content, suspicious options, and tampered tables.
- Account review: check administrators, user roles, sessions, and application passwords.
- Cron and scheduler review: examine scheduled tasks for persistence mechanisms.
- Removal of malware, webshells, and known persistence mechanisms.
- Checksum / integrity verification against vendor data, where available.
- Functional testing: verify frontend, login, REST endpoints, and core functions after cleanup.
Sample incident report
Every completed case is documented in a plain-language report. Every report includes these sections:
- Management summary
- Incident timeline
- Indicators of compromise
- Affected components
- Preserved evidence
- Actions taken
- Account and secret rotation
- Checksums and functional tests
- Data-exfiltration indicators
- Remaining risks
- Recommended monitoring
Example of the timeline in a final report. The displayed data is fictional:
- T+0hbackup.createdbaseline captured
- T+1hcontainedactive damage stopped
- T+—malware.removedpersistence removed
- T+—report.delivered✓ final report
Anonymized sample report
Active incident? We assess it for free.