The Last Line of Defense Just Became the First Point of Entry: How Attackers Are Living Inside Your Backup Infrastructure
There's a running joke in security circles that the most dangerous words in IT are "we have backups." For years, that confidence felt justified. Production gets hit, you restore, you move on. The backup was the escape hatch, the safety net, the thing that let you sleep at night.
Except someone forgot to lock the door on that escape hatch. And now attackers are using it as a front porch.
Over the last two years, a growing body of incident response reports, threat intelligence briefings, and breach disclosures have pointed to a quiet but alarming trend: sophisticated threat actors are deliberately bypassing production systems — sometimes entirely — and targeting backup and disaster recovery infrastructure instead. They're not smashing through the front door. They're finding a side entrance that nobody's watching, settling in, and waiting.
Why Backups Are the Perfect Hiding Spot
Think about how your organization treats backup infrastructure. It's usually managed by a separate team — sometimes ops, sometimes a managed service provider. It runs on its own schedule. It's rarely included in red team exercises. Monitoring is lighter. Patching cycles are slower. And because it's not "production," it doesn't get the same love from the security team.
That neglect is exactly what makes it so attractive to attackers.
Backup systems — whether that's Veeam, Commvault, Rubrik, Cohesity, or any of the major cloud-native solutions — are deeply privileged. They have read access to virtually everything in your environment. They authenticate against Active Directory. They touch file servers, databases, virtual machines, and in cloud environments, they're often wired directly into AWS S3 buckets, Azure Blob Storage, or Google Cloud Storage with broad permissions.
For an attacker who's already managed to get a foothold somewhere in your network, pivoting to the backup system isn't a stretch. It's a strategic upgrade.
The Anatomy of a Backup-Focused Attack
Here's how it typically plays out, based on patterns documented in multiple incident response engagements published by firms including Mandiant, CrowdStrike, and Coveware over the past 18 months.
Phase one is initial access — same as always. A phishing email, a vulnerable VPN appliance, a misconfigured RDP endpoint. Nothing novel. The attacker gets a low-privilege foothold and starts enumerating the environment quietly.
Phase two is where it diverges from the classic ransomware playbook. Instead of moving immediately toward domain controllers or crown-jewel databases, the attacker pivots toward backup management consoles. Why? Because those systems often have weaker detection coverage, and compromising them early gives the attacker something invaluable: control over the organization's recovery options.
Once inside the backup infrastructure, the attacker can do several things simultaneously. They can exfiltrate data from backup repositories — which often contain historical snapshots of sensitive information that's already been rotated or deleted from production. They can corrupt or encrypt backup catalogs without touching a single production file, ensuring that when ransomware eventually detonates, there's nowhere to run. And perhaps most chillingly, they can simply sit there. Dormant. Persistent. Watching.
Some of the more sophisticated groups have been documented maintaining access to backup environments for six to nine months before making any visible move. During that window, they're learning the environment, identifying the most valuable data, and timing their strike for maximum leverage.
The Ransomware Angle Is Only Part of the Story
Ransomware operators figured this out a while ago. The evolution from "encrypt everything and demand payment" to "destroy backups first, then encrypt" is well-documented. But the backup-as-foothold strategy goes beyond ransomware economics.
Nation-state actors — particularly groups attributed to Russia and China in recent federal advisories — have been observed using backup infrastructure as a long-term persistence mechanism in espionage campaigns. Because backup systems pull data from across the environment on a regular schedule, a compromised backup agent is essentially a built-in exfiltration pipeline. You don't need to maintain dozens of implants across different systems. You just need one persistent access point on the backup server, and the data comes to you.
The FBI and CISA have both flagged this pattern in joint advisories, though the specific technical details are often scrubbed before public release. What they've made clear is that backup systems are no longer a safe zone — they're an active target.
What Security Teams Are Getting Wrong
The gap here isn't technical. It's organizational. Most security teams have built their detection and response capabilities around production environments. EDR agents on endpoints, SIEM ingestion from servers and cloud workloads, network monitoring on the perimeter. Backup systems often fall into a gray zone where IT operations owns the infrastructure but security owns the risk — and that ambiguity is lethal.
Incident response playbooks are another blind spot. When a breach is detected, the standard move is to isolate affected systems and begin restoring from backup. But if the backup environment is already compromised, you've just handed the attacker the keys to your recovery process. Several documented cases involve organizations restoring from infected snapshots, unknowingly reintroducing malware into a freshly rebuilt environment and restarting the clock.
There's also the matter of credential hygiene. Backup service accounts are notorious for having excessive privileges and rarely-rotated passwords. In Active Directory environments, these accounts sometimes have domain admin rights — a legacy configuration that nobody's cleaned up because "it just works." For an attacker doing lateral movement, a backup service account is a jackpot.
Fixing the Problem Means Rethinking the Whole Model
Getting this right isn't glamorous work, but it's not impossibly complicated either. A few places to start:
Treat backup systems like production systems. That means EDR coverage, log ingestion into your SIEM, vulnerability management, and inclusion in tabletop exercises. If your backup console isn't generating alerts when someone logs in at 2 a.m., that's a problem.
Implement immutable backup storage. Most major cloud providers and backup vendors support object lock or WORM (write once, read many) configurations. Use them. An attacker who can't modify or delete your backups has lost a significant chunk of their leverage.
Separate backup credentials from production AD. Backup service accounts should not be domain admin. They should have the minimum permissions necessary to do their job, and those credentials should be rotated regularly and vaulted in a PAM solution.
Test your restores in isolated environments. Before you trust a backup in a real recovery scenario, validate it in a sandbox. This catches both accidental corruption and deliberate tampering.
Include backup infrastructure in your threat hunting rotation. Regularly review authentication logs, configuration changes, and data access patterns on backup systems. Anomalies here can be early indicators of an intrusion that hasn't surfaced anywhere else yet.
The Uncomfortable Truth
Organizations have spent years and serious money hardening their production environments. Firewalls, zero trust architectures, MFA everywhere, behavioral analytics — the works. And attackers noticed. They adapted. They started looking for the places where security investment thins out, where the attention wanders, where the assumption of safety breeds complacency.
Your backup system was supposed to be the answer when everything else failed. Right now, for a lot of organizations, it's quietly becoming the problem. The question is whether your security program is going to catch up before someone else makes that discovery for you.