Stopping Ransomware from Killing the Backups

What it stops This control prevents a total loss of business data during ransomware deployment. Attackers target backup catalogues and shadow copies first to eliminate recovery options. They use techniques like T1490 and T1486 to ensure payment is the only path forward. Immutable, offline backups stop this specific sequence. They ensure that once a backup is written, it cannot be modified or deleted for a set period. This remains true even if the attacker gains full domain administrator privileges. The business avoids the scenario where the only remaining copy of the data exists on an encrypted disk and a locked-down backup server. It stops the attacker from winning the war of attrition.

What it does not stop It does not prevent data exfiltration. A threat actor can steal the entire customer database before triggering the encryption routine. Immutability ensures the data is there, but it does not ensure the data stays private. This control also fails to protect against a slow-burn attack. If an attacker encrypts files gradually over several weeks, the backup system faithfully archives these encrypted blocks. The result is a very reliable archive of useless data. It provides no protection against the initial breach or the lateral movement across the network. It does not stop the spread of ransomware to reachable systems via segmentation failures. Finally, it does not solve the problem of downtime. Having a backup is not the same as having an operational business.

What it looks like when it is working Audit logs from the storage layer show denied requests to delete volumes or modify retention policies. These denials occur even when the request comes from a high-privileged service account. There is a physical or logical gap that requires manual, out-of-band intervention to bridge. Restore tests happen on a strict schedule and are documented with timestamps. The recovery process does not depend on the identity provider or the DNS servers that were just encrypted in the production environment. It looks like a recovery plan that assumes the entire primary site is a crime scene. The restore speed aligns with the recovery time objectives defined in the business continuity plan, rather than the optimistic figures found in a vendor brochure.

How to prove it Select one critical file server containing at least 500 gigabytes of data. Perform a full restore of this server to an isolated VLAN that has no connectivity to the primary production network. This must be done using only the offline media or the immutable vault. The operator must not use any management console that shares credentials with the compromised domain. The test passes if 100 percent of the sampled files are readable and the entire process completes in under 12 hours. Record the start time, the completion time, and the SHA-256 hashes of ten random files to verify they match the original production source. This proves the data is intact and the recovery window is realistic.