T1675: ESXi Administration Command
Adversaries may abuse ESXi administration services to execute commands on guest machines hosted within an ESXi virtual environment. Persistent background services on ESXi-hosted VMs, such as the VMware Tools Daemon Service, allow for remote management from the ESXi server. The tools daemon service runs as `vmtoolsd.exe` on Windows guest operating systems, `vmware-tools-daemon` on macOS, and `vmtoolsd ` on Linux.[1]
Adversaries may leverage a variety of tools to execute commands on ESXi-hosted VMs – for example, by using the vSphere Web Services SDK to programmatically execute commands and scripts via APIs such as `StartProgramInGuest`, `ListProcessesInGuest`, `ListFileInGuest`, and `InitiateFileTransferFromGuest`.[2][3] This may enable follow-on behaviors on the guest VMs, such as File and Directory Discovery, Data from Local System, or OS Credential Dumping.
Analyst context for executives and security teams
T1675 matters because control of ESXi administration paths can become control of the guest workloads running on that hypervisor. Instead of logging into each server normally, an adversary with access to ESXi/vSphere administration capabilities may execute commands or use guest operations against hosted VMs through VMware Tools-related services and APIs. For leaders, this makes virtualization administration a high-value identity, monitoring, and incident-response control point, not just an infrastructure function.
Executive priority
Prioritize this where ESXi hosts support critical business systems. The key governance question is whether privileged ESXi/vSphere accounts, guest-operation permissions, and administrative API activity are controlled and evidenced well enough for incident response and audit. Weak account lifecycle management or limited visibility at the hypervisor layer can let activity on many guest systems appear disconnected or under-monitored, increasing business-continuity and investigation risk.
Technical view
This is an execution technique for the ESXi platform. ATT&CK describes abuse of ESXi administration services and VMware Tools guest operations, including APIs such as StartProgramInGuest, ListProcessesInGuest, ListFileInGuest, and InitiateFileTransferFromGuest. SOC and IR teams should validate whether they can correlate ESXi/vCenter administrative authentication, guest-operation API activity, and guest OS process/file evidence, especially where processes originate from VMware Tools services such as vmtoolsd.exe on Windows, vmware-tools-daemon on macOS, or vmtoolsd on Linux. ATT&CK does not provide official detection text for this technique, but a related detection strategy, DET0232, is linked.
Likely telemetry
- ESXi and vCenter administrative authentication and session logs
- vSphere Web Services SDK or guest-operations API audit records, where available
- Events for guest operations such as program execution, process listing, file listing, and guest file transfer
- Guest OS process creation telemetry showing VMware Tools service context or parentage
- Guest OS file access or transfer evidence associated with VMware Tools operations
Detection direction
- Confirm whether DET0232 or an equivalent local detection strategy is implemented and mapped to ESXi guest-operation activity.
- Baseline legitimate ESXi/vSphere administrative guest operations so detections can distinguish routine management from unusual command execution or file activity.
- Correlate hypervisor-side administration events with guest-side process and file telemetry; relying on only endpoint logs or only vCenter logs may miss context.
- Pay particular attention to privileged account use, unexpected guest-operation APIs, unusual timing, and operations against sensitive or high-availability VMs.
- Account for false positives from normal administrator activity, automation, backup, maintenance, and support workflows that may legitimately use VMware Tools guest operations.
Mitigation priorities
- Apply User Account Management (M1018): enforce least privilege, tightly manage privileged ESXi/vSphere accounts, and promptly deactivate or modify accounts when roles change.
- Review which users, service accounts, and automation have permissions that enable guest operations through ESXi/vSphere administration services.
- Maintain auditable account lifecycle and privilege-change records for virtualization administration.
- Limit administrative access paths to ESXi/vCenter to required personnel and managed processes, then monitor those paths as high-value control points.
- Include ESXi/vSphere administration activity in incident-response playbooks so responders can assess both hypervisor actions and guest VM effects.
Analyst notes and limits
The relationship context adds useful prioritization: UNC3886 is listed as using this technique, and VIRTUALPITA is listed as software using it, with ESXi and Linux platforms noted for the software. These relationships support threat-informed validation but should not be treated as evidence of current activity in any specific environment. The supplied mitigation relationship is User Account Management, so identity governance and privilege control are the clearest control priorities.
ATT&CK provides no official detection text for T1675 in the supplied object, and DET0232 details are not included here. Local logging capability varies by ESXi/vCenter configuration, VMware Tools deployment, guest OS telemetry, and SIEM ingestion. This take is limited to the supplied ATT&CK fields, references, and relationships and does not establish active exploitation or customer exposure.
ESXi Administration Command
Adversaries may abuse ESXi administration services to execute commands on guest machines hosted within an ESXi virtual environment. Persistent background services on ESXi-hosted VMs, such as the VMware Tools Daemon Service, allow for remote management from the ESXi server. The tools daemon service runs as `vmtoolsd.exe` on Windows guest operating systems, `vmware-tools-daemon` on macOS, and `vmtoolsd ` on Linux.[1]
Adversaries may leverage a variety of tools to execute commands on ESXi-hosted VMs – for example, by using the vSphere Web Services SDK to programmatically execute commands and scripts via APIs such as `StartProgramInGuest`, `ListProcessesInGuest`, `ListFileInGuest`, and `InitiateFileTransferFromGuest`.[2][3] This may enable follow-on behaviors on the guest VMs, such as File and Directory Discovery, Data from Local System, or OS Credential Dumping.
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.
Groups, software, and campaigns
G1048: UNC3886
UNC3886 is a China-nexus cyberespionage group that has been active since at least 2022, targeting defense, technology, and telecommunication organizations located in the United States and the Asia-Pacific-Japan (APJ) regions. UNC3886 has displayed a deep understanding of edge devices and virtualization technologies through the exploitation of zero-day vulnerabilities and the use of novel malware families and utilities.[1][2]
S1217: VIRTUALPITA
VIRTUALPITA is a passive backdoor with ESXi and Linux vCenter variants capable of command execution, file transfer, and starting and stopping processes. VIRTUALPITA has been in use since at least 2022 including by UNC3886 who leveraged malicious vSphere Installation Bundles (VIBs) for install on ESXi hypervisors.[1]
All related ATT&CK context
Mitigation direction
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 | 2cd971ea7be9… |
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]
Broadcom VMware Tools Services
Broadcom. (n.d.). VMware Tools Services. Retrieved March 28, 2025.
Open source URL -
[2]
Google Cloud Threat Intelligence VMWare ESXi Zero-Day 2023
Alexander Marvi, Brad Slaybaugh, Ron Craft, and Rufus Brown. (2023, June 13). VMware ESXi Zero-Day Used by Chinese Espionage Actor to Perform Privileged Guest Operations on Compromised Hypervisors. Retrieved March 26, 2025.
Open source URL -
[3]
Broadcom Running Guest OS Operations
Broadcom. (n.d.). Running Guest OS Operations. Retrieved March 28, 2025.
Open source URL -
[4]
mitre-attack T1675Open 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.