Windows Server Backup and VSS Protection: Defending Shadow Copies and Backups Against Ransomware
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Ransomware operators learned years ago that local recovery capabilities are the fastest path to recovery for victims — and therefore the first target for destruction. The sequence that appears in post-incident reports is consistent: establish persistence, move laterally to gain domain administrator access, delete shadow copies and backup catalog records, then deploy the encryption payload across the domain. The deletion step is fast (vssadmin delete shadows /all /quiet completes in seconds) and permanent for local shadow copies.
The backup architecture that survives this attack pattern has a common characteristic: the backup data is stored somewhere that the ransomware operator cannot reach with the credentials they have compromised. Network isolation, immutable storage, and offline copies provide this property through different mechanisms — the correct choice depends on your recovery time requirements and infrastructure.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Backup architecture: the 3-2-1-1-0 framework
The 3-2-1-1-0 framework extends the classic 3-2-1 backup rule specifically to address ransomware: three copies, two media types, one offsite, one offline or immutable, and zero restore errors. The offline or immutable copy is the element that ransomware cannot destroy regardless of the privilege level it achieves on networked systems. Azure Backup with Vault Lock, AWS S3 Object Lock in Compliance mode, and Veeam Hardened Repository each implement this property differently, but all share the characteristic that a delete request from compromised credentials cannot immediately destroy the backup data. The 'zero errors' requirement means restore testing is not optional; it is the verification step that confirms the architecture actually delivers recovery when it is needed. Teams that skip restore testing regularly discover at the worst possible moment that a misconfigured agent, full storage volume, or application dependency failure has rendered months of backup jobs unrestorable.
Implement immutable cloud backup as the minimum viable ransomware-resilient copy
For organizations with Azure or AWS environments: Azure Backup with Enhanced Soft Delete (14-30 day retention of deleted backups) and Vault Lock (prevents vault policy weakening) provides immutable backup storage that is managed independently of the production environment. An operator who compromises the production environment cannot delete Azure Backup data during the soft delete retention period even with the local backup agent credentials. Setup: create an Azure Recovery Services vault, enable Enhanced soft delete in vault properties (Vault > Properties > Security Settings > Enhanced soft delete), enable MFA for destructive operations (Vault > Security Settings > Soft delete and security settings > Require MFA for vault security operations). Enroll production servers in Azure Backup using the MARS agent or VM backup depending on workload type. The resulting backup is stored in Azure with a retention policy that cannot be weakened without MFA.
Monitor for shadow copy deletion commands in real time
Configure SIEM detection rules for the specific commands ransomware uses before encryption: in your SIEM, create rules alerting on process creation events (Event ID 4688 or Sysmon Event ID 1) where CommandLine contains any of: 'vssadmin', 'shadowcopy delete', 'wbadmin delete catalog', 'bcdedit /set', 'recoveryenabled'. Set alert severity to Critical and configure automatic incident creation in your ticketing system. The window between shadow copy deletion and file encryption is typically minutes — real-time detection of the deletion command may allow incident response to begin before encryption is complete. In CrowdStrike: verify the 'Volume Shadow Copy Deletion Detected' behavior indicator is configured as a High or Critical severity alert in your detection policy. Test the detection rule: run vssadmin list shadows in a test environment (not delete) to confirm the process creation event appears in your SIEM — if the list command appears, the delete command will also appear.
The bottom line
Windows backup and VSS protection against ransomware requires a layered approach because ransomware operators are specifically designed to destroy local recovery capabilities. VSS shadow copies provide fast recovery for accidental deletions and early-stage ransomware caught before deletion completes — but local shadow copies are reliably destroyed by modern ransomware. The ransomware-resilient recovery capability is an immutable or offline backup copy that ransomware cannot reach with the credentials it compromises. Azure Backup with Vault Lock, Veeam Hardened Repository, or AWS S3 Object Lock provide this property for organizations with cloud or managed backup infrastructure. Implement detection rules for vssadmin and WMIC shadow copy deletion commands in your SIEM and EDR — early detection gives response teams time to act before encryption starts.
Frequently asked questions
How do I detect ransomware shadow copy deletion before it completes?
VSS deletion detection: ransomware uses several commands to delete shadow copies — detect all of them. (1) Windows Event Log detection: Event ID 8222 (Volume Shadow Copy Service error) and Event ID 7036 (Volume Shadow Copy service state change) appear when VSS copies are deleted. However, these events are generated after deletion is complete. (2) Process creation event detection (Event ID 4688 or Sysmon Event ID 1): alert on process creation events where the command line contains: vssadmin delete shadows, wmic shadowcopy delete, bcdedit /set recoveryenabled no, wbadmin delete catalog. These commands appear in the process creation log before the deletion completes. (3) EDR detection: modern EDR platforms (CrowdStrike, Defender for Endpoint, SentinelOne) have built-in detections for shadow copy deletion commands — confirm these are enabled in your EDR policy. In CrowdStrike: the 'Volume Shadow Copy Deletion' behavior indicator is included in the default detection policy. (4) SIEM alert: create a rule triggering on the command line patterns above in process creation events, with alert severity Critical and automatic escalation to incident response.
How do I restrict who can delete VSS shadow copies?
VSS access restriction: by default, local Administrators can delete shadow copies using vssadmin. Reducing the number of accounts with Administrator access to production servers is the primary control — if no account other than the break-glass admin account has Administrator access, ransomware that operates under a standard user context cannot use vssadmin. Specific VSS access controls: (1) Limit WBADMIN access: WBADMIN ENABLE BACKUP and WBADMIN DELETE CATALOG can be delegated using the WBADMIN Backup Operators group — add only authorized backup administrators to this group. (2) Use Protected Users security group: add service accounts to the Protected Users group in Active Directory, which prevents them from using NTLM (reducing Pass-the-Hash risk) — a compromised service account that is in Protected Users is harder to escalate to Administrator. (3) Apply Credential Guard: Credential Guard prevents NTLM hash extraction from LSASS, raising the bar for attackers trying to obtain Administrator credentials to escalate access and then delete shadow copies. (4) Monitor for shadow copy deletion: even with access restrictions, monitoring for deletion attempts is essential — an attacker who successfully escalates to Admin will attempt deletion, and early detection gives time for intervention.
How do I configure immutable backup storage to protect against ransomware backup deletion?
Immutable backup storage options: (1) Azure Blob Storage with immutability policies: enable time-based retention policy on the backup storage container in Azure. Policy type: Time-based retention with duration (e.g., 30 days). Once locked, no user — including the storage account owner — can delete blobs during the retention period. Azure Backup supports this via 'Enhanced soft delete' (14 days) and 'Vault Lock' (immutable vault that prevents policy weakening). (2) AWS S3 Object Lock: enable S3 Object Lock on the backup bucket with Compliance mode (prevents deletion even by root account during retention period) or Governance mode (can be overridden by accounts with s3:BypassGovernanceRetention permission). Configure Veeam or your backup software to write to the Object Lock bucket. (3) Veeam Hardened Repository: deploy a dedicated Linux backup repository with immutability enabled (Veeam Hardened Repository with single-use credentials for SSH access — the production backup server cannot SSH into the repository for administrative purposes, only for data writes). (4) Tape or offline disk: air-gapped backup copies on physical media that are rotated to offline storage provide the strongest protection but the slowest recovery time — appropriate for the deepest backup tier.
What is the correct VSS shadow copy configuration for production Windows servers?
VSS shadow copy configuration for production servers: (1) Schedule: configure shadow copies at least twice daily (recommended: 7:00 AM and 12:00 PM) to reduce data loss between VSS snapshots. Shadow copies are not a substitute for backup — they are local snapshots that provide fast recovery from accidental file deletion or ransomware if caught quickly. (2) Storage allocation: allocate shadow copy storage on a volume other than the volume being shadowed if possible. Set the maximum storage size to at least 10% of the volume size to retain multiple shadow copy versions. (3) Configure via PowerShell: $vol = Get-WmiObject Win32_Volume -Filter 'DriveLetter='C:''; $vol.EnableShadowCopy(); In older Windows: right-click volume > Properties > Shadow Copies > Settings. (4) Verify shadow copies are being created: vssadmin list shadows — the output should show recent shadow copies with correct creation timestamps. (5) Test restore: periodically test restoring a file from a shadow copy (right-click file > Properties > Previous Versions) to confirm shadow copies are functioning. (6) Important limitation: shadow copies deleted in a ransomware attack are unrecoverable unless you have a backup — VSS provides fast recovery for accidental deletions, not ransomware recovery. The offline or immutable backup is the ransomware recovery mechanism.
How do I test my backup restore capability for ransomware recovery scenarios?
Backup restore testing protocol: (1) Define the test scope: full restore test covers restoring an entire server from backup to bare metal or VM. Partial restore test covers restoring a specific set of files or a specific application's data. Run a partial restore test monthly and a full restore test annually (minimum). (2) Document the Recovery Time Objective (RTO) and Recovery Point Objective (RPO): the restore test should measure actual recovery time for the defined scope. If the actual recovery time significantly exceeds your documented RTO, either the RTO is unrealistic or the backup and restore process needs optimization. (3) Test from the immutable copy: specifically test restoring from the offline or immutable backup copy, not just from the primary backup job — ransomware scenarios require restoring from the copy that survives the attack, and this is often the slowest recovery path. (4) Test to an isolated environment first: restore the production data to a test environment and verify application functionality before considering the restore successful. A backup that restores files but produces a non-functional application is not a successful test. (5) Document test results: date of test, recovery time, recovery point (what date/time was the restored data from?), any issues encountered, and remediation actions taken. Auditors and cyber insurance underwriters request backup test documentation.
How do I configure Windows Server Backup for network-isolated backup destinations?
Network-isolated Windows Server Backup configuration: (1) The backup destination should not be a mapped drive share that the production server has persistent access to — a mapped share that is always accessible is a ransomware target. Options for isolation: (a) Configure the backup server (not the production server) to pull backup data: use a backup solution (Veeam, Cohesity, Nakivo) that operates with a push or pull model where the backup server initiates connections to production servers, not the reverse. With firewall rules allowing only the backup server's IP to initiate connections to production servers on the backup protocol port, a compromised production server cannot reach the backup server to delete backup data. (b) Use Azure Backup or another cloud backup service with MFA-protected deletion: even if a ransomware operator obtains the backup application credentials, deleting backup data from Azure Backup requires a separate MFA confirmation for destructive operations (Azure Backup's 'security PIN' feature). (2) Segment the backup server: place the backup server on a dedicated backup VLAN with firewall rules that: allow the backup server to initiate connections to all managed servers on the backup port (TCP 443 for cloud backup agents, or the agent port for your backup software), deny all connections from managed servers to the backup server (the production servers push data to the backup agent via the connection initiated by the backup server).
What is the backup monitoring and alerting setup that detects backup failures before an incident?
Backup monitoring configuration: a ransomware incident that exposes a backup failure is the worst time to discover the backup has not been running for 3 months. Monitoring to implement: (1) Backup job success/failure alerts: your backup software should send email or webhook alerts for failed backup jobs. Configure alerts for: backup job failure (any reason), backup job not running on schedule (missed backup), and backup target storage approaching capacity. (2) Backup age monitoring: configure an alert if the most recent successful backup is more than 25 hours old (for daily backup schedules). Many backup platforms provide this as a built-in dashboard metric. (3) VSS shadow copy age: create a scheduled PowerShell script that runs daily, checks vssadmin list shadows output, and alerts if no shadow copy was created in the last 25 hours. (4) Restore testing reminders: calendar the monthly partial restore test and annual full restore test as recurring calendar events with your team as required attendees — backup tests that are only planned when someone remembers to schedule them are backup tests that do not happen. (5) Backup reporting to CISO: include backup coverage (what percentage of servers have a successful backup in the last 24 hours?) in the monthly security metrics dashboard.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.