Live Active security incident? Get immediate response
MITRE ATT&CK® Detection Strategy

DET0321: Detection Strategy for Hidden Virtual Instance Execution

This detection strategy matters because hidden virtual instance execution can let an intruder run activity in a guest environment that normal endpoint moni...

EnterpriseDET0321Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This detection strategy matters because hidden virtual instance execution can let an intruder run activity in a guest environment that normal endpoint monitoring on the host may not see. For leaders, the practical issue is coverage assurance: do security tools, logging, and response procedures account for malicious work being shifted into virtual machines or similar isolated environments?

Executive priority

Prioritize this as a visibility and resilience question rather than a single-tool alert. Because the related ATT&CK technique applies to ESXi, Linux, macOS, and Windows, executives should ask whether SOC and incident response teams can identify suspicious virtualization use across server, workstation, and virtualization infrastructure, and whether audit evidence can show that monitoring extends beyond standard host process logs.

Technical view

DET0321 has no official ATT&CK detection text or platform list supplied, but it is linked to T1564.006 Run Virtual Instance under stealth. SOC and detection teams should validate whether they can observe virtualization software execution, creation or use of guest images, virtual networking changes, hypervisor activity, and gaps where endpoint controls do not inspect inside guest instances. IR teams should include checks for hidden or unauthorized virtual instances when investigating stealthy execution or missing host-level artifacts.

Likely telemetry

  • Endpoint process execution and command-line events related to virtualization tools
  • File system evidence of virtual disk images, VM configuration files, snapshots, or newly staged guest environments
  • Hypervisor or virtualization platform logs, especially for ESXi where available
  • Network telemetry showing virtual adapters, bridged/NAT virtual networking, or unexpected guest-originated traffic
  • Asset inventory and software inventory showing installed or portable virtualization technology

Detection direction

  • Validate whether detections cover both authorized and unauthorized virtualization use; tune with asset role, admin ownership, and approved software baselines to reduce false positives.
  • Look for mismatches between expected host activity and network behavior that may indicate execution shifted into a guest instance.
  • Review blind spots where EDR observes the host but not activity inside the virtual instance.
  • Correlate endpoint, asset inventory, hypervisor, and network evidence rather than relying on a single log source.
  • Because the ATT&CK object provides no official detection logic, treat DET0321 as a coverage-validation prompt tied to T1564.006, not as a ready-made analytic.

Mitigation priorities

  • Maintain an approved virtualization software and hypervisor inventory across endpoints, servers, and ESXi environments.
  • Restrict installation and execution of unauthorized virtualization tools using standard software control and administrative privilege governance.
  • Ensure logging is enabled for virtualization platforms and that SOC teams can access it during investigations.
  • Harden and monitor virtual networking configurations that could allow guest environments to bypass expected inspection points.
  • Update incident response playbooks to include collection of VM artifacts, virtual disk images, hypervisor logs, and guest-network indicators where legally and operationally appropriate.
Analyst notes and limits

The most useful local validation is a coverage exercise: identify where virtual instances are allowed, who administers them, what telemetry is collected from the host and hypervisor layers, and whether the SOC can distinguish legitimate lab, development, or administrative use from suspicious hidden execution.

The supplied ATT&CK detection strategy has no official description, detection text, tactics, or platforms. Platform and tactic context comes only from the relationship to T1564.006 Run Virtual Instance. Local environment evidence is required before making conclusions about exposure, control effectiveness, or detection coverage.

Official MITRE ATT&CK definition

Detection Strategy for Hidden Virtual Instance Execution

No official description is available in the imported ATT&CK source object.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1564.006 Run Virtual Instance Sub-technique This object detects Run Virtual Instance.
Relationship explorer

All related ATT&CK context

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
4b6d5c59123c6896...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 4b6d5c59123c…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack DET0321
    Open source URL
Source and licensing

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.