« Potential Ransomware Note File Dropped via SMB Volume Shadow Copy Deletion via PowerShell »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.24

Volume Shadow Copy Deleted or Resized via VssAdmin

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Volume Shadow Copy Deleted or Resized via VssAdmin

edit

Identifies use of vssadmin.exe for shadow copy deletion or resizing on endpoints. This commonly occurs in tandem with ransomware or other destructive attacks.

Rule type: eql

Rule indices:

  • endgame-*
  • logs-crowdstrike.fdr*
  • logs-endpoint.events.process-*
  • logs-m365_defender.event-*
  • logs-sentinel_one_cloud_funnel.*
  • logs-system.security*
  • logs-windows.forwarded*
  • logs-windows.sysmon_operational-*
  • winlogbeat-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References: None

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Impact
  • Resources: Investigation Guide
  • Data Source: Elastic Endgame
  • Data Source: Elastic Defend
  • Data Source: Windows Security Event Logs
  • Data Source: Microsoft Defender XDR
  • Data Source: Sysmon
  • Data Source: SentinelOne
  • Data Source: Crowdstrike

Version: 318

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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{"description":"","label":"Process events from the same parent","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • 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{"description":"","label":"File events from VssAdmin","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • 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{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • 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{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • 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".

Setup

edit

Setup

This rule is designed for data generated by Elastic Defend, which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

Rule query

edit
process where host.os.type == "windows" and event.type == "start" and
  (process.name : "vssadmin.exe" or ?process.pe.original_file_name == "VSSADMIN.EXE") and
  process.args : ("delete", "resize") and process.args : "shadows*"

Framework: MITRE ATT&CKTM

« Potential Ransomware Note File Dropped via SMB Volume Shadow Copy Deletion via PowerShell »