AN1332: Analytic 1332
Monitor resolver logs and auditd events for domains resolving to a rotating set of IPs within very short TTL intervals. Correlate high query rates from non-browser applications (e.g., python, curl).
Analyst context for executives and security teams
This analytic matters because unusual DNS behavior can be an early signal that a Linux workload or user process is communicating with infrastructure designed to change addresses rapidly. For leaders, the practical question is whether DNS and process audit data are collected well enough to connect suspicious domain resolution patterns to the application generating them.
Executive priority
Prioritize this where Linux systems support critical services, cloud workloads, or regulated environments that require incident evidence. The decision value is not just detecting odd DNS; it is proving whether the organization can identify which host and process produced high-rate queries to domains with very short TTLs and rotating IPs, so incident responders can scope and contain activity quickly.
Technical view
For Linux environments, validate monitoring of resolver logs and auditd events. Detection engineering should correlate domains that resolve to changing IP sets over very short TTL intervals with high query volume from non-browser processes such as python or curl. Because no tactic or relationship context is supplied, treat this as a behavior-focused analytic rather than a complete ATT&CK technique mapping.
Likely telemetry
- DNS resolver logs containing queried domain, response IPs, TTL values, timestamp, and client host
- Linux auditd process execution or network-related events tying activity to process name and command context
- Host identity and asset context for Linux systems generating high DNS query rates
- Application context to distinguish expected automation from suspicious non-browser query behavior
Detection direction
- Confirm that resolver telemetry preserves TTL and response IP details; without those fields, the rotating-IP and short-TTL pattern may be invisible.
- Correlate DNS activity with Linux process telemetry so high-rate queries can be attributed to applications such as python or curl rather than only to a host.
- Tune for known automation, monitoring, package management, and service-discovery workloads that may generate frequent DNS activity.
- Review blind spots where DNS bypasses central resolvers, auditd is not enabled, process names are missing, or ephemeral cloud/Linux workloads are not consistently logged.
Mitigation priorities
- Establish reliable centralized DNS logging for Linux systems and retain fields needed to analyze TTL and response changes.
- Enable and validate auditd or equivalent Linux process telemetry on systems where investigation evidence is required.
- Create baselines for expected high-volume DNS clients and non-browser automation before alerting aggressively.
- Use incident response playbooks that connect suspicious domain resolution to host ownership, process context, and containment decisions.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, not a full technique description. Its concrete value is in validating DNS-to-process correlation on Linux and identifying gaps in resolver and audit telemetry.
No official detection logic, tactics, related techniques, threat actors, malware, campaigns, or mitigation relationships were supplied. Local baselines are required to determine whether short-TTL rotating-IP domains and high query rates are suspicious in a specific environment.
Analytic 1332
Monitor resolver logs and auditd events for domains resolving to a rotating set of IPs within very short TTL intervals. Correlate high query rates from non-browser applications (e.g., python, curl).
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 | 8ae7acc1d504… |
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 AN1332Open 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.