AN1387: Analytic 1387
Abuse of VMFS or ESXi shell to hide datastore files, renaming/moving VMDK or VMX files into hidden directories. Defender view: anomalous ESXi shell commands or file operations obscuring VM artifacts.
Analyst context for executives and security teams
This analytic points to a virtualization-layer visibility problem: ESXi datastore files that define or store virtual machines may be renamed, moved, or hidden through VMFS or ESXi shell activity. For leaders, the value is not that this proves an incident by itself, but that loss of visibility into VMX/VMDK artifacts can complicate recovery, asset accountability, and incident scoping in environments that depend on VMware ESXi.
Executive priority
Prioritize this as a resilience and evidence-readiness issue for ESXi estates. Security and infrastructure leaders should ask whether ESXi shell activity and datastore file operations are logged, retained, and reviewed well enough to explain unexpected VM inventory changes during an incident. This supports business continuity, audit evidence, and IR readiness, especially where critical workloads run on ESXi.
Technical view
SOC and IR teams should validate whether they can observe anomalous ESXi shell commands and datastore file operations involving VM artifacts, especially VMX and VMDK files. Because ATT&CK does not provide a specific detection expression for this analytic, teams should focus on coverage validation: what events are available from ESXi hosts, how file rename/move activity is captured, and whether VM inventory state can be compared against datastore contents.
Likely telemetry
- ESXi shell command history or command execution logs where available
- VMFS datastore file operation records or logs showing rename, move, or directory changes
- vCenter or ESXi host management events related to VM inventory changes
- Datastore inventory scans for VMX and VMDK file location changes
- Administrative authentication and session logs for ESXi or vCenter access
Detection direction
- Baseline normal datastore maintenance and administrative file operations before alerting on all VMX/VMDK movement.
- Look for unexpected rename or move activity involving VM artifacts, particularly into hidden or nonstandard directories.
- Correlate datastore file changes with authorized change records, ESXi shell sessions, and VM inventory updates.
- Treat lack of ESXi shell or datastore file telemetry as a material blind spot rather than assuming coverage exists.
- Tune for legitimate maintenance, backup, migration, and recovery workflows that may also move or rename VM files.
Mitigation priorities
- Restrict and monitor ESXi shell access based on administrative need.
- Ensure ESXi and vCenter administrative activity is logged and retained for incident response.
- Maintain authoritative VM inventory and compare it with datastore contents where feasible.
- Require change control for datastore-level VM artifact movement or renaming.
- Validate backup and recovery processes can account for hidden, moved, or renamed VM artifacts.
Analyst notes and limits
The supplied object is a detection analytic for ESXi and describes abuse of VMFS or ESXi shell to obscure VM artifacts. No ATT&CK tactic, related technique, procedure, or detection query was supplied, so this take focuses on defensive validation and telemetry readiness rather than specific threat behavior.
Official detection content and relationship context were not provided. Local ESXi logging configuration, vCenter architecture, datastore practices, and administrative workflows are required to determine practical detectability and false-positive levels.
Analytic 1387
Abuse of VMFS or ESXi shell to hide datastore files, renaming/moving VMDK or VMX files into hidden directories. Defender view: anomalous ESXi shell commands or file operations obscuring VM artifacts.
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 | 684746eade8a… |
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 AN1387Open 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.