Hacked WordPress site: restore a clean backup or clean in place, and what a restore cannot do

Document first, and do not delete yet

WordPress's guidance for a hacked site begins with writing down what made you suspect it, when you noticed it with the time zone, and any recent changes such as new plugins. That record decides which backup is safe, and it is evidence if you bring in a professional. It also advises taking one more snapshot of the infected site before cleaning, so you have something to refer to if the cleaning goes badly.

• When you first noticed, and what you saw.
• Dates of every backup and where each is stored.
• Any message from the host or a search or browser warning.

Two routes: restore older, or replace and clean

If you have a backup older than the problem, the guidance says you can restore it and move on to finding out how the attacker got in. The alternative is to replace WordPress core, and re-install plugins and themes, with fresh files of the same version, and to go through the wp-content folder with care. The guidance prefers uploading fresh files by file transfer to using the dashboard reinstall, because the dashboard installer tends to overwrite existing files only, while attackers often add new ones. The guidance does not explain how to confirm that a backup is clean, which is the weak point of a restore.

Why a restore alone is not the end

A restore does not close the hole the attacker used, and a backup taken after the compromise can carry it back. The guidance tells you to reset every user's password, with administrators first, and to change the credentials for file transfer, the dashboard, the hosting control panel and the database. It also advises generating new secret keys in the configuration file, which signs out anyone still logged in, changing passwords again once the site is confirmed clean, and scanning your own computer, since a trojan there can capture your logins.

• Reset every credential yourself, and keep the new ones out of email.
• Update everything after the restore.
• Scan the computers used to manage the site.

What a checksum check proves, and what it does not

WP-CLI can verify core files against the checksums WordPress.org publishes. Its documentation says the command runs on the before_wp_load hook and, for security, avoids loading WordPress when verifying checksums; the tool and the site still run on the same host, so a compromised host could still affect what you see. It checks the files in the official list. The page describes comparing files with the official list and, with the --include-root option, warning about items in the root folder that do not belong to WordPress. Do not rely on it to find every unknown file. Search the uploads folder and the rest of wp-content for PHP files that do not belong as a separate step. A matching result shows that listed files are unchanged. It does not show that no extra file exists, and it says nothing about whether the backup you restored from was clean. The plugin version of the command works the same way for plugins WordPress.org hosts; without a strict option, small changes such as to a readme file are not reported, and a plugin that is not on WordPress.org has nothing to compare with, which is our reading of how the data is sourced.

So verification has three parts: checksums for what can be checked, a list of everything that cannot, and a search for files that do not belong, such as PHP files in the uploads folder.

When to stop, and where the paid outcome fits

Stop and take advice if customer or payment data may have been taken, because that can bring legal duties that are yours to decide. Stop if the host says the whole account or server is affected, or if no backup predates the first symptoms. Shops with live orders are outside the fixed scope.

The restore job is a published test price of £295 or more, quoted after we have the timeline, not yet tested with buyers, and payable after sign-off. It rebuilds one single-site WordPress installation from the newest backup dated before the earliest evidence we can find, checks core and plugins hosted on WordPress.org against checksums, lists what cannot be checked, lists unexplained PHP files, reviews administrators with you and gives you a credential reset list. It does not investigate how the attacker got in, we cannot rule out that the compromise began before that evidence, and it does not claim the site is free of malware.