Detecting Virtual Machine Discovery (MITRE ATT&CK T1673)

Virtual Machine Discovery (T1673) is a Discovery technique. After gaining access to a host or hypervisor, an adversary enumerates the virtual machines that are running. MITRE lists ESXi, Linux, macOS and Windows as platforms.

How attackers use it

MITRE's example is an ESXi hypervisor. An adversary can use a Hypervisor CLI (T1059.012) such as esxcli or vim-cmd, with commands like esxcli vm process list or vim-cmd vmsvc/getallvms. They can also use a graphical interface such as VMware vCenter to see the VMs on a host.

The list shapes what happens next. MITRE says discovered VMs can be used for follow-on actions such as Service Stop (T1489) or Data Encrypted for Impact (T1486). In other words, knowing which VMs exist tells the adversary what to stop and encrypt.

The technique page records examples of ransomware that ran esxcli vm process list to gather running VMs before terminating them, scripts that enumerated ESXi hypervisors and their guests, and malware that queried for virtual machine environments including ESXi hosts, datacenters and clusters in vCenter.

How to detect it

MITRE notes this technique cannot be easily mitigated with preventive controls because it abuses system features. Detection is the main tool, and the guidance lists commands by platform:

• ESXi and Linux hypervisors. Execution of esxcli vm process list or vim-cmd vmsvc/getallvms by unexpected users or outside normal admin workflows. For tools like virsh, VBoxManage and qemu-img, correlate command invocations with parent process lineage and the account involved.
• Windows. PowerShell Get-VM, VMware Workstation's vmrun.exe, or Hyper-V and VirtualBox tooling run by unexpected users or outside normal administrative sessions.
• macOS. Virtualization utilities such as VBoxManage or the Parallels CLI used abnormally, especially by non-admin users or from unusual parent processes.

The common signal is the same everywhere: a VM listing command from an account or session that is not part of normal operations.

How to reduce the risk

MITRE has no formal mitigation. Practical steps:

• Limit who can log in to hypervisor hosts and management consoles.
• Disable shell access on ESXi unless it is in use, and log when it is turned on.
• Forward hypervisor logs off the host so an intruder cannot erase them.
• Alert on VM enumeration commands from accounts that do not normally administer virtualization.

Check your own environment

Start with an inventory of what you actually run. If you cannot list your hypervisors, you cannot tell which ones matter.

• List every hypervisor host and management console and who can reach them.
• Confirm who is allowed to run VM management commands, and by what path.
• Check that hypervisor logs are forwarded to a central place.
• Test your alerting by having an authorized admin run a listing command and checking whether it appears.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• MITRE ATT&CK, Virtual Machine Discovery (T1673): https://attack.mitre.org/techniques/T1673