Detect Shadow Copy and Backup Catalog Deletion via vssadmin/wbadmin/wmic in CrowdStrike LogScale
Deleting Volume Shadow Copies and local Windows Server Backup catalogs is one of the most consistent pre-encryption steps observed across ransomware operators, because it removes the victim's fastest and cheapest recovery path before file encryption begins. Attackers who have already escalated privileges typically run one or more of: `vssadmin delete shadows /all /quiet` (bulk-deletes all shadow copies on all volumes, silently), `wmic shadowcopy delete` (the WMI equivalent, often used because vssadmin can be blocked by application allowlisting while wmic is overlooked), `wbadmin delete catalog -quiet` or `wbadmin delete systemstatebackup` (removes the local Windows Server Backup catalog and system-state backups so `wbadmin` itself can no longer be used to restore), and `bcdedit /set {default} recoveryenabled no` combined with `bcdedit /set {default} bootstatuspolicy ignoreallfailures` (disables the Windows Recovery Environment and automatic repair so a damaged/encrypted boot volume cannot self-heal). These four commands appear near-verbatim in incident reports for LockBit, Akira, Black Basta, BlackCat/ALPHV, Conti, and Ryuk, frequently chained together in a single batch script or PowerShell one-liner and executed seconds to minutes before the encryptor binary runs. The commands are legitimate, signed Windows administration utilities (LOLBins), so detection must key on the destructive argument combinations (bulk `delete shadows /all`, `shadowcopy delete`, `delete catalog`/`delete systemstatebackup`, `recoveryenabled no`) rather than on the binaries themselves, and correlate bursts of these commands across short windows and/or multiple hosts as the highest-confidence signal of an imminent or in-progress ransomware detonation.
MITRE ATT&CK
- Tactic
- Impact
LogScale Detection Query
#event_simpleName=ProcessRollup2
(
(FileName=/^vssadmin\.exe$/i CommandLine=/delete.*shadow/i) OR
(FileName=/^wmic\.exe$/i CommandLine=/shadowcopy.*delete/i) OR
(FileName=/^wbadmin\.exe$/i CommandLine=/delete.*(catalog|systemstatebackup|backup)/i) OR
(FileName=/^bcdedit\.exe$/i CommandLine=/(recoveryenabled\s+no|bootstatuspolicy\s+ignoreallfailures)/i)
)
| Technique := case([
FileName=/^vssadmin\.exe$/i, "vssadmin_delete_shadows";
FileName=/^wmic\.exe$/i, "wmic_shadowcopy_delete";
FileName=/^wbadmin\.exe$/i, "wbadmin_delete_catalog_or_backup";
FileName=/^bcdedit\.exe$/i, "bcdedit_recovery_tamper";
true(), "Other"
])
| groupBy([ComputerName, UserName], function=[count(as=Events), collect(Technique, limit=20)])
| sort(Events, order=desc)CrowdStrike LogScale query over ProcessRollup2 events for the recovery-inhibition command set. Flags vssadmin/wmic/wbadmin/bcdedit executions with destructive argument combinations, grouped by host/user for triage. Recommend a companion scheduled search requiring 2+ distinct Technique values within a 30-minute window to reproduce the multi-command burst scoring.
Data Sources
Required Tables
False Positives & Tuning
- Scheduled backup maintenance jobs pruning shadow copies or backup catalogs
- Administrators manually reclaiming shadow copy storage
- Golden-image pipelines adjusting bcdedit settings
- VM/disk imaging tools clearing shadow copy state
Other platforms for THREAT-Impact-VSSShadowCopyDeletion
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Delete All Volume Shadow Copies via vssadmin
Expected signal: Sysmon/DeviceProcessEvents/Security 4688 process creation: FileName=vssadmin.exe, CommandLine contains 'delete shadows /all /quiet'.
- Test 2Delete Shadow Copies via WMIC
Expected signal: Sysmon/DeviceProcessEvents/Security 4688 process creation: FileName=wmic.exe, CommandLine contains 'shadowcopy delete'.
- Test 3Delete Local Backup Catalog via wbadmin
Expected signal: Sysmon/DeviceProcessEvents/Security 4688 process creation: FileName=wbadmin.exe, CommandLine contains 'delete catalog -quiet'.
- Test 4Disable Windows Recovery Environment via bcdedit
Expected signal: Sysmon/DeviceProcessEvents/Security 4688 process creation: FileName=bcdedit.exe, two events with CommandLine containing 'recoveryenabled no' and 'bootstatuspolicy ignoreallfailures' respectively.
References (7)
- https://attack.mitre.org/techniques/T1490/
- https://attack.mitre.org/tactics/TA0040/
- https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/vssadmin
- https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/wbadmin
- https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/bcdedit--set
- https://www.cisa.gov/news-events/cybersecurity-advisories
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1490/T1490.md
Response Playbook
Triage
- Identify exactly which commands fired on the host (vssadmin, wmic, wbadmin, bcdedit, or the PowerShell WMI variant) and in what order — a full set (shadow-copy deletion + backup catalog deletion + recovery-environment disablement) within a short window is a near-certain ransomware precursor, not routine admin activity
- Check the initiating process and parent process chain: was this launched interactively by a logged-on admin, or spawned by a script/scheduled task/remote execution tool (PsExec, WMI, RDP session, RMM agent) — the latter is far more consistent with an attacker executing a pre-encryption batch script
- Determine whether the same account or a related set of accounts triggered this pattern on multiple hosts in a short window — recovery-inhibition is frequently pushed environment-wide via GPO, PsExec, or an RMM tool immediately before mass encryption
- Correlate against recent authentication and privilege-escalation events for the account involved (new admin group membership, unusual logon type, off-hours activity) to assess whether the account itself is compromised
- Check for concurrent or immediately-following indicators of the encryption stage itself: mass file rename/write activity, a new unsigned/unknown binary executing across multiple hosts, EDR/AV tampering, or Volume Shadow Copy service (VSS) being stopped — this materially raises urgency from 'investigate' to 'active incident'
Containment
- Isolate the affected host(s) from the network immediately (EDR network isolation or physical disconnection) to prevent the same session from proceeding to mass encryption or lateral movement
- Disable or force-expire the credentials of the account that executed the commands, and revoke any active sessions (RDP, PsExec admin$ shares, WMI) associated with it
- If multiple hosts show the pattern, assume an environment-wide event is in progress: pre-emptively isolate high-value servers (domain controllers, file servers, backup infrastructure) that have not yet shown the indicator before the attacker reaches them
- Verify the integrity and isolation of offsite/immutable/air-gapped backups immediately — do not wait for full scoping, since these commands specifically target the on-host recovery path and the attacker's next move is often to also target reachable network backup infrastructure
Evidence Collection
- Full process-creation record (command line, parent process, initiating user, logon session, PID/GUID) for every matched vssadmin/wmic/wbadmin/bcdedit/PowerShell event
- Preceding 24-48 hours of process, logon, and remote-execution telemetry for the source host and account to reconstruct how the attacker obtained the privileges needed to run these commands
- A list of any files, scripts, or scheduled tasks left on disk that reference these commands (batch files, PowerShell scripts, GPO startup scripts) for malware/toolkit attribution
- Endpoint memory/disk forensic image of the affected host(s) if resources allow, prior to any remediation reboot, since ransomware precursor activity is frequently followed within minutes by encryption
Escalation Criteria
- !Shadow-copy deletion, backup-catalog deletion, and recovery-environment disablement are all observed on the same host within a short window — this combination has essentially no legitimate single-actor use case
- !The pattern is observed across more than one host in the same time window, indicating scripted or centrally-pushed execution
- !The account or process chain shows signs of compromise (unfamiliar RMM/remote-execution tool, off-hours execution, recently elevated privileges)
- !Any concurrent indicator of active encryption, EDR/backup-agent tampering, or mass file modification is observed on the same or related hosts
Investigation Guide
Related Techniques
Forensic Artifacts
- >
Process-creation events (Sysmon Event ID 1, Security Event ID 4688, DeviceProcessEvents) for vssadmin.exe, wmic.exe, wbadmin.exe, bcdedit.exe, and powershell.exe with the matching command-line arguments - >
Windows Application/System Event Log entries generated by the VSS writer/service (Event IDs 8193/8194/12289 and related) reflecting shadow copy deletion - >
Prefetch and Amcache entries confirming execution of vssadmin.exe/wbadmin.exe/bcdedit.exe on the host, useful when process-creation logging was not enabled at the time - >
Any dropped batch/PowerShell scripts, scheduled tasks, or GPO startup scripts referencing these commands, which frequently also contain the ransomware payload's staging or execution logic - >
BCD (Boot Configuration Data) store contents showing recoveryenabled/bootstatuspolicy state changes, retrievable via `bcdedit /enum all` for comparison against the pre-incident baseline
Tuning Guidance
Build an allowlist of known backup service accounts, RMM/imaging automation identities, and the specific hosts (backup servers, golden-image build agents) that legitimately run vssadmin/wbadmin/bcdedit on a schedule, and suppress or down-rank alerts from that allowlist by account/host rather than by command — the command syntax itself is identical between legitimate maintenance and ransomware precursor activity. Keep the highest-severity tier reserved for the multi-command combination (shadow-copy deletion plus backup-catalog deletion plus recovery-environment disablement on the same host within 30 minutes), since any single command in isolation has meaningfully more legitimate use than the full combination. Cross-correlate with the cloud control-plane equivalent (THREAT-CloudBackup-SnapshotPurge) and with EDR/AV-tampering and mass-encryption detections, since ransomware operators rarely execute recovery-inhibition in isolation from the rest of the pre-encryption kill chain.
Hunting Queries
30-day baseline hunt across all four recovery-inhibition commands to establish which accounts/hosts run them routinely (backup service accounts, imaging pipelines) versus which show a first-time or rare execution — a rare account or workstation-class device running these commands is significantly higher-suspicion than a known backup server.
// Hunt: 30-day baseline of all recovery-inhibition command executions, to distinguish routine backup/admin tooling from anomalous first-time callers
DeviceProcessEvents
| where Timestamp > ago(30d)
| where (FileName =~ "vssadmin.exe" and ProcessCommandLine has "delete")
or (FileName =~ "wmic.exe" and ProcessCommandLine has "shadowcopy")
or (FileName =~ "wbadmin.exe" and ProcessCommandLine has "delete")
or (FileName =~ "bcdedit.exe" and (ProcessCommandLine has "recoveryenabled" or ProcessCommandLine has "bootstatuspolicy"))
| summarize Executions = count(), Hosts = dcount(DeviceName), FirstSeen = min(Timestamp), LastSeen = max(Timestamp) by FileName, AccountName
| sort by Executions descindex=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
(Image="*\\vssadmin.exe" CommandLine="*delete*")
OR (Image="*\\wmic.exe" CommandLine="*shadowcopy*")
OR (Image="*\\wbadmin.exe" CommandLine="*delete*")
OR (Image="*\\bcdedit.exe" (CommandLine="*recoveryenabled*" OR CommandLine="*bootstatuspolicy*"))
| stats count as Executions, dc(host) as Hosts, earliest(_time) as FirstSeen, latest(_time) as LastSeen by Image, User
| sort - ExecutionsAtomic Red Team Tests
Runs vssadmin's bulk shadow-copy deletion command exactly as used by ransomware operators to remove local recovery points. Run only in an isolated test VM with disposable shadow copies — this is destructive to any existing restore points on the host.
Command
vssadmin delete shadows /all /quietCleanup
wbadmin enable backup -addtarget:<TEST_BACKUP_TARGET> -schedule:22:00 (or simply snapshot/revert the disposable test VM rather than attempting to recreate shadow copies)Expected Telemetry
Sysmon/DeviceProcessEvents/Security 4688 process creation: FileName=vssadmin.exe, CommandLine contains 'delete shadows /all /quiet'.
Expected Detection
Alert fires with Technique=vssadmin_delete_shadows, MaxRisk=95.
Runs the WMIC equivalent of vssadmin shadow-copy deletion, the variant attackers use to bypass application-control rules that only block vssadmin.exe. Run only in a disposable test VM.
Command
wmic shadowcopy deleteCleanup
Snapshot/revert the disposable test VM; no in-place recreation of shadow copies is required for test cleanup.Expected Telemetry
Sysmon/DeviceProcessEvents/Security 4688 process creation: FileName=wmic.exe, CommandLine contains 'shadowcopy delete'.
Expected Detection
Alert fires with Technique=wmic_shadowcopy_delete, MaxRisk=95.
Deletes the local Windows Server Backup catalog, removing the record of all backups so wbadmin can no longer be used to restore, exactly as observed in ransomware pre-encryption playbooks. Run only against a disposable test backup catalog on an isolated VM.
Command
wbadmin delete catalog -quietCleanup
Reinitialize Windows Server Backup on the disposable test VM and run a fresh on-demand backup job to rebuild a test catalog, or discard the VM entirely.Expected Telemetry
Sysmon/DeviceProcessEvents/Security 4688 process creation: FileName=wbadmin.exe, CommandLine contains 'delete catalog -quiet'.
Expected Detection
Alert fires with Technique=wbadmin_delete_catalog_or_backup, MaxRisk=95.
Disables automatic recovery and forces the boot manager to ignore all boot failures, preventing Windows Recovery Environment from self-repairing after an encryption event. Run only on a disposable test VM and revert the BCD store afterward.
Command
bcdedit /set {default} recoveryenabled no && bcdedit /set {default} bootstatuspolicy ignoreallfailuresCleanup
bcdedit /set {default} recoveryenabled yes && bcdedit /set {default} bootstatuspolicy displayallfailuresExpected Telemetry
Sysmon/DeviceProcessEvents/Security 4688 process creation: FileName=bcdedit.exe, two events with CommandLine containing 'recoveryenabled no' and 'bootstatuspolicy ignoreallfailures' respectively.
Expected Detection
Alert fires with Technique=bcdedit_disable_recovery and Technique=bcdedit_ignore_boot_failures, MaxRisk=80; combined with the vssadmin/wbadmin tests above in the same 30-minute window, the summarized event shows all commands under one DeviceName/AccountName bucket.
Related Detections
Tactic Hub
Detection Variants (1)
Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.