Emergency changes can overwrite timestamps, rotate logs, invalidate sessions and remove the path that explains reinfection. Preservation does not mean keeping the site dangerous online; it means taking protected snapshots before destructive cleanup.
Collect only what supports scope, recovery and business obligations.
Start an incident timeline
Record first report, last known good time, symptoms, affected URLs, reporter, containment actions and every credential/configuration change. Use one timezone.
Include recent updates, deployments, migrations, new users and provider alerts. Separate observed facts from assumptions.
Do not paste customer submissions, payment data or passwords into the timeline.
Preserve host and application logs
Request web access/error, PHP, WordPress audit/security, control-panel, SFTP/SSH, mail and scheduled-task logs. Record source, timezone and retention window.
Export them to protected storage before rotation. Keep original copies read-only where the incident process supports it.
Redact only copies used for collaboration; preserve evidential integrity of controlled originals.
Snapshot files and configuration
Create a filesystem archive or provider snapshot that includes hidden files, server rules, must-use plugins and relevant configuration outside the visible WordPress root.
Record WordPress/PHP versions, document root, ownership/permissions and recently changed-file listing. Do not store the archive in public_html or send it by email.
Identify the snapshot with date, source and a checksum where practical.
Snapshot the database
Export the correct database before deleting users, options or injected content. Record database name, table prefix, multisite status and export method.
Protect it as sensitive because it can contain accounts, orders, entries and personal data. Limit access and retention according to organisational requirements.
Do not run broad search-and-replace on the only copy.
Record privileged access
List WordPress administrators, application passwords, active sessions where available, hosting users, SSH/SFTP keys, database users, DNS/CDN users and primary email administrators.
Capture unknown identifiers and creation/change times before revocation. Never copy password hashes or private keys into the incident report.
Document each rotated credential without recording the new secret.
Preserve scheduled and outbound activity
Record WordPress cron, Action Scheduler, server cron, mail queue, recent outbound provider events and unexpected network activity. Malicious persistence often lives outside normal page requests.
Keep representative job/queue IDs and scripts paths. Do not bulk-delete queues before distinguishing spam from legitimate order or lead messages.
Contain ongoing abuse after the snapshot.
Capture DNS, CDN and redirect state
Export authoritative DNS records, nameservers, Cloudflare workers/rules, redirects, API tokens/users and relevant audit events. Record origin addresses privately.
An incident may persist at DNS/CDN even after a clean WordPress rebuild. Do not publish origin IPs or account screenshots.
Keep before/after copies of every control-plane change.
Document business impact
List affected checkouts, orders, leads, account access, downloads, email and visible redirects. Record incident window and which system remains authoritative for reconciliation.
If customer or payment data may be affected, escalate to the organisation’s legal/privacy/payment incident process. Technical cleanup does not replace required assessment or notification.
Avoid claiming data was or was not accessed without evidence.
Record who collected, copied and accessed each evidence package. Even when formal forensic standards are not required, a simple custody log prevents confusion between originals and working copies.
Create a clean recovery inventory
List trusted sources for WordPress core, plugins, themes, custom code and known-good backups. Note licences and owners without copying keys into the evidence package.
Define what can be rebuilt, what content must be inspected and what secrets require rotation. Keep the infected snapshot separate from the new document root.
Request emergency repair before evidence disappears when logs are short-lived or several systems are involved. Share a redacted inventory and managed access—never public archives, database dumps, credentials or malicious payloads.