AN1023: Analytic 1023
Outbound encrypted traffic initiated from hypervisor shell or via VM backdoor mechanisms to relays in VPS infrastructure, especially if traversing multiple nodes before reaching Internet destination. Packet captures or firewall logs show non-VM communication paths.
Analyst context for executives and security teams
This analytic matters because it focuses on outbound encrypted communications originating from the ESXi hypervisor layer rather than from guest virtual machines. For executives and security leaders, that is a high-value visibility question: if the virtualization host itself communicates to external VPS relay infrastructure, normal VM-centric monitoring may miss it, and incident scope can quickly shift from a single workload to the platform that supports many systems.
Executive priority
Prioritize validation of network visibility around ESXi management and hypervisor-originated traffic. The business decision is whether current monitoring can distinguish legitimate management-plane communications from unexpected non-VM outbound paths. This is relevant to operational resilience, incident containment planning, audit evidence for critical infrastructure hosting controls, and risk prioritization for environments where ESXi supports business-critical services.
Technical view
For SOC, detection engineering, and IR teams, the supplied analytic describes outbound encrypted traffic initiated from the hypervisor shell or via VM backdoor mechanisms to VPS relay infrastructure, potentially through multiple nodes before reaching an Internet destination. Because no official detection logic or tactic mapping is provided, teams should validate whether firewall, packet capture, and network flow data can identify traffic sourced from ESXi hosts or management interfaces separately from guest VM traffic, and whether external relay-like destinations are visible in logs.
Likely telemetry
- Firewall logs showing source addresses associated with ESXi hosts or management networks
- Packet captures from hypervisor management or uplink segments
- Network flow records distinguishing host-originated traffic from guest VM traffic
- Proxy or egress logs, if ESXi management networks are routed through controlled egress
- Asset inventory mapping ESXi host interfaces, management IPs, and expected outbound destinations
Detection direction
- Baseline expected ESXi host outbound communications and alert on encrypted Internet-bound traffic that does not align with approved management or update paths.
- Ensure detections separate hypervisor-originated traffic from VM-originated traffic; otherwise the behavior may be hidden inside aggregate virtualization network flows.
- Review firewall and packet capture evidence for non-VM communication paths and multi-hop relay patterns to VPS infrastructure, while tuning for legitimate administrative, backup, monitoring, or vendor connectivity.
- Because MITRE provides no official detection implementation, treat this as a coverage validation requirement rather than a ready-to-deploy analytic.
Mitigation priorities
- Restrict ESXi management networks to approved administrative paths and required destinations only.
- Enforce controlled egress for hypervisor and management-plane traffic, with logging retained for investigation.
- Maintain accurate asset inventory for ESXi hosts, management interfaces, and expected communication patterns.
- Prepare IR procedures for cases where suspicious traffic originates from the hypervisor layer, including escalation beyond guest VM triage.
- Use segmentation and firewall policy review to reduce the chance that hypervisor-originated traffic can reach arbitrary Internet relay infrastructure.
Analyst notes and limits
The key decision value is visibility at the virtualization host layer. Many organizations have strong endpoint or VM telemetry but weaker evidence for ESXi host-originated encrypted egress. Detection engineering should begin by proving whether the environment can identify source context, expected destinations, and deviations from approved hypervisor communications.
The ATT&CK object supplies a description, ESXi platform scope, and external reference only. No tactics, relationships, official detection logic, mitigations, attribution, or exploitation status are provided. Local architecture, routing, firewall policy, and logging configuration are required to determine actual exposure or detection coverage.
Analytic 1023
Outbound encrypted traffic initiated from hypervisor shell or via VM backdoor mechanisms to relays in VPS infrastructure, especially if traversing multiple nodes before reaching Internet destination. Packet captures or firewall logs show non-VM communication paths.
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 | 0ab9fc0e6f4b… |
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 AN1023Open 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.