AN0329: Analytic 0329
Detects exploitation targeting ESXi/vCenter by correlating attempts to reach known exploitable endpoints (OpenSLP 427, CIM 5989, Hostd/Vpxa HTTPS 443, ESXi SOAP) with vmkernel/hostd crashes, unexpected hostd/vpxa restarts, or new reverse/outbound connections from ESXi host/vCenter to internal assets.
Analyst context for executives and security teams
This analytic matters because ESXi and vCenter are core virtualization control points: instability or compromise there can affect many business systems at once. The supplied ATT&CK description focuses on correlating suspicious access to known ESXi/vCenter service endpoints with signs of host instability or unexpected outbound activity. For leaders, the decision value is whether the organization can see early warning signs around virtualization infrastructure before an issue becomes a broad outage or incident-response crisis.
Executive priority
Prioritize validation of monitoring around ESXi and vCenter because these systems concentrate operational risk. Security leaders should ask whether network, host, and virtualization-platform logs are retained and reviewed well enough to show attempted access to ESXi services, crashes or unexpected service restarts, and unusual outbound connections from ESXi or vCenter. This also supports audit and resilience evidence: teams should be able to demonstrate who monitors the virtualization layer, what alerts exist, and how incidents involving hypervisor infrastructure are escalated.
Technical view
For SOC, detection engineering, and IR teams, the analytic is a correlation use case for ESXi: attempts to reach OpenSLP 427, CIM 5989, Hostd/Vpxa HTTPS 443, or ESXi SOAP should be evaluated alongside vmkernel or hostd crashes, unexpected hostd/vpxa restarts, and new reverse or outbound connections from ESXi hosts or vCenter to internal assets. Because ATT&CK does not provide an official detection query or tactic mapping here, teams should treat this as a detection design requirement rather than a ready-made rule. Validate that ESXi/vCenter logs, service restart evidence, crash events, and network flow telemetry can be joined by host, time window, and source/destination context.
Likely telemetry
- Network flow or firewall logs showing access attempts to ESXi/vCenter service endpoints, including OpenSLP 427, CIM 5989, Hostd/Vpxa HTTPS 443, and ESXi SOAP
- ESXi vmkernel logs indicating crashes or abnormal host behavior
- hostd logs showing crashes or unexpected restarts
- vpxa service restart or health events
- vCenter or ESXi management-plane logs where available
Detection direction
- Build correlation rather than single-event alerting: endpoint access attempts become more material when followed by vmkernel/hostd crashes, hostd/vpxa restarts, or new outbound connections from ESXi/vCenter.
- Tune for the local management architecture: expected backup, monitoring, administrative, and vCenter-to-host communications may otherwise create false positives.
- Validate visibility at the virtualization layer specifically; standard endpoint telemetry may not cover ESXi hosts in the same way it covers general-purpose servers.
- Confirm time synchronization and log retention across network devices, ESXi hosts, and vCenter so crash/restart activity can be correlated with connection attempts.
- Use asset context to distinguish exposure of management interfaces from ordinary internal management traffic.
Mitigation priorities
- Inventory ESXi and vCenter systems and identify where the referenced services are reachable.
- Restrict access to ESXi/vCenter management services to approved management networks and administrative paths where business operations allow.
- Ensure ESXi/vCenter logging, network flow collection, and service health monitoring are enabled and retained long enough for incident investigation.
- Define an incident escalation path for hypervisor or vCenter crash/restart events that coincide with suspicious network activity.
- Review administrative baselines so defenders know which outbound connections from ESXi hosts or vCenter are expected versus unusual.
Analyst notes and limits
The object is a MITRE ATT&CK detection analytic for ESXi platforms, external ID AN0329, associated with DET0118. The supplied description is specific about correlation elements but does not include an official detection query, tactic mapping, labels, aliases, or relationship context. The most useful implementation work is therefore local validation of telemetry coverage and correlation logic around ESXi/vCenter management services, crashes, restarts, and outbound connections.
This take is based only on the supplied official STIX fields, external reference, and empty relationship context. It does not establish active exploitation, attribution, customer exposure, impact, or guaranteed detection coverage. Local ESXi/vCenter configuration, network segmentation, logging levels, and normal administrative workflows are required to make the analytic operational.
Analytic 0329
Detects exploitation targeting ESXi/vCenter by correlating attempts to reach known exploitable endpoints (OpenSLP 427, CIM 5989, Hostd/Vpxa HTTPS 443, ESXi SOAP) with vmkernel/hostd crashes, unexpected hostd/vpxa restarts, or new reverse/outbound connections from ESXi host/vCenter to internal assets.
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 | 99fabe68ebeb… |
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 AN0329Open 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.