T1490

Inhibit System Recovery

Impact Last updated:

Adversaries may delete or remove built-in data and turn off services designed to aid in the recovery of a corrupted system to prevent recovery. This includes deleting Volume Shadow Copies (VSS), disabling Windows Recovery Environment (WinRE), clearing backup catalogs, and modifying Boot Configuration Data (BCD). This technique is almost universally observed as a pre-encryption step in ransomware attacks, executed within seconds to minutes before the encryption payload is launched. Real-world ransomware families including Ryuk, Black Basta, Medusa, RobbinHood, WastedLocker, EKANS, and Ragnar Locker all employ this technique to maximize the irreversibility of damage.

What is T1490 Inhibit System Recovery?

Inhibit System Recovery (T1490) maps to the Impact tactic — the adversary is trying to manipulate, interrupt, or destroy your systems and data in MITRE ATT&CK.

This page provides production-ready detection logic for Inhibit System Recovery, covering the data sources and telemetry it touches: Process: Process Creation, Command: Command Execution, Microsoft Defender for Endpoint. The queries below are rated high severity at high confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Impact
Technique
T1490 Inhibit System Recovery
Canonical reference
https://attack.mitre.org/techniques/T1490/
Microsoft Sentinel / Defender
kusto 
let RecoveryInhibitPatterns = dynamic([
  "delete shadows", "delete catalog", "shadowcopy delete", "delete shadow",
  "recoveryenabled no", "bootstatuspolicy ignoreallfailures",
  "resize shadowstorage", "diskshadow",
  "reagentc"
]);
let ShadowDeleteBinaries = dynamic(["vssadmin.exe", "wmic.exe", "diskshadow.exe", "wbadmin.exe"]);
let BcdEditBinary = dynamic(["bcdedit.exe"]);
let ReagentBinary = dynamic(["reagentc.exe"]);
// VSS and backup catalog deletion
let ShadowDeletes = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ (ShadowDeleteBinaries)
| where ProcessCommandLine has_any (RecoveryInhibitPatterns)
| extend TechniqueCategory = case(
    ProcessCommandLine has_any ("delete shadows", "delete shadow", "shadowcopy delete"), "VSS_Delete",
    ProcessCommandLine has "delete catalog", "BackupCatalog_Delete",
    ProcessCommandLine has "resize shadowstorage", "VSS_Resize",
    "Other"
  )
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
         InitiatingProcessFileName, InitiatingProcessCommandLine, TechniqueCategory;
// BCD boot recovery disable
let BcdDisable = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ (BcdEditBinary)
| where ProcessCommandLine has_any ("recoveryenabled", "bootstatuspolicy", "safeboot")
| extend TechniqueCategory = "BCD_Recovery_Disable"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
         InitiatingProcessFileName, InitiatingProcessCommandLine, TechniqueCategory;
// WinRE disable via REAgentC
let WinREDisable = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName =~ "reagentc.exe"
| where ProcessCommandLine has_any ("/disable", "-disable")
| extend TechniqueCategory = "WinRE_Disable"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
         InitiatingProcessFileName, InitiatingProcessCommandLine, TechniqueCategory;
ShadowDeletes
| union BcdDisable
| union WinREDisable
| sort by Timestamp desc

Detects attempts to inhibit system recovery using native Windows utilities. Monitors for Volume Shadow Copy deletion via vssadmin.exe, wmic.exe, and diskshadow.exe; backup catalog deletion via wbadmin.exe; Boot Configuration Data (BCD) modification to disable recovery mode via bcdedit.exe; and Windows Recovery Environment disabling via reagentc.exe. Uses a union of three sub-queries to categorize each technique variant. Covers all primary ransomware pre-encryption patterns observed in Ryuk, Black Basta, Medusa, RobbinHood, EKANS, and WastedLocker campaigns.

high severity high confidence

Data Sources

Process: Process Creation Command: Command Execution Microsoft Defender for Endpoint

Required Tables

DeviceProcessEvents

False Positives

  • Backup software agents (Veeam, Acronis, Veritas) that manage VSS snapshots as part of their own backup rotation — typically run under dedicated service accounts from known installation paths
  • System administrators manually reclaiming disk space by deleting old shadow copies on storage-constrained systems
  • IT operations scripts that adjust BCD settings during OS migration, sysprep, or imaging workflows
  • Disaster recovery testing procedures that exercise backup and recovery tools in controlled maintenance windows
  • Windows Update and major feature updates that temporarily modify BCD settings during staged upgrades

Sigma rule & cross-platform mapping

The detection logic for Inhibit System Recovery (T1490) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource: 

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for T1490 Sigma rules on detection.fyi

Platform-specific guides for T1490

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-04-13 Research depth: deep
References (10)

Testing Methodology

Validate this detection against 5 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.

  1. Test 1VSS Shadow Copy Deletion via vssadmin

    Expected signal: Sysmon Event ID 1: Process Create with Image=vssadmin.exe, CommandLine='vssadmin.exe delete shadows /all /quiet'. Security Event ID 4688 (if command line auditing enabled) with same details. Microsoft-Windows-Volume-Shadow-Copy/Operational Event ID 8194 on deletion attempt.

  2. Test 2VSS Shadow Copy Deletion via WMI

    Expected signal: Sysmon Event ID 1: Process Create with Image=wmic.exe, CommandLine='wmic shadowcopy delete'. Security Event ID 4688 with same details. WMI activity logs in Microsoft-Windows-WMI-Activity/Operational.

  3. Test 3Boot Recovery Disable via bcdedit

    Expected signal: Two Sysmon Event ID 1 events: first with CommandLine='bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures', second with CommandLine='bcdedit.exe /set {default} recoveryenabled no'. Security Event ID 4688 for each. Both events fire within milliseconds of each other from the same parent.

  4. Test 4Windows Backup Catalog Deletion via wbadmin

    Expected signal: Sysmon Event ID 1: Process Create with Image=wbadmin.exe, CommandLine='wbadmin.exe delete catalog -quiet'. Security Event ID 4688 with same details. Microsoft-Windows-Backup event log will record the catalog deletion operation.

  5. Test 5Ryuk-style VSS Storage Resize to Force Deletion

    Expected signal: Sysmon Event ID 1: Process Create with Image=vssadmin.exe, CommandLine containing 'resize shadowstorage' and '/maxsize=401MB'. Microsoft-Windows-Volume-Shadow-Copy/Operational events as Windows responds to the reduced quota by discarding existing shadow copies.

Response Playbook

Triage

  1. Immediately confirm whether the command actually executed and succeeded: for vssadmin, run 'vssadmin list shadows' — zero results confirms deletion; for bcdedit, run 'bcdedit /enum {default}' and check recoveryenabled and bootstatuspolicy values
  2. Identify the parent process: ransomware typically spawns recovery-inhibiting commands from cmd.exe or powershell.exe which was itself spawned by the ransomware binary — examine InitiatingProcessFileName and InitiatingProcessCommandLine for unknown or suspicious parent executables
  3. Check the user context: was this a service account with expected backup software entitlements, a domain admin with a corresponding change ticket, or an unexpected user context (standard user, compromised account)?
  4. Review the timeline: run 'DeviceProcessEvents | where DeviceName == "<host>" | where Timestamp between (ago(30m)..now()) | project Timestamp, FileName, ProcessCommandLine | sort by Timestamp' — ransomware deployments typically show recovery inhibition commands fired in rapid succession (within 1-2 minutes) from the same parent
  5. Check for file encryption activity: examine DeviceFileEvents for mass file modifications with new extensions (.enc, .locked, or randomized extensions), particularly against documents, images, and database files across multiple directories simultaneously
  6. Look for lateral movement indicators preceding this event: check for unusual remote logons (Event ID 4624 type 3), SMB access to administrative shares (C$, ADMIN$), or PsExec/WMI remote execution in the 60 minutes prior

Containment

  1. If ransomware is confirmed or strongly suspected: immediately isolate the endpoint using EDR network isolation or emergency VLAN change to prevent lateral spread — do NOT power off the system as volatile memory may contain encryption keys
  2. Isolate other endpoints in the same network segment or domain OU if the parent process was launched via a domain admin account, as ransomware spreading via pass-the-hash or credential reuse may have already reached additional hosts
  3. Disable the compromised user account in Active Directory and revoke all Kerberos tickets: 'net user <account> /domain /active:no' and force a KRBTGT password reset if domain admin credentials were involved
  4. If cloud backups or network-attached storage are accessible from the compromised host: immediately revoke access tokens, disconnect cloud backup agents, and take the NAS offline to prevent encryption of online backups
  5. Preserve memory from the isolated endpoint before any remediation: capture a full memory dump using WinPMEM or the EDR's memory acquisition capability — ransomware encryption keys may still be in memory
  6. Block the parent executable hash at the EDR/AV layer across the entire environment to prevent re-infection on other endpoints

Evidence Collection

  1. VSS state: Run 'vssadmin list shadows' and 'Get-WmiObject Win32_ShadowCopy' immediately after containment — document whether any shadow copies remain and their creation timestamps
  2. BCD state: Run 'bcdedit /enum all' and capture output — document the current values of recoveryenabled, bootstatuspolicy, and safeboot for the {default} and {current} entries
  3. WinRE state: Run 'reagentc.exe /info' to document current WinRE status and configuration path
  4. Process tree: Capture the full parent-child process chain using 'Get-WmiObject Win32_Process | Select-Object ProcessId, ParentProcessId, Name, CommandLine | Sort-Object ProcessId' or equivalent EDR query
  5. File system artifacts: Collect the ransomware binary (if identified from the parent process path), any dropped configuration files, and ransom notes — do NOT open ransom notes on the same endpoint
  6. Event logs: Export Security (4624, 4625, 4648, 4672, 4688), System (7045), Sysmon Operational, and Microsoft-Windows-Volume-Shadow-Copy/Operational logs before any remediation
  7. Network connections: Capture current network connections ('netstat -anob') and check DNS cache ('ipconfig /displaydns') for any C2 domains contacted before or during encryption
  8. Registry: Export HKLM\SYSTEM\CurrentControlSet\Services for any new or modified service entries, and HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options for debugger hijacks

Escalation Criteria

  • ! Multiple recovery-inhibiting commands fired in rapid succession from the same parent process within a 2-minute window — this is the definitive ransomware pre-encryption sequence
  • ! Recovery inhibition commands observed on more than 3 endpoints simultaneously or within the same 30-minute window — indicates active ransomware spreading across the network
  • ! The parent process executing recovery commands is an unsigned binary, has an anomalous file path (AppData, Temp, ProgramData), or has a name mimicking legitimate Windows processes
  • ! Evidence of active file encryption detected alongside or immediately following the recovery inhibition commands (mass file modifications with new extensions)
  • ! Domain admin or service account credentials used to execute recovery inhibition commands with no corresponding approved change request
  • ! Recovery inhibition commands preceded by evidence of credential dumping (LSASS access, comsvcs.dll MiniDump), lateral movement (PsExec, WMI remote execution, SMB admin share access), or privilege escalation in the preceding 24 hours

Investigation Guide

Forensic Artifacts

  • > Volume Shadow Copy Service event logs: Microsoft-Windows-Volume-Shadow-Copy/Operational — Event ID 8194 (VSS error on deletion), Event ID 8193 (VSS operation start) — useful for reconstruction even after deletion attempt
  • > Windows Backup event logs: Microsoft-Windows-Backup in Event Viewer — records catalog deletion operations with timestamps and initiating process
  • > BCD store: C:\Boot\BCD (binary) — can be parsed with 'bcdedit /store C:\Boot\BCD /enum all' to see current and historical settings; compare against known-good baseline
  • > WinRE configuration: C:\Windows\System32\Recovery\ReAgent.xml and C:\Recovery\ directory — reagentc status and WIM path
  • > Prefetch files: C:\Windows\Prefetch\VSSADMIN.EXE-*.pf, WMIC.EXE-*.pf, BCDEDIT.EXE-*.pf, DISKSHADOW.EXE-*.pf — execution timestamps even if logs were cleared
  • > USN Journal (C:\$Extend\$UsnJrnl:$J): Records file system changes including deletion of VSS-related files — parse with fsutil or commercial forensics tools
  • > AmCache.hve (C:\Windows\AppCompat\Programs\Amcache.hve): Contains execution evidence for binaries involved in the attack chain, including any novel ransomware executable
  • > ShimCache (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache): Tracks execution of binaries involved in the recovery inhibition chain

Tuning Guidance

The most important tuning step is building an allowlist of legitimate backup software parent processes. VSS management by Veeam (VeeamAgent.exe, veeam.backup.manager.exe), Acronis (AcronisAgent.exe, AcronisTrueImage.exe), Veritas Backup Exec (beremote.exe, BackupExec.exe), and Windows Server Backup itself will regularly trigger this detection. Exclude these by parent process name AND verify they run from expected installation directories (Program Files) under dedicated service accounts. Never exclude based solely on the command line pattern — ransomware can masquerade as backup tools. For BCD modification alerts, Windows Update (TrustedInstaller, WUDFHost, wuauclt.exe) and OS deployment tools (DISM.exe, Setup.exe during in-place upgrades) legitimately modify BCD — exclude these parent process contexts during known maintenance windows. Consider reducing alert severity for single-command detections from known service accounts while retaining high severity for: (1) any execution from unusual parent processes, (2) any execution by interactive user accounts, (3) any combination of two or more distinct recovery-inhibiting commands within 5 minutes, or (4) execution outside known maintenance windows. The multi-command hunting query is significantly higher fidelity than single-command detection and should be the primary triage focus.

Hunting Queries

Hunt for hosts executing multiple recovery-inhibiting commands within a 5-minute window. This is the definitive ransomware pre-encryption pattern — legitimate backup tools use a single tool for a single purpose, while ransomware typically chains several inhibition commands (VSS delete + BCD disable + catalog delete) in rapid sequence from the same parent. Two or more commands within 5 minutes from the same host/user should be treated as a high-confidence ransomware indicator.

Hunting — KQL
kql 
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("vssadmin.exe", "wmic.exe", "diskshadow.exe", "wbadmin.exe", "bcdedit.exe", "reagentc.exe")
| where ProcessCommandLine has_any ("delete shadows", "shadowcopy delete", "delete catalog", "recoveryenabled no", "bootstatuspolicy ignoreallfailures", "/disable")
| summarize CommandCount=count(), UniqueCommands=make_set(ProcessCommandLine), ParentProcesses=make_set(InitiatingProcessFileName), FirstSeen=min(Timestamp), LastSeen=max(Timestamp) by DeviceName, AccountName
| where CommandCount >= 2
| extend TimeDeltaMinutes = datetime_diff('minute', LastSeen, FirstSeen)
| where TimeDeltaMinutes <= 5
| sort by CommandCount desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
  (Image="*\\vssadmin.exe" OR Image="*\\wmic.exe" OR Image="*\\diskshadow.exe" OR
   Image="*\\wbadmin.exe" OR Image="*\\bcdedit.exe" OR Image="*\\reagentc.exe")
  (CommandLine="*delete shadows*" OR CommandLine="*shadowcopy delete*" OR
   CommandLine="*delete catalog*" OR CommandLine="*recoveryenabled no*" OR
   CommandLine="*bootstatuspolicy*" OR CommandLine="*disable*")
| stats count as CommandCount, dc(Image) as UniqueTools, values(CommandLine) as Commands, values(ParentImage) as ParentProcesses, earliest(_time) as FirstSeen, latest(_time) as LastSeen by host, User
| where CommandCount >= 2
| eval TimeDeltaSeconds=LastSeen-FirstSeen
| where TimeDeltaSeconds <= 300
| sort - CommandCount

Hunt for correlation between recovery inhibition commands and mass file creation/modification events (a proxy for encryption activity). Joins VSS/BCD deletion events with hosts showing >50 file operations in a 5-minute window, excluding known backup agent parent processes. This two-signal correlation dramatically increases confidence that ransomware is actively encrypting data alongside the recovery inhibition.

Hunting — KQL
kql 
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("vssadmin.exe", "wmic.exe", "bcdedit.exe", "wbadmin.exe", "diskshadow.exe")
| where ProcessCommandLine has_any ("delete shadows", "shadowcopy delete", "delete catalog", "recoveryenabled no", "bootstatuspolicy ignoreallfailures")
| where InitiatingProcessFileName !in~ ("VeeamAgent.exe", "BackupService.exe", "veeam.backup.manager.exe", "AcronisTrueImage.exe", "AcronisAgent.exe", "beremote.exe", "BackupExec.exe", "vnetd.exe")
| join kind=inner (
    DeviceFileEvents
    | where Timestamp > ago(7d)
    | where ActionType == "FileCreated" or ActionType == "FileModified"
    | where FileName matches regex @"\.[a-z0-9]{4,8}$"
    | where FolderPath !has "Windows" and FolderPath !has "Program Files"
    | summarize EncryptedFileCount=count() by DeviceName, bin(Timestamp, 5m)
    | where EncryptedFileCount > 50
) on DeviceName
| project DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, Timestamp, EncryptedFileCount
| sort by Timestamp desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
  (Image="*\\vssadmin.exe" OR Image="*\\wmic.exe" OR Image="*\\bcdedit.exe")
  (CommandLine="*delete shadows*" OR CommandLine="*shadowcopy delete*" OR CommandLine="*recoveryenabled no*")
  NOT (ParentImage="*\\VeeamAgent.exe" OR ParentImage="*\\AcronisAgent.exe" OR ParentImage="*\\beremote.exe")
| rename host as affected_host
| join type=inner affected_host [
    index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=11
    NOT (TargetFilename="*\\Windows\\*" OR TargetFilename="*\\Program Files*")
    | bucket _time span=5m
    | stats count as FileCreateCount by host, _time
    | where FileCreateCount > 50
    | rename host as affected_host
  ]
| table _time, affected_host, User, Image, CommandLine, ParentImage, FileCreateCount
| sort - _time

Hunt for the Ryuk ransomware-specific VSS shadow storage resize technique. Rather than deleting shadows directly (which can be blocked), Ryuk uses 'vssadmin resize shadowstorage /maxsize=401MB' to shrink the storage allocation to the minimum, forcing Windows to automatically delete existing shadow copies. This technique bypasses some VSS deletion protections and represents a distinct hunting opportunity separate from the main deletion patterns.

Hunting — KQL
kql 
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName =~ "vssadmin.exe"
| where ProcessCommandLine has "resize shadowstorage"
| extend MaxSizeGB = extract(@"/maxsize=(\d+)([GMB]+)", 1, ProcessCommandLine)
| extend MaxSizeUnit = extract(@"/maxsize=\d+([GMB]+)", 1, ProcessCommandLine)
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, MaxSizeGB, MaxSizeUnit, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 Image="*\\vssadmin.exe" CommandLine="*resize shadowstorage*"
| rex field=CommandLine "/maxsize=(?P<MaxSize>\d+)(?P<MaxUnit>[GMBgmb]+)"
| table _time, host, User, CommandLine, MaxSize, MaxUnit, ParentImage, ParentCommandLine
| sort - _time

Atomic Red Team Tests

Test 1 VSS Shadow Copy Deletion via vssadmin
windows

Simulates the most common ransomware recovery inhibition technique: deleting all Volume Shadow Copies using vssadmin.exe. This is the exact command used by Ryuk, Medusa, Black Basta, Ragnar Locker, RobbinHood, and most major ransomware families. WARNING: This will delete real shadow copies on the test system. Run only in an isolated lab environment. The /quiet flag suppresses the confirmation prompt, exactly as malware uses it.

Command

powershell 
vssadmin.exe delete shadows /all /quiet

Cleanup

powershell 
Note: Shadow copies cannot be restored after deletion. Ensure test system has no important recovery points before running this test. Create a new shadow copy post-test with: vssadmin.exe create shadow /for=C:

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=vssadmin.exe, CommandLine='vssadmin.exe delete shadows /all /quiet'. Security Event ID 4688 (if command line auditing enabled) with same details. Microsoft-Windows-Volume-Shadow-Copy/Operational Event ID 8194 on deletion attempt.

Expected Detection

Alert fires on 'delete shadows' pattern match. KQL: TechniqueCategory=VSS_Delete. SPL: VSSDelete=1, RecoveryInhibitScore >= 1. Severity: high.

Test 2 VSS Shadow Copy Deletion via WMI
windows

Simulates the WMI-based VSS deletion variant used by multiple ransomware families. This technique is functionally equivalent to vssadmin deletion but uses a different execution path (wmic.exe), allowing adversaries to vary their approach to evade detections that only look for vssadmin. Also observable as a PowerShell WMI call: Get-WmiObject Win32_ShadowCopy | ForEach-Object { $_.Delete() }.

Command

powershell 
wmic shadowcopy delete

Cleanup

powershell 
Note: Shadow copies cannot be restored after deletion. Create a new shadow copy post-test with: wmic shadowcopy call create Volume='C:\'

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=wmic.exe, CommandLine='wmic shadowcopy delete'. Security Event ID 4688 with same details. WMI activity logs in Microsoft-Windows-WMI-Activity/Operational.

Expected Detection

Alert fires on 'shadowcopy delete' pattern in wmic.exe command line. KQL: TechniqueCategory=VSS_Delete via wmic. SPL: VSSShadowCopy=1, RecoveryInhibitScore >= 1.

Test 3 Boot Recovery Disable via bcdedit
windows

Disables Windows automatic recovery options by modifying Boot Configuration Data (BCD). This two-command sequence is used by Ryuk, H1N1, and other ransomware families to prevent Windows from offering automatic startup repair after encryption renders the OS unbootable. 'bootstatuspolicy ignoreallfailures' suppresses recovery prompts; 'recoveryenabled no' disables the Windows Recovery Environment from the boot menu.

Command

powershell 
bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures && bcdedit.exe /set {default} recoveryenabled no

Cleanup

powershell 
bcdedit.exe /set {default} bootstatuspolicy displayallfailures && bcdedit.exe /set {default} recoveryenabled yes

Expected Telemetry

Two Sysmon Event ID 1 events: first with CommandLine='bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures', second with CommandLine='bcdedit.exe /set {default} recoveryenabled no'. Security Event ID 4688 for each. Both events fire within milliseconds of each other from the same parent.

Expected Detection

Two alerts fire in rapid succession — one on 'bootstatuspolicy ignoreallfailures', one on 'recoveryenabled no'. KQL: TechniqueCategory=BCD_Recovery_Disable for both. Multi-command hunting query will flag this as high-confidence ransomware pattern (2 commands, same host, <5 min).

Test 4 Windows Backup Catalog Deletion via wbadmin
windows

Deletes the Windows Server Backup catalog, which tracks backup job history and is required for restoring from Windows Server Backup. Used by ransomware targeting Windows Server environments. The -quiet flag suppresses the confirmation prompt. This is less common than VSS deletion but observed in attacks targeting enterprises with Windows Server Backup configurations.

Command

powershell 
wbadmin.exe delete catalog -quiet

Cleanup

powershell 
Note: The backup catalog cannot be directly restored from the command line — it is rebuilt when a new backup is taken. No cleanup action required beyond running a new backup job.

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=wbadmin.exe, CommandLine='wbadmin.exe delete catalog -quiet'. Security Event ID 4688 with same details. Microsoft-Windows-Backup event log will record the catalog deletion operation.

Expected Detection

Alert fires on 'delete catalog' pattern in wbadmin.exe command line. KQL: TechniqueCategory=BackupCatalog_Delete. SPL: BackupCatalogDelete=1, RecoveryInhibitScore >= 1.

Test 5 Ryuk-style VSS Storage Resize to Force Deletion
windows

Simulates the Ryuk ransomware VSS evasion technique that resizes shadow storage to 401MB (the Windows minimum) to force automatic deletion of shadow copies without calling the delete command directly. This technique bypasses some VSS deletion monitoring and is documented in Ryuk and several derivatives. Setting maxsize to 401MB effectively destroys all existing shadows by making the storage quota too small to retain them.

Command

powershell 
vssadmin.exe resize shadowstorage /for=C: /on=C: /maxsize=401MB

Cleanup

powershell 
vssadmin.exe resize shadowstorage /for=C: /on=C: /maxsize=10%

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=vssadmin.exe, CommandLine containing 'resize shadowstorage' and '/maxsize=401MB'. Microsoft-Windows-Volume-Shadow-Copy/Operational events as Windows responds to the reduced quota by discarding existing shadow copies.

Expected Detection

Alert fires on 'resize shadowstorage' pattern. KQL: TechniqueCategory=VSS_Resize. SPL: VSSResize=1, RecoveryInhibitScore >= 1. Hunting query for resize variant (third hunting query) will specifically identify this Ryuk-attributed technique.

Related Detections

Tactic Hub

TA0040Impact

Detection Variants (2)

Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.

Related Techniques

T1486Data Encrypted for ImpactT1485Data DestructionT1489Service StopT1562.001Disable or Modify ToolsT1047Windows Management InstrumentationT1059.001PowerShellT1059.003Windows Command ShellT1561.002Disk Structure WipeT1078Valid AccountsT1021.001Remote Desktop Protocol

Same Tactic: Impact

Popular Detections