Ransomware Deletes Your Shadow Copies First: Auditing VSS Tampering

Before nearly every modern ransomware payload starts encrypting files, it does something quieter: it destroys your ability to recover for free. Windows keeps point-in-time snapshots of volumes via the Volume Shadow Copy Service (VSS) — the same mechanism behind System Restore and "Previous Versions." If those snapshots survive an attack, victims can often roll a machine back and skip the ransom entirely. So the operators learned to delete them first.

This step, inhibiting system recovery, is catalogued as MITRE ATT&CK technique T1490. It is one of the most reliable, highest-signal indicators of an in-progress ransomware detonation — and it is trivially cheap to detect, because the tools attackers use are the same handful of built-in commands every time.

Why shadow copies are the first casualty

Shadow copies let Windows present an older version of a file or an entire volume without a full backup product. If a user's documents get encrypted but a shadow copy from this morning exists, recovery is a right-click away. From the attacker's economic point of view, leaving those snapshots intact means fewer victims pay. So the ransomware playbook is consistent:

• Delete every existing shadow copy on every volume.
• Shrink or cap the shadow storage area so Windows silently ages out any new snapshots.
• Disable the VSS service and related recovery features (WinRE, boot recovery, backup catalogs) so nothing regenerates.
• Only then begin encryption.

Because this happens before the loud encryption phase, catching it is your earliest cheap chance to interrupt the kill chain.

The commands attackers actually run

Almost all shadow-copy destruction funnels through a small, well-known set of living-off-the-land binaries. If you audit for nothing else, audit for these.

vssadmin — the classic

vssadmin.exe delete shadows /all /quiet
vssadmin.exe resize shadowstorage /for=c: /on=c: /maxsize=401MB

The first line nukes every snapshot without a prompt. The second caps shadow storage so tiny that Windows immediately discards new copies — a subtler variant that survives a naive "did anyone run delete shadows?" check.

wmic — the alias that dodges naive rules

wmic.exe shadowcopy delete

Same outcome, different binary. Detection that only watches vssadmin misses this entirely, which is exactly why attackers keep it in the toolbox.

PowerShell and WMI

Get-WmiObject Win32_ShadowCopy | ForEach-Object { $_.Delete() }
Get-CimInstance Win32_ShadowCopy | Remove-CimInstance

Recovery and boot tampering that travels with it

bcdedit.exe /set {default} recoveryenabled No
bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures
wbadmin.exe delete catalog -quiet

These usually appear in the same cluster: disabling automatic startup repair and wiping the Windows Backup catalog so no local recovery path remains. Seeing vssadmin delete shadows and bcdedit ... recoveryenabled No within seconds of each other is about as close to a ransomware smoking gun as host telemetry gets.

What to audit

There are two complementary questions: is the machine set up to keep useful snapshots at all? (posture) and has anything just tried to destroy them? (detection).

1. Posture — do usable shadow copies exist?

List current snapshots and the storage allocation. A machine with System Protection off, or with shadow storage capped absurdly low, has no local recovery even before an attack.

vssadmin list shadows
vssadmin list shadowstorage

Flag: no shadow copies on the system volume, a max shadow storage set to a tiny fixed value (the classic 401MB tell), or the VSS service set to Disabled rather than Manual.

2. Detection — watch the Security event log for the process launches

With process command-line auditing enabled (Audit Process Creation + the "Include command line" policy), every one of the commands above lands in the Security log as Event ID 4688 with its full arguments. That is the single most valuable thing you can turn on for this:

auditpol /set /subcategory:"Process Creation" /success:enable
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" ^
  /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f

Then alert on 4688 events whose command line matches vssadmin + delete/resize, wmic + shadowcopy, Win32_ShadowCopy, wbadmin delete catalog, or bcdedit + recoveryenabled. VSS itself also logs snapshot deletion under source VSS in the Application log (Event ID 8224 among others), which is useful corroboration but easier to miss than a clean 4688 command line.

The uncomfortable truth: on a default Windows install, command-line process auditing is off, so the very event that would catch this is not being recorded. Turning it on is a one-time, zero-cost hardening step — and it pays off far beyond shadow copies.

How WinSentinel checks this

WinSentinel's Event Log Analysis and recovery-posture checks fold this into a single local audit, so you do not have to remember five different command aliases:

• Command-line auditing enabled? — verifies Process Creation auditing and ProcessCreationIncludeCmdLine_Enabled are on, so the 4688 evidence trail actually exists.
• Recovery posture — flags System Protection disabled, VSS set to Disabled, and suspiciously capped shadow storage.
• Tampering detection — scans recent 4688 events for the known shadow-copy / recovery-deletion command patterns and raises them as high-severity findings mapped to T1490.

Everything above is a local, single-machine audit and it is free. Run winsentinel --audit and the event-log module reports whether recovery is being recorded and whether anything has tried to tamper with it. For organizations, WinSentinel Pro rolls these findings up across an entire fleet so one wiped-snapshot event on one endpoint surfaces on a central dashboard instead of dying in a log nobody reads — because with ransomware, the machine that gets hit first is the warning for all the others.

The takeaway

Shadow-copy deletion is where ransomware tips its hand before it does real damage. The defensive move is boring and effective: keep System Protection on with sane shadow storage, turn on command-line process auditing so the deletion attempts are recorded, and alert on the small fixed set of commands that do the deed. Audit it once, and you convert one of ransomware's favorite quiet preludes into your loudest early warning.