AN0415: Analytic 0415
Adversary destroys virtual disks (VMDK), images, or VMs by invoking `vim-cmd`, deleting datastore contents, or purging snapshots.
Analyst context for executives and security teams
This analytic describes destructive activity against ESXi-hosted virtual infrastructure: removal of virtual disks, VM images, VMs, datastore contents, or snapshots. For executives and security leaders, the business issue is not just “file deletion”; it is the potential loss of recoverability and service continuity for workloads that depend on VMware ESXi. The key decision value is whether the organization can prove it has visibility into destructive ESXi administrative actions and has resilient recovery paths if virtual machines or snapshots are removed.
Executive priority
Prioritize this as an operational resilience and recovery-readiness question for environments using ESXi. Leaders should ask whether ESXi administrative activity, datastore changes, VM deletion events, and snapshot removal are logged, retained, reviewed, and tied to accountable identities. Because snapshots and virtual disks may be part of recovery workflows, destructive actions in this area can affect incident response options, audit evidence, and continuity planning.
Technical view
SOC and IR teams should validate ESXi-focused telemetry for administrative actions involving `vim-cmd`, VM removal, datastore content deletion, virtual disk or image deletion, and snapshot purging. Since ATT&CK provides no official detection logic for this analytic and no relationship context, detection engineering should start by confirming which ESXi logs and management-plane events capture these actions, then baseline expected administrator and automation behavior before alerting on unusual or high-risk deletion activity.
Likely telemetry
- ESXi host management and system logs
- VMware management-plane events related to VM deletion, snapshot removal, and datastore operations
- Command or administrative action records involving `vim-cmd` where available
- Datastore file activity showing removal of VMDK, VM image, or related VM files
- Identity and access records for ESXi or virtualization administrators
Detection direction
- Confirm that ESXi administrative actions are centrally collected and retained; local-only logging may be lost or unavailable during an incident.
- Alert or review destructive actions against VMDK files, VM images, VMs, datastore contents, and snapshots, especially when performed outside approved change windows.
- Correlate deletion or snapshot purge activity with the authenticated identity, source system, management interface, and related change ticket where available.
- Baseline legitimate virtualization administration and automation to reduce false positives from planned decommissioning, storage cleanup, and maintenance tasks.
- Treat snapshot purging and datastore deletion as high-priority review events because they may reduce recovery options, even when performed with valid credentials.
Mitigation priorities
- Restrict ESXi administrative privileges to the minimum required roles and review who can delete VMs, remove datastore contents, or purge snapshots.
- Require approved change processes and strong authentication for destructive virtualization administration.
- Centralize and protect ESXi and virtualization management logs so they remain available after destructive activity.
- Maintain recovery capabilities that do not depend solely on local snapshots or datastore-resident artifacts.
- Regularly test restoration of critical VMs and confirm recovery evidence is usable for incident response and compliance readiness.
Analyst notes and limits
This object is an ATT&CK detection analytic for ESXi platforms. The official description identifies destructive actions against virtual disks, images, VMs, datastores, and snapshots, including use of `vim-cmd`. No tactics, detection logic, aliases, labels, or relationships were supplied, so this take focuses on defensive validation and recovery readiness rather than specific adversary procedures or attribution.
The supplied ATT&CK fields do not include an official detection query, data source list, tactic mapping, procedure examples, or related techniques. Local ESXi logging configuration, management tooling, identity integration, and backup architecture are required to determine actual detection and response coverage.
Analytic 0415
Adversary destroys virtual disks (VMDK), images, or VMs by invoking `vim-cmd`, deleting datastore contents, or purging snapshots.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 44d99828dd9e… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0415Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.