T1059.012: Hypervisor CLI
Adversaries may abuse hypervisor command line interpreters (CLIs) to execute malicious commands. Hypervisor CLIs typically enable a wide variety of functionality for managing both the hypervisor itself and the guest virtual machines it hosts.
For example, on ESXi systems, tools such as `esxcli` and `vim-cmd` allow administrators to configure firewall rules and log forwarding on the hypervisor, list virtual machines, start and stop virtual machines, and more.[1][2][3] Adversaries may be able to leverage these tools in order to support further actions, such as File and Directory Discovery or Data Encrypted for Impact.
Analyst context for executives and security teams
Hypervisor CLI abuse matters because ESXi command-line tools can directly control the virtualization layer that hosts business systems. If an adversary obtains sufficient access, commands such as those run through ESXi management CLIs may support discovery, VM control, firewall or log-forwarding changes, and follow-on impact such as encryption. This is not just endpoint execution; it is execution at the infrastructure layer where many servers may depend on one platform.
Executive priority
Treat this as a resilience and incident-readiness issue for ESXi estates. Leaders should ask whether hypervisor administrative access is tightly governed, whether CLI activity is logged and reviewed, and whether incident teams can quickly determine which VMs were listed, stopped, started, or otherwise affected. The ATT&CK relationships to ransomware families that target ESXi and to a backdoor with ESXi command execution make this especially relevant to recovery planning and audit evidence around privileged administration.
Technical view
T1059.012 is an ESXi execution sub-technique under Command and Scripting Interpreter. SOC and IR teams should validate visibility into hypervisor command execution, especially use of native management utilities such as esxcli and vim-cmd where available. Because MITRE provides no official detection text for this object, detection engineering should be driven by local ESXi logging, administrative access patterns, configuration-change records, and relationship context from DET0558, Royal, Cheerscrypt, VIRTUALPIE, and UNC3886.
Likely telemetry
- ESXi shell or management CLI command activity, including esxcli and vim-cmd where logged
- Hypervisor authentication and administrative session records
- VM inventory, power state, start, stop, and management events
- Firewall rule and log-forwarding configuration changes on ESXi hosts
- File and directory discovery indicators on the hypervisor
Detection direction
- Validate whether DET0558 or equivalent analytics are implemented for ESXi Hypervisor CLI abuse; do not assume coverage because endpoint EDR is deployed on guest VMs.
- Baseline legitimate hypervisor administration so detections can distinguish routine operations from unusual CLI use, off-hours activity, or commands inconsistent with change control.
- Prioritize alerts on CLI activity that changes logging, firewall behavior, VM power state, or enumerates hosted systems, because these actions can support follow-on discovery or impact.
- Correlate hypervisor CLI activity with privileged logons, management-plane access, VM state changes, and ransomware-impact indicators where available.
- Account for blind spots: guest operating system telemetry may not show commands executed on the ESXi host itself, and MITRE does not supply an official detection procedure for this technique.
Mitigation priorities
- Restrict ESXi administrative access to authorized personnel and controlled management paths.
- Ensure hypervisor logs and configuration-change records are forwarded to a location an attacker cannot easily disable from the host alone.
- Review change-control coverage for firewall, logging, VM inventory, and VM power operations performed through hypervisor CLIs.
- Include ESXi CLI abuse scenarios in incident response playbooks and recovery exercises, especially for ransomware and virtualization-layer compromise.
- Use relationship context to prioritize validation for environments running ESXi because the supplied ATT&CK object only lists ESXi as the platform.
Analyst notes and limits
ATT&CK links this technique to the broader Command and Scripting Interpreter technique and identifies ESXi as the platform. The relationship context shows use by UNC3886 and by ESXi-relevant software entries including Royal, Cheerscrypt, and VIRTUALPIE; these relationships support prioritizing hypervisor visibility but do not by themselves prove activity in any specific environment.
The official ATT&CK object does not provide detection guidance or mitigations. Recommendations here are defensive validation directions inferred from the official description, ESXi platform scope, external references, and supplied relationships. Local logging configuration, ESXi administration model, and retention determine whether the suggested telemetry is actually available.
Hypervisor CLI
Adversaries may abuse hypervisor command line interpreters (CLIs) to execute malicious commands. Hypervisor CLIs typically enable a wide variety of functionality for managing both the hypervisor itself and the guest virtual machines it hosts.
For example, on ESXi systems, tools such as `esxcli` and `vim-cmd` allow administrators to configure firewall rules and log forwarding on the hypervisor, list virtual machines, start and stop virtual machines, and more.[1][2][3] Adversaries may be able to leverage these tools in order to support further actions, such as File and Directory Discovery or Data Encrypted for Impact.
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.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1059 | Command and Scripting Interpreter | This object subtechnique of Command and Scripting Interpreter. |
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]
S1096: Cheerscrypt
Cheerscrypt is a ransomware that was developed by Cinnamon Tempest and has been used in attacks against ESXi and Windows environments since at least 2022. Cheerscrypt was derived from the leaked Babuk source code and has infrastructure overlaps with deployments of Night Sky ransomware, which was also derived from Babuk.[1][2]
S1073: Royal
Royal is ransomware that first appeared in early 2022; a version that also targets ESXi servers was later observed in February 2023. Royal employs partial encryption and multiple threads to evade detection and speed encryption. Royal has been used in attacks against multiple industries worldwide--including critical infrastructure. Security researchers have identified similarities in the encryption routines and TTPs used in Royal and Conti attacks and noted a possible connection between their operators.[1][2][3][4][5]
S1218: VIRTUALPIE
VIRTUALPIE is a lightweight backdoor written in Python that spawns an IPv6 listener on a VMware ESXi server and features command line execution, file transfer, and reverse shell capabilities. VIRTUALPIE has been in use since at least 2022 including by UNC3886 who installed it via malicious vSphere Installation Bundles (VIBs).[1]
All related ATT&CK context
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 | f0b36d7b6973… |
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 ESXCLI Reference
Broadcom. (n.d.). ESXCLI Reference. Retrieved March 27, 2025.
Open source URL -
[2]
Crowdstrike Hypervisor Jackpotting Pt 2 2021
Michael Dawson. (2021, August 30). Hypervisor Jackpotting, Part 2: eCrime Actors Increase Targeting of ESXi Servers with Ransomware. Retrieved March 26, 2025.
Open source URL -
[3]
LOLESXi
Janantha Marasinghe. (n.d.). Living Off The Land ESXi. Retrieved April 14, 2025.
Open source URL -
[4]
mitre-attack T1059.012Open 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.