Immutable Backups Are Not Enough: Testing Ransomware Recovery Before You Need It

Most organisations that lose data to ransomware had backups. The backups existed, ran on schedule and reported success. What failed was recovery: the backup catalog was encrypted, the restore took longer than the business could tolerate, or the restore point contained the malware and reintroduced it. Immutability addresses one of those failures, not all of them.

Why the reader needs this

Ransomware operators now target backup infrastructure deliberately, because backups are the control that removes their leverage. They look for the backup server's management interface, the credentials stored in the backup agent, and the catalog that maps restore points to systems. A backup that is immutable but whose catalog is not still leaves you unable to restore with confidence. The question worth answering before an incident is not "do we have backups" but "can we restore a known-good state, in the required time, without reintroducing the attacker".

Technical context: the four failure modes

Recovery failures cluster into four categories, and each needs a different control:

• Catalog and control plane loss. The data is intact but the index that describes it is gone. Immutability on the data repository does not protect a separate management database.
• Credential compromise. The backup agent runs with an account that can delete or modify restore points. If that account is compromised, immutability configured at the wrong layer does not help.
• Recovery time. Restoring a petabyte over a shared link takes as long as it takes. A recovery time objective that has never been tested is an assumption, not a plan.
• Reinfection. Restoring an image that already contained the foothold, or restoring into a network where the attacker still has access, repeats the incident. Immutability, typically implemented as object lock or write-once storage with a retention period, addresses deliberate deletion and modification. It does not address the other three, and treating it as a complete answer is a common and expensive mistake. ## A concrete failure chain This chain reflects publicly documented ransomware behaviour against backup systems, presented as a reasoning model rather than a specific victim report.
• The attacker gains administrative access to the virtualisation or endpoint management layer.
• They locate the backup server and its management console, which is reachable from the compromised network segment.
• They use the backup service account, whose credentials were stored on a system they already control, to delete or corrupt restore points outside the immutable retention window.
• They encrypt production systems.
• The victim attempts recovery and discovers that the available restore points are older than the immutability window, or that the catalog no longer resolves. The immutability control worked exactly as designed. The retention window was simply shorter than the dwell time, and the management plane was not protected to the same standard as the data. ## Defensive implications Test a restore, not a backup job. A quarterly exercise that restores a representative system into an isolated environment and measures the elapsed time produces evidence. A green backup dashboard produces confidence. Protect the control plane like the data. The backup catalog, management console and agent credentials need the same isolation as the repository. Put the management interface on a separate network segment and require separate credentials. Set retention longer than realistic dwell time. If an intrusion can go undetected for weeks, a fourteen-day immutable window may not contain a clean restore point. Align the window with your detection capability, not with storage cost alone. Use separate credentials and separate trust. The account that writes backups should not be the account that can delete them. Where the platform supports it, use a separate administrative boundary for deletion, ideally with a manual approval step. Restore into a clean environment. Validate the restored system for indicators of compromise before reconnecting it to production. Assume the restore point may contain the foothold. Rehearse the decision, not just the technology. Someone has to decide which systems come back first and what data loss is acceptable. That decision is easier to make in a planning meeting than at 3 a.m. during an incident. ## Limits of this analysis Immutable storage costs more than mutable storage, and long retention windows multiply that cost. Full recovery testing is disruptive and requires spare capacity that many environments do not have. Isolated recovery environments add operational complexity. None of these constraints change the underlying point: the value of a backup is realised at restore time, and until a restore has been performed and timed, the recovery objective is a hypothesis. ## References
• CISA, "#StopRansomware Guide": https://www.cisa.gov/stopransomware/ransomware-guide
• CISA and partners, "Data Backup Options" fact sheet within the StopRansomware resources: https://www.cisa.gov/stopransomware
• NIST SP 800-209, Security Guidelines for Storage Infrastructure: https://csrc.nist.gov/pubs/sp/800/209/final
• NIST SP 800-184, Guide for Cybersecurity Event Recovery: https://csrc.nist.gov/pubs/sp/800/184/final