AN1486: Analytic 1486
VMware daemons or user processes encapsulating traffic (e.g., guest VMs tunneling via hostd). Defender sees network services inside ESXi creating flows inconsistent with management plane traffic, such as SSH forwarding or DNS-over-HTTPS from management interfaces.
Analyst context for executives and security teams
This analytic matters because it focuses on unusual outbound or encapsulated traffic originating from ESXi management-plane components or user processes. For leaders, the practical concern is that virtualization infrastructure can become a blind spot: traffic that appears to come from trusted ESXi management interfaces may actually reflect tunneling or forwarding behavior inconsistent with normal administration.
Executive priority
Prioritize validation of ESXi network visibility and management-plane governance. If ESXi hosts are critical to business continuity, security teams should be able to prove what management interfaces normally communicate with, detect unexpected SSH forwarding or DNS-over-HTTPS-like flows, and explain how suspicious host-level network behavior would be triaged during an incident. This is relevant to resilience, audit evidence, and incident response readiness because loss of trust in virtualization hosts can affect many dependent workloads.
Technical view
The supplied object is a detection analytic for ESXi. It describes VMware daemons or user processes encapsulating traffic, such as guest VM tunneling via hostd, where defenders observe network services inside ESXi creating flows inconsistent with expected management-plane traffic. SOC and detection teams should baseline ESXi management interface destinations, ports, protocols, process context where available, and expected administrative services, then review deviations such as SSH forwarding patterns or DNS-over-HTTPS-like traffic from management interfaces. No ATT&CK tactic or official detection logic is provided, so implementation must be based on local ESXi architecture and telemetry availability.
Likely telemetry
- ESXi host network flow records from management interfaces
- Firewall, router, or network sensor logs showing ESXi source interfaces, destinations, ports, and protocols
- ESXi management-plane service/process logs where available, including VMware daemon activity
- SSH service logs or administrative access records associated with ESXi management networks
- DNS and HTTPS egress telemetry from ESXi management segments
Detection direction
- Establish a baseline of normal ESXi management-plane communications before alerting on deviations.
- Look for ESXi management interfaces initiating flows inconsistent with approved administration, monitoring, backup, update, or directory services.
- Prioritize investigation of SSH forwarding-like behavior or DNS-over-HTTPS-like egress from management interfaces, as these examples are explicitly described in the analytic.
- Separate expected VMware daemon traffic from user process or anomalous service traffic where telemetry supports process attribution.
- Tune detections to account for legitimate administrative tools and maintenance windows to reduce false positives.
Mitigation priorities
- Document and restrict expected ESXi management-plane destinations and protocols.
- Segment ESXi management interfaces from general workload and internet-facing networks where operationally feasible.
- Apply egress controls and monitoring to ESXi management networks, especially for unexpected SSH, HTTPS, DNS, or tunneling-like traffic.
- Ensure ESXi hosts are included in asset inventory, logging standards, and incident response playbooks.
- Validate that SOC runbooks distinguish legitimate virtualization administration from suspicious encapsulated or forwarded traffic.
Analyst notes and limits
This Glexia take is based only on the supplied MITRE analytic fields. The object provides a platform, ESXi, and a behavioral description involving VMware daemons or user processes creating traffic inconsistent with management-plane expectations. No ATT&CK tactic, relationship context, or official detection logic was supplied, so local baselining and environment-specific validation are essential.
The source object is sparse: no official detection text, no relationships, no tactics, and no external references beyond MITRE ATT&CK are supplied. This summary does not assert active exploitation, attribution, impact, or guaranteed detection coverage.
Analytic 1486
VMware daemons or user processes encapsulating traffic (e.g., guest VMs tunneling via hostd). Defender sees network services inside ESXi creating flows inconsistent with management plane traffic, such as SSH forwarding or DNS-over-HTTPS from management interfaces.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 1954772d923a… |
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 AN1486Open 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.