T1673 Virtual Machine Discovery: Spotting VM Enumeration Before Mass Encryption

Before ransomware encrypts a datastore it has to know which virtual machines are running, and that listing step is one of the last chances to stop the attack. MITRE ATT&CK T1673 Virtual Machine Discovery covers adversaries enumerating the VMs on a host or hypervisor, from hypervisor command line tools on ESXi to vCenter and desktop virtualisation tools on Windows, Linux and macOS. ATT&CK v20 places it in the Discovery tactic (TA0007). This guide explains how ransomware crews and espionage groups have used it, what MITRE's detection strategy DET0199 looks for, why the hypervisor is often the blind spot, and how to test and measure coverage. It is written for detection engineers, virtualisation administrators and incident responders.

Key takeaways

• It is the step before impact. ATT&CK states that discovered VMs may be used for follow-on Service Stop (T1489) or Data Encrypted for Impact (T1486). On ESXi, list, power off and encrypt often run within one script.
• The command set is small and specific. ATT&CK and vendor research name esxcli vm process list and vim-cmd vmsvc/getallvms on ESXi, which makes high fidelity detection possible where shell activity is logged and forwarded.
• Visibility is the hard part. Traditional host EDR agents generally cannot be installed on ESXi (check your vendor's support), so detection depends on forwarding shell.log, auth.log and hostd.log off the host before an attacker can tamper with them.
• Most ESXi enumeration needs a shell first. Enabling SSH or the ESXi Shell, or logging in directly to a host that is normally managed by vCenter, is a stronger and earlier signal than the listing command itself.
• Prevention is access control on the management plane. Lockdown mode, no internet exposure for vCenter, MFA on jump hosts and separate virtualisation admin identities remove most paths to this technique.

What T1673 covers

ATT&CK describes an adversary enumerating running virtual machines after gaining access to a host or hypervisor, for example with a Hypervisor CLI (T1059.012) such as esxcli or vim-cmd, or through a graphical interface such as VMware vCenter. The technique was added in 2025 and covers ESXi, Linux, macOS and Windows. It has no sub-techniques.

Malware that checks whether it is itself running inside a VM is a different technique, T1497 Virtualization/Sandbox Evasion; see the MITRE ATT&CK T1497 Virtualization/Sandbox Evasion guide. ATT&CK v20 also records some software under T1673 for finding virtualisation-related processes or hardware, so expect some overlap in threat reports.

How adversaries use it: recorded cases

The pattern behind these cases is that the VM list feeds an automated loop. In the eCrime examples, enumeration, power off and encryption are seconds apart, so detection only helps if it triggers containment automatically or arrives while the attacker is still establishing access. See the Play Ransomware Profile, the Qilin Threat Actor Profile and the UNC3886 Threat Actor Profile Guide.

Case: ESXi encryption at MGM Resorts

The MGM Resorts Breach 2023 page records the attackers' own claim, not confirmed by MGM, that ALPHV ransomware was deployed to more than 100 ESXi hypervisors after help desk social engineering gave the intruders identity platform admin access. Whatever the exact tooling, encrypting that many hypervisors requires knowing which hosts and VMs exist, which is the information T1673 and related discovery provide. The lesson for defenders is that identity compromise reached the virtualisation layer, so hypervisor telemetry and separate virtualisation admin credentials matter as much as endpoint controls.

What to detect and where

ATT&CK v20 maps detection strategy DET0199 to T1673 with four analytics. The table restates them and adds what makes each one practical.

ESXi telemetry you need first

Broadcom documents the ESXi log files in /var/run/log. The ones that matter here:

• shell.log: ESXi Shell usage, including enabling and disabling the shell and every command entered. This is where VM listing commands appear.
• auth.log: successful and failed ESXi Shell authentication, which gives the account and source behind a session.
• hostd.log: the host management service, including VM and host tasks and events and SDK connections. API driven enumeration and power operations surface here.
• vpxa.log: the vCenter agent's communication with vCenter and hostd.
• syslog.log: management service initialisation, scheduled tasks and DCUI use.

Local logs on a compromised host are not evidence you can rely on, so forward them to a central collector. The ESXi Logs Detection Guide covers syslog forwarding and parsing in depth; the VMware ESXi Forensics guide covers what to preserve after the fact.

Behaviour sequences worth an alert

1. SSH or ESXi Shell enabled on a host, followed by a root or local account login from an address that is not an approved jump host.
2. Direct host login (Host Client or SSH) on a host that is normally managed only through vCenter.
3. VM listing command followed within minutes by bulk power off, kill by World ID or snapshot deletion. See the MITRE ATT&CK T1489 Service Stop guide.
4. File transfer of an unknown ELF binary to a datastore or /tmp, followed by VM listing. ATT&CK records the related shell activity under T1675 ESXi Administration Command and T1059.012 Hypervisor CLI.
5. vCenter inventory or API reads from a service account at an unusual time or from a new source, especially a backup or monitoring account that normally reads on a fixed schedule.

Mitigations and controls

ATT&CK v20 maps no mitigations to T1673, which is typical for discovery techniques that use legitimate administration functions. The controls below are NHI Mgmt Group recommendations that limit who can reach the hypervisor and make the step visible. CrowdStrike's research supports several of them: manage hosts through vCenter rather than the Host Client or Direct Console, use an audited jump server with MFA where direct access is needed, keep vCenter off the internet, and back up VM disks and snapshots frequently to an offsite location.

For the wider architecture see the Hypervisor and Virtualisation Security Guide.

Where identity fits

Most VM enumeration in the cases above was done with valid credentials: root on ESXi, vCenter administrators, or the vpxuser account vCenter uses to manage hosts, which Mandiant notes can be recovered by an attacker with root on the vCenter server. Backup platforms, monitoring tools and infrastructure as code pipelines also hold vCenter service accounts with inventory rights across every host. Inventory these machine identities, scope them to the privileges they need, store their secrets in a vault, rotate them after any vCenter compromise, and alert when they log in interactively or from a new source. The T1087 and T1069 Account and Permission Group Discovery Defensive Guide covers the related account discovery that usually precedes hypervisor access.

Responding when VM enumeration is detected

1. Treat it as pre-impact: unexpected VM listing on ESXi should be handled as a possible ransomware precursor, not a low severity discovery alert. Follow the ESXi Ransomware Playbook.
2. Cut management access: disable SSH and the ESXi Shell, end active sessions, and rotate root, vCenter administrator and service account credentials from a clean workstation.
3. Do not power hosts off: CrowdStrike advises not shutting down ESXi hosts during an attack, because powered on VMs keep their disk files locked and shutdown releases the locks.
4. Preserve logs: collect forwarded shell.log, auth.log and hostd.log and vCenter events before the attacker can clear local copies.
5. Scope: check every host the same credentials could reach, and the vCenter server itself.

Common failure patterns

• ESXi logs stay on the host: without syslog forwarding the evidence of enumeration lives only where the attacker has root.
• SSH left enabled after maintenance: a permanently enabled shell removes the earliest and cleanest signal, the service start event.
• Hypervisor admin through the corporate domain: when a domain group grants vSphere admin, every domain compromise becomes a hypervisor compromise.
• Alerts route to a queue nobody watches at night: the eCrime pattern runs list, stop and encrypt in one script, often outside working hours.
• Backup service accounts with full vCenter admin: broad inventory rights for automation make attacker enumeration look like routine backup activity.

How to test your coverage

1. Lab host first: on a non-production ESXi host, enable the shell, log in from an approved and an unapproved address, run a VM listing command and disable the shell again.
2. Confirm telemetry: check that the service start, auth.log login and shell.log command reached the SIEM, with the time taken.
3. Confirm the analytic and escalation: the unapproved source should alert; the sequence with a power off on a test VM should page the on-call responder.
4. Repeat for other hypervisors: run Get-VM on a Hyper-V test host and virsh list on a KVM host from an unexpected account.
5. Roll back: restore the test VM state, disable services, remove any test accounts and record results against DET0199.

Metrics

• Percentage of ESXi hosts forwarding shell.log, auth.log and hostd.log centrally.
• Percentage of ESXi hosts in lockdown mode with SSH and ESXi Shell disabled.
• Number of ESXi shell enable events per month, each matched to a change ticket.
• Median time from a test VM listing on ESXi to an alert reaching a responder.
• Number of service accounts with vCenter administrator rights, tracked down over time.

Framework mapping

Practitioner checklist

• Forward ESXi shell.log, auth.log, hostd.log and vpxa.log to a central collector.
• Alert on every SSH or ESXi Shell enable and on direct host logins where vCenter is the normal path.
• Alert on VM listing commands from interactive shells, and page on listing followed by bulk power off.
• Enable lockdown mode and keep SSH and the shell disabled by default.
• Keep vCenter off the internet and require MFA for virtualisation admins.
• Separate hypervisor admin identities from the corporate domain admin path.
• Scope and vault vCenter service account credentials for backup and monitoring tools.
• Keep immutable or offline backups of VM disks and test restores.
• Tell responders not to power off ESXi hosts during an active encryption event.

Standards and references

• MITRE ATT&CK: T1673 Virtual Machine Discovery
• MITRE ATT&CK: T1059.012 Hypervisor CLI
• Broadcom: Location of ESXi log files
• CrowdStrike: Hypervisor Jackpotting, eCrime Actors Increase Targeting of ESXi Servers
• Trend Micro: New Play Ransomware Linux Variant Targets ESXi
• Google Cloud (Mandiant): VMware ESXi Zero-Day Used by Chinese Espionage Actor

Related NHI Mgmt Group resources: ESXi Ransomware Playbook · ESXi Logs Detection Guide · MITRE ATT&CK T1486 Data Encrypted for Impact · VMware ESXi Hardening Guide · Hypervisor and Virtualisation Security Guide · MITRE ATT&CK T1680 Local Storage Discovery Guide