AN0337: Analytic 0337
Invocation of esxcli 'system account remove' from vCLI, SSH, or vSphere API with anomalous user access or outside maintenance windows.
Analyst context for executives and security teams
This analytic is about watching for removal of ESXi system accounts through administrative access paths such as vCLI, SSH, or the vSphere API, especially when the user or timing is unusual. For leaders, the practical issue is change control and administrator accountability on virtualization infrastructure: unexpected account removal can disrupt access, weaken forensic traceability, or indicate unauthorized manipulation of a critical platform.
Executive priority
Prioritize this where ESXi supports business-critical workloads. Executives and risk owners should ask whether ESXi account changes are logged, reviewed against maintenance windows, and tied to approved administrators. This supports operational resilience, incident response readiness, and audit evidence for privileged access governance.
Technical view
SOC and detection teams should validate visibility into ESXi administrative actions involving account removal, with context for the initiating user, access path, target host, timestamp, and whether the activity occurred during an approved maintenance window. Because ATT&CK provides no formal detection logic for this analytic, local baselining of normal ESXi administration is required.
Likely telemetry
- ESXi host administrative logs
- vCLI activity records where available
- SSH authentication and command/session logs for ESXi administration
- vSphere API or management-plane audit events
- Privileged account inventory and role membership data
Detection direction
- Alert on ESXi system account removal when performed by anomalous users or outside approved maintenance windows.
- Correlate account-removal events with authentication source, administrative role, and recent change tickets.
- Tune for legitimate lifecycle activity such as planned deprovisioning, break-glass cleanup, or maintenance operations.
- Validate blind spots around direct host SSH access, incomplete vSphere API auditing, and unmanaged ESXi hosts outside centralized logging.
Mitigation priorities
- Establish and enforce approved maintenance windows for ESXi account administration.
- Restrict ESXi administrative access to authorized users and controlled access paths.
- Centralize and retain ESXi, SSH, vCLI, and vSphere API audit evidence for investigation and compliance review.
- Regularly reconcile ESXi local/system accounts against approved privileged-access records.
- Test incident response procedures for unauthorized or unexplained ESXi account changes.
Analyst notes and limits
This object is a detection analytic for ESXi and specifically references invocation of esxcli system account remove from vCLI, SSH, or the vSphere API with anomalous access or timing. There are no supplied ATT&CK tactics, technique relationships, aliases, or detection details, so the take focuses on defensive validation and governance value rather than inferred adversary behavior.
Official detection logic is not provided, and no relationship context is supplied. Organizations must rely on their own ESXi logging configuration, privileged-access model, maintenance-window data, and baseline administrator behavior to determine alert fidelity and coverage.
Analytic 0337
Invocation of esxcli 'system account remove' from vCLI, SSH, or vSphere API with anomalous user access or outside maintenance windows.
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 | 2b212a3afe8e… |
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 AN0337Open 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.