Ransomware Hits Backups First — Your Recovery Plan Is the Target

The Backup Paradox

We keep hearing the same post-incident refrain: "We had backups." And yet the organization still paid the ransom, still lost weeks of operations, still couldn't recover. The uncomfortable truth is that having backups and having recoverable backups are two entirely different things — and ransomware operators have understood this gap for years.

The core problem isn't backup absence. It's sequencing. Modern ransomware operations are methodical. Before a single file gets encrypted, threat actors spend time in your environment mapping infrastructure, escalating privileges, and identifying exactly where your recovery assets live. Backup servers, management consoles, cloud sync agents, tape libraries attached to domain-joined hosts — all of it is fair game. By the time the encryption payload fires, the escape routes are already blocked.

Why Backup Systems Are Soft Targets

Backup infrastructure tends to accumulate a specific set of security debt. Backup agents run with elevated privileges — often domain admin or local SYSTEM — because they need broad read access to do their job. Those same credentials become a skeleton key once an attacker has a foothold. Backup management consoles frequently sit on the same network segments as production systems, sometimes with weak or shared credentials, sometimes with direct internet exposure for remote management convenience.

On-premises backup targets that are continuously mounted or accessible via SMB are particularly vulnerable. If the backup server is domain-joined and reachable from an infected workstation, it's not a backup — it's a delayed copy of your problem.

Cloud backups aren't automatically safe either. If the credentials that write to your cloud backup bucket are stored on an endpoint or in a password manager that gets compromised, an attacker can enumerate and delete those snapshots just as easily as local ones. Immutability settings on object storage help here, but only if someone actually configured them correctly and tested that they can't be overridden by the account credentials in use.

What Operators Should Actually Check

A few concrete things worth auditing right now:

Blast radius of backup credentials. What can your backup service account actually reach? If it has rights beyond what's strictly needed to read and write backup data, that's an attack surface. Least privilege applies here as much as anywhere else.

Network segmentation between backup infrastructure and production. Your backup server should not be reachable from a compromised endpoint without crossing a meaningful security boundary. VLAN separation plus firewall policy enforcement is the minimum bar.

Immutability and air-gap status. Whether you're using object storage with object lock, tape rotation with offsite storage, or a purpose-built immutable appliance — verify that immutability is actually enforced at the storage layer, not just assumed. Then test it by trying to delete something.

Recovery testing cadence. This is the one most organizations skip. A backup you've never restored from is a hypothesis, not a capability. Scheduled recovery drills — including full system restores in an isolated environment — are the only way to know your RTO assumptions are grounded in reality.

Monitoring for backup job failures and deletions. Attackers will often disable or delete backup jobs days before the encryption event. If nobody is alerting on backup job failures or unexpected deletions from your backup catalog, you're flying blind during exactly the window when you most need visibility.

The Operational Mindset Shift

We need to stop treating backup as an insurance policy that gets filed away and never examined. Ransomware operators are actively probing it as an attack vector. That means we need to apply the same adversarial thinking to backup infrastructure that we apply to perimeter defenses and identity systems.

The 3-2-1 rule is a starting point, not a finish line. Three copies, two media types, one offsite — but also: one copy that is genuinely unreachable from your production environment, with immutability enforced, and a tested restore procedure that your team has actually executed under pressure.

Backups don't fail because they're missing. They fail because we treat them as passive artifacts rather than active security controls.

Source: Why ransomware attacks succeed even when backups exist — BleepingComputer