Ransomware used to create a fairly direct technical problem: attackers encrypted production data, defenders restored it, and the organization tried to resume operations. Modern ransomware crews have spent years attacking that equation. Rather than leaving recovery infrastructure untouched, operators increasingly target backup systems, virtualization platforms, identity services, storage, snapshots, recovery documentation, and the administrative accounts needed to rebuild an environment.
Google Threat Intelligence Group describes this change as a shift toward “recovery denial.” In its 2026 M-Trends reporting, Google said ransomware operators observed during 2025 actively targeted backup infrastructure, identity services, and virtualization management planes. The activity included groups associated with Akira and Qilin, along with attacks that deleted cloud backup objects or abused identity infrastructure to maintain privileged access.
The objective is straightforward. Encryption creates disruption. Destroying the victim’s ability to restore creates leverage.
Recovery Is Becoming Part of the Target
Backup infrastructure used to sit near the end of the defensive conversation. Security teams tried to keep ransomware away from production systems, then relied on backups if prevention failed. That model assumes the attacker treats recovery systems as neutral territory.
Current incident data shows the opposite. Veeam’s 2025 ransomware research surveyed 1,300 organizations, including 900 that had experienced at least one ransomware incident during the prior year. Veeam later reported that 89 percent of organizations in its study had backup repositories targeted by attackers. As with any vendor survey, that percentage represents the surveyed population rather than every ransomware incident, but it illustrates how routine attacks against backup infrastructure have become.
CISA has warned about the same tactic for years. Its StopRansomware guidance states that many ransomware variants search for accessible backups and attempt to delete or encrypt them so restoration becomes impossible. CISA recommends offline, encrypted backups and regular tests of backup availability and integrity.
The shift changes the security question. It is no longer enough to ask whether data is backed up. Organizations need to ask whether those backups remain accessible after an attacker gains privileged access to the rest of the environment.
Backup Servers Are More Than Storage
A backup server can hold far more value than the data inside its repositories.
Backup platforms frequently need broad access across an enterprise. They connect to servers, databases, virtual machines, storage systems, hypervisors, and cloud workloads. They may contain service accounts or stored credentials that allow those connections to function. From an attacker’s perspective, that can turn a backup platform into a source of privilege rather than merely something to delete.
Google’s 2026 analysis of ransomware activity found that threat actors targeted Veeam Backup & Replication for credential harvesting in roughly 10 percent of the intrusions it examined. Attackers used tools such as Veeam-Get-Creds.ps1 and custom PowerShell scripts to retrieve credentials stored in Veeam configuration data.
That creates an uncomfortable reversal. A product deployed to protect critical systems may also maintain trusted relationships with many of those systems. Once an attacker controls it, the same connectivity that supports backup operations can help reveal credentials, infrastructure relationships, storage locations, and recovery architecture.
This is why backup infrastructure needs its own administrative boundary. A backup console managed by the same accounts used across ordinary production infrastructure can inherit the compromise of those accounts.
Delete the Safety Net Before Encryption Starts
Some crews attack backup infrastructure manually before ransomware deployment.
Google’s investigation of UNC3944 provides a clear example. After gaining broad control of an Active Directory environment, the actor targeted virtualized backup infrastructure. Google documented the use of compromised Domain Admin credentials to access a backup server and another path in which attackers added an account they controlled to the Veeam Administrators group in Active Directory.
From there, the actor could delete backup jobs, snapshots, and repositories before ransomware deployment. Google described this stage as “Backup Sabotage” and recommended separating backup infrastructure from the normal Active Directory trust relationship, using dedicated credentials, restricting administrative access, and deploying immutable repositories.
The sequence matters.
By the time encryption becomes visible, the recovery environment may already be damaged. Alerts tied only to the ransomware executable arrive near the end of the intrusion. The events that determine whether the organization can recover may have happened hours earlier through administrative logins, group membership changes, repository deletions, retention changes, or storage operations that looked legitimate at the protocol level.
Ransomware defense needs to detect attacks against the recovery process before the encryptor appears.
Some Ransomware Tries to Shut Recovery Down Automatically
Recovery disruption is also built directly into modern ransomware.
In May 2026, Microsoft published a technical analysis of the Gentlemen ransomware family. The malware contains extensive process and service termination routines aimed at virtualization software, databases, endpoint security products, remote-access tools, and backup systems.
Among the targeted processes were VeeamNFSSvc, VeeamTransportSvc, VeeamDeploymentSvc, Iperius backup components, Commvault components, and VSS-related services. The service termination list included Veeam, Acronis, Backup Exec, Commvault, Volume Shadow Copy services, and other storage or recovery products.
Microsoft identified two reasons for the behavior. Stopping applications can release file locks and increase encryption coverage. Stopping security and backup services also interferes with detection and recovery.
That distinction matters. A stopped database service may help the ransomware encrypt a database file. A stopped backup service helps make sure defenders have fewer options after the encryption finishes.
The malware is attacking both the data and the process used to get the data back.
Hypervisors Turn One Compromise Into Mass Impact
Virtualization infrastructure has become another major pressure point.
Google reported that threat actors targeted virtualization infrastructure in nearly 20 percent of the ransomware incidents it examined from 2025. In one UNC5495 intrusion, an actor automated deployment of a Babuk ransomware variant against ESXi hosts using a batch script and SSH. In another incident, attackers used PowerShell to authenticate to vCenter, set new ESXi root passwords, enable SSH, transfer ransomware, delete backups, shut down virtual machines, disable security policies, and then run the encryptor.
The attraction is clear. Compromising an individual virtual machine affects one workload. Compromising the hypervisor can affect many workloads at once.
Microsoft documented the same trend in its research into CVE-2024-37085, an ESXi authentication vulnerability exploited by ransomware operators. Microsoft said its incident-response engagements involving attacks against ESXi hypervisors had more than doubled across the preceding three years. Groups and affiliates associated with Akira, Black Basta, Babuk, LockBit, and other ransomware families had developed or used ESXi encryption capabilities.
In one Black Basta intrusion described by Microsoft, the attackers compromised domain administrator accounts, created an “ESX Admins” group, gained administrative access to ESXi, and encrypted the hypervisor file system. The hosted virtual machines lost functionality as a result.
This is one reason hypervisors belong in the same defensive conversation as domain controllers and backup servers. They are concentration points. A single privileged action can affect dozens of systems that would otherwise require individual compromise.
Identity Can Break Recovery Before the Backups Are Touched
Recovery infrastructure still depends on identity.
Backup administrators need accounts. Hypervisor administrators need accounts. Cloud recovery vaults have roles and permissions. Storage systems accept administrative credentials. Recovery teams need access to documentation, consoles, encryption keys, and configuration data.
If all of those paths depend on the same identity system that the attacker already controls, the recovery environment may fail without a single backup file being encrypted.
Google’s M-Trends 2026 reporting described ransomware actors targeting identity services alongside backup and virtualization infrastructure. Researchers observed misuse of Active Directory Certificate Services configurations to create privileged access that could survive ordinary password rotation.
The UNC3944 activity shows the same relationship at a smaller scale. Compromised Active Directory privileges were used to gain control over Veeam administrative access. Production identity and recovery identity had become part of the same attack path.
Separating those trust relationships can materially change an attack. Google recommends placing backup infrastructure in a separate security domain or using dedicated credentials that are not joined to the normal Active Directory environment. Microsoft recommends out-of-band controls such as MFA or a separate PIN before permitting destructive changes to online backups.
The goal is to stop one compromised administrator account from becoming an administrator account for everything.
Immutability Changes What an Attacker Can Destroy
Immutable storage has become one of the strongest technical controls against recovery denial.
An immutable recovery point cannot be changed or deleted during its retention period, including by an account that normally has administrative access. That creates a security property very different from a traditional backup repository where an attacker with administrator credentials may be able to delete the data.
Microsoft’s 2026 ransomware-resilient backup architecture recommends immutability and soft-delete controls so compromised administrators cannot purge recovery points during the protected retention window. Microsoft also recommends separation between recovery copies to reduce the chance that a single administrative compromise destroys every usable copy. Immutability does not solve every recovery problem.
Veeam’s review of cyber-extortion cases from 2025 reported that attackers had moved beyond simple backup deletion into tampering with backup configurations, policies, schedules, and backup objects. Some forms of sabotage might not become apparent until the organization attempts a restore. Veeam argues that recovery confidence depends on the integrity of the management and identity paths around the backup system, not just whether the backup blocks themselves are immutable.
An immutable copy can preserve data. It cannot rebuild a broken identity system, reconstruct undocumented dependencies, replace compromised credentials, or tell responders which recovery point is clean. That is the gap between having a backup and having a recovery capability.
A Backup Is Not a Recovery Plan
Successful recovery depends on more than copying files back into production.
CISA recommends regular disaster-recovery testing, offline copies, golden images for critical systems, and protected infrastructure-as-code templates that can be used to rebuild environments. It also warns responders to avoid reconnecting infected systems to clean recovery networks.
Microsoft goes a step further by calling out the supporting information needed during restoration. Its ransomware recovery guidance recommends protecting recovery procedures, configuration-management data, network diagrams, and other documentation from the same attacker that is targeting production and backups. Microsoft states that attackers may deliberately target those materials to interfere with restoration. That point is easy to overlook.
A recovery runbook stored on the same domain file server that gets encrypted is not a reliable runbook. A network diagram available only through the compromised identity provider may not be available during the incident. A password vault that depends on unavailable authentication infrastructure can create another dead end. A backup of an application is less useful if nobody has documented its databases, service accounts, certificates, dependencies, DNS records, network rules, and restoration order.
A meaningful recovery test needs to prove that the organization can rebuild under hostile conditions rather than ideal ones.
Clean Recovery Is a Separate Security Problem
There is also a danger in restoring too quickly.
If attackers maintained persistence for days before encryption, a recent backup may contain artifacts from the intrusion. Rebuilding a server from that recovery point could restore attacker-created accounts, malicious scheduled tasks, web shells, remote-management tools, altered configurations, or other persistence mechanisms.
CISA explicitly warns organizations to avoid reinfecting clean systems during restoration and recommends isolating recovery environments so only verified systems are introduced.
Veeam’s 2026 analysis of cyber-extortion cases makes a similar point. Recovery needs to account for attacker persistence, compromised credentials, malware, and damaged backup configurations rather than treating restoration as a simple data-copy operation. This is where incident response and disaster recovery become the same problem.
The security team needs to establish what the attacker touched. The infrastructure team needs to determine what can be trusted. Identity teams need to rotate or rebuild compromised credentials. Backup teams need to identify clean recovery points. Network teams need isolation for restored systems. Application owners need to validate functionality before those systems reconnect to production. Restoration without that coordination can return the organization to an earlier version of the compromise.
Recovery Infrastructure Needs Detection Engineering Too
Backup and virtualization environments often receive far less detection coverage than Windows endpoints and domain controllers. That needs to change.
Google’s UNC3944 analysis gives defenders several concrete signals. An interactive logon to a backup server by an unexpected privileged account can appear in Windows Event ID 4624. Adding a user to a privileged security group such as Veeam Administrators can generate Event ID 4728. Backup audit logs can expose mass deletion of jobs, snapshots, or repositories.
Hypervisor activity creates another detection layer. Microsoft recommends forwarding ESXi logs into SIEM infrastructure and monitoring unexpected administrative access.
Security teams can extend that idea across the recovery estate. Changes to immutability settings, retention periods, backup schedules, repository configuration, cloud recovery vaults, storage snapshots, hypervisor SSH access, vCenter administrators, service accounts, recovery roles, or backup encryption keys all deserve security telemetry.
The same is true for failed recovery controls. A backup job that unexpectedly stops running may be an operational problem. Ten critical backup jobs disabled within minutes of a privileged login may be an incident.
Detection engineering should treat destructive changes to recovery infrastructure with the same seriousness as changes to identity or endpoint security controls.
Make Recovery Harder to Reach Than Production
The safest recovery architecture assumes an attacker may gain control of the production environment.
From that assumption, several design decisions follow. Backup administrators should have separate credentials. Destructive operations should require stronger authentication. At least one recovery copy should resist deletion through immutability, offline storage, or another isolated mechanism. Hypervisors and backup consoles need dedicated monitoring. Recovery documentation needs to remain available after the primary identity and file-storage systems fail. Restore procedures need to be tested under conditions that resemble an actual breach.
CISA and Microsoft both stress that backups need isolation and regular recovery testing rather than simple confirmation that backup jobs completed successfully. Modern ransomware makes that distinction necessary.
The attacker may have the Domain Admin account. They may have vCenter. They may know where Veeam is installed. They may have disabled backup services, deleted snapshots, changed retention settings, reset hypervisor credentials, and encrypted production systems by the time the ransom note appears.
At that point, the organization’s security depends on whether something survived outside the attacker’s administrative reach.
Ransomware crews have learned that the fastest route to payment is not always encrypting more data. Sometimes it is making sure the victim has nowhere clean to restore it from.
How Can Netizen Help?
Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally.
Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.
Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.
Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.
Netizen Blog and News 
Leave a comment