Why Ransomware Attackers Go After Your Backup First
By the time a ransom note appears on a screen, the most consequential decision in the attack has already been made, and it was not made by you. It was made days or weeks earlier, when the attacker went looking for your backups.
Linda Moss, Founder and CEO
By the time a ransom note appears on a screen, the most consequential decision in the attack has already been made, and it was not made by you. It was made days or weeks earlier, when the attacker went looking for your backups.
That sequencing is not incidental. It is the entire point.
The ransom is priced against your recovery options
A ransom demand is a negotiation, and every negotiation is shaped by what the other side believes you can do without them. An organization that can restore from a clean copy has an alternative. An organization that cannot has only one path back.
Attackers understand this precisely, and the pricing reflects it. Sophos research into backup compromise found that the median ransom demand for organizations whose backups had been compromised was 2.3 million dollars, compared with 1 million dollars for organizations whose backups were intact. Those with compromised backups were also nearly twice as likely to pay, 67 percent versus 36 percent.
The attacker is not guessing at that number. They looked.
It is a documented technique, not opportunism
The behavior has a name in the MITRE ATT&CK framework: T1490, Inhibit System Recovery, categorized under Impact. The technique description is specific about how it is carried out, and it reads like a checklist of everything most organizations rely on to recover.
On Windows hosts, native utilities do most of the work. vssadmin deletes volume shadow copies. wbadmin deletes the backup catalog, which is a subtle and effective move because the backup data itself may survive while the system that knows how to find it does not. bcdedit disables automatic recovery features by modifying boot configuration data.
On virtualized infrastructure, adversaries delete or encrypt virtual machine snapshots so they cannot serve as a fallback. In cloud environments, they disable versioning and backup policies and delete snapshots, database backups, machine images, and prior object versions. On network devices, they can wipe backup firmware images and reformat the file system, then force a reload.
None of this is exotic. It is standard operating procedure, executed with tools that are already present and already trusted.
How they find the backup infrastructure
Backup systems are unusually easy to locate once an attacker has a foothold, because everything about their design makes them discoverable.
They are joined to the same directory service as everything else. They run service accounts with elevated privileges, because taking a full backup requires reading everything. Agents installed across the estate advertise the address of the backup server. Management consoles are reachable from the same administrative network as every other console. Runbooks and documentation describe the topology, and they are usually stored on a file share.
Add to this the finding in the Sophos State of Ransomware 2026 report that 79 percent of ransomware attacks began with an identity-based approach, most often a stolen or misused credential. If the recovery infrastructure trusts the same identity system as production, then a compromised credential does not just open the door to your data. It opens the door to the copy you were counting on.
Why the usual protections do not always hold
Most organizations do have controls in place. The question is whether those controls survive an attacker who already holds administrative credentials.
Software enforced immutability. Retention locks and immutability flags are effective against accidental deletion and against unprivileged attackers. When the enforcement lives in software that an administrator can reach, an attacker holding those credentials can often reach it too. The relevant question is not whether immutability is configured, but what would have to be true for someone to turn it off.
Snapshots on the same storage. A snapshot is a recovery point, not a separate copy. If it lives on the array that holds production, it shares the array's fate.
Replication described as offsite. Geographic distance is not isolation. A second site reachable over the network is inside the same blast radius as the first. What matters is reachability, not mileage.
Cloud object lock in the wrong mode. Some object lock configurations allow privileged users to shorten retention or remove the lock. Others do not permit it under any circumstances, including by the account root. That distinction decides whether the control is a policy or a physical property of the data.
Backup credentials stored in production. A vault, a script, or a password manager that lives inside the domain you are trying to recover from is not available on the day you need it, and it may be available to someone else well before then.
What actually holds
The controls that survive an attacker with credentials share a common trait. They do not depend on the attacker's permissions being insufficient. They depend on the copy being unreachable in the first place.
Physical separation. Media that is not electrically connected to any network cannot be reached by any credential, any script, or any lateral movement. There is no permission model to defeat because there is no path.
Identity separation. Recovery infrastructure that authenticates against a separate source, with separate credentials, is not compromised by the compromise of production identity. This is the control most directly aligned with how attacks actually begin.
Write-once media. Data that physically cannot be overwritten once written removes the question of who is allowed to delete it. Nobody is, including you, including the vendor, including an attacker holding every credential in the environment.
Validation on the way out. Isolation protects the copy. It does not by itself guarantee that what you archived was clean. Scanning content on the way into the archive and again on the way out, with a quarantine step before anything reaches production, is what turns an intact copy into a trusted one. A restore that reintroduces the payload is not a recovery. It is a second incident.
Five questions worth answering this week
If our production identity system were fully compromised, which copy of our data would still be beyond reach, and what specifically makes it unreachable?
Who or what is technically capable of shortening our retention period or removing an immutability flag?
Where are our backup credentials stored, and would they be available if the domain were down?
When we last tested a restore, did we test the full sequence, including locating the data and validating it, or only the read?
Can we restore to a point in time before the intrusion began, rather than before encryption was detected?
What the difference is worth
The Sophos backup compromise analysis put a number on it. Median overall recovery costs came to 3 million dollars for organizations whose backups were compromised, against 375 thousand dollars for those whose backups were not. That is an eight times difference, and it excludes any ransom paid. Recovery speed diverged just as sharply: 26 percent of organizations with compromised backups were fully recovered within a week, compared with 46 percent of those with intact backups.
The gap between those two outcomes is not determined by the quality of your detection or the size of your security budget. It is determined by a decision made long before the attack, about whether your last-resort copy was ever reachable at all.
About the EchoLeaf SafeRoom™
The EchoLeaf SafeRoom™ was built for exactly this problem. It is a physically air-gapped, immutable vault. Once data is written, it cannot be encrypted, altered, or destroyed, and it is not reachable through production credentials or production network paths. Guardian Scan™ inspects content on the way in and again on the way out, and restores land in a quarantine area for inspection before release. That's how you get back to live in hours, not weeks.
If you want to assess your own position, our [Ransomware Recovery Readiness Checklist] walks through thirty specific controls across recovery priorities, copy protection, restore validation, and incident command.
