Cleaning changes files, database rows, timestamps, caches and logs. Without a preserved snapshot, you may remove the visible payload but lose the clues that reveal entry, persistence and affected accounts.
Evidence preservation does not mean leaving visitors exposed. Contain public harm first, then capture the environment before broad replacements or restores.
Record the incident conditions
Create a simple timeline with timezone:
- first report and reporter;
- affected URLs and symptoms;
- redirect or download destinations as text;
- device, referrer and first-visit conditions;
- hosting or scanner alerts;
- recent updates, access changes and deployments;
- containment actions already taken.
Screenshots and response headers are useful. Do not click malicious destinations merely to improve the record.
Contain with the least destructive action
Use a known-clean maintenance response, access restriction or hosting quarantine. Preserve the infected document root behind that boundary.
Avoid updating every plugin, replacing core and clearing all caches before capture. Those steps can overwrite timestamps and remove the initial loader.
If a malicious download or phishing page is active, visitor safety takes priority over a perfect snapshot. Record the emergency action and time.
Preserve files with metadata
Create an archive or filesystem snapshot that retains paths and modification times. Include hidden files such as .htaccess, must-use plugins and files outside the obvious WordPress directory where the account permits.
Generate a manifest of cryptographic hashes:
find /path/to/working-copy -type f -print0
| sort -z
| xargs -0 sha256sum > wordpress-files.sha256Run commands only on an authorised offline or quarantined copy. Paths containing untrusted filenames require careful null-delimited handling as shown. Store the manifest beside, not inside, the source tree.
Export the database consistently
Use the hosting backup tool, snapshot or a database dump method appropriate to the server. Preserve table names, charset and timestamp.
Encrypt the export at rest and restrict access. It can contain users, customer data, form entries, sessions and malicious scripts.
Do not upload the database to a public file-sharing link or paste suspicious option values into a ticket.
Collect relevant logs before rotation
Preserve available web access/error logs, PHP logs, authentication history, WordPress security logs, FTP/SFTP activity, hosting-panel events and CDN/firewall logs.
Log retention may be short, so capture them early. Note each source’s timezone and whether the log is complete.
Do not expand logging to capture passwords, cookies, payment data or request bodies. Existing metadata is usually enough to trace access and file changes.
Record accounts and scheduled persistence
Export or screenshot authorised lists of WordPress users, administrators, application passwords, hosting/SFTP accounts, cron entries, active plugins and must-use plugins.
For WooCommerce, record relevant scheduled queues without exposing customer payloads. Do not delete unfamiliar jobs until ownership is established.
Preserve DNS, redirect and CDN worker/rule configurations. Malware persistence can sit outside WordPress.
Protect the evidence copy
Keep an untouched original and perform investigation on a duplicate. Store both outside a web-accessible folder with least-privilege access.
Record who collected the copy, when, source and later transfers. Formal chain-of-custody requirements depend on legal context, but basic handling records still prevent confusion.
Set a retention and secure-deletion decision with the site owner because the copy may contain personal data and malware.
Begin cleanup from verified sources
With evidence preserved, compare WordPress core to the matching official release, replace trusted packages, manually review custom code, inspect the database and close the entry route.
Track every removed, replaced or changed item and keep rollback points. A clean scanner result is only one verification signal.
When expert evidence handling matters
Request specialist help before modification when the incident involves checkout injection, personal-data exposure, several sites, law enforcement, insurance or repeated reinfection. Send symptoms and public URLs first—not the archive or passwords.
A sound cleanup begins with enough evidence to explain what happened and ends with proof that the payload and its return path are gone.