Example: a verification record for restoring a hacked WordPress site

What this example is

This is a synthetic worked example for the invented site larkbakery.example. No site was restored, and no customer or result is claimed. It shows the structure of the record that a restore should return, so you can judge whether a proposal will give you evidence or only a promise. Command output below is illustrative and the exact wording differs between versions.

Timeline and backup choice

The backup chosen is the newest one older than the earliest evidence, and the record says what that evidence was and where it came from.

• Earliest evidence: a host notice dated 14 September, which reports a file changed on 12 September.
• Backups: 1, 8 and 15 September. The 8 September backup is chosen.
• Content changed since 8 September is listed from the snapshot so the owner can decide what to re-enter.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

backup date   older than first evidence (12 Sep)?   chosen
1 Sep         yes                                    no (older than needed, more content lost)
8 Sep         yes                                    YES
15 Sep        no                                     no

Checksum verification and files that do not belong

Core files are compared with the checksums WordPress.org publishes. Plugins hosted there are compared the same way. Anything that cannot be compared is listed with its source, and PHP files that do not belong in the uploads folder or the site root are listed. A passing checksum shows that listed files are unchanged. It does not show that no extra file exists, which is why the second list exists.

• Core: all listed files match, checked with the root-folder option.
• The snapshot of the compromised site is searched too, to show what the attacker left; the restored copy is then searched the same way.
• Plugin A and plugin B from WordPress.org: match.
• Plugin C, a paid plugin: cannot be checked; source and version recorded.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

core:        verifies against checksums for the installed version and language
plugin A:    matches
plugin B:    matches
plugin C:    not hosted on WordPress.org - cannot be checked (source: vendor download, version 4.2)
snapshot of compromised site:  uploads/2026/09/cache.php  -> a PHP file that belongs to no plugin or theme; not carried into the restored copy
restored copy (8 Sep backup):  no PHP files in uploads/, none outside plugins, themes and core

Administrators and the credential reset list

The owner marks each administrator as expected or removed, and completes the reset list. The reset list names the credentials, not their values, and the owner does the resets so the service never holds them.

• Administrators in the snapshot: three. The restored copy, taken from the 8 September backup, has two, both marked expected by the owner; the third was created on 12 September and is not carried across.
• Reset by the owner: host panel, database, file transfer, every WordPress user, and the site's secret keys.
• Updates applied after the restore, and the dashboard code editor switched off.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

administrator   created       owner decision (restored copy)
site-owner      2022-03-10    expected
bookkeeper      2024-06-02    expected
temp-support    2026-09-12    unknown - in the snapshot only, not in the restored copy

credential          reset by owner   date
host panel          yes              2026-09-16
database            yes              2026-09-16
file transfer       yes              2026-09-16
WordPress users     yes              2026-09-16
secret keys         yes              2026-09-16

What this record does not prove

It does not prove the site is free of malware, and it does not say how the attacker got in. It records what was checked, what could not be checked and what the owner decided. A sign-off on this record accepts that evidence, not a certification of security. If customer data may have been taken, the owner takes advice on any legal duties before relying on a restore.