AN0110: Analytic 0110
Monitor /var/log/audit/audit.log and DNS resolver logs for repeated failed lookups or connections to high-entropy domain names. Correlate suspicious DNS queries with process lineage (e.g., Python, bash, or unusual system daemons).
Analyst context for executives and security teams
This analytic matters because unusual, repeated DNS activity to high-entropy domain names on Linux systems can be an early signal of suspicious automation, command activity, or software behavior that needs investigation. For leaders, the decision value is not simply “detect strange DNS”; it is whether the organization can connect DNS evidence back to the Linux process that caused it, fast enough to support incident triage and containment decisions.
Executive priority
Prioritize this as a visibility and response-readiness question for Linux environments: do security teams retain DNS resolver logs and Linux audit evidence, and can they tie suspicious lookups to process lineage? The business risk is delayed investigation when DNS anomalies are visible but cannot be attributed to a host process, user context, or service. This also supports compliance and audit evidence by demonstrating that network indicators can be correlated with endpoint activity on Linux systems.
Technical view
Validate collection and correlation for Linux systems using /var/log/audit/audit.log and DNS resolver logs. The analytic specifically calls for monitoring repeated failed lookups or connections to high-entropy domain names, then correlating suspicious DNS queries with process lineage such as Python, bash, or unusual system daemons. Because ATT&CK does not specify tactics or a separate detection implementation here, SOC teams should treat this as a detection engineering requirement: confirm logging exists, define what qualifies as repeated failure and high entropy in the local environment, and ensure process lineage is available for triage.
Likely telemetry
- Linux audit logs, especially /var/log/audit/audit.log
- DNS resolver query logs
- Failed DNS lookup records
- Connection attempts associated with suspicious domain names
- Process lineage and parent-child process context on Linux hosts
Detection direction
- Confirm DNS resolver logs are collected from relevant Linux environments and retained long enough for investigation.
- Confirm Linux audit logging captures process context that can be correlated to DNS activity.
- Tune high-entropy domain logic against local baselines to reduce false positives from legitimate generated domains or internal services.
- Alert on repeated failed lookups or connections where the originating process lineage is unusual, such as scripting interpreters, shells, or unexpected daemon activity.
- Build triage views that show domain, host, timestamp, failure pattern, process lineage, and command context together.
Mitigation priorities
- Start with visibility: ensure Linux audit logs and DNS resolver logs are enabled, centralized, and time-synchronized.
- Establish baselines for normal DNS behavior and known legitimate high-entropy domains in the environment.
- Improve correlation between DNS events and endpoint process lineage before relying on alerting alone.
- Use investigation playbooks that require analysts to validate the originating process, parent process, host role, and recurrence pattern.
- Where suspicious activity is confirmed, use standard incident response containment and eradication procedures appropriate to the affected Linux host and service.
Analyst notes and limits
This object is a detection analytic, not a technique, and no tactic or relationship context was supplied. The strongest operational takeaway is correlation quality: DNS anomalies become materially more useful when mapped to Linux process lineage. Detection engineering should define local thresholds for “repeated,” “failed,” and “high-entropy” rather than assuming a universal value.
The supplied ATT&CK object provides a short monitoring description but no official detection logic, no tactics, and no relationships. This take is therefore limited to Linux telemetry and correlation guidance explicitly supported by the object. It does not imply active exploitation, attribution, impact, or guaranteed detection coverage.
Analytic 0110
Monitor /var/log/audit/audit.log and DNS resolver logs for repeated failed lookups or connections to high-entropy domain names. Correlate suspicious DNS queries with process lineage (e.g., Python, bash, or unusual system daemons).
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 | 863fd1ab7a76… |
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 AN0110Open 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.