DET0199: Detection Strategy for Virtual Machine Discovery
DET0199 is a detection strategy placeholder for identifying Virtual Machine Discovery, where an intruder enumerates VMs from a host or hypervisor after acc...
Analyst context for executives and security teams
DET0199 is a detection strategy placeholder for identifying Virtual Machine Discovery, where an intruder enumerates VMs from a host or hypervisor after access. This matters because VM inventory gives an attacker a map of critical workloads, recovery systems, and high-value infrastructure, especially in virtualized estates. The ATT&CK object itself has no official detection text, so its value is mainly as a prompt to validate whether the SOC can see VM enumeration behavior across the related environments: ESXi, Linux, macOS, and Windows.
Executive priority
Treat this as a coverage validation item for resilience and incident readiness in virtualized environments. Leaders should ask whether security teams can prove visibility into administrative VM-discovery activity, especially on hypervisors, and whether that evidence is usable during an incident to determine which workloads may have been scoped or targeted. Because the object lacks official detection guidance, audit and risk discussions should focus on evidence collection, administrative activity monitoring, and response procedures rather than assuming a named detection already exists.
Technical view
SOC and detection teams should map this strategy to the related ATT&CK technique T1673: Virtual Machine Discovery under Discovery. Validate telemetry for host and hypervisor administrative activity that can reveal VM inventory enumeration, including command execution, management interface activity, and authentication context. Detection engineering should distinguish expected administrator or automation inventory activity from unusual enumeration by new users, unusual hosts, abnormal timing, or activity following suspicious access. IR teams should preserve logs that show who queried VM inventory, from where, and which virtualization management surfaces were used.
Likely telemetry
- Hypervisor management logs and administrative command activity
- Host command execution telemetry on ESXi, Linux, macOS, and Windows where available
- Authentication and session logs for virtualization administration interfaces
- Process and shell activity related to system or VM inventory collection
- Change-management or automation records to compare expected inventory jobs against observed activity
Detection direction
- Build or validate detections around VM inventory enumeration behavior tied to T1673 rather than relying on DET0199 content alone, because no official detection text is supplied.
- Baseline legitimate virtualization administration, backup, monitoring, and asset inventory activity to reduce false positives.
- Prioritize high-risk context: enumeration from unusual accounts, unexpected source systems, nonstandard hours, or shortly after suspicious authentication or host access.
- Confirm visibility on hypervisor administration paths as well as guest operating systems; VM discovery may occur through management interfaces that endpoint-only monitoring may miss.
- Ensure alerts preserve enough context for triage: actor account, source host, target management surface, time, and observed enumeration action.
Mitigation priorities
- Restrict and review administrative access to virtualization management interfaces and hypervisors.
- Require strong authentication and least-privilege access for accounts able to list or manage VMs.
- Centralize and retain logs for hypervisor, management interface, and host administrative activity.
- Separate routine inventory automation from interactive administrator activity so detections can compare expected versus abnormal behavior.
- Include VM discovery evidence requirements in incident response playbooks for suspected hypervisor or host compromise.
Analyst notes and limits
The supplied ATT&CK detection strategy has no official description, detection text, tactics, or platforms. The practical guidance above is derived from its stated relationship to T1673 Virtual Machine Discovery and the related technique metadata, including Discovery tactic and ESXi, Linux, macOS, and Windows platforms.
This take does not assert active exploitation, attribution, impact, or existing detection coverage. Local validation is required to determine which virtualization platforms are present, which logs are collected, and what administrative VM enumeration looks like in the environment.
Detection Strategy for Virtual Machine Discovery
No official description is available in the imported ATT&CK source object.
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.
Techniques used
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 | T1673 | Virtual Machine Discovery | This object detects Virtual Machine Discovery. |
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 | 954ed66b357e… |
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]
mitre-attack DET0199Open 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.