AN0849: Analytic 0849
Enumeration of local ESXi accounts using esxcli or vSphere API from unauthorized sessions.
Analyst context for executives and security teams
This analytic is about spotting unauthorized attempts to enumerate local accounts on ESXi hosts using esxcli or the vSphere API. For leaders, the practical issue is visibility into virtualization administration activity: if an unauthorized session can list local ESXi accounts, responders may be dealing with credential discovery or preparation for further access against critical infrastructure hosting business workloads.
Executive priority
Prioritize this as a control-validation item for virtualization security and incident readiness. ESXi hosts often support high-value business services, so security leaders should ask whether administrative sessions are attributable, logged, reviewed, and separated from normal user activity. The key decision value is confirming that SOC and IR teams can distinguish approved ESXi administration from unauthorized account enumeration and can produce audit evidence for privileged access monitoring.
Technical view
The supplied ATT&CK object identifies ESXi as the platform and describes enumeration of local ESXi accounts via esxcli or the vSphere API from unauthorized sessions. Because ATT&CK provides no official detection logic or tactic mapping for this analytic, teams should validate locally available ESXi/vCenter authentication, session, API, and command/activity logs and define what constitutes an authorized versus unauthorized administrative session in their environment.
Likely telemetry
- ESXi host authentication and session logs
- vCenter or vSphere API audit/activity logs
- Administrative command execution records involving esxcli where collected
- Privileged account and local ESXi account inventory records
- Source IP, user, session, and timestamp context for ESXi administrative access
Detection direction
- Baseline approved ESXi and vSphere administrative users, service accounts, source networks, and management hosts before alerting on enumeration behavior.
- Correlate account-listing activity with authentication/session context to identify activity from unauthorized or unexpected sessions.
- Tune for legitimate administrative workflows, audits, backup operations, or inventory tooling that may query local accounts.
- Validate whether logs capture both esxcli-driven activity and vSphere API-driven account enumeration; one path may be visible while the other is not.
- Because no ATT&CK detection text is supplied, treat this as a detection engineering requirement rather than a ready-made rule.
Mitigation priorities
- Restrict ESXi and vSphere administrative access to approved identities, management networks, and hardened administration paths.
- Review and reduce local ESXi accounts where operationally feasible, with clear ownership and documented business need.
- Ensure privileged access monitoring covers ESXi hosts and vSphere API activity, not only general server or endpoint logs.
- Maintain audit-ready records of authorized administrators, service accounts, and expected management tooling.
- Test incident response procedures for suspicious ESXi administrative sessions, including evidence preservation from host and vCenter logs.
Analyst notes and limits
This object is a detection analytic, not a technique description. Its value is in prompting validation of ESXi administrative telemetry and authorization context. Relationship context, tactic mapping, and official detection logic were not supplied, so local baselining is essential.
The source fields provide only a short description, ESXi platform scope, and external reference. No official detection query, data sources, related ATT&CK techniques, tactics, procedures, threat actors, or mitigations were supplied. Conclusions should therefore be limited to defensive validation around unauthorized ESXi local account enumeration.
Analytic 0849
Enumeration of local ESXi accounts using esxcli or vSphere API from unauthorized sessions.
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 | 9fece96637d4… |
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 AN0849Open 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.