Volume Shadow Copy Deletion
Wiping shadow copies blocks rollback before ransomware encryption, but the deletion is loud and the snapshots are often recoverable.
The Volume Shadow Copy Service (VSS) maintains point-in-time snapshots of a volume that Windows uses for System Restore, "Previous Versions," and backup software. Those snapshots also let a victim roll back files that ransomware would otherwise hold hostage. For that reason, deleting shadow copies is one of the most consistent steps in the ransomware kill chain: it is executed immediately before mass encryption to remove the cheapest recovery path.
The technique is attractive because it is a single privileged command using a signed, built-in binary — no custom code required. That same simplicity is its weakness: the commands are well-known, rarely run by legitimate users, and leave clear traces in process auditing and the registry.
How it works
Operators destroy all snapshots with a built-in utility, often before kicking off encryption:
:: Remove every shadow copy on the system (classic pre-encryption step)
vssadmin delete shadows /all /quietEquivalent paths include wmic shadowcopy delete, wmic.exe calling the WMI Win32_ShadowCopy class, Delete-WmiObject in PowerShell, and resizing the shadow storage to near-zero with vssadmin resize shadowstorage. Ransomware frequently chains this with bcdedit /set recoveryenabled No, wbadmin delete catalog, and fsutil usn deletejournal in one cleanup script. Crucially, deletion does not securely wipe the snapshot's underlying differential clusters — the storage is marked free but historical data often persists until reused.
Detection & analysis
Static analysis:
- Carve unallocated space and the shadow storage area for VSS catalog and differential block structures; deleted snapshots frequently leave recoverable data. Tools:
vss_carver, The Sleuth Kit's VSS support, Velociraptor's VSS artifacts. - Inspect the
$MFTand$UsnJrnl:$Jfor the cleanup tooling itself — dropped scripts,vssadmin/wmicinvocations, and the encryptor — to reconstruct the sequence and timing of the recovery-inhibition step. - Review the registry: a forced VSS resize or service tampering leaves traces under
HKLM\SYSTEM\CurrentControlSet\Services\VSSand the volume's shadow storage configuration.
Dynamic analysis:
- Process auditing (Event ID 4688 / Sysmon 1) captures the exact command line:
vssadmin delete shadows,wmic shadowcopy delete,bcdedit ... recoveryenabled No. Treat any of these on a workstation or server as high-severity. - The VSS service writes to its operational event log; snapshot deletions and provider errors around the encryption window help bound the incident timeline.
Detection rule hint: Alert on any process command line matching vssadmin delete shadows, wmic shadowcopy delete, Win32_ShadowCopy deletion, bcdedit disabling recovery, or wbadmin delete catalog — especially when several fire within seconds of each other, the signature of a ransomware cleanup script. Recovery path: carve deleted shadow differential blocks from unallocated space and mount any surviving snapshots to restore pre-encryption files.