AN0762: Analytic 0762
VMware management daemons or guest processes initiating encrypted connections outside expected vCenter, update servers, or internal comms. Defender identifies hostd or vpxa initiating outbound TLS flows with uncommon destinations.
Analyst context for executives and security teams
This analytic is about spotting unusual encrypted outbound connections from VMware ESXi management components, specifically hostd or vpxa, to destinations that are not expected vCenter, update, or internal communication endpoints. For leaders, the value is not just detecting “network traffic”; it is validating whether critical virtualization infrastructure can be monitored for unexpected external communication that could affect incident containment, audit confidence, and operational resilience.
Executive priority
ESXi hosts often support business-critical workloads, so unexpected TLS communication from management daemons should be treated as a high-value visibility and control question. Security leaders should ask whether ESXi management traffic baselines exist, whether allowed destinations are documented, and whether the SOC can distinguish normal vCenter/update communications from uncommon outbound destinations. This supports incident decision-making, compliance evidence for infrastructure monitoring, and prioritization of network egress controls around virtualization management planes.
Technical view
The supplied ATT&CK object identifies an ESXi-focused detection analytic: VMware management daemons or guest processes initiating encrypted connections outside expected vCenter, update servers, or internal communications. SOC and detection teams should validate whether they can observe outbound TLS flows from ESXi hosts and attribute them, where possible, to hostd or vpxa. Because no official detection logic is provided and no tactic or relationship context is supplied, implementation should focus on environment-specific baselining of legitimate vCenter, update, and internal destinations, then alerting on uncommon external TLS destinations from ESXi management components.
Likely telemetry
- Network flow logs for ESXi hosts showing outbound TLS connections
- Firewall, proxy, or egress gateway logs for ESXi management networks
- DNS logs associated with ESXi host outbound destinations
- vCenter or ESXi management logs that may help associate activity with hostd or vpxa
- Asset inventory and network segmentation records identifying ESXi hosts, vCenter servers, update servers, and approved internal communication paths
Detection direction
- Build and maintain an allowlist or baseline of expected vCenter, update server, and internal communication destinations for ESXi hosts.
- Validate that outbound TLS from ESXi management networks is logged with enough detail to identify source host, destination, port, time, and frequency.
- Tune detections for hostd or vpxa initiating TLS flows to uncommon destinations, while accounting for legitimate maintenance, patching, backup, monitoring, or vendor support workflows.
- Review blind spots where ESXi hosts bypass proxies, firewalls, DNS logging, or centralized network monitoring.
- Because the official detection field is not provided, test candidate analytics against local traffic baselines before using them for high-severity alerting.
Mitigation priorities
- Document approved ESXi management communication paths, including vCenter, update infrastructure, and required internal services.
- Restrict ESXi management-plane egress to approved destinations where operationally feasible.
- Ensure ESXi management networks are segmented and monitored separately from general workload traffic.
- Maintain accurate asset inventory for ESXi hosts and management services so detections can target the correct sources.
- Use incident response runbooks that define how to triage unusual ESXi outbound TLS without disrupting critical virtualized workloads unnecessarily.
Analyst notes and limits
This is best treated as a detection engineering and control-validation item for virtualization management infrastructure. Its practical value depends on local baselines: an uncommon destination in one environment may be normal in another due to patching, monitoring, backup, or support tooling. The absence of relationship context means this take should not be mapped to a specific ATT&CK technique, campaign, or adversary behavior beyond the supplied analytic description.
The official object provides a concise description but no official detection logic, no tactics, and no relationship context. It supports ESXi as the platform and mentions hostd, vpxa, outbound TLS, and uncommon destinations, but it does not establish exploitation, attribution, impact, or guaranteed detection coverage. Local ESXi architecture, logging coverage, and approved destination lists are required to operationalize it.
Analytic 0762
VMware management daemons or guest processes initiating encrypted connections outside expected vCenter, update servers, or internal comms. Defender identifies hostd or vpxa initiating outbound TLS flows with uncommon destinations.
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 | e667ed312732… |
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 AN0762Open 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.