Why Attackers Target Your Backups First
Most organisations treat backups as the last line of defence. The thing you fall back on when everything else has gone wrong. The answer to the ransomware question: “We don’t need to pay, we’ll just restore.”
Attackers know this. And they plan accordingly.
Before a ransomware operator encrypts a single production file, the most sophisticated ones have already spent days, sometimes weeks, inside your network, quietly mapping out where your backups live, how they’re protected, and how to destroy them. By the time the ransom note appears on your screen, your recovery options may already be gone.
This isn’t a niche tactic used by advanced nation-state actors. It’s standard operating procedure for ransomware groups, and it’s the reason organisations with mature backup strategies still end up paying.
Why Backups Are the Target
The economics of ransomware are straightforward. An attacker encrypts your data and demands payment in exchange for the decryption key. The leverage they have over you is directly proportional to how badly you need that key.
If you have clean, tested, recent backups you don’t need the key. You restore, you recover, you carry on. The ransom demand is irrelevant.
Attackers worked this out early. The entire calculus of a ransomware attack changes if the victim can’t recover. Destroying or encrypting backups before triggering the final payload isn’t an optional extra in a modern ransomware operation it’s often the prerequisite that makes everything else viable.
No backups means no choice. You either pay, or you lose the data. For many organisations, losing the data isn’t survivable. So they pay.
How Attackers Find Your Backups
This is where the dwell time matters. Dwell time is the period between an attacker gaining access to your network and you detecting them. Industry figures consistently put this at weeks, sometimes months, for sophisticated intrusions. That’s not an accident attackers deliberately operate slowly and quietly during this phase because they’re doing exactly this kind of reconnaissance.
During dwell time, an attacker with a foothold in your network is exploring. They’re reading emails, browsing file shares, mapping network topology. And they’re looking for your backups.
Backup infrastructure tends to be findable. Backup software agents run on servers and show up in process lists. Backup servers appear in DNS, in Active Directory, in configuration files. Scripts used to automate backup jobs the kind left in an admin’s home directory or a shared scripts folder often contain the hostnames, credentials, and schedules for the entire backup operation. Finding your backup infrastructure from inside your network is, in most cases, not a difficult problem.
Once they’ve found it, they catalogue it. They note what software is in use, where the backup data is stored, whether it’s on-site, off-site, or cloud-based, and crucially whether the backup system shares any credentials or authentication with the rest of the network.
The Attack on the Backups Themselves
With reconnaissance complete, the attacker’s approach to your backups depends on what they’ve found. There are a few common paths.
Deleting or Encrypting Backup Data Directly
If your backup server is accessible from the rest of the network and uses domain credentials for authentication, an attacker who has compromised Active Directory can simply log in. They have the same access your backup administrators do. They can delete backup jobs, wipe backup catalogues, or encrypt the backup data directly all before the ransomware payload runs on production systems.
By the time your operations team discovers the ransomware and goes looking for the backups, there’s nothing there.
Targeting the Backup Application
Backup software is not exempt from vulnerabilities. There have been documented critical vulnerabilities in widely-used enterprise backup platforms unauthenticated remote code execution, authentication bypasses, privilege escalation. Attackers specifically target backup infrastructure because they know how valuable it is as a stepping stone.
A compromised backup server is a particularly bad outcome. Backup servers typically have network access to every machine they protect, often with elevated credentials. Compromising the backup server doesn’t just destroy your recovery capability it can also be a launchpad for deeper network access.
Abusing the Backup Agent
Most enterprise backup solutions work by deploying lightweight agents on every protected server. Those agents communicate back to the backup server and have enough local privilege to read everything on the machine.
If an attacker can interact with or abuse those agents, they can use them as a vector for lateral movement, or simply disable them silently weeks before deploying ransomware. Your backup jobs appear to complete successfully, the monitoring dashboard shows everything green, but no usable data is being captured. You only find out when you try to restore.
Targeting Cloud Backups
Many organisations have moved part or all of their backup infrastructure to cloud storage, which feels inherently safer. Off-site, physically separate, surely harder to reach.
Not necessarily. If your cloud backups authenticate using credentials or API keys that are accessible from your on-premises environment stored in a script, a configuration file, a secrets manager that’s also been compromised an attacker can reach them. Cloud storage buckets with overly permissive access controls, or without versioning and deletion protection enabled, can be wiped or overwritten just as effectively as an on-premises backup server.
The physical separation of cloud backups only protects you if the access controls are genuinely independent of your compromised environment.
A Realistic Scenario
Here’s how this tends to play out in practice.
An attacker gains initial access through a phishing email. They establish persistence on a workstation and spend the next two weeks quietly exploring the network. They compromise a domain admin account through credential dumping from a server.
With domain admin access, they browse Active Directory and identify a server named something like BACKUP01. They log in. It’s running a well-known enterprise backup platform, with a service account that has domain admin privileges common practice for backup software that needs to reach every server on the network.
The attacker checks the backup schedule. Full backups run on Sundays. Today is Thursday. They make a note and do nothing yet.
Over the following days, they map production systems, stage their ransomware payload, and identify the highest-value data stores. On Saturday night, they log back into the backup server and delete all backup catalogues and stored recovery points. They also identify that the organisation uses a cloud storage bucket for off-site copies. The credentials are in a configuration file on the backup server. They connect to the cloud bucket and delete everything there too.
Sunday morning, the scheduled backup job runs and fails but the alerting on backup failures goes to an inbox nobody checks over the weekend.
Sunday night, they detonate the ransomware across the entire estate.
Monday morning, the operations team arrives to find every server encrypted and a ransom note on every screen. They call the backup team. The backup team logs into BACKUP01. There’s nothing there.
The negotiation starts.
What Good Backup Security Looks Like
The good news is that backup security is a solvable problem. It just requires treating backups with the same adversarial mindset you’d apply to any other critical system.
Immutable backups are the most important control. An immutable backup is one that cannot be modified or deleted for a defined period even by administrators, even by the backup software itself, even by someone with full credentials. Major cloud storage providers support object lock policies that enforce this at the storage layer. On-premises solutions increasingly offer similar capabilities. An attacker who compromises your backup server cannot delete an immutable backup, regardless of what credentials they have.
Air-gapped or offline backups take this further. A backup that has no network connection cannot be reached by an attacker who is operating over the network. Traditional tape backups, taken off-site, are genuinely resilient to network-based attacks. They’re slow, they’re inconvenient, and they’re increasingly relevant again.
Separate credentials. Your backup infrastructure should authenticate independently of your main Active Directory domain wherever possible. If compromising domain admin gives an attacker full access to your backup system, you’ve made the attacker’s job significantly easier. Backup service accounts should follow least privilege, and the backup management interface should be accessible only from a restricted network segment.
Test your restores. A backup you’ve never restored from is a backup you don’t actually have. Regular, documented, tested restore exercises are the only way to know your backups work and they’re also how you’d detect a scenario where backup jobs have been silently failing for weeks.
Monitor backup infrastructure. Unusual access to backup servers, failed authentication attempts, changes to backup schedules or retention policies, unexpected deletion events all of these should be generating alerts. Backup systems are often under-monitored because they’re treated as infrastructure rather than security-critical systems. They are both.
Follow the 3-2-1 rule. Three copies of the data, on two different media types, with one copy off-site. It’s a starting point, not a complete strategy, but it addresses the most common failure modes.
Takeaways
Backups are only a safety net if they survive the attack.
- Ransomware groups routinely target backup infrastructure before deploying their payload destroying your recovery options is the point
- Dwell time gives attackers weeks to find and catalogue your backup systems from inside your network
- Backup servers are high-value targets: they often hold privileged credentials and have access to every system they protect
- Cloud backups are not inherently safe if the credentials are accessible from a compromised environment, the backups are reachable
- Immutable backups are the most effective technical control data that cannot be deleted cannot be destroyed by an attacker
- Separate credentials, monitor backup infrastructure, and actually test your restores
If an attacker is already inside your network and you haven’t thought carefully about how your backups are protected, they probably have. The question is whether you’ve made it easy for them.