How to detect shadow copy deletion

In this page

Threat snapshot

Deleting shadow copies is one of the most reliable signals that a ransomware attack is seconds away from its encryption phase. Shadow copies, the local backup snapshots created by Windows Volume Shadow Copy Service, are the fastest recovery path for most organizations after a file-encrypting attack. Ransomware operators know this. Removing them before the encryptor runs is standard practice across virtually every ransomware family active today, from LockBit to BlackCat to Ryuk.

The deletion itself takes seconds and leaves a clear trail in Windows process creation logs. That trail is the detection opportunity. vssadmin, wmic, diskshadow, and wbadmin are all legitimate system utilities, but their use for shadow copy deletion or backup catalog removal in an enterprise environment outside of a documented backup window is almost never legitimate. BCDEdit tampering with boot recovery flags follows the same logic. These commands fired in combination, or in rapid sequence, represent one of the highest-confidence ransomware pre-staging signals available.

Log360 detects shadow copy deletion and recovery inhibition activity across all the primary vectors: vssadmin and wmic shadow copy deletion, wbadmin backup catalog deletion, BCDEdit boot recovery disabling, and Diskshadow script mode abuse. With 16 detection rules mapped to this use case, it covers the full range of T1490 (Inhibit System Recovery) behavior documented in real-world ransomware incidents.

Shadow copy deletion, at a glance

Severity Critical
Category Ransomware & Extortion
MITRE ATT&CK tactic TA0040 Impact
MITRE technique T1490 Inhibit System Recovery
Sub-techniques covered vssadmin shadow deletion, wmic shadowcopy delete, wbadmin catalog deletion, BCDEdit recovery tampering, Diskshadow script abuse
Platforms covered Windows
Log360 detection rules 16 rules
SOC maturity level Level 3 - Incident Response
Compliance mapping NIST CSF RC.RP-1, PCI-DSS 12.10, HIPAA Section 164.308(a)(6), ISO 27001 A.17.1

How shadow copy deletion works

Windows Volume Shadow Copy Service (VSS) creates point-in-time snapshots of volumes that users and backup tools can access to restore individual files or entire drive states without a full backup restoration. For most organizations, shadow copies are the first line of recovery after accidental deletion, ransomware encryption, or file corruption. Ransomware operators treat them as the primary obstacle to forcing payment.

vssadmin and wmic: the most common deletion vectors

The two most widely used commands for deleting shadow copies are vssadmin delete shadows /all /quiet and wmic shadowcopy delete. Both are built-in Windows utilities, so no additional tooling is needed. The /quiet flag on vssadmin suppresses confirmation prompts. Both commands generate process creation events (Windows Security Event 4688 or Sysmon Event 1) with the full command line visible, making them straightforward to detect if process creation auditing is enabled.

Ransomware groups frequently run these commands through a parent process that provides plausible deniability: cmd.exe launched by a scheduled task, or PowerShell called from a service context. The parent process chain is the additional signal that distinguishes a legitimate administrator action from a ransomware pre-staging sequence.

wbadmin backup catalog deletion

wbadmin delete catalog -quiet removes the Windows Server Backup catalog, destroying the index of available backup points without deleting the actual backup files. This is a subtler form of recovery inhibition: the backup data may still exist on the backup target, but the system cannot locate or restore from it without significant manual reconstruction. This command is particularly targeted at Windows Server environments where Windows Server Backup is the primary backup mechanism.

BCDEdit boot recovery tampering

BCDEdit /set {default} recoveryenabled no and BCDEdit /set {default} bootstatuspolicy ignoreallfailures disable Windows Recovery Environment, preventing the system from booting into recovery mode after an encryption-induced boot failure. This is almost always run in combination with shadow copy deletion, ensuring that both the file-level and boot-level recovery paths are eliminated before encryption begins.

Diskshadow script mode abuse

Diskshadow is a less commonly known VSS management utility that supports scripted operations. Ransomware operators and red teamers use Diskshadow script mode to execute VSS deletion commands in ways that may not match signatures written specifically for vssadmin or wmic. Diskshadow execution from non-standard locations or with unusual script file extensions is a signal that the utility is being used for something other than its administrative purpose.

Real-world campaigns

LockBit: automated shadow deletion as standard procedure

LockBit affiliates include vssadmin delete shadows /all /quiet as a standard pre-encryption step, typically executed through a cmd.exe process launched by the ransomware binary itself. The command runs within seconds of the encryptor being deployed. In LockBit 3.0 incidents, the shadow copy deletion, Defender disabling, and encryption steps have been observed completing in under two minutes on individual hosts.

Ryuk: wbadmin targeting Windows Server Backup

Ryuk has been documented specifically targeting wbadmin catalog deletion on Windows Server hosts, reflecting an understanding that enterprise environments often rely on Windows Server Backup as the primary on-premises backup solution. Ryuk operators also use net stop commands to stop the Volume Shadow Copy service itself before attempting deletion, adding a service stop event to the detection sequence.

BlackCat/ALPHV: Diskshadow as an evasion technique

BlackCat affiliates have been observed using Diskshadow in script mode as an alternative to vssadmin, likely to evade detection rules specifically pattern-matched on vssadmin command lines. Diskshadow scripts are written to temporary files and executed via the diskshadow.exe /s flag, producing a process creation event with the script file path rather than the deletion arguments directly in the command line.

Business impact

  • Recovery without shadow copies is measured in days or weeks, not hours: When shadow copies are deleted and no off-site backup exists or the off-site backup is also compromised, full recovery requires rebuilding systems from scratch or paying the ransom. The deletion of shadow copies directly correlates with the ransom payment rate in documented incidents because it eliminates the free recovery option.
  • Every minute of delay after shadow copy deletion increases encryption exposure: Shadow copy deletion is a pre-encryption step, but it happens very close to encryption. In fast-moving ransomware operations, the window between detecting shadow copy deletion and the first encrypted file may be under five minutes. Detection and response must be near-immediate to have any effect on the blast radius.
  • Windows Server environments face additional exposure through wbadmin targeting: Organizations relying on Windows Server Backup as their primary backup mechanism face complete recovery path destruction if wbadmin catalog deletion runs successfully. Off-site backup integrity should be verified immediately when this signal fires.

Detecting shadow copy deletion with Log360

The rules below cover the primary shadow copy deletion and recovery inhibition vectors. For process creation events, Windows Security Event 4688 must be enabled with command-line auditing, or Sysmon Event 1 must be deployed. Without command-line capture, the detection coverage for these rules drops significantly because the process name alone (vssadmin.exe, wbadmin.exe) is not sufficient to distinguish deletion commands from legitimate administrative use.

Rule name Severity Platform MITRE technique What it detects
Potential Ransomware or Unauthorized MBR Tampering Via Bcdedit.EXE Trouble Windows T1070 BCDEdit executed with arguments that disable Windows Recovery Environment (recoveryenabled no, bootstatuspolicy ignoreallfailures). Nearly always part of a ransomware pre-staging sequence when combined with shadow copy deletion events on the same host.
Disabled Volume Snapshots Trouble Windows T1562.001 Registry modification or command execution that disables the Volume Shadow Copy service itself, preventing new snapshots from being created and making existing ones inaccessible.
Diskshadow Script Mode Execution Trouble Windows T1218 Diskshadow executed with the /s flag to run a script file, the pattern used by BlackCat and other ransomware affiliates to delete shadow copies via Diskshadow rather than vssadmin, evading signature-based detection for vssadmin.
Diskshadow Script Mode - Execution From Potential Suspicious Location Trouble Windows T1218 Diskshadow script execution where the script file is located in a temp directory, user profile, or other non-administrative path, distinguishing attacker-controlled scripts from legitimate backup administration scripts.
Diskshadow Script Mode - Uncommon Script Extension Execution Trouble Windows T1218 Diskshadow script executed with an unusual file extension (anything other than .dsh or .txt), a technique used to avoid file extension-based detection rules.
Diskshadow Child Process Spawned Trouble Windows T1218 A child process launched by diskshadow.exe, which can indicate the script being used to execute additional commands or spawn further tooling beyond shadow copy deletion.
Amsi.DLL Load By Uncommon Process Attention Windows T1490 An uncommon process loading AMSI.DLL, which can indicate an attempt to bypass antimalware scanning before executing the shadow copy deletion commands, a pattern observed in some ransomware pre-staging sequences.
Shadow Copies Creation Using Operating Systems Utilities Trouble Windows T1003 Operating system utilities used to interact with VSS, providing context for correlating legitimate shadow copy creation activity against deletion events on the same host.
Sensitive File Dump Via Wbadmin.EXE Trouble Windows T1003.003 wbadmin used to dump specific files from backup, a behavior that overlaps with ransomware operators using wbadmin to access backup contents before destroying the catalog.

Attack chain visibility

Shadow copy deletion does not happen in isolation. The sequence below shows how it fits into the broader pre-encryption sequence and what Log360 sees at each step.

Step Log source and event What it indicates Time offset
1 Windows Event 4688 / Sysmon Event 1 - vssadmin.exe with 'delete shadows /all /quiet' Primary shadow copy deletion. Log360 correlates against the Disabled Volume Snapshots and Potential Ransomware via Bcdedit.EXE rules. This event alone, without prior context, should generate a high-priority alert and immediate investigation. T+0
2 Windows Event 4688 / Sysmon Event 1 - wmic shadowcopy delete (if run in addition to vssadmin) Secondary deletion confirmation. Some ransomware operators run both commands to ensure all shadow copies are removed regardless of which VSS interfaces are available. T+0 to T+30 sec after step 1
3 Windows Event 4688 / Sysmon Event 1 - wbadmin delete catalog -quiet Backup catalog destruction. Combined with the shadow copy deletion in steps 1 and 2, this confirms systematic elimination of all local recovery options. Escalate immediately. T+30 sec to T+2 min
4 Windows Event 4688 / Sysmon Event 1 - bcdedit /set {default} recoveryenabled no Boot recovery disabled. Potential Ransomware or Unauthorized MBR Tampering Via Bcdedit.EXE rule fires. At this point all local recovery paths have been eliminated and encryption is imminent. T+concurrent with or immediately after step 3
5 High-velocity Windows file audit events (Event 4663) - mass file renames and modifications Active encryption begins. The window between step 4 and step 5 may be under two minutes in fast-moving ransomware deployments. Isolation decisions must be made before this step. T+1 to T+5 min after step 4

Investigation playbook

Step 1: Confirm the deletion command and scope

  • Query Log360 for all vssadmin.exe, wmic.exe, diskshadow.exe, and wbadmin.exe process creation events on the alerting host in the 10 minutes surrounding the alert. Establish whether one or multiple deletion methods were used and whether the commands ran to completion (check for error events if available).
  • Identify the parent process that launched the deletion command. A cmd.exe or PowerShell process spawned by a non-administrative application, a scheduled task with an unusual name, or a service process with no corresponding legitimate service are the highest-priority parent process signals.
  • Determine whether BCDEdit tampering events appear on the same host in the same window. The combination of shadow copy deletion and BCDEdit recovery disabling represents a complete local recovery elimination sequence and should trigger immediate incident declaration.

Step 2: Determine whether this is pre-encryption or active encryption

  • Query Log360 for high-velocity file modification events (Event 4663) on the same host. If bulk file modifications appear within minutes of the shadow copy deletion, encryption has begun or is running concurrently. Switch to the encryption response playbook immediately.
  • If no bulk file modifications are present, the detection may have caught the pre-encryption phase before the encryptor deployed. This is the best-case scenario and leaves a window for isolation before encryption begins.
  • Check whether the Excessive Attempt To Disable Services rule has fired on the same host. Mass service disabling combined with shadow copy deletion is a near-certain pre-encryption sequence even without active file encryption events.

Step 3: Investigate lateral scope

  • Query the account used to run the deletion commands against all domain hosts for the prior 24 hours using Event 4624 Type 3 logons. If the same account has authenticated to multiple hosts, shadow copy deletion may have already run or may be running on those hosts as well.
  • Check whether the same process creation events appear on other hosts in the environment. Ransomware operators running lateral movement via PsExec or admin shares will deploy the pre-encryption scripts to all target hosts, and shadow copy deletion events will appear across many machines in a short window.

Response and remediation

Immediate actions

  • Isolate the host from the network immediately: Do not wait to complete the investigation before isolating. If shadow copy deletion and BCDEdit tampering have both fired, encryption is likely seconds to minutes away. Network isolation stops the encryptor from receiving any additional commands and prevents lateral movement from reaching additional hosts.
  • Verify off-site backup integrity before any recovery decision: If shadow copies and backup catalogs have been deleted, on-premises recovery is not available. Contact the backup team to verify whether off-site or cloud backups exist and whether the backup agent service on the backup server was targeted. Veeam infrastructure should be checked specifically for the Veeam Backup Database Suspicious Query alert in the same window.
  • Do not reboot the host: BCDEdit tampering means the system may not boot normally after shutdown. Preserve the host in its current running state for forensic imaging before any shutdown or reboot.

False positive tuning

False positive source Rules affected Tuning strategy
Backup software running scheduled VSS operations Disabled Volume Snapshots, Shadow Copies Creation Create a time-bounded exception scoped to the backup service account (e.g., NT SERVICE\VSS or the Veeam service account) and the scheduled backup window. Any VSS interaction from a different account, or outside the backup window, should continue to alert without exception.
Disk cleanup or storage management tools Diskshadow Script Mode Execution Allowlist the specific script files used by storage management tools by their full path and hash. Any Diskshadow execution from a path not in the allowlist, or with a script file not matching the known hash, should still alert.
Administrators manually managing shadow copy storage limits Potential Ransomware or Unauthorized MBR Tampering Via Bcdedit.EXE This rule should almost never be suppressed. BCDEdit with recovery-disabling arguments has no routine administrative justification in production environments. If a legitimate use case exists, require a change ticket and create a break-glass exception with mandatory SOC notification.