AN0729: Analytic 0729
Inspect resolver and audit logs for processes initiating outbound connections to ports calculated from DNS response IPs. Abnormal ephemeral port usage shortly after DNS queries can indicate DNS calculation behavior.
Analyst context for executives and security teams
This analytic is about spotting Linux processes that appear to derive outbound connection ports from DNS response IPs. For security leaders, the value is not the specific math; it is whether the organization can connect DNS resolver evidence, process activity, and outbound network telemetry quickly enough to identify abnormal command-and-control style behavior or other suspicious network automation.
Executive priority
Prioritize this where Linux workloads are important to business operations and where outbound network access is broadly permitted. The decision question is whether SOC and incident response teams can prove which process made a suspicious connection shortly after a DNS lookup, and whether logs are retained well enough to support investigation, audit evidence, and containment decisions.
Technical view
Validate that Linux DNS resolver logs, audit/process telemetry, and outbound connection records can be correlated by host, process, destination IP, destination port, and time. The analytic’s core signal is abnormal ephemeral port usage shortly after DNS queries, especially where outbound ports appear calculated from DNS response IPs. Because no ATT&CK tactic, technique relationship, or formal detection logic is supplied, teams should treat this as a hypothesis to test and tune in local telemetry rather than a ready-to-run rule.
Likely telemetry
- Linux DNS resolver logs or host DNS query/response records
- Linux audit logs showing process execution and network connection activity
- Outbound network connection logs with destination IP, destination port, timestamp, and source host
- Process-to-network correlation data from endpoint or audit tooling
- Firewall, proxy, or network sensor records that preserve outbound port details
Detection direction
- Confirm the environment records DNS responses, not only DNS queries; the response IP is required for this analytic concept.
- Correlate outbound connections made shortly after DNS lookups by the same Linux host and, where possible, the same process.
- Baseline normal ephemeral port behavior for Linux servers and workloads before alerting on abnormal port patterns.
- Tune for legitimate applications that perform dynamic service discovery or unusual outbound port selection to reduce false positives.
- Check for blind spots where NAT, proxies, containers, short log retention, or missing process-to-connection mapping prevent attribution to a specific Linux process.
Mitigation priorities
- Ensure DNS and outbound connection logging are enabled and retained for Linux systems that matter to operations.
- Restrict unnecessary outbound network access from Linux hosts and workloads, especially to arbitrary destination ports.
- Improve endpoint audit coverage so responders can tie suspicious connections to processes and users where applicable.
- Use egress control and segmentation to limit the business impact if abnormal outbound behavior is confirmed.
- Document telemetry coverage and gaps as compliance and incident readiness evidence.
Analyst notes and limits
The supplied object is a detection analytic, AN0729, for Linux. It provides a description but no formal detection logic, no tactic mapping, and no relationship context. The practical use is as a validation prompt for DNS, process, and outbound network telemetry correlation.
This take is limited to the official STIX fields and the single MITRE external reference supplied. It does not establish active exploitation, actor usage, specific malware behavior, impact, or guaranteed detection coverage. Local baselines and environment-specific logging quality are required to determine usefulness.
Analytic 0729
Inspect resolver and audit logs for processes initiating outbound connections to ports calculated from DNS response IPs. Abnormal ephemeral port usage shortly after DNS queries can indicate DNS calculation behavior.
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 | b562fc1b89a7… |
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 AN0729Open 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.