AN0754: Analytic 0754
vSphere API logins (vimService) or SSH to ESXi host followed by unauthorized shell commands or lateral remote logins from the ESXi host.
Analyst context for executives and security teams
This analytic focuses on suspicious access to ESXi management surfaces: vSphere API logins through vimService or SSH access to an ESXi host followed by unauthorized shell commands or remote logins from that host. For leaders, the value is in validating whether the organization can see and investigate administrative activity on virtualization infrastructure, where poor visibility can delay incident decisions affecting business continuity.
Executive priority
Treat this as a control-validation item for critical virtualization operations. ESXi hosts often support important workloads, so security leaders should confirm who is allowed to log in, whether shell use is governed, and whether SOC/IR teams have usable evidence when ESXi access appears unauthorized. This also supports audit and compliance conversations around privileged access, administrative logging, and incident readiness for core infrastructure.
Technical view
For SOC and IR teams, the practical task is to validate monitoring around ESXi access paths named in the ATT&CK object: vSphere API logins using vimService, SSH logins to ESXi hosts, subsequent shell command activity, and lateral remote logins originating from an ESXi host. Because no official detection logic or relationships are supplied, teams should build or tune detections against local baselines for expected ESXi administrators, management jump hosts, maintenance windows, and approved automation.
Likely telemetry
- vSphere or ESXi authentication logs showing vimService/API login activity
- ESXi SSH login records
- ESXi shell command or host management logs where available
- Network telemetry showing remote logins to or from ESXi hosts
- Privileged account and administrative session records tied to ESXi management
Detection direction
- Validate that ESXi authentication and administrative activity logs are collected, retained, and searchable by the SOC.
- Alert on ESXi logins from unapproved users, sources, or times, with special attention to SSH and vSphere API/vimService access.
- Correlate ESXi host access with follow-on shell commands or remote login activity originating from the ESXi host.
- Tune for known administration, patching, backup, and automation workflows to reduce false positives.
- Document blind spots where ESXi shell activity, API authentication, or east-west network sessions are not visible.
Mitigation priorities
- Confirm and enforce approved administrative access paths for ESXi hosts.
- Restrict SSH and shell access to authorized administrators and management sources where operationally feasible.
- Review privileged accounts used for ESXi and vSphere administration.
- Maintain logging and retention sufficient for incident response around ESXi access.
- Use inventory and change-control records to distinguish authorized maintenance from suspicious access.
Analyst notes and limits
The ATT&CK object is a detection analytic for ESXi and describes suspicious vSphere API or SSH access followed by unauthorized shell commands or lateral remote logins from the ESXi host. No ATT&CK tactics, relationships, or official detection procedure were supplied, so this take emphasizes validation of telemetry, access governance, and local baselining rather than a specific detection rule.
The source does not provide detection logic, related techniques, procedure examples, attribution, or evidence of active exploitation. Any assessment of risk, coverage, or alert fidelity requires local ESXi architecture, logging configuration, administrator baselines, and network visibility.
Analytic 0754
vSphere API logins (vimService) or SSH to ESXi host followed by unauthorized shell commands or lateral remote logins from the ESXi host.
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 | 2f19003856a4… |
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 AN0754Open 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.