What T1673 virtual machine discovery tells an attacker and where it shows up
T1673 Virtual machine discovery tells an adversary whether the host it has landed on is a virtual machine, which hypervisor runs it, and what the surrounding environment looks like. Under MITRE ATT&CK tactic TA0007 (Discovery), this is the step where an intruder works out whether it is inside a production system or an analysis sandbox. The answer decides what happens next: an attacker may stop, change behavior to avoid sandbox detection, or move laterally toward hosts that are more valuable. This page targets Enterprise ATT&CK version 20.0, and the technique sits in the Discovery tactic, so the detection mappings below name that version explicitly.
For a SOC lead, the practical question is where this activity appears in your telemetry. On Windows, Linux and macOS, it usually shows up as process creation and command execution events, where a short-lived, low-noise query for hypervisor or virtualization indicators can be the only trace. On ESXi and other virtualization hosts, the same behavior may appear in shell or management logs rather than endpoint logs. Confirm with your endpoint and hypervisor teams which of these sources you actually collect, at what fidelity, and for how long, because a detection that depends on a data source you do not retain will fail silently.
Treat discovery of this kind as an early warning, not a verdict. Before you tune alerts, check whether your own tooling produces the same activity: configuration management agents, vulnerability scanners, asset inventory jobs and backup software often query virtualization details legitimately. Build an allowlist from those known processes and their service accounts, and record the ATT&CK version and the data components your rules rely on, such as Process Creation (DC0032) and Command Execution (DC0064). Then validate the rules in a private cyber range before relying on them, since ATT&CK releases can rename or deprecate techniques and detection logic must keep pace.
Process Creation and Command Execution signals for virtual machine discovery
This table maps each platform in scope (ESXi, Linux, macOS and Windows) to the telemetry that tends to reveal T1673 Virtual Machine Discovery, the open-source collector that gathers it, and what to confirm locally. Read each row as a starting point for a detection backlog: Process Creation and Command Execution are the primary signals, while File Access is a supporting source for corroboration. The main takeaway is that ESXi host logging is the dependency most often missing, so confirm it before writing rules.
| Platform | Primary telemetry (DC0032, DC0064) | Open-source collector | What to confirm locally |
|---|---|---|---|
| ESXi | Shell and command activity on the host, captured as process execution where the host forwards it. File Access (DC0055) to hypervisor configuration and inventory files as supporting evidence. | Syslog forwarding to Wazuh or Security Onion, with Wazuh agents where the host supports them | Whether shell and SSH access are logged on each host, where logs are stored, and whether the forwarder retains command-level detail |
| Linux guests and hypervisor management hosts | Process Creation for utilities that read virtualization hints (for example, hardware or DMI-related queries). Command Execution from shell history or auditd-style records. | Wazuh agent with command monitoring enabled, Velociraptor for on-demand hunts | Whether auditd or equivalent execve auditing is enabled, and whether the agent collects it without excessive volume |
| macOS endpoints | Process Creation for system profiling commands run from terminals or scripts. Command Execution from unified log or shell records. File Access to hardware or virtualization-related system files as supporting evidence. | Wazuh agent for macOS, Velociraptor artifacts for endpoint collection | Which macOS log sources the agent version collects, and whether terminal and script execution is visible to the sensor |
| Windows endpoints | Process Creation (Sysmon or Windows Security process auditing) for WMI, PowerShell and system information utilities. Command Execution from PowerShell script block or command-line records. | Wazuh agent with Sysmon, Security Onion for network and host correlation, Velociraptor for hunts | Whether command-line auditing is enabled, whether script block logging is on, and the Sysmon configuration in use |
| Cross-platform correlation | Process Creation and Command Execution events grouped by host and user across platforms, with File Access used to confirm reads of virtualization indicators. | Wazuh or Security Onion as the central store, with Sigma rules converted to the chosen backend | Which ATT&CK version the rules target (v20 in these pages), and whether mappings were checked against the current STIX bundle |
How to write detection logic for virtual machine discovery
Virtual machine discovery is noisy on its own because many legitimate tools query the hypervisor or guest hardware. The cards below describe how to combine process context, thresholds by host role and sequencing with other Discovery techniques so that an alert means something to the analyst.
Correlate with virtualization process context
Start by building an allow-list of the processes that legitimately query virtualization state on each host class, such as hypervisor management agents on ESXi and guest tools on Linux and Windows virtual machines. Process Creation and Command Execution events that invoke virtualization-aware utilities from an unexpected parent, user or working directory are the strongest signal. Record the parent chain and the account context, because a discovery command launched from a web service or a scripting host deserves more weight than the same command run from an administrator's shell. Confirm the baseline with the platform team before enabling the rule.
Set thresholds per host role
A domain controller, a build server and a jump host should not share one count threshold. For each role, measure how many virtualization-related process executions occur in a normal window, then alert on deviations rather than on any single execution. Short bursts across many hosts in a few minutes are more suspicious than repeated runs on one administrative workstation. Document the thresholds per role in version control so that changes are reviewed, and revisit them after each change to the host fleet or the ATT&CK version your mappings target.
Sequence with other Discovery techniques
Virtual machine discovery rarely appears alone. Adversaries often pair it with process discovery (T1057), system information discovery (T1082) and system owner or user discovery (T1033) in a short window on the same host. Build a correlation rule that raises priority when two or more Discovery techniques from the same source occur within a short, role-tuned window. Pairing with Network Service Discovery (T1046) or Remote System Discovery (T1018) helps show lateral intent. Treat single-technique hits as triage items and sequenced hits as incidents.
False positives from configuration management
Configuration management, golden image and patching tools routinely query virtualization details to decide which packages or drivers to install. Their runs are scheduled, repeatable and launched from known service accounts, which makes them easy to suppress by parent process, account and time window. Keep suppressions narrow. A suppression that matches only the tool name will also hide an attacker who copies that name, so bind each exclusion to the signing path, the service account and the expected hosts.
False positives from inventory and monitoring agents
Asset inventory, vulnerability scanners and monitoring agents often read hypervisor and guest metadata on a fixed schedule across the whole estate. These produce high volume and broad host coverage, so they can drown a rule that alerts on count alone. Ask each vendor which processes, accounts and schedules their agents use, and confirm them in a lab before tuning. Hardware support and driver utilities used by server vendors are a second source of noise and should be inventoried in the same way.
Validate tuning in a cyber range
Before production use, replay known benign administrative and tooling runs in a private cyber range that mirrors your host roles, then measure how often each rule fires. Add simulated discovery sequences of your own design, label them clearly as test activity, and confirm the alerts reach the right queue with the right context. Keep the results with the rule version so auditors can see how tuning decisions were made. Ask your partner or internal team to confirm the telemetry sources available on each platform before scoping the exercise.
How to validate the virtual machine discovery detection
This sequence proves that the T1673 detection fires on the platforms in scope, at the expected times, with the expected evidence. It produces a repeatable record of rule versions, alert latency and gaps that the team can re-run after every tuning change.
Define the emulation scope per platform
The detection owner and the cyber range lead agree which platforms are in scope for T1673 Virtual Machine Discovery, such as ESXi hosts, Linux, macOS and Windows endpoints, and any hypervisor management hosts the organization runs. For each platform they name the test hosts, the operating system versions and the telemetry sources that should cover them. The step is done when the scope is written down in a shared test plan that the range team can reference without follow-up questions.
Write the scenario and expected events
For each platform, the team writes a planned emulation scenario in plain words, describing the category of behavior being exercised and the environment conditions it runs under, without recording any commands. They then list the events each data source should produce, such as Process Creation and Command Execution records from the endpoint agent, and note which fields the analyst expects to see. The output is an expected-events table that a reviewer can check against the logs after the run.
Fix the rule versions under test
Before the run, the detection engineer records the exact rule identifiers, rule versions and ATT&CK version the test targets, so results cannot be confused with a later change. Because ATT&CK releases can rename or deprecate techniques, the record should name the ATT&CK version used for the mapping, and the detection strategy and analytic identifiers it relies on. The step is complete when a frozen copy of each rule is stored alongside the test plan.
Set pass criteria before execution
The team agrees pass criteria in advance: the expected event appears in the log pipeline, the rule fires for each in-scope platform, the alert carries the host and user context the analyst needs, and alert latency stays within a threshold the detection owner sets for the environment. The threshold should be confirmed with the SOC and the platform owners, since no fixed value is supplied for this page. The output is a signed-off checklist that defines a clear pass or fail for every platform.
Run the emulation and capture evidence
The range team runs the planned scenario on each in-scope host while a second person observes the run and notes the start time. Analysts watch the alert queue and log pipeline without changing rules during the window. The output is a raw record of activity, so that every alert or missing alert can be traced back to a specific host and time.
Record timestamps, hosts, rule IDs and latency
For each expected event, the reviewer records the source timestamp, the time the event reached the log platform, the time the rule fired, the host name, the rule identifier and the rule version. Alert latency is the gap between the event and the alert. Missing events are logged as gaps with a probable cause, such as a telemetry source that was not enabled. The step closes when the results table covers every platform in the scope document, with no empty cells.
Compare results and tune the rule
The team compares the results table with the pass criteria and classifies each platform as passed, partially detected or failed. Where a rule misses a platform or fires late, the detection engineer adjusts the logic or the data collection and records the change as a new version. Any change to the telemetry configuration is also logged. The output is a short findings note that names what changed and why.
Re-run the emulation after tuning
After each tuning change, the same scenario is repeated on the same platforms, using the new rule version recorded in the test plan. The reviewer checks that the earlier gaps are closed and that no previously passing platform has regressed. The step is done when the new results table is stored next to the earlier one, so the detection history can be shown to auditors or internal reviewers.
How SOC analysts triage a virtual machine discovery alert
The first triage question for a T1673 Virtual machine discovery alert is whether the activity belongs to a known management workflow on that host. On an ESXi host, the same discovery-style commands can come from a configuration management agent, a backup or inventory job, or an administrator working from a jump host. Start by confirming the user context of the process, whether the session came through the expected administrative account, and whether that account is on your approved list for hypervisor access. Then check the parent process and its lineage: a scheduled task or known agent spawning the command is a very different picture from an interactive shell, a web-facing service process, or a script launched from a temporary directory. Finally, look at recent change records for the host, including patches, new virtual machines, snapshot activity, and tooling deployments, because a fresh change often explains an unfamiliar inventory pattern.
Escalate when the alert does not match a documented workflow or when several signals point the same way. Typical escalation criteria include discovery activity from an account that has no record of hypervisor administration, a parent process that is a network-facing service or an unexpected interpreter, execution outside maintenance windows, or the same host showing other discovery techniques, such as process or account enumeration, within a short period. Treat activity that is followed by credential access, new administrative sessions, or changes to virtual machine configuration as an incident. Before closing any alert, answer a short set of questions: who ran the activity, from which host and session, what process started it, whether a change or job is recorded for that time, whether the same pattern appears on other hosts, and whether the output was copied or sent off the host. Record the answers in the ticket so the next analyst can reuse the baseline. Your team should confirm which of these fields your Wazuh or Security Onion pipeline actually retains for ESXi and Linux hosts before relying on them.
Preventive controls that limit T1673 exposure
Virtual machine discovery succeeds when an attacker can read hypervisor, guest and management details without being noticed or challenged. The four ATT&CK mitigations below reduce what those reads reveal and make the reads easier to see, so they complement detection rather than replace it. Confirm each mapping against the ATT&CK version your team targets, because mitigation mappings change between releases.
Audit access to hypervisor data
Audit (M1047) covers configuring and reviewing the logging that records use of platform and management functions. For T1673, the useful question is whether your ESXi hosts, vCenter or other hypervisor management planes record who queried virtual machine inventory, power state, and guest tool details, and whether those records reach your SIEM. Check that logs from hypervisors and management consoles are forwarded, retained, and reviewed, not only stored on the host. Confirm the exact audit settings your platform supports with its vendor documentation.
Harden operating system configuration
Operating System Configuration (M1028) means setting guest and host operating systems so that common virtualization checks return less useful information. On Linux and Windows guests, review which packages, kernel modules, device identifiers and virtualization-related tools are present when they are not needed. Remove or restrict tools that expose hypervisor identity by default. Test each change in a staging image first, because some hardware drivers and monitoring agents depend on the same data that discovery scripts read.
Limit accounts that can query the platform
User Account Management (M1018) restricts who holds accounts that can authenticate to hypervisor managers, cloud consoles and guest systems. T1673 often runs under an account that already has a foothold, so reducing standing privileges shrinks the population that can perform inventory reads at all. Review read-only roles on vCenter and similar tools, remove unused service accounts, and require named accounts for administrative sessions. Track who has these roles in a register that your access review process checks on a schedule.
Disable unneeded management features
Disable or Remove Feature or Program (M1042) reduces the number of services that answer discovery queries. Hypervisor management interfaces, guest integration services, remote APIs and diagnostic utilities each give an attacker another way to read virtual machine metadata. Inventory which of these are enabled on each host and guest, disable those with no operational owner, and document the exceptions. Ask your platform vendor which features can be turned off safely and which are required for backup or monitoring.
Response steps when a virtual machine discovery detection fires
The first decision when a T1673 Virtual machine discovery alert fires is whether the activity came from a legitimate administrative or monitoring workflow or from an unexpected identity or host. Start by confirming the account, source host and parent process in the Process Creation or Command Execution events that raised the alert, then check whether the same identity queried the hypervisor management plane, such as vCenter or the ESXi host itself, during a change window. Record the answer before touching the host, because an approved inventory or backup tool can produce the same signal as a hostile enumeration step. Treat an unknown identity on a jump host or workstation that reaches the virtualization management network as a confirmed incident until proven otherwise.
Containment in a virtualized estate is a trade-off, since isolating the wrong guest can disrupt production while leaving the attacker's path open. Prefer narrowing the source first: restrict the account's access to the management network, revoke or rotate its session and credentials, and block the originating host at the network layer. Isolate the originating guest only when triage points to it, and confirm with the application owner which services depend on it. Keep the hypervisor itself out of scope for shutdowns unless a hypervisor compromise is established, and confirm your isolation runbook with the platform team before the first exercise, since the correct sequence depends on your own vSphere or hypervisor layout.
Evidence collection should begin before any remediation changes state. Use Velociraptor or a similar agent to collect the process tree, command history, recent logons, the list of scheduled tasks and the relevant log files from the source host, and hash the collected artifacts with chain-of-custody notes. On the Wazuh or Security Onion side, export the alert, the surrounding events and the raw telemetry for the time window, and preserve the hypervisor audit and authentication logs for the same period. Ask your incident response lead to confirm retention settings for these sources, since short retention on the management plane can erase the evidence you need within days.
Rehearsing virtual machine discovery detection in a private cyber range
This track builds a range with a small ESXi host cluster, a management network separated from guest networks, and a log forwarder that ships host and vCenter events to the SIEM. The goal is to confirm that reconnaissance of the hypervisor layer, such as enumerating which virtual machines are running and on which hosts, produces records that a detection engineer can actually query. Injects are scripted as observed behavior: an unexpected administrative session opens against a host, a burst of inventory queries comes from a service account that normally only reads configuration, and a session appears from a jump host outside the approved change window.
- Topology: Two or three illustrative ESXi hosts, one vCenter instance, a syslog collector and the Wazuh or Security Onion sensor reading those logs.
- Injects: Out-of-hours management sessions, inventory-style queries from a non-administrative account and repeated reads of virtual machine metadata.
- Good detection: The alert fires on the unusual actor and volume, not only on a keyword, and the record includes source address, account and target host.
- Good response: The analyst confirms the account owner, isolates the session at the management layer and checks whether any change followed the query.
- Metrics to record: Time from inject to first event, time from first event to alert, fraction of injects with complete host and account fields, and whether the log source stayed healthy throughout.
Check with your hypervisor vendor which audit events are emitted by default and whether your retention meets your own policy.
This track places a mixed set of Linux and Windows guest virtual machines on an isolated range network, each running the Wazuh agent or equivalent endpoint telemetry. The purpose is to check that process creation and command execution records from inside guests carry enough context to tell routine inventory tasks from suspicious ones. Injects describe what a participant does on a guest, such as checking which hypervisor-related services or guest tools are present, and the detection team must decide whether the behavior is administrative or hostile without the range operator revealing the answer.
- Topology: Three to five illustrative guests across both operating systems, a central manager, and a file integrity or audit component enabled on the hypervisor-related paths.
- Injects: Process activity that looks up virtualization indicators, reads of hardware or hypervisor-related configuration, and a scheduled task that repeats the same checks on several guests.
- Good detection: Process creation and command execution are correlated by parent process and user, and the rule is tuned so that approved management tooling is suppressed by a documented allow list.
- Good response: The analyst pivots from the guest to the host that owns it, reviews the parent chain and decides whether to contain the guest or close the alert with a recorded reason.
- Metrics to record: Alerts per inject, false positives per run, percentage of alerts with a complete parent chain, and mean time to a documented decision.
Confirm the exact telemetry each agent version provides on your target operating system builds before you score the run.
This track is for the analysts who receive the alerts. It uses the same range as the other two tracks but measures the human workflow: triage, enrichment, escalation and closure. Analysts work from the alert queue only, with no hints from the range operator, and their notes are scored against a written playbook. The track also tests whether the case record gives an auditor enough evidence to reconstruct what happened and why the team acted as it did.
- Topology: The production-like SIEM dashboard, a ticketing or case system, and read-only access to inventory and change records.
- Injects: A sequence of three to five related events spread over the exercise window, some benign and some hostile, so that analysts must decide which to escalate.
- Good detection: Analysts link related events into one case rather than handling each in isolation, and they document the hypothesis they tested.
- Good response: Containment steps are proportionate, approvals are recorded, and the case closes with a root cause and a list of rule changes.
- Metrics to record: Time to acknowledge, time to triage decision, number of cases correctly linked, escalation accuracy and completeness of closure notes.
Ask your SOC lead to agree the scoring rubric before the run so results are comparable across rehearsals.
Questions detection engineers ask about T1673
How do we keep alert volume manageable when detecting VM discovery on ESXi?
Start with a narrow, high-context rule and widen it only after a baseline. Hypervisor management hosts, backup servers and monitoring agents routinely query virtual machine inventory, so an unfiltered rule on inventory commands will fire constantly. Build an allowlist of known service accounts, source hosts and maintenance windows, and record each exception with an owner and a review date. Route the remaining hits to triage with enough context (account, source host, parent process, time) to decide quickly. Tune against at least several weeks of normal administrative activity in your own environment before you treat the rule as paging-grade.
Do Sigma rules cover VM discovery on all four platforms?
Not completely, and you should confirm coverage per platform rather than assume it. Sigma is a generic rule format that is converted into backend queries, so coverage depends on which log sources your SIEM or Wazuh deployment ingests and on whether community rules exist for each platform. Process creation and command execution telemetry on Linux and macOS is usually the easiest to map. Windows coverage depends on process auditing being enabled. ESXi often needs shell, syslog or hypervisor audit forwarding configured before any rule can fire. Treat the Sigma rule set as a starting point, then test each platform in your range and document gaps.
How often should we retest T1673 detections after an ATT&CK version change?
Retest whenever you move to a new ATT&CK version that touches the technique, its sub-techniques or the data components your detections depend on. MITRE publishes releases on a regular schedule and can rename, deprecate or revoke techniques, so a mapping that was correct under one version may point to outdated content under the next. Record the ATT&CK version each detection targets, diff the technique page and its detection strategies between versions, and rerun your range scenarios for any changed content. Ask your provider to define in writing what a retest covers and how it is reported.
How should we map T1673 to sub-techniques and related Discovery techniques?
Map each detection to the most specific technique or sub-technique it actually observes, then record broader coverage separately. A single command or API call can relate to more than one ATT&CK entry, so avoid claiming coverage for a sub-technique just because the parent technique rule fires. Keep a coverage matrix that lists the detection, the ATT&CK version, the data components used, the platforms tested and the last validation date. Review adjacent Discovery techniques in the same matrix so that overlapping rules are not counted twice when you report gaps.
How do we log hypervisor activity well enough to see VM discovery?
You need audit records from the hypervisor management layer, not only from guest operating systems. Forward ESXi host logs and vCenter audit events to your central platform, confirm that shell access and management API sessions are logged, and check the retention period against your investigation needs. Guest VMs contribute process telemetry, but discovery run from a compromised management path may never touch a guest at all. Test the pipeline end to end in your cyber range by generating controlled inventory queries and confirming they arrive, are parsed and are searchable within your target time.
Can our own team run T1673 detection testing without an outside provider?
Often yes, if you have someone who can operate the SIEM, read hypervisor and endpoint logs and run controlled tests in an isolated environment. The work splits into building rules, validating them against scripted activity, tuning false positives and maintaining the rules as ATT&CK changes. Teams usually struggle most with the isolated test environment and with keeping evidence current. A fixed-scope engagement can cover the range build, rule set and rehearsal, and a retainer can cover ongoing retesting. Agree the deliverables and acceptance criteria in writing before any work starts.
Which mitigations should we pair with T1673 detection?
Pair detection with hardening that reduces who can discover inventory in the first place. ATT&CK maps User Account Management (M1018) and Audit (M1047) to Discovery techniques, and Operating System Configuration (M1028) and Network Segmentation (M1030) also apply to many of them. Restrict hypervisor management access to dedicated administration networks, limit which accounts can read inventory through vCenter roles, and keep audit logging enabled on every platform. Confirm the exact applicability of each mitigation to T1673 against the current ATT&CK technique page for your version before you cite it in an audit file.
How DeployOpen builds T1673 detections and cyber range exercises
DeployOpen works on T1673 Virtual machine discovery as a written, fixed-scope engagement inside your own environment. The work covers the detection logic, the telemetry it depends on, and a cyber range exercise that proves the detection fires before it is trusted in production.
How we scope
- Confirm which hypervisors, Linux, macOS and Windows hosts are in scope for T1673 detection.
- Inventory where Process Creation and Command Execution telemetry already exists and where it is missing.
- Agree the ATT&CK version the detection mappings will target before any rule is written.
How we build
- Write detection logic in open-source formats, such as Sigma rules, and map it to the relevant data components.
- Configure collection in your existing Wazuh, Security Onion or other SIEM stack, using your data sources.
- Test false positive behavior against your own administrative tooling, backup agents and management scripts.
How we hand over
- Deliver rule documentation, validation results, and response steps written for your SOC analysts.
- Run a cyber range rehearsal in a private environment and record which telemetry produced each alert.
- Walk your security and platform teams through the runbook and the known gaps before sign-off.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Re-validate the T1673 detection when ATT&CK releases rename, deprecate or revoke related mappings.
- Confirm with your team which changes to hypervisor, endpoint or logging configuration need re-testing.
