If the attempt to compromise your backups succeeds, negotiation leverage shifts entirely to the attacker. If it fails, the incident becomes a restore exercise instead of a payment decision.
Every modern ransomware playbook now includes a step that has nothing to do with encrypting your production data: find the backups first, and destroy or encrypt them before the ransom note ever appears. If that step succeeds, negotiation leverage shifts entirely to the attacker. If it fails, the incident becomes a restore exercise instead of a payment decision. The difference between those two outcomes is decided months before the attack, in how the backup storage layer was architected.
This is not a new tactic, but it has become the default one. Backup-aware ransomware groups now spend the early, quiet phase of an intrusion, sometimes days or weeks, mapping backup jobs, snapshot schedules, and admin credentials before triggering encryption. For infrastructure teams, that reframes backup storage from an IT hygiene line item into a security control that has to be evaluated with the same rigor as identity and network segmentation.
Encrypting production data alone is a weak extortion position if the victim can restore from an untouched backup in a few hours. Attackers understand this, so their operating model has adapted: reconnaissance now routinely includes backup infrastructure discovery as a distinct phase, using compromised admin or service accounts to enumerate backup servers, snapshot repositories, and any storage target the backup software can reach.
The economics are straightforward from the attacker's side. A victim with clean, isolated backups has a real alternative to paying: restore and rebuild. A victim whose backups were deleted, encrypted, or silently corrupted has no alternative but negotiation. Every dollar an organization spends making its backups untouchable is a dollar it never has to consider paying in ransom, which is why storage architecture decisions made years before an incident end up determining the outcome of that incident.
A typical sequence looks less like a single encryption event and more like a multi-stage operation against the storage layer itself:
Attackers use living-off-the-land tools and stolen credentials to enumerate backup software consoles, scheduled jobs, and connected repositories, often targeting the backup administrator account specifically because it typically has the broadest storage access in the environment.
Where backups sit on the same network segment or share credentials with production, attackers delete retention snapshots, disable replication jobs, or reconfigure retention policies to zero before encryption ever runs. This step is often scripted and takes minutes.
Only after backup infrastructure has been neutralized does the group deploy the encryptor against production systems, frequently paired with data exfiltration for double-extortion leverage even if the victim does manage to restore.
The common thread across all three stages is reachability. If the backup layer is reachable from the same identity plane, network segment, or account as production, it is a target, not a safety net.
Immutability means a written object cannot be modified or deleted, including by an administrator, until a retention period expires. This is the single control that most directly defeats backup-aware ransomware, because it removes deletion and encryption as options against the backup copy even with fully compromised credentials.
Object Lock, the write-once-read-many mechanism available on S3-compatible storage, is now table stakes rather than a premium feature. It is supported natively across hyperscaler object storage and across zero-egress alternatives including Backblaze B2 and Wasabi, both of which apply Object Lock at the bucket or object level with governance or compliance retention modes.
The choice between providers should not hinge on whether Object Lock exists, since it now exists everywhere that matters, but on what it costs to actually use the backup during a real restore. A closer look at how these two zero-egress providers compare on architecture fit is in Wasabi vs. Backblaze: Which Cloud Storage Provider Fits Your Infrastructure?
| Approach | Ransomware Resistance | Egress Cost on Failover | Operational Complexity |
|---|---|---|---|
| Hyperscaler Object Lock (S3, Azure Immutable Blob) | High | Standard pricing | Low |
| Zero-egress object storage with Object Lock (Backblaze B2, Wasabi) | High | None or minimal | Low to medium |
| True air-gapped tape or offline media | Highest | Not applicable | High |
| Logically isolated vault, separate account and credentials | High | Depends on provider | Medium |
True air gaps, offline tape or disk with no network path at all, remain the highest-assurance option and are still standard in regulated environments. For most infrastructure teams, logical isolation is the practical equivalent: a separate cloud account, separate identity provider tenant, and separate credentials with no trust relationship to production. A logically isolated backup target defeats the credential-reuse pattern that makes most backup-targeting attacks succeed in the first place, because there is no single compromised account that reaches both environments.
Immutability solves the security half of the problem. Egress pricing quietly solves, or breaks, the economics of actually using the backup. A restore is not a small file download, it is often the full dataset, and hyperscaler egress pricing was not designed with mass, single-event downloads in mind.
As a planning exercise, restoring 500 TB from standard hyperscaler object storage at roughly $0.08 per GB in egress runs approximately $40,000 in transfer costs alone, before compute, staging, or downtime are counted. Current list pricing should be confirmed against the provider's published rate card at the time this article is published, since egress pricing structures change and some providers have introduced free-egress exceptions for specific scenarios. A broader look at how these charges accumulate across a bill is in Hidden Costs in Cloud Billing: What Your Provider Isn't Telling You.
This is where backup storage strategy and cloud cost strategy converge. Zero-egress providers remove that variable entirely, and it is worth running the actual math for a specific environment rather than estimating. The Cloud Cost Calculator compares real egress and storage costs across providers side by side, which turns disaster recovery planning from a hypothetical into a number a CFO can evaluate against ransom demands and cyber insurance premiums.
The classic 3-2-1 rule, three copies of data, on two different media, with one copy offsite, has been extended in response to ransomware specifically. The current standard adds a fourth and fifth element.
That last element is the one teams skip most often, and it is the one that determines whether an incident response plan survives contact with an actual attack. A backup that has never been test-restored is a hypothesis, not a recovery capability.
Ranked by effort versus risk reduction, the highest-leverage moves for most infrastructure teams are the following.
First, separate backup credentials from production identity entirely. This single change closes the most common attack path and requires no new storage purchase. A structured way to plan that separation is in Zero Trust Architecture: Implementation Guide for Cloud Teams.
Second, enable Object Lock or equivalent immutability on at least one backup copy, with a compliance-mode retention window that no account, including the organization's own administrators, can shorten.
Third, run the egress math for a full-dataset restore against current provider pricing before an incident forces the calculation under pressure.
Fourth, schedule and document an actual test restore on a quarterly cadence, not an annual one, and treat a failed test restore as a security incident, not a maintenance backlog item.
The backup you have never tried to restore is not a safety net. It is an assumption, and ransomware groups are counting on organizations never finding out the difference until it is too late.
Compare AWS, Google Cloud, Azure, and alternatives like Backblaze B2 Discover how much you could save in seconds
