T1059.012 Hypervisor CLI is a sub-technique of Command and Scripting Interpreter (T1059) in the MITRE ATT&CK framework, under the Execution tactic. It refers to the use of a command-line interface (CLI) to interact with and manage hypervisors that control virtual machines (VMs). This interface allows administrators to directly issue commands to the hypervisor or VMs, enabling tasks such as creating, starting, stopping, or migrating VMs, adjusting resource allocations (CPU, memory, storage), and reviewing logs.
Hypervisor CLIs provide precise, scriptable management, enabling administrators to bypass graphical user interfaces and perform low-level diagnostics or maintenance tasks more efficiently. Due to their integration with virtualization layers, hypervisor CLIs allow for powerful, flexible control of virtual environments, supporting tasks from routine management to advanced debugging and system configuration.
To read about other sub-techniques of the T1059 Command and Scripting Interpreter technique, you can visit the related hub blog.
Adversaries use T1059.012 Hypervisor CLI to gain administrative access to the virtualization layer, enabling them to operate below the guest operating system and bypass traditional endpoint defenses. With this level of control, attackers can manipulate VMs, perform actions directly on virtual disks, and execute commands that evade in-guest security mechanisms.
By exploiting hypervisor CLI access, adversaries can disable or reconfigure virtual machine protections, migrate VMs to other hosts, or manipulate offline virtual disks to extract credentials, steal data, or deploy malicious payloads. These actions, which occur outside the reach of traditional EDR solutions, guest OS logging, or other in-VM defenses, allow for rapid escalation, lateral movement, and data exfiltration. The ability to operate directly at the hypervisor level enables adversaries to compromise entire virtualized infrastructures stealthily, making it a high-impact method for bypassing defenses and maintaining persistence across cloud and on-prem virtual environments.
In mid-2025, UNC3944 was observed abusing the ESXi hypervisor CLI as a central mechanism in its vSphere-focused intrusion chain [1]. After socially engineering help desk agents and gaining control of privileged Active Directory accounts, the group used inherited vCenter admin rights to enable SSH on ESXi hosts and reset the root password, granting themselves direct hypervisor shell access.
From there, UNC3944 issued ESXi-level commands to disable security controls such as execInstalledOnly, power off critical VMs, and perform offline disk operations. This included detaching a Domain Controller's VMDK and attaching it to an abandoned "orphaned" VM they controlled, allowing them to extract NTDS.dit without generating any in-guest telemetry.
|
Adversarial Goal |
Hypervisor CLI Action (as described in the blog) |
Why It Works |
|
Gain hypervisor control |
Enable SSH, reset root password |
Gives root-level ESXi access |
|
Disable protections |
Turn off execInstalledOnly |
Allows ransomware execution |
|
Steal AD credentials |
Offline disk manipulation (detach/attach DC disks) |
Bypasses Windows & EDR |
|
Prepare ransomware |
Power off VMs at hypervisor layer |
Unlocks .vmdk for encryption |
|
Execute ransomware |
Run custom binary via ESXi shell |
Encrypts entire datastores |
|
Exfiltrate data |
SFTP staging & C2 exfiltration via VCSA |
Avoids segmentation & detection |
|
Maintain stealth |
Work entirely below guest OS |
No visibility from in-guest tools |
They then used SFTP from the hypervisor shell to stage stolen data on the compromised VCSA and exfiltrated it through a Teleport-based C2 channel established earlier in the intrusion. In the ransomware phase, UNC3944 uploaded their payload to /tmp, made it executable, and launched it using nohup, coordinating mass VM shutdowns via vim-cmd before encrypting datastore-level files (.vmdk, .vmx).
ESXi shell logs captured each step, from login, payload preparation, and exclusion-list creation to ransomware execution and cleanup, while the group's operations remained largely invisible to EDR due to their placement at the hypervisor layer. This use of the hypervisor CLI enabled UNC3944 to achieve rapid, full-environment impact with minimal forensic noise.
[1] “From Help Desk to Hypervisor: Defending Your VMware vSphere Estate from UNC3944,” Google Cloud Blog, Jul. 23, 2025. Available: https://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944. [Accessed: Dec. 04, 2025]