AN0912: Analytic 0912
Direct execution of /bin/vmx or presence of rogue .vmx files not registered in vCenter inventory. Defender perspective: anomalous commands in shell history, edits to rc.local.d/local.sh for persistence.
Analyst context for executives and security teams
This analytic matters because it points to virtual machines being run or persisted on an ESXi host outside normal vCenter inventory control. For leaders, the business issue is not just a suspicious command: it is whether critical virtualization infrastructure can be used in ways that bypass asset inventory, monitoring, change control, and incident scoping.
Executive priority
Prioritize validation where ESXi hosts support important workloads or regulated systems. Ask whether the organization can prove that every running or configured VM is registered in vCenter inventory, that host-level shell activity is monitored, and that startup scripts are governed. This is relevant to operational resilience, audit evidence, incident response scoping, and virtualization administration controls.
Technical view
SOC, IR, and platform teams should validate visibility on ESXi hosts for direct execution of /bin/vmx, rogue .vmx files that are not registered in vCenter inventory, anomalous commands in shell history, and edits to rc.local.d/local.sh that could indicate persistence. Because the ATT&CK object provides no tactic or relationship context, treat this as a detection analytic focused on host and inventory consistency rather than as proof of a specific intrusion phase.
Likely telemetry
- ESXi host shell history and command execution evidence
- vCenter inventory data for registered virtual machines
- ESXi datastore file listings for .vmx files
- Configuration or file integrity evidence for rc.local.d/local.sh
- Administrative change records for ESXi host maintenance and VM registration activity
Detection direction
- Compare .vmx files present on ESXi datastores with VMs registered in vCenter inventory to identify unregistered candidates.
- Review host shell activity for direct /bin/vmx execution and distinguish expected administrative troubleshooting from anomalous use.
- Monitor or periodically verify rc.local.d/local.sh for unauthorized edits, with attention to persistence-like startup behavior.
- Tune triage around authorized maintenance windows, lab hosts, recovery operations, and documented administrator actions to reduce false positives.
- Validate that ESXi host logging and vCenter inventory collection are complete enough to support this analytic; missing host-level telemetry is a primary blind spot.
Mitigation priorities
- Establish governance requiring VMs to be registered and managed through approved vCenter workflows.
- Restrict and audit ESXi shell access to authorized administrators only.
- Maintain change control and integrity monitoring for ESXi startup scripts such as rc.local.d/local.sh.
- Regularly reconcile datastore contents against vCenter inventory for high-value ESXi environments.
- Ensure incident response playbooks include steps to identify unregistered VMs and host-level persistence artifacts on ESXi.
Analyst notes and limits
The object is an ATT&CK detection analytic for ESXi. Its strongest decision value is inventory and host-control assurance: defenders should be able to explain whether a VM exists outside normal management visibility and whether ESXi startup behavior has been altered.
The supplied ATT&CK fields include no tactic, no relationships, and no official detection procedure beyond the description. This take therefore avoids attribution, exploitation claims, impact claims, and guaranteed detection outcomes. Local ESXi architecture, logging configuration, administrative practices, and vCenter coverage are required to assess material risk.
Analytic 0912
Direct execution of /bin/vmx or presence of rogue .vmx files not registered in vCenter inventory. Defender perspective: anomalous commands in shell history, edits to rc.local.d/local.sh for persistence.
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 | 362f02faeed4… |
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 AN0912Open 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.