Can Ransomware Delete Your Backups? Yes – Here’s How to Stop It

Direct answer

Yes – ransomware can and does delete your backups. Modern ransomware groups deliberately target backup systems before encrypting production data. A backup that is connected to your network, uses shared credentials, or is stored in the same cloud account as your production environment is not safe. Only backups protected by immutable storage – WORM hardware, cloud Object Lock, or an air-gap – are reliably ransomware-proof.

• 93% of ransomware attacks attempt to destroy backups first
• Shadow copies are deleted automatically by most modern strains
• Shared credentials mean one compromised password = backup gone
• Immutable + air-gapped backups are the only proven defense
• Cloud backups must be in a separate account to be safe

Most people believe they’re safe because they have a backup. They’re not. Modern ransomware groups specifically hunt for and destroy backup systems before launching their main attack – leaving victims with nothing to recover from. Here’s the full picture.

1. How do attackers reach your backups?

Professional ransomware groups – including LockBit, BlackCat, and Conti – don’t simply encrypt your files and demand a ransom. They follow a deliberate, multi-week playbook designed to maximize damage and eliminate any path to free recovery.

After gaining initial access, attackers spend weeks quietly mapping your environment. Their primary objective during this reconnaissance phase is to locate backup infrastructure: where backups reside, what software manages them, and which credentials can access them.

Ransomware attackers reach backups by first gaining network access through phishing or exposed RDP ports, then spending 1–3 weeks in silent reconnaissance to map backup servers and credentials. They escalate privileges to the domain admin level, delete all shadow copies and backup agents, and only then deploy the encryption payload — ensuring victims have no clean restore point.

1: Initial access: Entry via phishing email, compromised VPN credentials, or an exposed RDP port

2: Reconnaissance (1–3 weeks): Silent network scanning to locate backup servers, NAS devices, and cloud storage accounts

3: Privilege escalation: Gaining domain admin or backup admin rights using credential theft or Pass-the-Hash techniques

4: Backup destruction: Deleting shadow copies, disabling backup agents, wiping NAS volumes, and revoking cloud access

5: Ransomware deployment: Only after backups are confirmed destroyed does the encryption payload execute across production systems.

Real attack timing: Attackers study your backup schedule, then time the final encryption strike to coincide with the moment your most recent backup is also corrupted — leaving no clean restore point at all.

2. Shared credentials = shared risk

The single most common backup security mistake is using the same administrative credentials for both production systems and backup infrastructure. If an attacker compromises your domain admin account, they own your backup server too — and modern ransomware toolkits are specifically built to exploit this.

Backup software, including Veeam, Commvault, and Veritas, is explicitly targeted by ransomware operators. Their toolkits maintain lists of backup agent process names to kill before deploying encryption.

Shared credentials make backups unsafe from ransomware because a single compromised domain admin password gives attackers full access to both production systems and backup servers. Secure backups require dedicated credentials with MFA, a network-isolated backup server, and at least one offline or air-gapped copy that ransomware cannot reach over the network.

The 3-2-1 rule is no longer enough: Three copies, two media types, one offsite was designed before ransomware was this capable. Today, follow the 3-2-1-1-0 rule: add one offline or air-gapped copy, and verify zero errors on every restore test.

3. What “immutable” actually means

The word “immutable” is heavily marketed but frequently misunderstood. A truly immutable backup cannot be deleted, modified, or encrypted by anyone – not a sysadmin, not ransomware, not even a cloud provider – for a defined retention period. This protection must be enforced at the storage level, not the software level.

If your backup software’s admin console has a “delete backup” button — even one requiring a password – that backup is not truly immutable. An attacker with stolen admin credentials can click it.

Immutable backups are ransomware-safe because they use storage-level write protection – WORM hardware, cloud Object Lock, or air-gap isolation – that prevents deletion or modification regardless of software permissions. Software-level “delete protection” that can be bypassed with admin credentials is not true immutability and does not protect against ransomware that steals credentials before attacking.

WORM storage (Write Once Read Many): Hardware-enforced. Once written, the storage medium cannot be physically modified or erase data. Magnetic tape and specialized disk arrays (like Dell EMC DataDomain with retention lock) fall here.

Object Lock: Cloud-native WORM equivalent on AWS S3, Azure Blob, and Google Cloud Storage. Objects cannot be deleted or overwritten — even by the root account – until the retention date expires.

Air-gap: A backup physically disconnected from all networks. Ransomware cannot reach it over any connection. Offline tape libraries are the gold standard for air-gap protection.

4. On-site WORM vs cloud Object Lock

Neither option is universally better. The right choice depends on your recovery time objective, data volume, budget, and compliance requirements. Most mature organizations use both.

 On-site WORM

• Fast recovery at local network speeds
• No ongoing cloud egress costs
• Strong data sovereignty posture
• Vulnerable to physical disasters
• High upfront hardware investment
• Requires dedicated management

 Cloud Object Lock

• Geographically distributed by default
• Elastic, pay-as-you-go pricing
• S3 Glacier Deep Archive = very affordable
• Recovery slow from the archive tiers
• Egress fees add up at scale
• Must use a completely separate account

Critical warning on cloud backups: Never store cloud backups in the same AWS, Azure, or GCP account as production workloads. A compromised production account with sufficient IAM permissions can disable Object Lock retention settings and then delete the bucket – bypassing the protection entirely.

5. How to verify your backups are truly safe?

Having a backup strategy on paper is meaningless without verification. Run this checklist quarterly and treat every gap as an urgent remediation item – not a “nice to fix later” note.

• Perform a full restore test to an isolated environment every quarter — this is the only real proof that a backup works
• Backup credentials are completely separate from production, with MFA enforced on all access
• WORM or Object Lock retention is set to at least 30 days (90 days recommended)
• The backup server sits in a network segment with no inbound access from production
• Alerts fire on any attempt to delete VSS/shadow copies
• At least one offline or air-gapped copy exists at a separate physical location
• Audit logging is enabled on the backup management console
• Cloud backups are in a dedicated account with separate billing and offline root credentials

To verify backups are safe from ransomware: confirm WORM or Object Lock retention is active for at least 30 days, ensure backup credentials are separate from production with MFA, test a full restore quarterly in an isolated environment, maintain one offline or air-gapped copy, and store cloud backups in a separate account with offline root credentials. Backups that have never been restore-tested are not verified as safe.

Best practice: Run a full simulated ransomware recovery drill – restore your entire production environment to a test environment, measure actual RTO, and document every gap found. Fix those gaps before an attacker finds them for you.