A backup restore test to run before ransomware does

Before ransomware tests your backups, run three checks yourself: whether anyone can delete them, whether a stolen admin account can reach them, and how long a real restore takes against what the business can tolerate.

The NCSC guidance on mitigating malware and ransomware is blunt. Up-to-date backups are the most effective way of recovering from a ransomware attack, ransomware actively targets them to increase the likelihood of payment, and attackers have destroyed copied files or disrupted recovery before launching the attack. So test the backups the way an attacker would.

Test 1: try to delete your own backup

The examples here use Amazon S3 Object Lock. Elsewhere, find the equivalent immutability or retention lock in your backup product. Check that it is on, what the retention period is, and who can shorten or remove it. Then attempt a permanent delete as an ordinary user, as your most privileged backup administrator, and as an account an attacker would plausibly take over. Record who succeeds.

For S3, work in a scratch bucket. Object Lock works only in buckets with S3 Versioning enabled, so check that first. Use governance mode, which AWS describes as a way to test retention settings before creating a compliance-mode retention period.

Never apply compliance mode in the scratch bucket. In compliance mode the retention mode can't be changed and the period can't be shortened, and the only way to delete a compliance-locked object early is to delete the associated AWS account.

Run these attempts through the console and through the API or CLI, and compare:

The second row is not a failure: the locked version remains, because retention periods do not stop new versions or delete markers being created. The third row is the worry. The S3 console includes the x-amz-bypass-governance-retention:true header by default, so anyone holding that permission can wipe governance-locked objects with a few clicks.

Then send the same permanent delete as that user through the API or CLI without the header. AWS requires it on any request that overrides governance mode, so this should return Access Denied. If it succeeds, check the bucket's retention mode and the lock settings on the object version.

Then audit who can undo the lock

List every principal whose policies allow s3:BypassGovernanceRetention, including roles, groups and inline policies. Do the same for s3:PutObjectLegalHold: a legal hold has no expiry, and any user with that permission can place and remove holds freely.

Remove both permissions from accounts an attacker could plausibly take over. For data you cannot lose, consider compliance mode with a retention period you have chosen deliberately.

Test 2: try to reach the backup with the wrong credentials

Immutable storage does not help if the attacker controls the console that manages it. Try logging in to the backup console and storage with a domain admin, a backup-operator account and a cloud IAM user, and check whether each can delete data or change retention settings.

The NCSC guidance recommends these protections for backup accounts:

• Privileged Access Workstations and hardware firewalls that enforce IP allow listing.
• MFA, with the MFA method not installed on the device used to administer the backups.
• Privileged Access Management, so administrators do not access high-value backup systems directly.

Backup drives and USB sticks should not be permanently connected to your network, and the backup products need patching. With a cloud service, confirm that previous versions are protected from immediate deletion and that you can restore to them, because services often synchronise straight after your files are replaced with encrypted copies.

Test 3: restore something, with a stopwatch

Pick a system the business would miss within a day and restore it from backup to a clean, isolated environment, so a restored infection cannot reach live systems. Write down the elapsed time, who did what, and every point where someone had to hunt for a password, a licence key or a document that lives on the servers you are restoring.

If the restore fails partway, record the step, the elapsed time, the cause and the fix, then restart from that step and log the remaining time separately. Keep the steps identical between runs so results are comparable.

Connect backups only to known clean devices before recovery, and scan them for malware before restoring files. Ransomware may have replicated into backups before it was discovered, so a clean-looking restore point may not be clean.

Compare your measured time with what the business says it can tolerate. Get that number from the system owner before the test, so you are not fitting the target to the result. Full ransomware recovery, if possible at all, can take several weeks, so treat a single-system figure as a floor.

On paper, work out what happens if onsite systems and cloud backup servers are both unusable and you must rebuild from offline backups, and how you would keep critical business services running. Check that playbooks, checklists and contact details exist somewhere you can reach without your computer systems. Our incident response service covers this kind of exercise if you want an outside view.

Where to start

1. Pick one business-critical system and ask its owner how long it can be down. Write the number down first.
2. Create a scratch S3 bucket with versioning and Object Lock in governance mode, never compliance. Attempt a permanent delete and a simple delete, and record the responses.
3. Repeat the permanent delete as a user holding s3:BypassGovernanceRetention, from the console and from the API or CLI without the bypass header. Then list every holder of that permission and of s3:PutObjectLegalHold, and remove those who do not need it.
4. Try to log in to the backup console with a domain admin, a backup operator and a cloud IAM user. Where a login worked, plan MFA on a separate device and IP allow listing. Confirm that an offline copy exists, is not permanently connected, and has been restored from.
5. Restore the chosen system to an isolated environment from a scanned backup, timing every step, and compare the result with the number from step 1.
6. Fix the largest gap, then rerun the tests whenever the backup design changes.