AN0935: Analytic 0935
ESXi shell or vim-cmd execution that deletes all VM snapshots using vmsvc/snapshot.removeall or rm on snapshot paths
Analyst context for executives and security teams
This analytic matters because mass deletion of VMware ESXi virtual machine snapshots can remove an important recovery option during an incident or outage. For executives and security leaders, the practical question is whether the organization can see and investigate ESXi shell or management-command activity that removes snapshots, and whether snapshot loss would materially affect recovery time, evidence preservation, or business continuity.
Executive priority
Prioritize this as a resilience and incident-readiness control point for environments that run ESXi. Snapshot deletion is not automatically malicious, but unexpected or bulk removal can undermine recovery plans and complicate response decisions. Leaders should ask who is authorized to remove snapshots, whether those actions are logged centrally, how quickly SOC/IR teams would know, and whether audit evidence exists to prove snapshot administration is controlled.
Technical view
AN0935 is a detection analytic for ESXi focused on shell or vim-cmd execution that deletes all VM snapshots using vmsvc/snapshot.removeall or file removal activity against snapshot paths. SOC and detection teams should validate visibility into ESXi command execution, administrative shell access, and snapshot-related file operations. Because ATT&CK provides no official detection logic and no relationship context for this analytic, implementation should be environment-specific and tuned against approved maintenance, backup, and virtualization administration workflows.
Likely telemetry
- ESXi shell command history or command execution logs where available
- vCenter or ESXi host task and event logs for snapshot removal activity
- Authentication and administrative session logs for ESXi or vCenter access
- File operation telemetry or host logs involving VM snapshot paths where available
- Change-management, backup, or maintenance records to distinguish authorized snapshot cleanup from suspicious activity
Detection direction
- Alert on snapshot removal commands or bulk snapshot deletion activity occurring outside approved maintenance windows or by unexpected accounts.
- Correlate snapshot deletion with recent ESXi administrative logons, privilege changes, backup failures, or unusual remote access to reduce false positives.
- Build allowlists carefully for backup and virtualization operations teams, but avoid suppressing all snapshot cleanup activity because legitimate tools may be abused or credentials may be compromised.
- Validate whether ESXi logs are forwarded to the SIEM before an incident; local-only logs may be unavailable when the host is disrupted.
- Because no official detection is supplied, test detections against normal lifecycle events such as scheduled cleanup, storage reclamation, and backup orchestration.
Mitigation priorities
- Define and enforce least-privilege access for ESXi and vCenter accounts that can remove snapshots.
- Require administrative accountability through centralized authentication, logging, and change approval for snapshot management.
- Centralize ESXi and vCenter logging so snapshot deletion evidence is available to SOC and incident responders.
- Document recovery dependencies so teams know whether snapshot deletion affects restoration, forensic preservation, or business continuity objectives.
- Regularly review authorized snapshot cleanup processes and compare them with observed telemetry.
Analyst notes and limits
This object is an ATT&CK detection analytic, not a technique. It is specific to ESXi and describes detection-relevant behavior around deletion of all VM snapshots through ESXi shell or vim-cmd activity, including snapshot.removeall-style activity or removal of snapshot paths. No tactics, relationships, aliases, or official detection logic were supplied, so the Glexia take focuses on defensive validation and operational risk rather than adversary attribution or campaign context.
The supplied ATT&CK fields do not include official detection pseudocode, data sources, mitigations, tactics, or relationship context. Local ESXi/vCenter configuration, logging level, administrative model, backup tooling, and change-management records are required to determine detection feasibility, expected false positives, and business impact.
Analytic 0935
ESXi shell or vim-cmd execution that deletes all VM snapshots using vmsvc/snapshot.removeall or rm on snapshot paths
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 | d654968f2dd3… |
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 AN0935Open 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.