Volume Shadow Copy Deletion via WMIC
Identifies use of wmic.exe for shadow copy deletion on endpoints. This commonly occurs in tandem with ransomware or other destructive attacks.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2020/02/18"
3integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
4maturity = "production"
5updated_date = "2026/05/03"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies use of wmic.exe for shadow copy deletion on endpoints. This commonly occurs in tandem with ransomware or
11other destructive attacks.
12"""
13from = "now-9m"
14index = [
15 "endgame-*",
16 "logs-crowdstrike.fdr*",
17 "logs-endpoint.events.process-*",
18 "logs-m365_defender.event-*",
19 "logs-sentinel_one_cloud_funnel.*",
20 "logs-system.security*",
21 "logs-windows.forwarded*",
22 "logs-windows.sysmon_operational-*",
23 "winlogbeat-*",
24]
25language = "eql"
26license = "Elastic License v2"
27name = "Volume Shadow Copy Deletion via WMIC"
28risk_score = 73
29rule_id = "dc9c1f74-dac3-48e3-b47f-eb79db358f57"
30severity = "high"
31tags = [
32 "Domain: Endpoint",
33 "OS: Windows",
34 "Use Case: Threat Detection",
35 "Tactic: Impact",
36 "Resources: Investigation Guide",
37 "Data Source: Elastic Endgame",
38 "Data Source: Elastic Defend",
39 "Data Source: Windows Security Event Logs",
40 "Data Source: Microsoft Defender XDR",
41 "Data Source: Sysmon",
42 "Data Source: SentinelOne",
43 "Data Source: Crowdstrike",
44]
45timestamp_override = "event.ingested"
46type = "eql"
47
48query = '''
49process where host.os.type == "windows" and event.type == "start" and
50 (process.name : "WMIC.exe" or ?process.pe.original_file_name == "wmic.exe") and
51 process.args : "delete" and process.args : "shadowcopy"
52'''
53
54note = """## Triage and analysis
55
56### Investigating Volume Shadow Copy Deletion via WMIC
57
58#### Possible investigation steps
59
60- What recovery data did WMIC try to delete?
61 - Focus: `process.command_line` scope: "shadowcopy delete", "ID=", "VolumeName=", "where", "/node:", or broad no-filter deletion.
62 - Implication: escalate when the command removes all shadows, targets a remote node, or lacks a narrow snapshot or volume filter; lower suspicion only when it targets one expected snapshot or volume and parent, account, host, and later process evidence fit that task.
63
64- Is this the expected Microsoft WMIC binary for the host?
65 - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
66 - Implication: escalate when WMIC is renamed, runs outside a Windows system path, has a non-Microsoft or untrusted signature, or mismatches its original file name; Microsoft-signed system-path WMIC lowers identity risk but does not clear shadow-copy deletion.
67
68- Which launcher and account initiated the deletion?
69 - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, `user.name`, and `user.domain`.
70 - Implication: escalate when a document, browser, archive tool, script host, interactive user, or unexplained remote-management parent launches WMIC; lower suspicion only when parent command, account, and host identify the exact recovery, imaging, lab-reset, or authorized test runner.
71
72- Did the same host or lineage run other recovery-inhibition or encryption-prep commands?
73 - Why: ransomware often mixes WMIC with "vssadmin.exe", "wbadmin.exe", "bcdedit.exe", "REAgentC.exe", "diskshadow.exe", service-stop commands, or encryption tooling.
74 - Focus: same-`host.id` process starts, scoped to `process.parent.entity_id` when present, for recovery-inhibition utilities, service stops, backup-agent tampering, or encryption tools. $investigate_2
75 - Hint: without `process.entity_id`, pivot by `host.id` + `process.pid` near the alert and treat lineage as weaker.
76 - Implication: escalate when WMIC is adjacent to additional recovery inhibition, backup tampering, service stops, or encryption preparation; keep scope narrower when process activity stays limited to one coherent maintenance or test sequence.
77
78- If local evidence is suspicious or unresolved, is the activity broader than one host workflow?
79 - Focus: same-`user.id` alerts for impact, execution, credential, or recovery-inhibition activity. $investigate_0
80 - Hint: review same-`host.id` alerts for alternate shadow-copy deletion utilities, backup tampering, or repeated destructive command lines. $investigate_1
81 - Implication: escalate scope when the user or host shows related impact or execution alerts beyond this command; keep host-local only when both pivots stay confined to the same narrow command sequence.
82
83- Escalate for unauthorized shadow-copy deletion, remote targeting, destructive preparation, or broader spread; close only when command scope, binary identity, parent/account context, same-host corroboration, and related alerts bind to one recognized workflow; preserve evidence and escalate when mixed or incomplete.
84
85### False positive analysis
86
87- Treat WMIC shadow-copy deletion as a recovery-inhibition anti-pattern. Benign closure is narrow: telemetry must show one expected snapshot or volume, a parent command for that exact task, the expected account and host, and no contradictory same-host recovery-inhibition or encryption-prep activity. Use change records or test plans only as corroboration.
88- Do not close as benign when the command removes all shadows, uses "/node:" remote targeting, has unexplained lineage, or appears with service-stop, backup-tampering, or encryption-prep activity. Recurrence, WMIC identity, or a stated maintenance window is not enough when process evidence remains broad or contradictory.
89- Before creating an exception, require a confirmed benign case with the exact `process.command_line` scope, `process.parent.executable`, `process.parent.command_line`, `user.id`, and `host.id`. Build the exception from that minimum pattern, never on "wmic.exe", `process.name`, or "shadowcopy" alone.
90
91### Response and remediation
92
93- If confirmed benign, reverse temporary containment and document the command scope, parent workflow, account, host, and corroborating maintenance or test evidence. Create an exception only when the same workflow recurs consistently for the same account and host scope.
94- If suspicious but unconfirmed, export the alert, process tree, full command line, parent command line, account, host identifiers, and related-alert results before containment. Apply reversible containment first, such as heightened monitoring or temporary administrative-access restrictions for the affected host or account; isolate the endpoint only if process evidence suggests active encryption, backup tampering, or broader destructive activity.
95- If confirmed malicious, preserve the process tree and command evidence before stopping processes or deleting artifacts. Isolate the endpoint to prevent further impact, suspend or reset involved accounts when the same `user.id` shows unauthorized activity, and remove only the scripts, scheduled tasks, services, or tools identified through the process investigation.
96- Restore recovery capability after containment: re-enable or repair affected VSS, backup, and recovery settings, validate that snapshots or backup jobs are functioning, and confirm no related recovery-inhibition commands remain active on the same host or scoped host set.
97- Post-incident hardening: restrict WMIC and VSS-management access on sensitive hosts, use application control where WMIC is not required, retain the process evidence that proved the case, and record any observed variants such as "vssadmin.exe", PowerShell Win32_ShadowCopy deletion, "wbadmin.exe", "bcdedit.exe", or "diskshadow.exe" in the case notes.
98"""
99
100setup = """## Setup
101
102This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
103
104Setup instructions: https://ela.st/install-elastic-defend
105
106### Additional data sources
107
108This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
109
110- [CrowdStrike](https://ela.st/crowdstrike-integration)
111- [Microsoft Defender XDR](https://ela.st/m365-defender)
112- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
113- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
114- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
115"""
116
117[rule.investigation_fields]
118field_names = [
119 "@timestamp",
120 "host.name",
121 "host.id",
122 "user.id",
123 "process.entity_id",
124 "process.pid",
125 "process.executable",
126 "process.pe.original_file_name",
127 "process.command_line",
128 "process.parent.entity_id",
129 "process.parent.executable",
130 "process.parent.command_line",
131 "process.code_signature.subject_name",
132 "process.code_signature.trusted",
133]
134
135[transform]
136
137[[transform.investigate]]
138label = "Alerts associated with the user"
139description = ""
140providers = [
141 [
142 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
143 { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
144 ]
145]
146relativeFrom = "now-48h/h"
147relativeTo = "now"
148
149[[transform.investigate]]
150label = "Alerts associated with the host"
151description = ""
152providers = [
153 [
154 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
155 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
156 ]
157]
158relativeFrom = "now-48h/h"
159relativeTo = "now"
160
161[[transform.investigate]]
162label = "Process events from the same parent"
163description = ""
164providers = [
165 [
166 { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
167 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
168 { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.parent.entity_id}}", valueType = "string" }
169 ]
170]
171relativeFrom = "now-1h"
172relativeTo = "now"
173
174[[rule.threat]]
175framework = "MITRE ATT&CK"
176
177[[rule.threat.technique]]
178id = "T1490"
179name = "Inhibit System Recovery"
180reference = "https://attack.mitre.org/techniques/T1490/"
181
182[rule.threat.tactic]
183id = "TA0040"
184name = "Impact"
185reference = "https://attack.mitre.org/tactics/TA0040/"
186
187[[rule.threat]]
188framework = "MITRE ATT&CK"
189
190[[rule.threat.technique]]
191id = "T1047"
192name = "Windows Management Instrumentation"
193reference = "https://attack.mitre.org/techniques/T1047/"
194
195[rule.threat.tactic]
196id = "TA0002"
197name = "Execution"
198reference = "https://attack.mitre.org/tactics/TA0002/"
Triage and analysis
Investigating Volume Shadow Copy Deletion via WMIC
Possible investigation steps
-
What recovery data did WMIC try to delete?
- Focus:
process.command_linescope: "shadowcopy delete", "ID=", "VolumeName=", "where", "/node:", or broad no-filter deletion. - Implication: escalate when the command removes all shadows, targets a remote node, or lacks a narrow snapshot or volume filter; lower suspicion only when it targets one expected snapshot or volume and parent, account, host, and later process evidence fit that task.
- Focus:
-
Is this the expected Microsoft WMIC binary for the host?
- Focus:
process.executable,process.pe.original_file_name,process.code_signature.subject_name, andprocess.code_signature.trusted. - Implication: escalate when WMIC is renamed, runs outside a Windows system path, has a non-Microsoft or untrusted signature, or mismatches its original file name; Microsoft-signed system-path WMIC lowers identity risk but does not clear shadow-copy deletion.
- Focus:
-
Which launcher and account initiated the deletion?
- Focus:
process.parent.executable,process.parent.command_line,user.id,user.name, anduser.domain. - Implication: escalate when a document, browser, archive tool, script host, interactive user, or unexplained remote-management parent launches WMIC; lower suspicion only when parent command, account, and host identify the exact recovery, imaging, lab-reset, or authorized test runner.
- Focus:
-
Did the same host or lineage run other recovery-inhibition or encryption-prep commands?
- Why: ransomware often mixes WMIC with "vssadmin.exe", "wbadmin.exe", "bcdedit.exe", "REAgentC.exe", "diskshadow.exe", service-stop commands, or encryption tooling.
- Focus: same-
host.idprocess starts, scoped toprocess.parent.entity_idwhen present, for recovery-inhibition utilities, service stops, backup-agent tampering, or encryption tools. $investigate_2 - Hint: without
process.entity_id, pivot byhost.id+process.pidnear the alert and treat lineage as weaker. - Implication: escalate when WMIC is adjacent to additional recovery inhibition, backup tampering, service stops, or encryption preparation; keep scope narrower when process activity stays limited to one coherent maintenance or test sequence.
-
If local evidence is suspicious or unresolved, is the activity broader than one host workflow?
- Focus: same-
user.idalerts for impact, execution, credential, or recovery-inhibition activity. $investigate_0 - Hint: review same-
host.idalerts for alternate shadow-copy deletion utilities, backup tampering, or repeated destructive command lines. $investigate_1 - Implication: escalate scope when the user or host shows related impact or execution alerts beyond this command; keep host-local only when both pivots stay confined to the same narrow command sequence.
- Focus: same-
-
Escalate for unauthorized shadow-copy deletion, remote targeting, destructive preparation, or broader spread; close only when command scope, binary identity, parent/account context, same-host corroboration, and related alerts bind to one recognized workflow; preserve evidence and escalate when mixed or incomplete.
False positive analysis
- Treat WMIC shadow-copy deletion as a recovery-inhibition anti-pattern. Benign closure is narrow: telemetry must show one expected snapshot or volume, a parent command for that exact task, the expected account and host, and no contradictory same-host recovery-inhibition or encryption-prep activity. Use change records or test plans only as corroboration.
- Do not close as benign when the command removes all shadows, uses "/node:" remote targeting, has unexplained lineage, or appears with service-stop, backup-tampering, or encryption-prep activity. Recurrence, WMIC identity, or a stated maintenance window is not enough when process evidence remains broad or contradictory.
- Before creating an exception, require a confirmed benign case with the exact
process.command_linescope,process.parent.executable,process.parent.command_line,user.id, andhost.id. Build the exception from that minimum pattern, never on "wmic.exe",process.name, or "shadowcopy" alone.
Response and remediation
- If confirmed benign, reverse temporary containment and document the command scope, parent workflow, account, host, and corroborating maintenance or test evidence. Create an exception only when the same workflow recurs consistently for the same account and host scope.
- If suspicious but unconfirmed, export the alert, process tree, full command line, parent command line, account, host identifiers, and related-alert results before containment. Apply reversible containment first, such as heightened monitoring or temporary administrative-access restrictions for the affected host or account; isolate the endpoint only if process evidence suggests active encryption, backup tampering, or broader destructive activity.
- If confirmed malicious, preserve the process tree and command evidence before stopping processes or deleting artifacts. Isolate the endpoint to prevent further impact, suspend or reset involved accounts when the same
user.idshows unauthorized activity, and remove only the scripts, scheduled tasks, services, or tools identified through the process investigation. - Restore recovery capability after containment: re-enable or repair affected VSS, backup, and recovery settings, validate that snapshots or backup jobs are functioning, and confirm no related recovery-inhibition commands remain active on the same host or scoped host set.
- Post-incident hardening: restrict WMIC and VSS-management access on sensitive hosts, use application control where WMIC is not required, retain the process evidence that proved the case, and record any observed variants such as "vssadmin.exe", PowerShell Win32_ShadowCopy deletion, "wbadmin.exe", "bcdedit.exe", or "diskshadow.exe" in the case notes.
Related rules
- Volume Shadow Copy Deleted or Resized via VssAdmin
- Volume Shadow Copy Deletion via PowerShell
- Backup Deletion with Wbadmin
- Modification of Boot Configuration
- Suspicious Execution from INET Cache