AN0064: Analytic 0064
Attacker disables VM-related services or stops VMs forcibly to target vmdk or logs. Behavioral chain: esxcli or vim-cmd stop + audit log showing user privilege use + datastore file manipulation.
Analyst context for executives and security teams
This analytic matters because forced VM shutdown or service disruption on ESXi can be a precursor to tampering with virtual disk files or logs. For business leaders, the key issue is not just a hypervisor command being run; it is whether the organization can quickly prove who used privileged access, which VMs were affected, and whether datastore files were manipulated during an incident.
Executive priority
Prioritize this as an operational resilience and privileged-access assurance issue for ESXi environments. Leaders should ask whether SOC and infrastructure teams can correlate hypervisor administrative actions with audit evidence and datastore activity, and whether that evidence is retained well enough to support incident response, recovery decisions, and compliance review.
Technical view
The supplied analytic is for ESXi and describes a behavioral chain: use of ESXi management commands to stop VM-related services or forcibly stop VMs, audit logs showing privileged user activity, and subsequent datastore file manipulation involving VMDK files or logs. SOC and IR teams should validate whether ESXi command activity, privilege-use audit events, VM power/service state changes, and datastore file operations can be correlated by user, host, VM, and time window. Because no official detection logic is provided, local baselining and environment-specific tuning are required.
Likely telemetry
- ESXi host audit logs showing privileged user actions
- VM stop, power-state, or service-state events from ESXi management interfaces
- Command execution evidence involving ESXi administration utilities where available
- Datastore file activity involving VMDK files and logs
- Authentication and session records for ESXi administrative access
Detection direction
- Validate correlation across three evidence classes: VM/service stop activity, privileged user audit events, and datastore file manipulation.
- Tune for authorized maintenance windows, backup operations, storage administration, and planned VM lifecycle activity to reduce false positives.
- Prioritize alerts where VM shutdown activity is followed closely by VMDK or log manipulation on the same datastore or host.
- Confirm whether logs identify the acting user or service account; shared or poorly attributed administrative access is a major blind spot.
- Because ATT&CK supplies no detection implementation, treat this as a detection-validation requirement rather than a ready-to-deploy rule.
Mitigation priorities
- Harden and review privileged access to ESXi administrative functions, especially accounts able to stop VMs or manipulate datastore files.
- Ensure ESXi audit logging and datastore activity records are enabled, retained, and protected from tampering where feasible.
- Separate routine maintenance workflows from emergency or high-risk administrative actions through approval and change tracking.
- Review recovery readiness for affected VMs, including backup integrity and the ability to investigate VMDK or log changes.
- Use periodic control testing to confirm the SOC can reconstruct the described behavioral chain.
Analyst notes and limits
This object is a detection analytic rather than a technique, and no tactic, relationship context, or official detection query is supplied. The practical value is in using the described behavioral chain to test ESXi visibility, privileged-access accountability, and incident reconstruction capability.
Assessment is limited to the official STIX fields and the single MITRE external reference. No active exploitation, adversary attribution, prevalence, impact outcome, or guaranteed detection coverage is stated by the supplied data. Local ESXi architecture, logging configuration, retention, and administrative practices will determine actual coverage.
Analytic 0064
Attacker disables VM-related services or stops VMs forcibly to target vmdk or logs. Behavioral chain: esxcli or vim-cmd stop + audit log showing user privilege use + datastore file manipulation.
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 | e1c64bba32a8… |
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 AN0064Open 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.