A backup is a historical copy, not proof of a clean site. It can include dormant backdoors, vulnerable versions, malicious users and database payloads that were not visible when created.
Restore first into an isolated analysis environment with outbound effects disabled.
Verify archive source and integrity
Record creation time, backup product/provider, included files/databases and original checksum where available. Hash the received archive and keep an untouched encrypted copy.
Do not extract an untrusted archive directly into a public document root. Malicious paths or symlinks can write outside the intended folder.
Use a disposable restricted environment and inspect archive listings before extraction.
Isolate execution and outbound traffic
Do not expose the restored WordPress publicly or allow it to send email, webhooks, payments or scheduled remote calls.
Use fake/sandbox credentials and a controlled hosts entry where visual review is needed. Avoid logging into real external services from the environment.
Keep the database and files accessible only to investigators.
Inventory versions and components
Identify WordPress core, plugins, themes, must-use plugins and custom code. Compare trusted packages with exact verified sources and note unsupported/vulnerable versions.
Do not update everything before comparison; that destroys evidence of what existed. Preserve differences, then build a separate patched candidate.
Check unknown plugin directories and files outside standard WordPress paths.
Review executable and changed files
Search uploads, caches and temporary directories for PHP-like extensions. Rank recent/unusual modifications and compare core checksums.
Inspect .htaccess, wp-config.php, root loaders and PHP prepend settings. Analyse suspicious files statically without executing or uploading them publicly.
Hash confirmed indicators for comparison with the live incident.
Check archive paths and links before extraction
List archive entries and reject absolute paths, ../ traversal and symlinks that resolve outside the designated analysis directory. Extract as a non-privileged user into an empty disposable location.
Confirm the resolved destination remains inside that location before moving or deleting anything. A normal backup can also contain hard links, huge sparse files or nested archives that exhaust storage.
Set explicit resource limits and inspect nested packages separately. This protects the analysis host without modifying the evidence archive.
Inspect the database
Review administrators, application passwords, cron, options, posts/widgets, spam URLs and script domains. Use WordPress-aware tools to preserve serialised data.
Search exact incident indicators and establish the owner of suspicious options/tables. Protect customer/order/form data in the dump.
Do not run broad string replacements.
Rebuild a restoration candidate
Install current supported core/plugins/themes from verified sources, manually migrate reviewed custom code and clean exact database records.
Rotate salts/secrets for the new environment and patch the entry route. Remove abandoned components and scheduled persistence.
Keep the candidate separate from the evidence backup.
Test business and recurrence conditions
Test public pages, languages, forms, search and authorised WooCommerce sandbox flows. Trigger normal cron, cache regeneration and deployments.
Repeat the original malware conditions and monitor files/users/options beyond the historical recurrence interval.
Check media files and documents that scanners often treat as passive. PDFs, SVGs, archives and office documents can contain scripts, links or embedded content. Preserve originals, compare business ownership and serve only reviewed types with accurate content headers.
Do not convert or open suspicious documents on the analyst’s normal workstation. Use the organisation’s isolated document-analysis process.
Restore with a rollback plan
Snapshot production, contain the infected site and deploy the clean candidate through a controlled process. Verify public origin, CDN, email and integrations before full reopening.
Request help when the archive source is uncertain, database contains payloads or several sites share it. Send metadata and hashes, not the backup.
A safe restoration promotes a reviewed clean build, never the unexamined historical archive.