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

AN1125: Analytic 1125

Detects unusual outbound DNS traffic from ESXi hosts, often from shell scripts, custom daemons, or malicious VIBs interacting with external DNS infrastructure outside the management plane.

EnterpriseAN1125AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

AN1125 focuses on unusual outbound DNS traffic from ESXi hosts. For leaders, the importance is not “DNS” by itself; it is that virtualization hosts are high-value infrastructure and normally have a narrow management role. Unexpected external DNS activity from an ESXi host can indicate scripts, custom services, or malicious VIBs communicating outside the expected management plane, which can affect incident containment decisions and operational resilience for virtualized workloads.

Executive priority

Treat this as a control-validation item for critical virtualization infrastructure. Security leaders should ask whether ESXi hosts are expected to make outbound DNS requests, which resolvers they are allowed to use, and whether SOC teams can distinguish normal management-plane DNS from unusual external DNS activity. The business value is in reducing blind spots around infrastructure that supports many systems, and in producing audit or incident-response evidence that outbound network behavior from ESXi is monitored and governed.

Technical view

The supplied ATT&CK analytic is scoped to ESXi and describes detection of unusual outbound DNS traffic from ESXi hosts, especially activity associated with shell scripts, custom daemons, or malicious VIBs communicating with external DNS infrastructure outside the management plane. Because no official detection logic is provided, SOC and detection engineering teams should validate environmental baselines: expected ESXi DNS resolvers, expected destinations, normal query volume, permitted management networks, and any approved host-level services that generate DNS. Detection should focus on deviations from those baselines rather than generic DNS volume alone.

Likely telemetry

  • Network DNS logs showing queries sourced from ESXi hosts
  • Firewall, proxy, or network security device logs for outbound DNS from ESXi management interfaces
  • ESXi host inventory and network identity mapping to confirm which IPs are virtualization hosts
  • Allowed DNS resolver configuration for ESXi hosts
  • Change or configuration records for approved ESXi services, scripts, daemons, or VIBs

Detection direction

  • Validate that DNS telemetry can identify ESXi hosts as the source, not only aggregate resolver activity.
  • Baseline expected DNS destinations and resolvers for ESXi management traffic, then alert on direct external DNS or resolver bypass where not approved.
  • Tune for local administrative activity and sanctioned integrations that may legitimately generate DNS from ESXi hosts.
  • Investigate unusual query volume, new external DNS destinations, or DNS activity temporally associated with host configuration changes.
  • Document blind spots where DNS is not logged at the host, resolver, or network egress layer.

Mitigation priorities

  • Define and enforce expected outbound DNS paths for ESXi hosts, preferably through approved resolvers and management networks.
  • Restrict unnecessary outbound network access from ESXi hosts where operationally feasible.
  • Maintain inventory of approved ESXi scripts, daemons, integrations, and VIBs so unusual DNS activity has context.
  • Ensure incident response runbooks include virtualization-host containment and evidence collection considerations.
  • Use this analytic as a validation point for virtualization infrastructure monitoring and compliance evidence.
Analyst notes and limits

No relationship context, ATT&CK tactics, or official detection logic were supplied. The strongest defensive use is therefore environmental validation: confirm whether ESXi DNS behavior is known, logged, and constrained. This analytic is most useful when paired with local asset inventory, network segmentation policy, resolver logs, and change records.

This take is limited to the supplied ATT&CK fields. It does not assert active exploitation, actor attribution, impact, or guaranteed detection. Practical thresholds and allowlists require local ESXi architecture, management-plane design, and DNS logging availability.

Official MITRE ATT&CK definition

Analytic 1125

Detects unusual outbound DNS traffic from ESXi hosts, often from shell scripts, custom daemons, or malicious VIBs interacting with external DNS infrastructure outside the management plane.

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