Volume Shadow Copy Deleted or Resized via VssAdmin

Identifies use of vssadmin.exe for shadow copy deletion or resizing 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 vssadmin.exe for shadow copy deletion or resizing on endpoints. This commonly occurs in tandem with
 11ransomware or other 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 Deleted or Resized via VssAdmin"
 28risk_score = 73
 29rule_id = "b5ea4bfe-a1b2-421f-9d47-22a75a6f2921"
 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 : "vssadmin.exe" or ?process.pe.original_file_name == "VSSADMIN.EXE") and
 51  process.args : ("delete", "resize") and process.args : "shadows*"
 52'''
 53
 54note = """## Triage and analysis
 55
 56### Investigating Volume Shadow Copy Deleted or Resized via VssAdmin
 57
 58#### Possible investigation steps
 59
 60- What recovery-inhibition path does the alert-local command express?
 61  - Focus: `process.command_line` and `process.args`; separate "delete shadows" with "/all", "/quiet", "/for=", "/oldest", or "/shadow=" from "resize shadowstorage" with "/for=", "/on=", and "/maxsize=".
 62  - Implication: escalate faster when the command deletes all shadows, suppresses prompts, targets broad restore scope, or forces a tiny maximum; lower suspicion when it targets one volume, one shadow ID, or capacity-aligned resize inside a recognized retention, storage, or reset workflow.
 63
 64- Is the VssAdmin binary identity consistent with the tool being invoked?
 65  - Focus: `process.executable`, `process.pe.original_file_name`, and, when available, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
 66  - Implication: escalate when path, PE metadata, hash, signer, or trust does not fit Microsoft VssAdmin; lower suspicion when identity matches the expected Microsoft tool, but identity never clears broad deletion or forced shrinkage.
 67
 68- Does the launcher and account explain why VssAdmin changed shadow-copy state?
 69  - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, `user.name`, and `user.domain`.
 70  - Implication: escalate when Office, a browser, script host, remote-access tool, or unusual account launches the command; lower suspicion when the parent and account match the same backup agent, deployment runner, storage-management console, image-prep script, or lab-reset workflow.
 71
 72- Are surrounding process events part of the same recovery-inhibition or impact chain?
 73  - Why: destructive operators often pair VssAdmin with recovery tampering ("wmic shadowcopy delete", "diskshadow", "wbadmin delete catalog", "bcdedit recoveryenabled no", "reagentc /disable"), service stops, or encryption launchers.
 74  - Focus: same-parent starts by `host.id` plus `process.parent.entity_id`; compare `process.name`, `process.command_line`, parent context, and timing. $investigate_2
 75  - Range: start with the alert window through the next 15 minutes; expand only if the same lineage shows recovery tampering or encryption prep.
 76  - Implication: escalate when the same lineage or short window shows backup deletion, recovery disablement, service stops, security-tool interference, or encryption tooling; lower suspicion when activity stays within one coherent maintenance or reset sequence.
 77
 78- If endpoint file telemetry is available, is destructive file impact already visible from this process or host?
 79  - Focus: file events by `host.id` plus `process.entity_id`; fallback to `host.id`, `process.pid`, and a tight alert window, checking `file.path`, `file.extension`, and `file.Ext.original.extension`. $investigate_3
 80  - Implication: escalate when file activity shows mass renames, unfamiliar extensions, ransom-note drops, or destructive cleanup after VssAdmin starts; absence of file telemetry is unresolved, not benign.
 81
 82- Do same-user or same-host alerts show spread beyond this VssAdmin event?
 83  - Focus: same-`user.id` related alerts, especially impact, backup tampering, execution, credential, or lateral-movement activity. $investigate_0
 84  - Hint: if local scope, lineage, process activity, or file impact remains suspicious or unresolved, review the same `host.id` for other shadow-copy, backup-catalog, service-stop, encryption, or ransom-note alerts. $investigate_1
 85  - Implication: broaden containment when same-user or same-host alerts show additional recovery inhibition, encryption, credential access, or lateral movement; keep scope local when both pivots match the same exact retention, storage-maintenance, image-prep, or lab-reset pattern.
 86
 87- Escalate when command intent plus launch context or surrounding process/file evidence supports unauthorized recovery inhibition; close only when command scope, identity, lineage, account, host, and follow-on telemetry bind to one exact recognized workflow, with outside confirmation if telemetry cannot prove legitimacy. Preserve evidence and escalate on conflict or incomplete visibility.
 88
 89### False positive analysis
 90
 91- Backup retention, storage maintenance, disaster-recovery testing, image preparation, and lab resets can delete one shadow copy or resize shadow storage. Confirm command scope (`process.command_line`), lineage (`process.parent.executable` and `process.parent.command_line`), actor/asset (`user.id`, `host.id`, `host.name`), and follow-on evidence with no same-window recovery tampering, encryption, ransom-note, or destructive cleanup outside that workflow. External records can corroborate after telemetry matches; otherwise require recurring command scope, parent, account, and host pattern across prior alerts without contradictory process or file evidence.
 92- Before creating an exception, validate recurring `process.executable`, `process.pe.original_file_name`, `process.parent.executable`, stable `process.command_line` scope, `user.id` or `user.name`, and `host.id` for the confirmed workflow. Keep it constrained to that workflow and avoid exceptions on `process.name`, "vssadmin.exe", "resize", "delete", or "shadows" alone.
 93
 94### Response and remediation
 95
 96- If confirmed benign, reverse temporary controls and record the command scope, parent lineage, account, host, and external evidence that tied the event to recognized maintenance or reset activity. Create an exception only if the same command scope, lineage, account, and host recur consistently across prior alerts from this rule.
 97- If suspicious but unconfirmed, preserve the alert document, raw process event, parent tree, full command line, account and host identifiers, same-window process activity, and any file-impact artifacts before containment. Apply reversible containment first: isolate the host if destructive activity appears and host criticality allows it; otherwise restrict the implicated admin channel or account while scope is confirmed. Broaden containment only if same-user or same-host pivots show spread.
 98- If confirmed malicious, keep the preserved evidence and isolate the endpoint to stop further impact while retaining telemetry. Suspend related accounts or admin channels when session, lineage, or related-alert evidence shows misuse. Record `process.entity_id` and `process.command_line` before termination. Remove only malicious scripts, payloads, scheduled tasks, services, ransom notes, and backup-tampering changes identified during the investigation.
 99- Restore affected VSS, backup, and recovery settings, validate that snapshots or backup jobs work again, and recover impacted data from trusted backups after containment and eradication are complete.
100- Post-incident hardening: restrict VSS-management workflows on sensitive hosts, limit backup-administration rights, protect offline or out-of-band backups from the same accounts, and validate controls for adjacent recovery-inhibition variants such as "wmic shadowcopy delete", "diskshadow", "wbadmin delete catalog", "bcdedit", and "reagentc".
101"""
102
103setup = """## Setup
104
105This 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.
106
107Setup instructions: https://ela.st/install-elastic-defend
108
109### Additional data sources
110
111This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
112
113- [CrowdStrike](https://ela.st/crowdstrike-integration)
114- [Microsoft Defender XDR](https://ela.st/m365-defender)
115- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
116- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
117- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
118"""
119
120[rule.investigation_fields]
121field_names = [
122    "@timestamp",
123    "host.name",
124    "host.id",
125    "user.id",
126    "process.entity_id",
127    "process.pid",
128    "process.executable",
129    "process.command_line",
130    "process.pe.original_file_name",
131    "process.parent.entity_id",
132    "process.parent.executable",
133    "process.parent.command_line",
134]
135
136[transform]
137
138[[transform.investigate]]
139label = "Alerts associated with the user"
140description = ""
141providers = [
142  [
143    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
144    { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
145  ]
146]
147relativeFrom = "now-48h/h"
148relativeTo = "now"
149
150[[transform.investigate]]
151label = "Alerts associated with the host"
152description = ""
153providers = [
154  [
155    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
156    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
157  ]
158]
159relativeFrom = "now-48h/h"
160relativeTo = "now"
161
162[[transform.investigate]]
163label = "Process events from the same parent"
164description = ""
165providers = [
166  [
167    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
168    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
169    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.parent.entity_id}}", valueType = "string" }
170  ]
171]
172relativeFrom = "now-1h"
173relativeTo = "now"
174
175[[transform.investigate]]
176label = "File events from VssAdmin"
177description = ""
178providers = [
179  [
180    { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
181    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
182    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
183  ]
184]
185relativeFrom = "now-1h"
186relativeTo = "now"
187
188[[rule.threat]]
189framework = "MITRE ATT&CK"
190
191[[rule.threat.technique]]
192id = "T1490"
193name = "Inhibit System Recovery"
194reference = "https://attack.mitre.org/techniques/T1490/"
195
196[rule.threat.tactic]
197id = "TA0040"
198name = "Impact"
199reference = "https://attack.mitre.org/tactics/TA0040/"

Triage and analysis

Investigating Volume Shadow Copy Deleted or Resized via VssAdmin

Possible investigation steps

  • What recovery-inhibition path does the alert-local command express?

    • Focus: process.command_line and process.args; separate "delete shadows" with "/all", "/quiet", "/for=", "/oldest", or "/shadow=" from "resize shadowstorage" with "/for=", "/on=", and "/maxsize=".
    • Implication: escalate faster when the command deletes all shadows, suppresses prompts, targets broad restore scope, or forces a tiny maximum; lower suspicion when it targets one volume, one shadow ID, or capacity-aligned resize inside a recognized retention, storage, or reset workflow.
  • Is the VssAdmin binary identity consistent with the tool being invoked?

    • Focus: process.executable, process.pe.original_file_name, and, when available, process.hash.sha256, process.code_signature.subject_name, and process.code_signature.trusted.
    • Implication: escalate when path, PE metadata, hash, signer, or trust does not fit Microsoft VssAdmin; lower suspicion when identity matches the expected Microsoft tool, but identity never clears broad deletion or forced shrinkage.
  • Does the launcher and account explain why VssAdmin changed shadow-copy state?

    • Focus: process.parent.executable, process.parent.command_line, user.id, user.name, and user.domain.
    • Implication: escalate when Office, a browser, script host, remote-access tool, or unusual account launches the command; lower suspicion when the parent and account match the same backup agent, deployment runner, storage-management console, image-prep script, or lab-reset workflow.
  • Are surrounding process events part of the same recovery-inhibition or impact chain?

    • Why: destructive operators often pair VssAdmin with recovery tampering ("wmic shadowcopy delete", "diskshadow", "wbadmin delete catalog", "bcdedit recoveryenabled no", "reagentc /disable"), service stops, or encryption launchers.
    • Focus: same-parent starts by host.id plus process.parent.entity_id; compare process.name, process.command_line, parent context, and timing. $investigate_2
    • Range: start with the alert window through the next 15 minutes; expand only if the same lineage shows recovery tampering or encryption prep.
    • Implication: escalate when the same lineage or short window shows backup deletion, recovery disablement, service stops, security-tool interference, or encryption tooling; lower suspicion when activity stays within one coherent maintenance or reset sequence.
  • If endpoint file telemetry is available, is destructive file impact already visible from this process or host?

    • Focus: file events by host.id plus process.entity_id; fallback to host.id, process.pid, and a tight alert window, checking file.path, file.extension, and file.Ext.original.extension. $investigate_3
    • Implication: escalate when file activity shows mass renames, unfamiliar extensions, ransom-note drops, or destructive cleanup after VssAdmin starts; absence of file telemetry is unresolved, not benign.
  • Do same-user or same-host alerts show spread beyond this VssAdmin event?

    • Focus: same-user.id related alerts, especially impact, backup tampering, execution, credential, or lateral-movement activity. $investigate_0
    • Hint: if local scope, lineage, process activity, or file impact remains suspicious or unresolved, review the same host.id for other shadow-copy, backup-catalog, service-stop, encryption, or ransom-note alerts. $investigate_1
    • Implication: broaden containment when same-user or same-host alerts show additional recovery inhibition, encryption, credential access, or lateral movement; keep scope local when both pivots match the same exact retention, storage-maintenance, image-prep, or lab-reset pattern.
  • Escalate when command intent plus launch context or surrounding process/file evidence supports unauthorized recovery inhibition; close only when command scope, identity, lineage, account, host, and follow-on telemetry bind to one exact recognized workflow, with outside confirmation if telemetry cannot prove legitimacy. Preserve evidence and escalate on conflict or incomplete visibility.

False positive analysis

  • Backup retention, storage maintenance, disaster-recovery testing, image preparation, and lab resets can delete one shadow copy or resize shadow storage. Confirm command scope (process.command_line), lineage (process.parent.executable and process.parent.command_line), actor/asset (user.id, host.id, host.name), and follow-on evidence with no same-window recovery tampering, encryption, ransom-note, or destructive cleanup outside that workflow. External records can corroborate after telemetry matches; otherwise require recurring command scope, parent, account, and host pattern across prior alerts without contradictory process or file evidence.
  • Before creating an exception, validate recurring process.executable, process.pe.original_file_name, process.parent.executable, stable process.command_line scope, user.id or user.name, and host.id for the confirmed workflow. Keep it constrained to that workflow and avoid exceptions on process.name, "vssadmin.exe", "resize", "delete", or "shadows" alone.

Response and remediation

  • If confirmed benign, reverse temporary controls and record the command scope, parent lineage, account, host, and external evidence that tied the event to recognized maintenance or reset activity. Create an exception only if the same command scope, lineage, account, and host recur consistently across prior alerts from this rule.
  • If suspicious but unconfirmed, preserve the alert document, raw process event, parent tree, full command line, account and host identifiers, same-window process activity, and any file-impact artifacts before containment. Apply reversible containment first: isolate the host if destructive activity appears and host criticality allows it; otherwise restrict the implicated admin channel or account while scope is confirmed. Broaden containment only if same-user or same-host pivots show spread.
  • If confirmed malicious, keep the preserved evidence and isolate the endpoint to stop further impact while retaining telemetry. Suspend related accounts or admin channels when session, lineage, or related-alert evidence shows misuse. Record process.entity_id and process.command_line before termination. Remove only malicious scripts, payloads, scheduled tasks, services, ransom notes, and backup-tampering changes identified during the investigation.
  • Restore affected VSS, backup, and recovery settings, validate that snapshots or backup jobs work again, and recover impacted data from trusted backups after containment and eradication are complete.
  • Post-incident hardening: restrict VSS-management workflows on sensitive hosts, limit backup-administration rights, protect offline or out-of-band backups from the same accounts, and validate controls for adjacent recovery-inhibition variants such as "wmic shadowcopy delete", "diskshadow", "wbadmin delete catalog", "bcdedit", and "reagentc".

Related rules

to-top