T1673: Virtual Machine Discovery
An adversary may attempt to enumerate running virtual machines (VMs) after gaining access to a host or hypervisor. For example, adversaries may enumerate a list of VMs on an ESXi hypervisor using a Hypervisor CLI such as `esxcli` or `vim-cmd` (e.g. `esxcli vm process list or vim-cmd vmsvc/getallvms`).[1][2] Adversaries may also directly leverage a graphical user interface, such as VMware vCenter, in order to view virtual machines on a host.
Adversaries may use the information from Virtual Machine Discovery during discovery to shape follow-on behaviors. Subsequently discovered VMs may be leveraged for follow-on activities such as Service Stop or Data Encrypted for Impact.[1]
Analyst context for executives and security teams
Virtual Machine Discovery matters because it is often the point where access to one host or hypervisor becomes awareness of the organization’s virtualized estate. On ESXi, Linux, macOS, and Windows environments, an adversary who can list running VMs can identify high-value systems, plan disruption, or select targets for later actions such as service stoppage or encryption. For leaders, this is a visibility and resilience question: can the organization prove who enumerated virtual machines, from where, and whether that activity was expected?
Executive priority
Prioritize this technique where virtualization supports critical business services, recovery infrastructure, regulated workloads, or operational continuity. The key management question is whether hypervisor and vCenter-style administrative activity is logged, reviewed, and restricted tightly enough to distinguish normal administration from unauthorized discovery. This also supports audit and incident response readiness because VM enumeration can be an early indicator of preparation for broader impact activity.
Technical view
ATT&CK defines this as discovery of running virtual machines after access to a host or hypervisor, including use of hypervisor command-line tools such as esxcli or vim-cmd and graphical interfaces such as VMware vCenter. SOC and IR teams should validate telemetry for ESXi, Linux, macOS, and Windows hosts where VM administration occurs, with special attention to hypervisor CLI execution, management-plane logins, VM inventory queries, and administrative sessions. Relationship context shows ATT&CK maps this technique to DET0199, UNC3886, and multiple software entries including Cheerscrypt, VIRTUALPITA, Qilin, and PureCrypter; use that context for threat-informed detection testing without assuming local exposure or active compromise.
Likely telemetry
- Hypervisor command execution logs, especially ESXi administrative command activity
- vCenter or virtualization management GUI authentication and session logs
- VM inventory query events and administrative API activity where available
- Host process execution logs on ESXi, Linux, macOS, and Windows systems involved in virtualization management
- Privileged account authentication, source IP, and session context for virtualization administrators
Detection direction
- Review DET0199, the related ATT&CK detection strategy, and map its assumptions against locally available telemetry.
- Baseline legitimate VM inventory activity by virtualization administrators, automation accounts, backup platforms, monitoring tools, and configuration management systems.
- Alert or hunt for VM enumeration commands or management-plane inventory views from unusual accounts, hosts, times, or network locations.
- Correlate VM discovery with follow-on behaviors referenced by ATT&CK, especially Service Stop and Data Encrypted for Impact, while avoiding over-reliance on single command strings.
- Account for false positives from routine administration, capacity planning, backup validation, monitoring, and incident response activity.
Mitigation priorities
- Restrict virtualization management access to approved administrators, hardened management paths, and dedicated administrative workflows.
- Enforce strong authentication and least privilege for hypervisor and vCenter-style management interfaces.
- Centralize and retain logs for hypervisor CLI, management GUI, authentication, and VM inventory activity.
- Separate routine automation accounts from human administrator accounts so discovery behavior can be attributed and reviewed.
- Validate incident response playbooks for suspected hypervisor compromise, including rapid scoping of VM enumeration and potential follow-on impact actions.
Analyst notes and limits
The ATT&CK object has no official detection text, so this take focuses on telemetry and validation derived from the official description, platforms, tactics, and relationship context. The relationship to ransomware and backdoor software makes the technique relevant to resilience planning, but local risk depends on whether the organization operates the supported platforms and exposes virtualization management activity to monitoring.
This summary uses only the supplied ATT&CK fields, external references, and relationships. It does not establish that any named group or software is active in a specific environment, nor does it prove detection coverage. Local architecture, logging configuration, identity model, administrative baselines, and retention determine practical detectability.
Virtual Machine Discovery
An adversary may attempt to enumerate running virtual machines (VMs) after gaining access to a host or hypervisor. For example, adversaries may enumerate a list of VMs on an ESXi hypervisor using a Hypervisor CLI such as `esxcli` or `vim-cmd` (e.g. `esxcli vm process list or vim-cmd vmsvc/getallvms`).[1][2] Adversaries may also directly leverage a graphical user interface, such as VMware vCenter, in order to view virtual machines on a host.
Adversaries may use the information from Virtual Machine Discovery during discovery to shape follow-on behaviors. Subsequently discovered VMs may be leveraged for follow-on activities such as Service Stop or Data Encrypted for Impact.[1]
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]
S9019: PureCrypter
PureCrypter is a fully-featured malware loader, developed by a threat actor called “PureCoder," that has been in use since at least 2021 to distribute a variety of remote access trojans and information stealers.[1]
S1242: Qilin
Qilin is a ransomware family operated as a ransomware-as-a-service (RaaS) that has been active since at least 2022. It includes variants written in Go and Rust capable of targeting Windows, Linux, and VMware ESXi environments. Qilin shares functionality overlaps with Black Basta, REvil, and BlackCat ransomware. Qilin affiliates have targeted multiple entities worldwide with the majority of victims in the US, France, Canada, and the UK, primarily in the manufacturing, technology, financial services, and healthcare sectors.[1][2][3][4][5]
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]
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]
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 | cafa0edff933… |
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]
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 -
[2]
TrendMicro Play
Cj Arsley Mateo, Darrel Tristan Virtusio, Sarah Pearl Camiling, Andrei Alimboyao, Nathaniel Morales, Jacob Santos, Earl John Bareng. (2024, July 19). Play Ransomware Group’s New Linux Variant Targets ESXi, Shows Ties With Prolific Puma. Retrieved March 26, 2025.
Open source URL -
[3]
mitre-attack T1673Open 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.