AN0112: Analytic 0112
Monitor esxcli and syslog records for DNS resolver changes or repeated queries to unusual external domains by management agents. Detect unauthorized changes to VM or host network settings that redirect DNS lookups.
Analyst context for executives and security teams
This analytic matters because DNS changes on ESXi hosts can quietly alter how virtual infrastructure resolves names, potentially disrupting management workflows or sending lookups to unexpected external domains. For leaders, the value is not just detecting a configuration change; it is confirming that virtualization administration, logging, and change-control evidence are strong enough to distinguish authorized maintenance from suspicious redirection of host or VM network behavior.
Executive priority
Prioritize this where ESXi supports business-critical workloads. Ask whether DNS resolver changes on ESXi hosts are governed by change control, logged centrally, reviewed by the SOC, and recoverable during an incident. This is especially relevant to operational resilience, incident response readiness, audit evidence for privileged infrastructure administration, and risk decisions around virtualization management visibility.
Technical view
SOC and detection teams should validate monitoring of esxcli activity and ESXi syslog records for DNS resolver changes, repeated queries to unusual external domains by management agents, and unauthorized changes to VM or host network settings that redirect DNS lookups. Because no ATT&CK tactic, relationship context, or detailed detection logic is supplied, teams should anchor implementation to local ESXi administration patterns, approved DNS infrastructure, and known maintenance windows.
Likely telemetry
- ESXi syslog records
- esxcli command activity related to DNS resolver or network configuration changes
- Host network configuration change records
- VM network settings change records
- DNS query activity from ESXi management agents
Detection direction
- Baseline approved DNS resolvers and expected external domains for ESXi hosts and management agents.
- Alert or review DNS resolver changes that lack an approved change ticket or occur outside maintenance windows.
- Correlate esxcli-driven network or DNS changes with privileged administrator activity and ESXi syslog evidence.
- Tune for legitimate virtualization maintenance, upgrades, and troubleshooting to reduce false positives.
- Look for repeated queries to unusual external domains from management agents, but define 'unusual' using local environment baselines.
Mitigation priorities
- Ensure ESXi DNS and network configuration changes require authorized administrative access and documented change control.
- Centralize and retain ESXi syslog and relevant management activity logs for investigation and audit support.
- Maintain an approved inventory of ESXi DNS resolver settings and management-agent communication destinations.
- Periodically compare live ESXi host and VM network settings against approved baselines.
- Prepare incident response procedures for validating and reverting unauthorized ESXi DNS or network changes.
Analyst notes and limits
The supplied object is a detection analytic for ESXi focused on monitoring esxcli and syslog records for DNS resolver changes, unusual external DNS queries by management agents, and unauthorized VM or host network-setting changes that redirect DNS lookups. No relationship context is supplied, so this take does not infer associated techniques, actors, campaigns, or impacts.
Official detection logic is not provided, tactics are not specified, and no relationships are supplied. Local ESXi architecture, logging configuration, DNS baselines, administrator workflows, and change-control data are required to turn this into reliable detection or risk evidence.
Analytic 0112
Monitor esxcli and syslog records for DNS resolver changes or repeated queries to unusual external domains by management agents. Detect unauthorized changes to VM or host network settings that redirect DNS lookups.
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 | f5227d414fec… |
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 AN0112Open 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.