Hunting Ransomware Precursors: Shadow Copy Deletion Before the Encryption Starts

Case file: the quiet step before the loud one

Ransomware is loud. The ransom note, the encrypted extensions, the help-desk tickets — nobody misses detonation. But the steps before detonation are quiet, and one of the quietest is also one of the most telling: deleting shadow copies. Before encrypting a single file, most ransomware strains run vssadmin delete shadows /all /quiet or wmic shadowcopy delete to destroy the victim's built-in recovery option. No backups to restore from means the ransom demand carries weight.

That makes shadow copy deletion a high-value precursor — a behavior that reliably precedes impact. It maps to MITRE ATT&CK T1490 (Inhibit System Recovery), and it appears in the playbooks of virtually every major ransomware family. The evidence is crisp: two specific binaries, a handful of known command-line patterns, and almost no legitimate reason for an interactive user to run them. When this hunt fires, treat the clock as already ticking.

The hypothesis

If ransomware is staging on a host in our environment, then we will observe vssadmin.exe or wmic.exe executed with shadow-deletion arguments (delete shadows, shadowcopy delete, resize shadowstorage), or direct tampering with the Volume Shadow Copy service — outside of sanctioned backup-administration activity.

Data you'll need

Log source	Table / index	What it gives you
Microsoft Defender for Endpoint	DeviceProcessEvents, DeviceEvents	Process launches with full command lines; service-stop events
Windows System log	EventCode 7036 / 7045 (index=wineventlog)	VSS service state changes and new service installs
Sysmon	EventCode 1	Parent process of the deletion command

Hunting with KQL

Cast a wide net over every known shadow-copy destruction pattern — the classic commands, the storage-resize trick that starves shadow copies to zero, and the service-disable variant.

// Hunt: shadow copy deletion / VSS tampering precursors
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where (FileName =~ "vssadmin.exe"
         and ProcessCommandLine has_any ("delete shadows", "resize shadowstorage"))
    or (FileName =~ "wmic.exe"
        and ProcessCommandLine has_all ("shadowcopy", "delete"))
    or (FileName =~ "powershell.exe"
        and ProcessCommandLine has_any ("delete shadows", "shadowcopy delete",
            "Stop-Service VSS", "vssadmin", "Get-WmiObject Win32_ShadowCopy"))
    or (FileName =~ "sc.exe"
        and ProcessCommandLine has_all ("vss", "delete"))
| extend Technique = case(
    FileName =~ "vssadmin.exe", "vssadmin delete/resize",
    FileName =~ "wmic.exe", "wmic shadowcopy delete",
    FileName =~ "sc.exe", "service deletion",
    "powershell variant")
| project TimeGenerated, DeviceName, InitiatingProcessFileName,
    InitiatingProcessCommandLine, FileName, ProcessCommandLine,
    InitiatingProcessAccountName, Technique
| order by TimeGenerated desc

What this does: the query matches each known T1490 execution pattern and labels the technique variant, so you can see at a glance whether the attacker used the classic vssadmin route or a PowerShell/WMI alternative. The parent process columns are the real prize — ransomware droppers, not backup admins, are what you're looking for.

Watch for the quieter variants too. Some strains avoid vssadmin entirely and instead stop the service, delete its registry keys, or use bcdedit to disable recovery:

// Hunt: VSS service tampering and recovery-disable variants
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where ProcessCommandLine has_any (
        "net stop vss", "sc stop vss", "sc config vss",
        "bcdedit", "recoveryenabled no", "bootstatuspolicy ignoreallfailures")
    and FileName in~ ("net.exe", "sc.exe", "bcdedit.exe", "cmd.exe", "powershell.exe")
| where not(InitiatingProcessAccountName has "backup")
| project TimeGenerated, DeviceName, FileName, ProcessCommandLine,
    InitiatingProcessFileName, InitiatingProcessAccountName

Example: what a true-positive result row looks like

TimeGenerated	2026-09-20 01:47:03 UTC
DeviceName	SRV-FILE-02
InitiatingProcessFileName	svchost.exe (unusual child chain via cmd.exe)
ProcessCommandLine	`vssadmin delete shadows /all /quiet & wmic shadowcopy delete /nointeractive`
Follow-on (4 min later)	Mass file renames to `.locked` extension begin on shared drives
Why it's malicious	Both canonical deletion commands chained in one line, on a file server, at 1:47 a.m., immediately before encryption behavior. This is the precursor firing exactly as designed.

Hunting with Splunk

In Splunk, combine Sysmon process creation with the Windows System log to catch both the deletion command and its effect on the VSS service:

index=sysmon EventCode=1 earliest=-14d
| where match(Image, "(?i)(vssadmin\.exe|wmic\.exe)$")
  AND match(CommandLine, "(?i)(delete shadows|resize shadowstorage|shadowcopy.+delete)")
| table _time, host, user, ParentImage, Image, CommandLine

What this does: it filters Sysmon process-creation events to the two canonical binaries and their destructive arguments. Because Sysmon logs the parent image, you immediately see whether the command came from a backup console or from an intruder's cmd.exe.

index=wineventlog (EventCode=7036 OR EventCode=7040) earliest=-14d
| where match(_raw, "(?i)Volume Shadow Copy")
| table _time, host, EventCode, _raw

Example hit: Sysmon EventCode 1 on SRV-FILE-02 — Image: C:\Windows\System32\vssadmin.exe, CommandLine: vssadmin delete shadows /all /quiet, ParentImage: C:\Windows\System32\cmd.exe, launched by a process whose own parent is a recently dropped executable in C:\ProgramData. Seconds later, System log EventCode 7036 records the Volume Shadow Copy service entering the stopped state. Two independent sources, one story.

Validating the hit

Confirm the shadows are actually gone. Run vssadmin list shadows on the host. If the store is empty and the host previously had restore points, the deletion succeeded — recovery options are degraded.
Identify the parent and the dropper. Trace the process tree upward: what launched cmd.exe? Look for a recently written executable, a malicious service (EventCode 7045), or a scheduled task created in the same window.
Check for concurrent ransomware staging. Search the host for the other precursors that travel with T1490: disabled Defender, deleted event logs (wevtutil cl), new ransom-note filenames, and mass file modification. One precursor is a warning; three is a detonation in progress.
Scope immediately. Query the same command-line patterns across all hosts for the last 30 days. Ransomware operators routinely stage on multiple machines and detonate simultaneously.

Tuning out false positives

Backup administrators: legitimate backup software and storage admins manage shadow copies with vssadmin. Exclude known backup service accounts and management hosts — but verify the parent chain anyway, since attackers love to hide behind admin tooling.
Disk-space maintenance: vssadmin resize shadowstorage is occasionally used legitimately to reclaim disk space. Correlate with change tickets; unplanned resizes to tiny values at odd hours are not maintenance.
VDI / imaging workflows: golden-image build pipelines sometimes clear shadow copies. Restrict exclusions to the build subnet and the imaging service account.

What to do next

A true positive here is a P1 incident. Isolate the host from the network immediately — but do not power it off, since memory forensics may be your only view into the staging malware. Verify your offline backups are intact and disconnected before the attacker finds them too. Engage your incident response plan, notify stakeholders, and sweep the environment for lateral movement: by the time shadow copies are being deleted, the intruder has usually been inside for days. Document the full precursor timeline — it becomes the backbone of your post-incident report and your detection engineering backlog.

Next in this series: DNS tunneling and data exfiltration — hunting the quiet channel attackers use to steal data out.