Keep backups running, and change what the backup path is allowed to do. Give the backup system its own credentials, make at least one copy immutable or offline, keep restore points longer than an attacker may stay undetected, and scan or test-restore before you recover. Pause only deletion and retention cleanup if you suspect an infection, not backup creation.
Key Takeaways
CISA’s #StopRansomware Guide warns that many ransomware variants try to find and delete or encrypt reachable backups, so the goal is to make backup unreachable for deletion, not to stop making them.
Microsoft’s analysis of ESXi ransomware attacks shows that encrypting a single hypervisor host can disable every VM on it, making hypervisor hosts high-value targets.
Immutability protects retention, not cleanliness. An immutable copy of already-encrypted data is still unusable, so pair it with scanning and test restores.
Retention must outlast detection time. If clean restore points rotate out before the attack is noticed, the backup job is working while the recovery plan is failing.
Count the credentials that can reach each copy, not just the number of copies.
Behavior differs by platform and version; verify each control against your hypervisor and backup software documentation.
Why Not Simply Stop Backups?
Stopping backups removes the one thing that gives you a recent recovery point, and it does not stop the attack.
The instinct is understandable. Teams worry that a running job will back up encrypted VMs, or that new encrypted restore points will push older clean ones out. Both worries are valid, but they are retention and verification problems, not reasons to stop creating restore points.
RPO continuity. Every hour without a backup widens the gap between your last clean state and the point of recovery.
Unknown timing. You rarely know the exact moment of compromise. Having frequent restore points lets you choose one from before the earliest indicator.
Evidence. Backup job logs and failures can themselves signal an attack. The Proxmox Backup Server documentation notes that if a source host is hit by ransomware, sync jobs will likely fail and trigger an error notification.
Platform note (VMware): Broadcom’s article on Changed Block Tracking states that disabling and then re-enabling CBT results in a full backup, which lengthens the backup window. Avoid cleanup steps that reset it unless necessary. This depends on your vSphere version and backup application.
How Ransomware Reaches VM Backups
Mostly through shared credentials, shared networks, and unpatched management layers, not through the backup software itself.
Credential reuse. Microsoft documented ransomware operators gaining full administrative access to domain-joined ESXi hosts by abusing an Active Directory group (CVE-2024-37085), then encrypting the hypervisor file system. A backup server administered through the same domain admin sits behind the same door.
Unpatched hypervisor. In February 2023, CISA and the FBI described the ESXiArgs campaign, which targeted likely unpatched or out-of-date ESXi servers and encrypted configuration files. The joint advisory AA23-039A reports that over 3,800 servers were compromised and urges organizations to update ESXi and keep it off the public internet. The lesson: recovery scripts are a last resort; a clean backup is the plan.
Reachable repositories. The #StopRansomware Guide recommends offline, encrypted backups precisely because many variants go after accessible backups.
The Control Stack
Control
| What it stops
| What it does not stop
| Keeps backups running?
|
Separate backup credentials and least privilege | Attacker using production/domain admin to delete backups | Compromise of the backup system itself | Yes |
Write-only access from sources | Compromised host deleting or editing existing backups | How writing bad data into new backups | Yes |
Immutable storage (WORM) | Deletion/encryption of locked restore points within the retention period | Backing up already-infected data; deletion after retention expires | Yes |
Offline/offsite copy | Local-network compromise reaching the copy | Anything already in the copy | Yes (schedule copy) |
Malware scan/test restore | Restoring contaminated data | Backup deletion | Yes |
Monitoring of job failures and deletions | Delayed detection | Prevention on its own | Yes |
Separate Credentials, Write-Only Paths
Proxmox Backup Server illustrates the pattern well. The Proxmox Backup Server documentation says the Datastore. Backup privilege allows creating but not deleting or altering existing backups, recommends separate API tokens per host or cluster with minimal permissions, and advises running pruning on the backup server itself instead of granting delete rights to clients. It also notes that PBS does not rewrite data for existing blocks, so a compromised client cannot corrupt existing backups.
Immutability
Object storage offers a vendor-neutral model. Amazon S3 Object Lock uses write-once-read-many storage, requires versioning, and offers two modes:
Compliance mode: a protected version cannot be overwritten or deleted by any user, including the account root user, and the retention period cannot be shortened.
Governance mode: most users cannot delete or alter lock settings, but users with the s3:BypassGovernanceRetention permission can.
Compliance mode is stronger and also less forgiving of mistakes. AWS notes that governance mode can be used to test retention settings first. A compromised account that holds bypass permission defeats governance mode, which is why it pairs with credential separation.
Offsite and Offline Copies
The CISA #StopRansomware Guide lists offline, encrypted, regularly tested backups as a core control. The Proxmox Backup Server documentation recommends off-site sync with sync jobs configured so snapshots that vanish at the source are not removed at the target, which prevents an attacker who controls the source from triggering deletions downstream.
Scan and Verify
NIST SP 1800-25 covers protecting assets against ransomware with backups, secure storage, integrity checking, and audit logs. On the restore side, the Proxmox Backup Server documentation recommends frequent test restores to a new guest rather than overwriting the current one, and notes that verification jobs can start failing if ransomware encrypts backups on a compromised server, though an advanced attacker could evade them.
Two Gaps in Most VM Backup Plans: Retention Timing and Shared Credentials
Free Deletion, Not Creation
Question most teams do not ask: When we suspect an infection, which half of the backup system should we stop?
Answer: The deleting half. A backup system does two jobs: it creates restore points, and it retires them. Creation raises your odds of having a clean recovery point. Retirement is the only mechanism that can destroy one. The Proxmox Backup Server documentation notes that some ransomware lies dormant for days or weeks before encrypting. With a short retention window, daily jobs can rotate out every pre-infection copy during that dormancy, so you are left with a full set of restore points that are all affected.
Practical Implication:
1. Set retention longer than your realistic time-to-detect, using your own incident history, since no universal figure exists.
2. On suspicion, suspend pruning, garbage collection, and expiry-based deletion, and keep creation running into a protected target.
3. Treat any restore point created after the earliest indicator as suspect until scanned or test-restored.
Vinchin’s recommended approach: Vinchin suggests designing backup systems with a focus on creating and retiring restore points. Key features include WORM Protection for read-only backup data and Storage Protection for access control. Set a longer WORM retention period to ensure effective detection of threats. Note that this approach may increase storage costs, and confirm deletion capabilities for your specific Vinchin version.
Count Credentials, Not Copies
Question: Why can an organization following 3-2-1 still lose every backup?
Answer: 3-2-1 counts copies and media types, but an attacker deletes with credentials, not with media. Microsoft’s ESXi case shows one domain group yielding full hypervisor control. If the backup server, its repository, and the cloud copy are all reachable by that same identity, you have three copies and one point of failure.
Practical implication: For each copy, list which identities can delete it. A good target is that no single production identity appears on more than one list, and at least one copy cannot be deleted by anyone before the retention date (immutability) or is not reachable from the network (offline).
Vinchin’s recommended architecture: Vinchin recommends treating backups as a separate trust domain. Their Storage Protection allows only authorized Vinchin applications to modify backup data. Backups can be copied to remote locations or cloud services like AWS S3, but separate credentials must be configured. Availability varies by version and license.
Platform Differences that Change the Design
Platform
| What matters for this topic
|
VMware vSphere/ESXi | ESXi has been a repeated ransomware target, as Microsoft’s incident analysis describes. Incremental backup relies on Changed Block Tracking, and Broadcom’s CBT article states that disabling and re-enabling results in a full backup. |
Proxmox VE with PBS | Per the Proxmox Backup Server documentation: privilege-based write-only access, existing blocks not rewritten, verification jobs, sync-job deletion control, S3-backed datastores. |
Hyper-V and other platforms | The same principle applies (separate identity, immutable target, tested restore); confirm snapshot and change-tracking behavior in the platform vendor’s own documentation |
Decision Matrix: Which Design Fits
Situation
| Recommended minimum
| Why
|
Small environment, one backup server | Separate credentials + one immutable or offline copy | Cheapest way to remove the single point of failure |
Domain-joined hypervisors, shared admins | Separate identity first, then immutability | Insight 2: immutability is your only wall if identities overlap |
Regulated or long-retention data | Immutable object storage in compliance mode + tested restores | Retention cannot be shortened by any user |
Frequent change, short RPO | Write-only paths + continuous job monitoring | Keeps backups running while limiting what a compromised host can do |
Mixed hypervisors | One backup layer with consistent controls | Reduces the number of identities and consoles to defend |
Implementation Workflow
1. Inventory and tier VMs. List workloads by recovery priority and acceptable data loss. NIST SP 1800-25 starts from the premise that defending data requires knowing the assets in the enterprise.
2. Separate the backup identity. Remove the backup server from the production admin domain or restrict its admin group. Easy to get wrong: leftover service accounts with domain-admin rights.
3. Make source access write-only. Source hosts should create backups but not delete them. Run retention on the backup side.
4. Add an immutable copy. Use object storage with retention lock or an equivalent WORM feature. Set retention above your time-to-detect. Easy to get wrong: locking a short retention and assuming it covers dormancy.
5. Add an offsite or offline copy. Prevent source-side deletions from replicating to the target.
6. Scan and test-restore. Restore to a new, isolated guest on a schedule. Do not overwrite production.
7. Alert on anomalies. Failed jobs, failed verification, unexpected delete request, sudden changes in backup size.
8. Rehearse the pause. Write down who can suspend deletion without stopping creation, and test it.
Where Vinchin fits: Vinchin’s ransomware protection page describes Storage Protection (restricts write and modify access on backup-server storage to authorized Vinchin applications), per-job WORM Protection that keeps backup data read-only until a preset retention period ends, and the option to copy backup to a remote site or public cloud storage. Vinchin’s malware scan page describes Malware Scan, which runs ClamAV and Kaspersky engines after a backup completes or before recovery. Availability depends on version, license, and platform.
If You Suspect an Infection: Pause or Keep Running?
Component
| Action
| Reason
|
Backup creation into protected storage | Keep running | Preserves recent restore points and logs |
Pruning, garbage collection, expiry deletion | Pause | Prevents clean restore points from rotating out |
Sync/copy jobs that mirror deletions | Pause or set to no-delete | Stops source-side deletions reaching offsite copies |
Restores over production | Do not run | Restore to a new isolated guest and scan first |
Credentials | Rotate for backup and hypervisor admin | Removes attacker access |
These steps follow the pattern in the CISA #StopRansomware Guide and the Proxmox Backup Server documentation. Your incident response plan and legal obligations take priority.
Common Mistakes
Treating snapshots on the same storage as backups.
Joining the backup server to the same domain with the same admin.
Setting immutable retention shorter than detection time.
Granting delete permission to source hosts for convenience.
Never test-restoring, so the first restore is the real incident.
Assuming encryption of backups prevents ransomware encryption; it protects confidentiality, not availability.
FAQs
Q1: Will continuing backups during an active infection overwrite my clean restore points?
Not if retention is long enough and deletion is paused. Creation adds restore points; only pruning removes them. Confirm in your product that you can pause deletion independently.
Q2: Can an immutable backup still contain ransomware?
Yes. Immutability locks what was written, including infected or already encrypted data. Scan backups and test-restore before relying on them.
Q3: Compliance or governance mode for S3 Object Lock?
In compliance mode, AWS S3 Object Lock lets no user, including the root user, delete a protected version or shorten its retention. Governance mode allows bypass for users with the right permission. Many teams trial governance mode, then move to compliance once settings are proven.
Q4: Does encryption stop ransomware?
No. It protects confidentiality of stored data. It does not prevent deletion or encryption of the backup files.
Q5: How should I test restores without risking reinfection?
The Proxmox Backup Server documentation advises restoring to a new guest rather than over the original. Add an isolated network and scan the restored guest before connecting it anywhere.
Conclusion
Ransomware defense for VMs is mainly a question of who can delete restore points and how long clean ones survive. Keep creating backups, remove shared credentials from the deletion path, lock at least one copy, outlast the attacker’s dwell time, and verify before restoring. Stopping jobs gives up recovery points without removing the risk.
