Ransomware attacks have been a fixture of the threat landscape for over a decade, but the past few years have seen a significant evolution in tactics. Modern ransomware operators don't just encrypt data — they exfiltrate it first, spend weeks moving laterally through the network before triggering encryption, and specifically target backup infrastructure to eliminate the recovery option.
This means that the organizations most likely to pay a ransom are those whose backup strategy was designed for hardware failures, not for an adversary who has specifically compromised those backups before triggering the attack. Building resilience means designing your backup and recovery architecture with this threat model in mind.
The Modern Ransomware Threat Model
Understanding what you're defending against matters before designing defenses. Modern ransomware groups (LockBit, BlackCat/ALPHV, Cl0p, and their successors) typically follow a pattern:
- Initial access: Phishing, exposed RDP, VPN vulnerabilities, or supply chain compromise
- Reconnaissance and lateral movement: Weeks or months of low-and-slow network traversal using legitimate admin tools
- Privilege escalation: Domain admin credentials obtained to enable full network control
- Data exfiltration: Sensitive data staged and stolen before encryption begins
- Backup destruction: Shadow copies deleted, backup servers encrypted or corrupted
- Encryption: Mass encryption of the environment
The sequence matters. By the time encryption happens, the attacker has already been in the network for an extended period and has specifically addressed your recovery options.
The 3-2-1-1-0 Backup Rule
The classic 3-2-1 rule (3 copies, 2 different media types, 1 offsite) was designed for hardware failure scenarios. The modern extension is 3-2-1-1-0:
- 3 copies of data
- 2 different storage media types
- 1 copy offsite
- 1 copy air-gapped or immutable
- 0 errors on verified restore tests
The critical additions are the immutable/air-gapped copy and the verified restore requirement. An immutable backup — one that cannot be modified or deleted, even by an admin with credentials — is the specific control that breaks the ransomware backup-destruction attack chain.
"An untested backup is not a backup. It's a hypothesis. The only way to know your recovery works is to recover — not to look at backup job success logs."
Immutable Backup Implementation Options
Several approaches to immutable backup exist, each with different cost and complexity profiles:
Object storage with object lock
Cloud object storage services (AWS S3 Object Lock, Azure Blob immutable storage) allow you to set a retention period during which objects cannot be modified or deleted, even by the storage account owner. This is the simplest and most cost-effective implementation for most organizations. The immutability is enforced at the storage service layer, outside the control of your on-premises infrastructure.
Tape-based air-gap
Physical tape that is ejected from the tape library and stored offline is immune to network-based attacks by definition. The tradeoff is recovery time — restoring from tape is slow, and the logistics of managing tape rotation require operational discipline. For organizations with strict RTO requirements, tape alone is insufficient for time-sensitive systems.
Purpose-built backup appliances with WORM
Dedicated backup appliances from vendors like Dell EMC PowerProtect and HPE StoreOnce offer Write Once Read Many (WORM) storage with retention lock. These are more expensive than cloud object storage but offer faster restore performance for local recovery scenarios.
Backup Segmentation
Backup infrastructure should be on a separate network segment, managed through separate credentials, and not accessible from the production domain. An attacker who has compromised domain admin credentials in your production environment should not be able to reach your backup infrastructure with those same credentials.
In practice: dedicated backup management accounts that exist only in the backup system, network segmentation via VLAN with firewall rules restricting access to backup servers, and multi-factor authentication on backup management consoles — even for internal access.
Recovery Time and Recovery Point Objectives
RTO (how long it takes to restore) and RPO (how much data you can afford to lose) should be defined per system tier, not as a blanket organizational metric. The core banking system has different requirements than the HR document management system. When ransomware hits, you need to know — before the incident, not during it — which systems to restore first and in what order.
This prioritization should be tested. A tabletop exercise is the minimum; an actual restore test from the immutable backup copy is better. Many organizations discover during a tabletop that their recovery order sequence creates dependency conflicts — the database server needs to come back before the application server, but the application server is tier 1 and the database is tier 2 in the existing plan.
Incident Response Preparation
When ransomware detonates, the first hour matters enormously. Organizations that have a documented, pre-approved decision framework for that first hour — who authorizes isolation, who communicates with the board, who contacts external IR support — recover faster than those making those decisions under pressure for the first time.
Maintain your IR retainer documentation offline. When your systems are encrypted, you don't want to discover that the IR firm's contact information is only accessible through the encrypted systems.
Key Takeaways
- Modern ransomware specifically targets backup infrastructure — your backup architecture must account for this
- Implement immutable backups (cloud object lock, WORM appliances, or air-gapped tape)
- Backup infrastructure needs separate credentials and network segmentation from production
- Define and test RTO/RPO per system tier, not as a blanket metric
- Run actual restore tests, not just backup job verification — test from the immutable copy specifically
- Keep IR contact information and runbooks accessible offline