Ransomware crews go after backups first. Isolated, immutable copies help, but only up to a point

Ransomware operators increasingly attack backups, recovery points and restore infrastructure before they encrypt anything, according to BleepingComputer, Netizen, CyberFortress and Bacula Systems. The logic is simple. A victim who can restore has less reason to pay.

Isolated and immutable backups blunt that tactic, but they do not cover everything. Some statistics below come from vendors or are relayed second-hand, and each is attributed where it appears.

What attackers are doing to recovery

Google Threat Intelligence Group calls the shift “recovery denial.” Netizen, summarizing the group’s 2026 M-Trends reporting, says ransomware operators active in 2025 went after backup systems, identity services and the tools that manage virtual machines. Netizen says that included groups tied to Akira and Qilin, an association attributed by Google Threat Intelligence Group. The summary states no confidence level.

In the cloud, Google’s Cloud Threat Horizons reporting, as relayed by CSO Online and ZENDATA, says attackers disable or delete cloud-hosted backups early in an intrusion to maximize leverage. Credential compromise and misconfiguration remain the main ways into cloud environments. The same stolen login that opens the door can often reach the recovery copies too.

if an organization's backups live on the same control plane as production, adversaries assume they are fair game.

David Kasabji, CSO Online

Cloud-native extortion goes further by abusing built-in features. Examples cited in the reporting include Codefinger, which used server-side encryption with customer-provided keys (SSE-C) and lifecycle policies that auto-delete files within days.

How the access works

Backup platforms are attractive for a second reason: they often store credentials with broad access across the enterprise. Netizen, summarizing Google’s findings, says threat actors targeted Veeam Backup & Replication for credential harvesting in roughly 10% of the intrusions Google examined. Industrial Cyber reports that Trend Micro said the Qilin/Agenda group targeted Veeam infrastructure to harvest credentials and disable recovery options.

Netizen’s summary of Google’s work describes the actor UNC3944 using compromised Domain Admin credentials to reach a backup server. In another path, it added an attacker-controlled account to the Veeam Administrators group in Active Directory, the Microsoft directory service that manages logins. From there it could delete backup jobs, snapshots and repositories before deploying ransomware, a stage Google called “Backup Sabotage.”

Some ransomware does the work itself. Netizen, summarizing Microsoft’s May 2026 analysis of Gentlemen ransomware, says the malware has built-in routines that stop backup and recovery services from Veeam, Acronis, Backup Exec and Commvault, plus Volume Shadow Copy services. Microsoft’s stated reasoning, per Netizen, is that stopping services both frees file locks and hinders recovery.

Virtualization is another route. Netizen reports that in Google’s review of 2025 ransomware cases, attackers hit the virtual machine layer in close to one of every five incidents. In one case described there, attackers used PowerShell against vCenter and ESXi and deleted backups before running the encryptor.

Cases on the record

The tactic is not new. The accounts in this section come mainly from BleepingComputer, which is vendor-sponsored content. That article says BlackMatter wiped or reformatted backup stores on victim networks before encrypting, using compromised admin credentials, in 2021 attacks on NEW Cooperative and Crystal Valley. Because the backups sat on the same network, they were easy targets.

BleepingComputer also describes a joint CISA and FBI advisory on Gunra ransomware, which it says covered a case where attackers deleted backup and archived data at both the primary data center and the disaster recovery site. One set of stolen credentials reached both. We have not reviewed the advisory itself.

In the June 2024 Akira attack on a Latin American airline, attackers exploited CVE-2023-27532 in Veeam Backup & Replication to pull credentials, according to BleepingComputer and Bacula Systems. Both say the patch had been available for over a year. Both are vendor-linked secondary accounts.

A newer group called n0n was first reported by CyberXTron, and Infosecurity Magazine relayed the findings. The group threatens to encrypt or destroy backups and shadow copies of victims that do not pay. It was first seen Sept. 18 and had a leak site listing more than a dozen victims by Sept.

22.

Those listings are the group’s claims. We name no victims, and the reporting does not say which, if any, have confirmed an incident. The reporting adds that some countdown timers expired and data was released, which it reads as a sign some victims declined to pay. That is the reporters’ interpretation, not a statement from any victim.

How often it happens: read the numbers carefully

Survey figures vary by report and by who relays them. One secondary source cites Sophos 2024 data as 94% of incidents with backup compromise attempts and 57% success. Another cites Sophos 2026 as 96% targeted and 76% compromised. Both are vendor-survey numbers relayed second-hand, so treat them as indicators, not settled measurements.

A Veeam study cited by Netizen surveyed 1,300 organizations, 900 of which had been hit by ransomware in the prior year. Veeam reported that 89% of organizations in the study had backup repositories targeted. Netizen notes this reflects the surveyed population, not all incidents.

On cost, CyberFortress, itself a backup vendor, relays Sophos data saying organizations whose backups were compromised faced recovery costs about 8x higher. It gives a total average incident cost of $1.7 million and says organizations with working backups recovered through them in 66% of encrypted-data cases.

What isolation and immutability change

Immutable storage means recovery points cannot be changed or deleted during the retention period, even by an administrator account. That directly counters the pattern above, where a single compromised admin purges everything. The sources report that Microsoft recommends immutability, soft-delete (a holding period before deletion becomes final) and separation between recovery copies so one compromised admin cannot remove every copy.

Isolation addresses the shared-credentials problem described in the Gunra case. Google Cloud promotes Cloud Isolated Recovery Environments, which separate restored data from compromised systems and give a place to test backups. That is a vendor product pitch, but the design goal is clear: restore somewhere the attacker cannot already reach.

What they do not fix

Immutability does not guarantee a restore will complete, an application will boot, or recovered data is clean. It cannot rebuild a broken identity system or identify a clean recovery point.

Attackers can also tamper with backup configurations, policies and schedules, and with retention or object-lock settings, if the controlling accounts are compromised. An immutable copy protected by a weak control account is only as safe as that account.

Practical steps

The defenses below recur across BleepingComputer, Netizen, Industrial Cyber and ZENDATA.

• Separate backup infrastructure from production Active Directory, using dedicated credentials.
• Require multifactor authentication or out-of-band approval for destructive backup changes.
• Keep offline copies of backups.
• Patch backup software promptly, as the Veeam case shows.
• Monitor backup systems for unexpected changes.
• Test restores regularly, including identity and application recovery.

Why it matters

If backups share credentials or networks with production, one compromised admin account can remove the recovery option and shift the ransom decision. Isolation, immutability and tested restores change that leverage. They do not fix identity compromise or guarantee a clean restore.

For a victim, that gap shows up as services staying down. An immutable copy still has to be restored into an identity system that works, and someone has to find a recovery point that is clean. Until the directory is rebuilt and restores are tested, applications may not boot even though the backups survived.