Designing Backup Systems for an Adversary That Knows Your Playbook

Why traditional backup strategies fail against modern ransomware — and how to design recovery systems that assume the attacker already understands your environment.

Ransomware backup architecture fails the moment you design it for accidental failure instead of adversarial intent.

Assume the attacker has your runbooks.

Not as a theoretical exercise. As an operational reality. Modern ransomware groups are not opportunistic. They are deliberate. They conduct reconnaissance that lasts weeks. They map your environment before they touch it. They identify your backup infrastructure, your recovery dependencies, your administrative credentials, and your retention policies — before they encrypt a single file.

They are not trying to destroy your data. They are trying to make recovery impossible.

That distinction matters more than anything else in this post.

Your backup strategy was designed around a failure model: hardware fails, data is lost, you restore from backup. That model assumes the threat is accidental. Ransomware is not accidental. Ransomware assumes recovery. It attacks the recovery path first, the data second.

The attacker reads your runbook. Then they rewrite the ending.

Flip The Lens — Your Architecture Through Their Eyes

Now look at your backup architecture the way an attacker does.

They are not looking for data. They are looking for control points. The questions they ask are not “where is the data?” but “where is the recovery path?” and “what do I need to disable to make restoration impossible?”

Walk through your environment with that lens:

Where does your backup orchestration live? If the answer is a management server with domain admin credentials, an attacker who compromises that server owns your recovery before you know you have an incident.

How are your snapshots protected? If they exist in the same identity plane as your production environment, snapshot deletion is a single API call away. Retention policies that can be modified by a compromised account are not retention policies — they are suggestions.

What does “air-gapped” actually mean in your environment? If your air-gapped backup target is reachable via network, reachable via identity, or reachable via API — it is not air-gapped. It is a backup with extra steps.

Where does your recovery runbook live? If it lives in a wiki that uses the same SSO as your production environment, an attacker with domain access has read your recovery documentation. Your predictable recovery steps become their attack sequencing guide.

What enforces your immutability? If the storage layer is immutable but the management layer is not, immutability is enforced at exactly the layer the attacker will bypass.

This is the game. Information asymmetry. Move sequencing. Control of recovery paths.

The thesis is simple and uncomfortable:

Backup strategies assume failure. Ransomware assumes recovery.

The Six Predictable Attacker Moves

Modern ransomware operations follow a playbook that is well-documented because it works. These are not edge cases. They are standard operating procedure.

1. Backup Control Plane Compromise

Encryption is not the first move. Control plane compromise is.

Attackers target backup orchestration systems specifically because owning the backup system means owning recovery. Admin credentials, API tokens, service accounts — any of these provide the ability to alter backup policies, disable jobs, or destroy catalogs silently. By the time encryption runs, the recovery path has already been severed.

This is the first failure mode any serious ransomware backup architecture must account for — and most don’t. If your backup admin credentials share an identity plane with your domain admin credentials, your backup system is one credential compromise away from being owned.

2. Pre-Encryption Snapshot Destruction

Sophisticated ransomware does not encrypt immediately after gaining access. It waits. It maps the environment. It identifies snapshot schedules and retention windows. Then it destroys snapshots before triggering encryption — ensuring that by the time the attack is visible, the recovery points are gone.

Delayed detonation attacks are specifically designed around this pattern: establish persistence, wait for retention windows to expire, then encrypt. Your 30-day retention policy becomes their 31-day patience exercise. The immutable backup deep dive covers exactly which retention lock implementations are resistant to this pattern — and which aren’t.

3. The Air Gap Illusion

Air gaps are one of the most misunderstood concepts in backup architecture. An air gap is not a network segment. It is not a VLAN. It is not a backup target that “isn’t normally connected.”

A true air gap means: not reachable via network, not reachable via identity, not reachable via API, not reachable via any automated process. The moment your “air-gapped” backup can be reached by anything your compromised environment can reach — it is not air-gapped.

Connected air gaps are theater. They provide the compliance checkbox without the protection. Attackers know this. They specifically look for backup targets that appear isolated but remain reachable through identity or management plane access.

4. Runbook Intelligence Leak

Your recovery runbook is a document that describes, step by step, exactly how you will respond to a ransomware attack. It names your backup systems, your recovery sequence, your escalation contacts, and your dependencies.

If that document is accessible to anyone with domain credentials — and most are — an attacker with persistence in your environment has read it. Your predictable recovery steps become their attack sequencing guide. They know which systems you will try to restore first, which dependencies those systems have, and which steps they can disrupt to maximize recovery time.

5. Immutability Bypass via Management Plane

Object-level immutability is a real protection. WORM storage genuinely prevents file modification at the storage layer. But immutability is enforced somewhere — by a management system, an API, a policy engine. Attackers do not attack the immutable storage. They attack the system that manages the immutability.

If your immutability policy can be modified by a compromised admin account, your immutability is enforced at exactly the layer that is most exposed. The storage layer is hardened. The management layer is the attack surface. This distinction is exactly why platform selection matters in sovereign environments — the question isn’t whether your storage is immutable, it’s whether your management plane can be reached.

6. Recovery Path Disruption

This is the most underestimated attack vector in ransomware backup architecture — and the one that elevates this conversation from backup design to recovery system design.

Even if your backups are intact, recovery can be made impossible. Identity systems unavailable — you cannot authenticate to restore. DNS broken — you cannot resolve the systems you are restoring to. Orchestration layer compromised — you cannot execute the recovery workflow. No clean environment to restore into — even perfect backups cannot be recovered without a functional target.

Attackers increasingly target recovery dependencies specifically because organizations have hardened backup storage but left recovery infrastructure exposed. Your backups survive. Your ability to use them does not. And if your database backups aren’t application-consistent, you may restore successfully and still find your databases in an unrecoverable state.

The Architectural Assumption That Gets You Killed

Most backup architectures are built on assumptions that ransomware specifically invalidates:

Designing For The Adversary

Adversarial resilience is not a feature you add to your backup architecture. It is the design constraint you build from.

The architectural response to each attacker move:

Against control plane compromise: Separate the identity plane of your backup infrastructure from your production environment. Backup admin accounts should not exist in the same directory as domain admins. MFA on backup consoles is not optional.

Against pre-encryption snapshot destruction: Immutable snapshots with retention locks enforced at the storage layer, not the management layer. Retention policies that cannot be modified without out-of-band authentication.

Against air gap theater: Define air gap as: not reachable via any path from a compromised production environment. Test this assumption actively — if you can reach the backup target from a compromised host, it is not air-gapped.

Against runbook intelligence leaks: Recovery documentation should not be accessible from production systems. Offline copies. Out-of-band storage. Assume your production wiki is compromised.

Against immutability bypass: The management system that enforces immutability must be as hardened as the storage itself. Separate credentials. Separate identity. Separate network path.

Against recovery path disruption: Test recovery end-to-end in a clean environment regularly — not just restore verification, but full recovery path execution including identity, DNS, and orchestration. If you cannot execute a full recovery drill, you do not know if recovery is possible.

Additional Resources

About The Architect

R.M.

Senior Solutions Architect with 25+ years of experience in HCI, cloud strategy, and data resilience. As the lead behind Rack2Cloud, I focus on lab-verified guidance for complex enterprise transitions. View Credentials →