AN1238: Analytic 1238
Account created using esxcli commands. Sequence includes esxcli execution and successful modification to account DB.
Analyst context for executives and security teams
This analytic matters because new local account creation on ESXi can change who has administrative access to virtualization infrastructure. For executives and security leaders, the business issue is not the command itself; it is whether the organization can prove that privileged access changes on hypervisors are authorized, logged, reviewed, and investigated quickly.
Executive priority
Treat ESXi account creation as a control-validation point for identity governance, virtualization resilience, and incident readiness. Leaders should ask whether hypervisor account changes are covered by change management, privileged access review, centralized logging, and SOC triage procedures. If ESXi supports critical workloads, gaps here can weaken audit evidence and slow incident decisions during a virtualization security event.
Technical view
The supplied analytic describes a sequence on ESXi: esxcli execution followed by successful modification to the account database. SOC and detection teams should validate whether they can observe both parts of that sequence and correlate them on the same host and time window. Because no official detection logic or related ATT&CK technique context was supplied, implementation should focus on authorized-versus-unauthorized account creation workflows rather than assuming malicious activity from esxcli use alone.
Likely telemetry
- ESXi host command execution evidence showing esxcli activity
- ESXi authentication and authorization logs
- Local account or account database change records on ESXi
- Change-management records for approved administrator account creation
- Centralized log collection from ESXi hosts, if configured
Detection direction
- Validate that ESXi logs are collected centrally and retained long enough to investigate account creation events.
- Correlate esxcli execution with successful account database modification on the same ESXi host.
- Tune for approved administrative maintenance to reduce false positives, but require evidence of authorization for new or modified privileged accounts.
- Alerting should prioritize unexpected account creation, creation outside maintenance windows, or accounts not tied to documented change requests.
- Review blind spots where ESXi hosts are not forwarding logs, local logs can be overwritten, or account changes are reviewed only manually.
Mitigation priorities
- Maintain an authoritative inventory of ESXi administrative accounts and expected owners.
- Require formal change approval for ESXi account creation or modification.
- Restrict ESXi administrative access to approved personnel and managed administrative paths.
- Centralize ESXi logging and include account-change events in SOC runbooks.
- Perform periodic privileged access reviews for hypervisor accounts and reconcile findings with change records.
Analyst notes and limits
This is a detection analytic, not a full ATT&CK technique entry. The only supplied behavior is ESXi account creation using esxcli with a successful account database modification. The practical value is in validating visibility and governance around privileged hypervisor identity changes.
No official detection text, tactics, relationships, aliases, or related techniques were supplied. This take does not infer attacker intent, active exploitation, attribution, or guaranteed detection coverage. Local ESXi logging configuration and account-management process evidence are required to determine real coverage.
Analytic 1238
Account created using esxcli commands. Sequence includes esxcli execution and successful modification to account DB.
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 | eeab38d607fb… |
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 AN1238Open 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.