Overview

Inhibit System Recovery (T1490) describes adversary actions taken to delete, disable, or corrupt the built-in recovery mechanisms of an operating system or platform — including volume shadow copies, backup catalogs, boot repair settings, and VM snapshots — before or during a destructive attack. The goal is to ensure that even if the primary attack (ransomware encryption, disk wipe, data destruction) is detected, the victim has no fast path back to a clean state.

Every security team needs reliable detection for this technique because it is a near-universal precursor to ransomware deployment and destructive malware. By the time shadow copies are deleted, the attacker is typically minutes away from triggering the primary payload. Catching T1490 in real time is often the last viable opportunity to interrupt an incident before catastrophic, organization-wide impact.

Attacker Perspective

Attackers execute recovery inhibition as a deliberate preparation step to guarantee that data encryption or destruction is irreversible, maximizing pressure on victims and eliminating self-service recovery options.

• Volume Shadow Copy deletion via vssadmin: The most common ransomware preparatory step — vssadmin.exe delete shadows /all /quiet — wipes all VSS snapshots silently and is observed in families including LockBit, BlackCat/ALPHV, and Ryuk.
• Boot recovery disabled via bcdedit: Commands like bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures and bcdedit.exe /set {default} recoveryenabled no prevent Windows from offering automatic startup repair, trapping a victim in a broken boot state after disk encryption.
• Backup catalog deletion via wbadmin: wbadmin.exe delete catalog -quiet removes the Windows Server Backup catalog, eliminating the metadata index that maps backups to recovery points even if raw backup data still exists.
• ESXi snapshot deletion: Ransomware targeting hypervisors (e.g., ESXiArgs, Royal) uses the esxcli command or direct VMFS manipulation to delete VM snapshots and then encrypt flat VMDK files, making recovery from the hypervisor layer impossible.

This technique is attractive because it requires only a few seconds to execute, uses entirely native system utilities that are rarely blocked by default, and converts a recoverable encryption event into an unrecoverable one — dramatically increasing ransom payment probability.

Detection Strategy

Required Telemetry

• Windows Process Creation (Event ID 4688): Enable via GPO Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation. Also enable command-line capture: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. This is mandatory — without command-line data, process events are nearly useless for this technique.
• Sysmon Event ID 1 (Process Create): Deploy the Sysinternals Sysmon driver with a configuration that captures CommandLine, ParentImage, User, IntegrityLevel, and Hashes. Sysmon provides richer parent-child chain data than native 4688 alone.
• Windows PowerShell Script Block Logging (Event ID 4104): Enable via GPO at HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. Required to catch WMI-based shadow copy deletion wrapped inside PowerShell: Get-WmiObject Win32_ShadowCopy | Remove-WmiObject.
• WMI Activity Log (Event ID 5861 in Microsoft-Windows-WMI-Activity/Operational): Enable by ensuring the Microsoft-Windows-WMI-Activity/Operational channel is collected. Catches wmic shadowcopy delete and programmatic WMI calls that bypass vssadmin.exe entirely.
• Windows Security Event ID 4719 (System Audit Policy Changed): Catches attackers disabling audit policies to blind the SIEM before recovery inhibition. Enable via Audit Policy Change subcategory.
• VSS Provider / Volume Shadow Copy Service Events: Collect from the Application event log — VSS deletion events are logged here with source VSS or volsnap. Event ID 8224 (VSS service stopped) and 8193 are notable.
• Linux Auditd: Add rules to capture executions of backup-relevant binaries: -a always,exit -F arch=b64 -S execve -F path=/usr/bin/vgremove -k inhibit_recovery and equivalent rules for lvremove, rm targeting /boot or backup directories, and any scripted deletion of /var/backup or snapshot mount points. Forward via auditbeat or rsyslog to your SIEM.
• ESXi Shell / SSH Logs: Collect /var/log/shell.log and /var/log/hostd.log from ESXi hosts. These capture interactive commands including esxcli, vim-cmd snapshot operations, and direct rm or vmkfstools calls against VMDK files.
• Cloud/IaaS Audit Logs: For AWS — CloudTrail events DeleteSnapshot, DeleteBackup, DisableBackupVault. For Azure — Activity Log operations Microsoft.Compute/snapshots/delete, Microsoft.RecoveryServices/vaults/delete. For GCP — Cloud Audit Logs for compute.snapshots.delete. These must be enabled at the account/subscription/project level and forwarded to the SIEM.
• Endpoint Detection and Response (EDR) Telemetry: If available (CrowdStrike, Defender for Endpoint, SentinelOne), prioritize EDR process trees over native Windows logs — they correlate parent/child/grandchild relationships automatically and survive log tampering better.

Key Indicators

• vssadmin shadow deletion: Source: Sysmon EID 1 or Windows EID 4688. Field: CommandLine contains delete shadows AND process_name = vssadmin.exe. Flag any invocation — there is no common legitimate reason to delete all shadows interactively.
• wmic shadowcopy delete: Source: Sysmon EID 1 / EID 4688. Field: CommandLine matches shadowcopy AND delete. Also check WMI Activity EID 5861 where Operation contains Win32_ShadowCopy and DeleteInstance.
• wbadmin catalog deletion: Source: Sysmon EID 1 / EID 4688. Field: CommandLine contains delete catalog AND process_name = wbadmin.exe. The -quiet flag is a strong indicator of scripted/malicious use.
• bcdedit recovery disabled: Source: Sysmon EID 1 / EID 4688. Field: CommandLine contains recoveryenabled no OR bootstatuspolicy ignoreallfailures AND process_name = bcdedit.exe.
• diskshadow delete shadows all: Source: Sysmon EID 1 / EID 4688. Field: process_name = diskshadow.exe AND CommandLine contains delete shadows all OR diskshadow invoked with a script file argument (/s flag) where the script content contains delete shadows.
• REAgentC WinRE disable: Source: Sysmon EID 1 / EID 4688. Field: process_name = reagentc.exe AND CommandLine contains /disable.
• Suspicious parent process: Source: Sysmon EID 1. Field: ParentImage is cmd.exe, powershell.exe, wscript.exe, cscript.exe, or a path under C:\Users\ or C:\Temp\ spawning any of the above recovery-inhibition binaries. Legitimate admin tools typically have a management console or scheduled task as parent, not a user-land script host.
• High-volume rapid execution: Source: Sysmon EID 1 / EDR process telemetry. If three or more of vssadmin.exe, wbadmin.exe, bcdedit.exe, wmic.exe, diskshadow.exe are executed within a 60-second window on the same host, this is a near-certain indicator of a ransomware preparation script.
• PowerShell WMI-based VSS deletion: Source: EID 4104 Script Block. Field: ScriptBlockText contains Win32_ShadowCopy AND (Delete() OR Remove-WmiObject OR DeleteInstance).
• ESXi snapshot deletion: Source: ESXi shell.log. Field: log line contains vim-cmd vmsvc/snapshot.removeall OR esxcli storage vmfs snapshot OR rm *.vmsn / rm *.vmem.
• Cloud snapshot deletion: Source: CloudTrail / Azure Activity Log / GCP Audit. Field: eventName = DeleteSnapshot (AWS) OR operationName = Microsoft.Compute/snapshots/delete (Azure), especially from an IAM principal that has not previously performed this action, or where multiple snapshots are deleted in rapid succession.

Detection Logic

Rule 1 — Broad: Any Known Recovery-Inhibition Binary Executed
IF process_name IN ["vssadmin.exe","wbadmin.exe","bcdedit.exe","diskshadow.exe","reagentc.exe"]
AND CommandLine CONTAINS_ANY ["delete shadows","delete catalog","recoveryenabled no","bootstatuspolicy","delete shadows all","/disable"]
THEN alert(severity=HIGH, title="Recovery Inhibition Tool Executed")

This rule catches every documented native-binary abuse path. Expect low-to-moderate volume; legitimate admin invocations do exist (see Tuning) but are infrequent and should be reviewed on every hit. Apply to all Windows endpoints and servers.

Rule 2 — Medium: WMI or PowerShell Shadow Copy Deletion
IF (event_id = 5861 AND wmi_query CONTAINS "Win32_ShadowCopy" AND wmi_query CONTAINS "Delete")
OR (event_id = 4104 AND ScriptBlockText CONTAINS "Win32_ShadowCopy"
AND ScriptBlockText CONTAINS_ANY ["Delete()","Remove-WmiObject","DeleteInstance"])
THEN alert(severity=HIGH, title="WMI/PowerShell VSS Deletion Detected")

This catches adversaries who avoid vssadmin.exe because it is commonly monitored. Expected alert volume is very low — legitimate scripts rarely touch Win32_ShadowCopy destructively.

Rule 3 — Precision: Recovery Tool Cluster Execution (Ransomware Canary)
IF COUNT_DISTINCT(process_name) >= 3
WHERE process_name IN ["vssadmin.exe","wbadmin.exe","bcdedit.exe","wmic.exe","diskshadow.exe","reagentc.exe"]
AND host_id = [same host]
AND time_window = 120 seconds
THEN alert(severity=CRITICAL, title="Multi-Tool Recovery Inhibition — Likely Ransomware Preparation")

This rule is extremely high-fidelity. Running three or more recovery-inhibition tools on one host within two minutes is a near-certain indicator of a pre-ransomware script. Expected alert volume is near-zero outside of genuine incidents; treat every alert as a P1 until proven otherwise.

Rule 4 — Cloud: Bulk Snapshot Deletion
IF cloud_event_name IN ["DeleteSnapshot","snapshots/delete","compute.snapshots.delete"]
AND COUNT(events) >= 3
AND principal_user = same_identity
AND time_window = 300 seconds
AND NOT principal_user IN [approved_backup_service_accounts]
THEN alert(severity=HIGH, title="Bulk Cloud Snapshot Deletion")

Catches ransomware actors targeting IaaS infrastructure who delete multiple snapshots rapidly through the cloud control plane. Legitimate snapshot lifecycle management is typically automated under known service accounts and follows predictable schedules.

Tuning Guidance

• Backup software agents (Veeam, Backup Exec, Commvault, Windows Server Backup service): These products legitimately interact with VSS and may invoke vssadmin.exe or WMI VSS calls as part of normal backup jobs. Identify the service account and parent process used by your backup product, then exclude: parent_process IN ["VeeamAgent.exe","BackupExecAgentAccelerator.exe"] OR user IN [veeam_service_account, backup_svc]. Do not exclude blindly by process name alone — validate the full parent chain.
• System Center Configuration Manager (SCCM) / Intune remediation scripts: Automated compliance scripts may run bcdedit.exe to enforce boot settings as part of OS hardening. Exclude: parent_process = ccmexec.exe or executions with user = SYSTEM AND parent_process = smsexec.exe, only after confirming the specific command-line matches your known hardening baseline.
• System administrators performing manual recovery cleanup: Admins sometimes manually delete old shadow copies to reclaim disk space. Tune by adding a time-of-day filter (alert only outside business hours) or requiring the process to fire from a non-admin workstation. Better: require that all legitimate VSS admin tasks are performed through a jump server, and alert on any execution outside that source host.
• Cloud automation and IaC pipelines: Terraform destroy operations or scheduled snapshot retention policies legitimately delete cloud snapshots in bulk. Exclude: principal_user IN [terraform_service_principal, snapshot_lifecycle_sa] AND source_ip IN [cicd_runner_ip_ranges]. Build this exclusion list from your cloud identity inventory, not from observation of alerts.
• Antivirus / EDR self-protection tests: Some security tools run validation scripts that invoke vssadmin.exe list shadows (list, not delete) — ensure your rule matches specifically on destructive subcommands (delete) and not read-only ones (list, query).

When the Alert Fires: Investigation Steps

1. Verify the alert is real by pulling the raw event. Retrieve the original log entry from your SIEM (Sysmon EID 1, Windows EID 4688, or cloud audit log) and confirm the CommandLine, process_name, host, and timestamp fields are present and unambiguous — rule out data parsing errors or a test environment before escalating.
2. Identify the affected host and user account. Determine the hostname, IP, OS version, and business function of the affected system using your asset inventory or CMDB; flag immediately if it is a domain controller, backup server, hypervisor host, or file server, as these represent maximum-impact targets. Check whether the executing account is a privileged user, service account, or a standard user account — a standard user running vssadmin.exe delete shadows /all is an immediate red flag.
3. Pull the full process execution chain. Using Sysmon EID 1 or your EDR’s process tree, trace the parent, grandparent, and sibling processes of the flagged binary — look for the chain originating from a dropped executable in C:\Temp\, C:\Users\Public\, or a network share. Capture all command-line arguments for every process in the chain and hash each binary against VirusTotal or your threat intel platform.
4. Check for files written to disk immediately before the alert. Query Sysmon EID 11 (FileCreate) and EID 15 (FileCreateStreamHash) for the 30 minutes preceding the alert on the same host, focusing on new executables, scripts (.bat, .ps1, .vbs), or archives dropped in user-writable paths. Cross-reference file hashes against known ransomware loaders in your threat intel feeds.
5. Identify outbound network connections from the host. Query firewall logs, Sysmon EID 3 (NetworkConnect), or EDR network telemetry for the affected host in the window surrounding the alert — look for connections to unusual external IPs or domains, especially on ports 443, 80, 4444, or 8080 from non-browser processes. A C2 beacon immediately before recovery inhibition confirms the attacker has hands-on-keyboard access and has not merely dropped a script.
6. Search for lateral movement originating from this host. Query Windows Security EID 4624 (logon) and EID 4648 (explicit credential use) in your SIEM filtered to source_host = [affected_host] for the 2 hours prior to the alert; also check SMB access logs and any RDP or WinRM session logs. If you find successful logons to additional hosts using the same account or pass-the-hash indicators, immediately scope those hosts as potentially compromised and add them to the investigation.
7. Make the escalation decision based on evidence weight. Treat the incident as confirmed ransomware preparation and escalate to P1 if you observe: (a) multiple recovery-inhibition tools run in sequence, (b) new executable or script dropped before the alert, (c) C2 network connections, or (d) lateral movement to additional hosts. Downgrade to a lower-priority investigation only if the executing process parent is a known, approved backup agent, the user is a validated admin performing a documented task, and no additional suspicious activity appears in the surrounding 2-hour window.

Response Playbook

Containment

• Isolate the host immediately — leave it powered on. Use your EDR console (CrowdStrike Network Contain, Defender for Endpoint Isolate Device, SentinelOne Network Quarantine) or a firewall ACL to block all inbound and outbound traffic except to your SIEM and EDR management infrastructure. Do not power off the host — volatile memory may contain encryption keys, injected code, or attacker credentials that are needed for forensics.
• Disable the affected user account. In Active Directory, immediately disable the account using Disable-ADAccount -Identity [username] or the AD Users and Computers console. If the account is a service account, coordinate with the application owner before disabling, but do not delay more than 15 minutes — reset the password immediately as an interim step.
• Block identified C2 infrastructure. Push block rules for any external IPs or domains identified in network telemetry to your perimeter firewall, proxy, and internal DNS resolver. If using Microsoft Sentinel or Defender, add the IOCs to the Threat Intelligence blade to trigger automatic blocking across all enrolled endpoints.
• Kill the malicious process if still running. Use your EDR’s live response capability to kill any active ransomware or loader process by PID. In Defender for Endpoint use Live Response → remediate process [PID]; in CrowdStrike use Real Time Response → kill [PID]. Killing the process before encryption completes may save a significant portion of data.
• Revoke active sessions and tokens. Invalidate all active Kerberos tickets for the affected account using klist purge on the host or by resetting the account password (which forces re-authentication). If cloud credentials were potentially exposed, rotate IAM keys, revoke OAuth tokens, and invalidate active cloud management console sessions immediately.
• Snapshot or image surviving systems for forensics before touching them further. If you have additional hosts in scope from the lateral movement check, capture memory dumps using WinPmem or your EDR’s memory acquisition feature, and create forensic disk images before any remediation steps alter evidence.

Eradication

• Remove all identified persistence mechanisms. Query for new scheduled tasks (EID 4698), services (EID 7045), registry run keys (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run), and WMI subscriptions created in the window before and after the alert. Delete each one after documenting it; use Autoruns (Sysinternals) on the isolated host for a comprehensive view.
• Delete all dropped payloads and attacker tools. Using EDR Live Response or a direct forensic connection, delete any executables, scripts, or archives identified during investigation. Verify deletion using file hash — do not rely solely on filename, as attackers often rename tools.
• Reset credentials for all accounts that touched the affected host. Force password resets for the compromised user account and any other accounts observed logging into the host during the incident window. If Kerberoastable service accounts were present, rotate their passwords and verify SPNs. If LSASS credentials were potentially dumped (check for procdump.exe, comsvcs.dll MiniDump in process telemetry), treat all accounts with cached credentials on the host as compromised.
• Audit and remediate lateral movement targets. For each additional host identified during lateral movement investigation, run the same eradication checklist — search for the same dropped files by hash, check for the same persistence mechanisms, and verify no additional recovery-inhibition commands were run on those hosts.
• Rotate any exposed secrets or API keys. If the affected system had cloud provider credentials, database connection strings, or API keys stored on disk or in environment variables (check C:\ProgramData\, %APPDATA%, and .env files), rotate all of them immediately and audit their usage logs for unauthorized activity.

Recovery

• Verify the host is clean before reconnecting to the network. If confidence in eradication is high (limited scope, full process chain understood, no evidence of rootkit or firmware implant), validate using your EDR’s full scan plus a manual Autoruns review. If confidence is low — particularly if the host is a server, domain controller, or backup appliance — re-image from a known-good baseline rather than attempting in-place cleanup.
• Restore data from the most recent verified clean backup. Identify the last backup taken before the incident timestamp and verify its integrity before restoring. If VSS copies were deleted, check offsite or cloud backups (AWS Backup, Azure Recovery Services Vault, Veeam offsite repository) — the attacker can only delete snapshots they have access to, and air-gapped or immutable backups should be intact.
• Re-enable the user account only after confirming no persistence remains. Before re-enabling the account, verify all sessions are clean, all persistence mechanisms are removed, and the account’s MFA is re-enrolled. Brief the user on what happened and require a fresh credential setup.
• Monitor the affected host and account for 72 hours post-remediation. Create a temporary, high-sensitivity watch rule in your SIEM scoped to the specific host and user for all process creation, network connection, and authentication events. Any recurrence of suspicious behavior within this window indicates incomplete eradication.
• Document the full incident timeline and update detections. Record every IOC discovered (hashes, IPs, domains, file paths, account names, command-line patterns) in your threat intelligence platform and push them to existing detection rules. Close the incident ticket with a written timeline from initial access to containment, and schedule a 5-day post-incident review to assess whether detection fired early enough and what tuning is needed.