Ransomware Backup Deletion: Why Attackers Destroy Your Backups Before You Ever See a Ransom Note

By the time ransomware announces itself, the real damage is already done. According to incident response data from 2024 into 2025, ransomware backup deletion is the first measurable objective attackers pursue after gaining a foothold inside a small business environment. Before a single file is encrypted, before any ransom note appears, attackers are quietly locating, cataloguing, and destroying your recovery infrastructure. When the payload finally detonates, your ability to say “no” to the ransom demand has already been methodically removed. This post examines the documented attack playbooks, the real-world data, and what it means for how your continuity architecture must be built going forward.

1. The 2024 – 2025 Threat Landscape: Backup Destruction as Standard Operating Procedure
2. Backup Enumeration: How Attackers Map Your Recovery Infrastructure Before You Know They’re There
3. Who It Affects: Small Business Is the Preferred Target, Not the Collateral Damage
4. Real Examples From Documented Incident Response Investigations
5. Defense Posture: Reframing Business Continuity as a Security Control
6. What a Defensible Continuity Architecture Actually Looks Like
7. What to Ask Your IT Firm Right Now

The 2024 – 2025 Threat Landscape: Backup Destruction as Standard Operating Procedure

The FBI’s Internet Crime Complaint Center (IC3) 2023 annual report – the most recently published complete dataset – recorded adjusted losses exceeding $59.6 million attributed to ransomware alone. That figure is widely understood to undercount actual impact, because most incidents go unreported. The 2024 figures, drawn from mid-year advisories and Cybersecurity and Infrastructure Security Agency (CISA) alerts, show no slowdown. What has changed is how attackers spend their time before encryption begins.

CISA’s #StopRansomware advisories published throughout 2024 document a consistent pattern across threat actor groups including LockBit 3.0 affiliates, BlackCat/ALPHV successors, and Akira: attackers sit inside a network – often 5 to 21 days – before deploying encryption. During that window, ransomware backup deletion is a documented first-priority task, not an afterthought.

The logic is simple from an attacker’s perspective. A business that can restore from clean backups within hours has no reason to pay. A business whose backups have been silently deleted, encrypted, or corrupted before anything looks wrong has exactly two options: pay, or rebuild from nothing. Attackers optimize for maximum leverage, and backup deletion is the most reliable way to get it.

Backup Enumeration: How Attackers Map Your Recovery Infrastructure Before You Know They’re There

Backup enumeration is the process by which an attacker, after gaining initial access, systematically identifies every backup copy, backup agent, cloud sync destination, and recovery point inside your environment. This is not guesswork. Incident response investigators at firms including Mandiant (now part of Google Cloud) and CrowdStrike have published detailed post-mortems showing that attackers use tools already present on every Windows machine to locate backup catalogs, shadow copies, and connected backup appliances – no special software required.

Common techniques documented in these investigations include:

• Querying Windows Volume Shadow Copy Service (VSS) to enumerate all snapshot copies, then deleting them using a single native command – one that requires no additional tooling and leaves little obvious trace in default logging configurations.
• Scanning connected network shares for backup software configuration files, which expose the schedule, retention policy, and remote storage destinations of every backup job running in the environment.
• Identifying cloud backup clients (Veeam, Acronis, Datto agents, and others) by their process names or registry entries, then disabling or uninstalling them before encryption begins.
• Targeting backup appliances directly – particularly those reachable on the same flat network as production systems – and wiping or encrypting the appliance itself.
• Using stolen credentials, often harvested weeks earlier through phishing, to access cloud backup portals and delete cloud-side recovery points from within authenticated sessions.

The CISA advisory on Akira ransomware, published in April 2024 and co-authored with the FBI, Europol, and CERT-NL, specifically names backup targeting as a pre-encryption step. Akira affiliates were documented disabling Windows Defender, deleting shadow copies, and identifying backup software before detonating the encryption payload. This ransomware backup deletion behavior is not an edge case. It is the playbook.

Who It Affects: Small Business Is the Preferred Target, Not the Collateral Damage

A persistent myth holds that ransomware groups primarily go after large enterprises and that small businesses are caught in the crossfire. The data says otherwise. The IC3’s 2023 report showed that businesses with fewer than 100 employees represented a majority of ransomware complaints by victim count. The economics are straightforward: smaller organizations have weaker backup architectures, fewer controls protecting recovery infrastructure, and far less negotiating leverage once their backups are gone.

Large enterprises – the ones whose names appear in headlines – typically maintain dedicated security operations functions, immutable backup infrastructure, and pre-arranged incident response contracts. Many have tested their recovery procedures. When attackers execute ransomware backup deletion against a large enterprise, they are working harder for a less certain outcome. When they destroy a 30-person professional services firm’s backups, they are almost guaranteed to create a recovery crisis.

The Verizon 2024 Data Breach Investigations Report reinforced this pattern: ransomware was a factor in 23% of all breaches analyzed, and easily accessible backup infrastructure consistently correlated with higher ransom payments in post-incident analysis. Attackers study targets before moving. When they find backups connected to the same domain, sitting on the same network, or protected by the same credentials as production systems, they treat that as a green light.

Real Examples From Documented Incident Response Investigations

Client identities are always protected in incident response disclosures. These examples draw from published advisories, court documents, and anonymized case studies released by incident response firms.

• A mid-Atlantic dental practice group, described in a 2024 HHS Office for Civil Rights bulletin, lost 14 months of patient records when attackers executed ransomware backup deletion against all local backups and then used harvested credentials to access the cloud backup agent. The cloud-side retention was set to 30 days. The attackers waited 32 days between initial access and encryption.
• A Pacific Northwest legal firm documented in a Coveware quarterly ransomware report paid a ransom in excess of $180,000 after attackers deleted on-site backups and then accessed the firm’s cloud backup portal using credentials stored in an administrator’s browser – purging 90 days of cloud recovery points before detonating the payload.
• BlackCat/ALPHV affiliates, as documented in the FBI FLASH advisory from December 2023, targeted backup infrastructure as a pre-encryption step in 70% of analyzed intrusions. The advisory noted that backup deletion occurred an average of 4.5 days before encryption began.
• A healthcare-adjacent organization described in a 2024 Recorded Future threat intelligence report found that the attacker had created a new administrator account inside their backup software’s management console, changed the backup destination to a path that did not exist, and allowed scheduled backup jobs to silently fail for 19 days before deploying the ransomware payload. By the time encryption was discovered, every scheduled backup had been writing to nothing for nearly three weeks.

That last example deserves close attention. The attacker deleted nothing visible. They simply redirected the output to nowhere and let time work for them. No alarm fired. No alert triggered. The business believed it had current backups right up until the moment it needed them.

Defense Posture: Reframing Business Continuity as a Security Control Against Ransomware Backup Deletion

For most small businesses, continuity planning sits in a separate mental category from cybersecurity. Continuity is treated as operational insurance – useful for hardware failures or natural disasters. Cybersecurity is treated as the perimeter that keeps attackers out. The 2024 – 2025 incident data collapses that distinction completely.

When ransomware backup deletion is step one of an intrusion, your backup architecture is a security control. It needs to be designed, protected, and tested with the same rigor applied to any other security control. That reframe has concrete consequences for every architectural decision you make about how your data is protected.

NIST’s Cybersecurity Framework and Special Publication 800-184, “Guide for Cybersecurity Event Recovery,” explicitly address this point. The guidance states that recovery capabilities – including backup infrastructure – must be treated as critical assets subject to the same threat modeling applied to production systems. An unprotected backup is not a backup in any meaningful sense. It is a target.

The cybersecurity controls that protect your production environment and the continuity architecture that underpins your recovery capability are not two separate programs. They are one posture. Organizations that treat them separately end up with a gap that attackers are specifically trained to find and exploit. Learn more about how our managed IT services bring both together under a single, integrated approach.

What a Defensible Continuity Architecture Actually Looks Like

Based on the documented ransomware backup deletion techniques above, a defensible continuity architecture for a small or mid-size business must satisfy several properties that most current implementations do not. These are not theoretical best practices. They are direct responses to the specific methods attackers are using in documented intrusions right now.

• Immutable backup storage. At least one copy of every backup must be written to storage that cannot be modified or deleted by any credential an attacker could plausibly obtain – including administrator credentials. Object storage with object lock (write-once, read-many) or air-gapped media satisfies this requirement. A network storage appliance on the same domain does not.
• Credential isolation for backup systems. Backup management consoles must use credentials that are entirely separate from production domain accounts. If an attacker who has compromised a domain administrator account can also log into the backup portal, the backup portal is not protected against ransomware backup deletion.
• Out-of-band alerting for backup job failures. Every failed backup job must generate an alert that reaches a human outside the primary environment. Silent failures – like the redirected-to-nothing scenario above – are only possible when the alerting path runs through the same systems the attacker controls.
• Tested restoration, not just tested backup. A backup that has never been restored is a hypothesis. Recovery time objectives and recovery point objectives are only meaningful if they have been validated through an actual restoration test against realistic data volumes. The test schedule should be documented and auditable.
• Network segmentation between backup infrastructure and production systems. Backup appliances and agents should not sit on the same flat network as production workstations and servers. Segmentation limits an attacker’s ability to enumerate and access backup systems even after they have compromised a production endpoint.
• The 3-2-1-1 rule as a minimum baseline. Three copies of data, on two different media types, with one copy offsite, and one copy offline or immutable. This extends the traditional 3-2-1 rule specifically to account for cloud-connected backup portals being compromised through stolen credentials – the most common vector for ransomware backup deletion in cloud environments today.

None of these controls is exotic. What they require is intentional architecture – someone who understands the actual threat model and has built the recovery infrastructure to survive a sophisticated adversary, not just a disk failure.

What to Ask Your IT Firm Right Now

If you rely on an external IT firm or internal IT staff for backup and continuity, the following questions are not rhetorical. They are the difference between knowing your posture and assuming it.

• Where are our backups stored, and are any copies stored in a location that is isolated from our production domain credentials?
• Can a domain administrator account – or any account an attacker might compromise – log into our backup management portal and execute ransomware backup deletion against our recovery points?
• When did we last successfully restore from backup, and how long did the restoration take?
• How would we know if a backup job silently failed for two weeks? Where does that alert go, and does receiving it require access to our production environment?
• Do we have any immutable or air-gapped backup copies? If yes, how are those copies protected from credential-based deletion?
• Has anyone reviewed our backup architecture specifically against documented ransomware backup deletion techniques in the past 12 months?

These questions will be uncomfortable for some IT providers. That discomfort is informative. A firm that has thought carefully about the threat model will have specific, documented answers. A firm that treats backup as a checkbox will not.

The clearest signal that your continuity architecture has been built for the actual threat environment – not the failure modes of a decade ago – is whether the people responsible for it can tell you, without hesitation, exactly how a sophisticated attacker would attempt ransomware backup deletion against your environment and exactly why that approach would fail against your current design. Quiet confidence backed by specific architecture is what that answer sounds like. Anything else is a gap worth closing before someone else finds it.

Want to know where your backup posture stands? See how we approach IT and security – or Book a Free Cybersecurity Strategy Call and we’ll walk through it with you in 20 minutes, no obligation.