Your backups are the first target: how modern ransomware destroys your copies before touching your data

There's a comfortable belief still circulating in a lot of companies: "if something happens, we'll just restore from backup." That single sentence explains why ransomware groups completely reversed the order of the attack over the past few years.

From the attacker's point of view, the logic is simple and cold. An intact backup removes their leverage. If you can restore, you have no reason to pay. So before encrypting anything in production, the objective shifted: find, compromise, and destroy the recovery copies first.

The consequence is that your backup repository is no longer your plan B. It is the primary target of the incident. And that changes how a data protection strategy has to be designed.

What the data says about the new reality

Vendor research and market studies help put the shift into perspective:

• Industry research indicates that the vast majority of ransomware attacks deliberately go after backup repositories, and that a significant share of those attempts succeed to some degree.
• Recovery from backup — once the default answer to an incident — has been losing effectiveness precisely because copies are being compromised before detection ever happens.
• Veeam's Data Trust and Resilience Report 2026, based on more than 900 senior IT, security, and risk leaders, surfaced an uncomfortable finding: 90% of organizations say they are confident they can recover from a cyber incident, yet fewer than one in three ransomware victims fully recovered their data. On average, they got back roughly 72% of what was affected.
• Sophos research on the impact of compromised backups found that organizations that lost their copies faced dramatically higher recovery costs — the figure cited is on the order of eight times more.

Look closely at what those numbers actually say. The problem is rarely the absence of backup. The problem is backup that exists but does not survive the attack — or survives and does not restore within the window the business needs.

How the attack on your backups actually plays out

Modern ransomware, especially in cloud and hybrid environments, often doesn't depend on a malicious executable running on an endpoint. It depends on identity and permission.

1. Initial access

A leaked credential, phishing, an exposed VPN, open RDP, an unpatched edge vulnerability, or a service account without MFA. The intruder walks in with a legitimate credential, which is exactly why nothing obvious lights up.

2. Quiet reconnaissance

Before any encryption, the attacker maps the environment. They look specifically for: the backup console, the backup server, repositories, network shares holding copies, snapshots, scheduled jobs, saved credentials, cloud storage API keys, and accounts with administrative privilege. This stage is espionage, not destruction.

3. Privilege escalation and identity takeover

Once they hold administrative privilege or control the domain, the attacker has precisely the same power your backup administrator has. And a backup administrator, by definition, can delete backups.

4. Destroying the copies

This is where the attack hits your backups before it ever touches production: deleting jobs, removing snapshots, wiping repositories, revoking keys, rewriting retention policies down to a minimum, disabling schedules, and clearing logs. In cloud environments, abusing a single IAM permission is often enough — no "break-in" in the classic sense required.

5. Encryption and extortion

Only then is production data encrypted. By the time you notice the incident, the decision between restoring and negotiating was already made — by the attacker, days or weeks earlier.

Practical risks to the business

• Extended downtime. Without an intact copy, time-to-recovery stops being a technical decision and starts depending on improvisation, manual rebuilds, or negotiation.
• Multiplied cost. Recovering without clean backups means emergency consulting, overtime, server rebuilds, re-keying data, and in many cases permanent information loss.
• Legal and regulatory exposure. CCPA, GDPR, HIPAA where applicable, SOC 2 commitments, and contractual or audit requirements do not grant exceptions because your backup failed. The obligation to protect the data stays with your company.
• Reputational impact. Customers, partners, and suppliers notice the outage before any official statement goes out.
• Loss of history. Short retention means that even a successful restore may only bring back an already-compromised version.

Common mistakes that turn backups into an easy target

• Backups inside the same identity domain as production. If one administrative credential reaches both the servers and the repository, the compromise is a single event: one falls, both fall.
• Backups on the same physical or network environment as the original data. A NAS on the same network, reachable over SMB, is convenient for your routine and equally convenient for the intruder.
• A backup console without MFA. The interface that controls every copy the company owns is frequently less protected than corporate email.
• Over-permissioned API keys. A key that can write can usually also delete. If it leaks, the cloud repository becomes a direct target.
• No immutability. A backup that can be deleted by anyone with privilege will be deleted by whoever steals that privilege.
• Retention decided by disk space instead of risk. Attackers often dwell for weeks. Seven days of retention can mean every available restore point is already contaminated.
• Nobody watches the routines daily. Jobs failing for weeks, alerts landing in a mailbox nobody reads, and the discovery arriving at the worst possible moment.
• No full restore test, ever. A backup that has never been restored is a hypothesis, not a guarantee.
• Treating sync as backup. OneDrive, SharePoint, and Google Drive are excellent for collaboration and synchronization, but syncing means replicating the change — including the encryption and the deletion.

Practices that reduce the risk of an impossible recovery

Isolate backup identity

Backup credentials and accounts should not depend on the same directory and privilege chain as production. The goal is to prevent a single compromise from controlling both the data and the copies. MFA and least privilege on the backup console are no longer optional.

Adopt immutability — and understand its limit

Immutable storage (object lock, WORM, vault lock) prevents a copy from being altered or deleted within a defined window, even by an administrator. It is one of the most effective layers against repository destruction. But there's an honest and important caveat: immutability protects the copy; it does not guarantee the copy is clean. An immutable snapshot of an already-compromised database is still compromised. That's why immutability has to travel alongside adequate retention and recovery-point verification.

Extend 3-2-1

The classic rule — three copies, two media, one offsite — still holds, but the current reading adds two requirements: at least one isolated or immutable copy, and zero verified errors in the routines. Redundancy alone doesn't help when the attacker is aiming precisely at the redundancy.

Plan retention around attacker dwell time

The right question isn't "how much space do I have," it's "from what date forward am I confident the environment was still intact?" Retention has to cover the gap between initial compromise and detection.

Monitor routines every day

Job failures, unexpected retention policy changes, deleted restore points, and sudden drops in protected volume all deserve immediate alerts — they are frequently the first visible evidence that someone is already inside.

Test restores for real

Restoring one file is not a restore test. A real test rebuilds a server, brings up a database, validates the application, and puts a clock on it. It's the only method that converts confidence into demonstrated capability.

Set RTO and RPO with the business, not just with IT

How long operations can be down, and how much data the company is willing to lose, are business decisions. The backup architecture is the consequence of those answers — not the other way around.

Why this is a continuity conversation, not a storage conversation

Storing data is the cheap, easy part of the problem. What determines the outcome of an incident is the combination of four things: copies that survive the attack, retention that reaches a clean point, monitoring that catches the deviation in time, and restores that were proven before the emergency.

When all four exist, ransomware becomes a hard but manageable operational event. When one is missing, it becomes a continuity crisis — and for some companies, an existential one.

How SafetyOnCloud can help

SafetyOnCloud works consultatively with organizations that depend on critical data to operate. Our job doesn't end at storage: it involves evaluating how your current strategy would behave under a real attack.

• Assessment of your existing backup strategy, including the exposure of the repository and of the identity that controls it.
• Cloud backup with retention tuned to your actual requirements rather than an off-the-shelf plan.
• Active monitoring of routines, with identification of failures, deviations, and unexpected policy changes.
• Protection for servers, files, databases, and SaaS environments, including Microsoft 365 and Google Workspace.
• Support in defining RTO, RPO, and recovery priority together with the business.
• Support for MSPs, consultants, and IT firms that need to deliver monitored backup to their own client base.

No solution completely eliminates ransomware risk, and you should be skeptical of anyone who promises that. What a well-planned strategy does — measurably — is drastically reduce the impact, shorten downtime, and increase the probability of a clean recovery.

Conclusion

The question that separates companies that recover from companies that negotiate isn't "do we have backup?" It's a far more uncomfortable one: if an attacker held administrator credentials in our environment today, how many of our copies could they delete before encrypting anything?

If the answer is "I don't know" or "probably all of them," that's the gap to close first — and the best time to close it is now, not during an incident.

If your company isn't certain it could recover its data after a failure, an accidental deletion, or a ransomware attack, this is the moment to review your backup strategy. SafetyOnCloud can help you assess risk, define appropriate retention, monitor routines, and structure more reliable protection for your critical data.

Request an assessment of your company's backup strategy

Sources consulted: Veeam Data Trust and Resilience Report 2026; Sophos research on the impact of compromised backups on ransomware outcomes; public market analyses of attacks against backup repositories in cloud environments. Figures reflect publications available as of July 2026 and should be re-verified against the original sources before reuse in commercial materials.