Inhibit System Recovery (T1490) is the move right before ransomware encrypts: the attacker destroys the backups a victim would restore from, deleting Volume Shadow Copies with vssadmin, wiping the Windows Backup catalog, and disabling boot repair. It is a high-fidelity endpoint signal, because legitimate software almost never bulk-deletes shadow copies. Catching it buys minutes to isolate the host.
Practice detecting Inhibit System Recovery on realistic SIEM, XDR alerts in SOCSimulator Operations.
“Inhibit System Recovery is documented as technique T1490 in MITRE ATT&CK® v19.1 under the Impact tactic. Detection requires visibility into SIEM, XDR telemetry.”
The first target is the Volume Shadow Copy Service, the snapshot store Windows uses for point-in-time recovery. The classic command is vssadmin delete shadows /all /quiet, which removes every snapshot without a prompt. Attackers reach the same result with wmic shadowcopy delete or a scripted diskshadow session, and some shrink vssadmin resize shadowstorage so old copies age out on their own. Once the snapshots are gone, a victim cannot roll encrypted files back to a clean version.
Two more surfaces get hit. wbadmin delete catalog -quiet destroys the Windows Server Backup catalog so wbadmin restores fail even when backup media survives. On the boot side, bcdedit /set {default} recoveryenabled no and bcdedit /set {default} bootstatuspolicy ignoreallfailures disable the Windows Recovery Environment that would normally launch after repeated boot failures, so the machine cannot self-repair.
These are usually chained into one cmd.exe line joined with an ampersand, fired by the ransomware binary itself or pushed out through PsExec, a scheduled task, or a GPO. Running them under a service or backup account is deliberate: that account already holds the admin rights VSS needs and is expected to touch shadow storage, so the activity looks routine until you notice the /all scope.
By the time recovery inhibition fires, the operator is already deep in the intrusion. Initial access, credential theft, and privilege escalation to domain or local admin all came first, followed by lateral movement to reach as many hosts as possible. Wiping shadow copies is one of the final pre-detonation steps, run once the attacker is confident they hold the environment.
It sits directly upstream of T1486 Data Encrypted for Impact: kill recovery, then encrypt. Splunk's 'Deleting Shadow Copies' detection attributes this behaviour to LockBit, Black Basta, Clop, and Rhysida, families that treat the shadow wipe as a standard part of the playbook. For a defender this ordering is the opportunity: the recovery-inhibition alert is often the last cheap warning you get before files across the network start encrypting, which is why it deserves a same-shift response rather than a morning-queue triage.
The following detection strategies help SOC analysts identify Inhibit System Recovery activity. These methods apply across SIEM, XDR environments and can be implemented as detection rules, correlation queries, or behavioral analytics in your security platform.
index=* EventCode=1
(Image="*\\vssadmin.exe" OR Image="*\\wmic.exe" OR Image="*\\diskshadow.exe")
CommandLine="*shadow*" CommandLine="*delete*"
| table _time, ComputerName, User, ParentImage, CommandLineAny shadow-copy utility whose command line contains both 'shadow' and 'delete'. Mirrors Splunk Security Content's 'Deleting Shadow Copies' analytic, which attributes this behaviour to LockBit, Black Basta, Clop and Rhysida.
EventID: 1
UtcTime: 2026-07-14 03:14:22.501
Image: C:\Windows\System32\vssadmin.exe
CommandLine: vssadmin.exe delete shadows /all /quiet
User: CORP\svc_backupadmin
IntegrityLevel: High
ParentImage: C:\Windows\System32\cmd.exe
ParentCommandLine: cmd.exe /c vssadmin.exe delete shadows /all /quiet & wbadmin delete catalog -quietdetection:
selection1_img:
Image|endswith:
- '\powershell.exe'
- '\pwsh.exe'
- '\wmic.exe'
- '\vssadmin.exe'
- '\diskshadow.exe'
selection1_cli:
CommandLine|contains|all: ['shadow', 'delete']
selection2_img:
Image|endswith: '\wbadmin.exe'
selection2_cli:
CommandLine|contains|all: ['delete', 'catalog', 'quiet']
condition: (all of selection1*) or (all of selection2*)SigmaHQ's shadow-copy deletion rule, portable across any EDR that maps process-creation telemetry. Covers the PowerShell, WMI, vssadmin and diskshadow variants plus wbadmin catalog deletion.
detection:
selection_img:
Image|endswith: '\bcdedit.exe'
selection_cli:
- CommandLine|contains|all: ['bootstatuspolicy', 'ignoreallfailures']
- CommandLine|contains|all: ['recoveryenabled', 'no']
condition: all of selection_*Companion SigmaHQ rule for bcdedit boot-configuration tampering: disabling automatic recovery or telling Windows to ignore all boot failures.
Timestamp: 2026-07-14T03:14:22.777Z
DeviceName: FS-01.corp.local
FileName: bcdedit.exe
ProcessCommandLine: bcdedit.exe /set {default} recoveryenabled no
InitiatingProcessFileName: vssadmin.exe
AccountName: svc_backupadminNot every shadow-copy deletion is hostile. Enterprise backup agents create, mount, and recycle shadow copies as part of normal jobs and will legitimately invoke vssadmin. VM snapshot maintenance and disk-imaging or cloning tools prune old snapshots on a schedule. Even vssadmin resize shadowstorage, run to reclaim space, can age copies out. Any rule that alerts on vssadmin alone will bury an analyst in benign backup traffic.
The tuning that works is context, not the utility name. Allow-list the service accounts and parent processes your backup and imaging stack legitimately runs from, then alert on the /all bulk-deletion pattern when it comes from anything outside that set, especially a process spawned by a shell, an Office child, or an unfamiliar binary. Correlate with the host's recent behaviour: a shadow wipe sitting next to mass file renames, a new service, or PsExec is not a backup job. Bulk deletion plus unusual parent is the combination that separates ransomware prep from Tuesday-night maintenance.
These realistic alert examples show what Inhibit System Recovery looks like in your security tools. Use them to tune detection rules and train analysts to recognize true positives versus false positives in live environments.
A process ran vssadmin.exe delete shadows /all /quiet under the service account svc_backupadmin, with cmd.exe as parent, and chained a wbadmin delete catalog -quiet call from the same command line. Bulk shadow-copy deletion by a non-backup workflow is a near-certain pre-encryption action.
bcdedit.exe /set {default} recoveryenabled no executed on a file server, immediately preceded by shadow-copy deletion. Disabling Windows automatic repair removes the victim's ability to roll back after a destructive payload runs.
wmic.exe shadowcopy delete spawned from a PowerShell session on a domain controller. WMI is a common living-off-the-land path to the same shadow-copy destruction, chosen to evade rules that only watch vssadmin.
When this fires, the first question is whether the account and parent process belong to a sanctioned backup or imaging workflow. If they do, confirm the schedule and close it. If they do not, read the command line: /all, delete shadows, delete catalog, or bcdedit recovery flags all mean the whole recovery surface, not a single snapshot. Then pull the host's last 15 minutes, new service creations, PsExec or remote execution, mass file writes, and ransom-note filenames, to see how far along the intrusion already is.
Bulk /all deletion by anything outside your backup stack is a detonation precursor. Escalate it as an active ransomware event, not a maintenance false positive, and do it now rather than after more triage. Recovery inhibition typically runs seconds to minutes ahead of encryption, so isolate the host from the network immediately: pulling it can stop the payload spreading to file shares and other machines before it finishes. Keep the host powered on and preserved for IR instead of reimaging, since the volatile state is your best lead on entry point and scope.
Investigate Inhibit System Recovery on realistic SIEM, XDR, and firewall consoles, free.
Ransomware is malware that encrypts victim data or systems and demands payment, typically cryptocurrency, for the decryp…
Read more GlossaryIncident response (IR) is the structured, repeatable process an organization follows before, during, and after a securit…
Read more GlossaryContainment is the incident response phase focused on limiting the spread and impact of a confirmed security incident: i…
Read more GlossaryRecovery is the final phase of the incident response lifecycle, where affected systems are restored to normal, validated…
Read more Career PathIncident Responders lead the technical response when confirmed breaches happen. You coordinate containment, run forensic…
Read more Career PathSOC Managers run the operation. You own staffing, playbook development, tool selection, performance metrics, and executi…
Read more ToolThe SIEM console in SOCSimulator replicates the workflow of enterprise platforms like Splunk Enterprise Security, Micros…
Read more ToolThe XDR console in SOCSimulator replicates the investigation workflow of platforms like CrowdStrike Falcon, Microsoft De…
Read more ComparisonSOCSimulator wins on operational realism. You get multi-tool shift simulation with SLA pressure, noise injection, and al…
Read more PlaybookWhen indicators suggest ransomware, mass file encryption, suspicious process behavior, ransom notes, or shadow copy dele…
Read more GlossaryComplete glossary of Security Operations Center terminology for aspiring SOC analysts.
Read more FeaturePractice alert triage under realistic time pressure with SLA timers and noise injection.
Read more