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

AN0991: Analytic 0991

Detects VMs sending outbound traffic through non-standard services or to unknown destinations. Exfiltration over reverse shells tunneled via VMkernel or custom payloads routed via hostd/vpxa.

EnterpriseAN0991AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This analytic matters because unexpected outbound traffic from ESXi-hosted virtual machines can be a signal that data is leaving the environment through paths that normal server or endpoint monitoring may not fully see. For leaders, the practical issue is not just a single alert: it is whether the organization can observe and investigate VM-to-external network activity, especially when traffic uses non-standard services or unknown destinations.

Executive priority

Prioritize this as a virtualization and network visibility question for environments that run ESXi. Security leaders should ask whether outbound traffic from VMs and ESXi management-related paths is baselined, logged, and reviewable during an incident. This supports business continuity and incident response readiness because gaps at the hypervisor or virtual network layer can delay decisions about containment, data exposure, and recovery scope.

Technical view

The supplied ATT&CK analytic is for ESXi and focuses on VMs sending outbound traffic through non-standard services or to unknown destinations, including possible exfiltration over reverse shells tunneled via VMkernel or custom payloads routed via hostd/vpxa. SOC and detection engineering teams should validate whether they can correlate VM network flows, destination reputation or ownership, service/port anomalies, and ESXi management-plane context. Because no official detection logic is provided, implementation should be based on local baselines for expected VM egress, approved destinations, and normal hostd/vpxa-related activity.

Likely telemetry

  • VM outbound network flow logs or equivalent east-west/north-south traffic records
  • Firewall, proxy, or egress gateway logs showing destination, port, protocol, and action
  • ESXi or virtualization platform logs relevant to VMkernel, hostd, and vpxa activity
  • Asset inventory mapping VMs to owners, applications, expected network destinations, and business criticality
  • DNS logs and destination enrichment for unknown or unusual external endpoints

Detection direction

  • Establish baselines for normal VM outbound destinations, services, ports, and volumes before treating all unusual egress as malicious.
  • Tune detections for outbound traffic using non-standard services or unknown destinations from ESXi-hosted VMs.
  • Correlate network anomalies with ESXi management-plane telemetry where available, especially activity involving VMkernel, hostd, or vpxa as named in the ATT&CK description.
  • Review false positives from legitimate application updates, backup tools, monitoring agents, administrative access, and newly deployed workloads.
  • Identify blind spots where virtual switch traffic, VMkernel interfaces, or direct VM egress bypasses centralized proxy, firewall, or packet/flow monitoring.

Mitigation priorities

  • Inventory ESXi-hosted VMs and define expected outbound destinations and services for critical workloads.
  • Restrict unnecessary outbound access from VMs using network segmentation and controlled egress paths.
  • Ensure ESXi and virtualization management logs are retained and available to SOC and incident response teams.
  • Use change control for new VM egress requirements so detection baselines remain current.
  • Test incident response playbooks for suspicious VM outbound traffic, including containment decisions that avoid unnecessary disruption to critical workloads.
Analyst notes and limits

This take is based only on the supplied ATT&CK analytic fields. The object is a detection analytic, not a technique entry, and no relationships or official detection logic were supplied. The strongest decision value is to validate visibility and control over VM egress in ESXi environments, especially where hypervisor-adjacent telemetry may not be integrated into SOC workflows.

Tactics are not specified, no related ATT&CK objects were supplied, and the official detection field is not provided. Local network architecture, ESXi logging configuration, VM inventory quality, and approved egress patterns are required to convert this into reliable detection logic.

Official MITRE ATT&CK definition

Analytic 0991

Detects VMs sending outbound traffic through non-standard services or to unknown destinations. Exfiltration over reverse shells tunneled via VMkernel or custom payloads routed via hostd/vpxa.

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

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
83237cc4137d7917...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 83237cc4137d…
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 AN0991
    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.