T1568.003: DNS Calculation
Adversaries may perform calculations on addresses returned in DNS results to determine which port and IP address to use for command and control, rather than relying on a predetermined port number or the actual returned IP address. A IP and/or port number calculation can be used to bypass egress filtering on a C2 channel.[1]
One implementation of DNS Calculation is to take the first three octets of an IP address in a DNS response and use those values to calculate the port for command and control traffic.[1][2][3]
Analyst context for executives and security teams
DNS Calculation matters because it can let command-and-control traffic avoid simple allow/block assumptions. Instead of connecting to a fixed IP address or port, malware can use values returned from DNS and calculate where to connect next. For leaders, the practical issue is whether DNS, egress, and network monitoring are correlated well enough to explain why a host connected to a particular destination and port after a DNS lookup.
Executive priority
Prioritize this as a command-and-control resilience and visibility problem, not just a DNS problem. Organizations relying mainly on static blocklists, fixed port rules, or domain-only detections may miss activity where the DNS response is only an input to a later connection. Security leaders should ask whether SOC and incident response teams can reconstruct DNS-to-connection sequences across Windows, Linux, macOS, and ESXi environments where applicable, and whether egress controls are validated against dynamic destination or port selection.
Technical view
T1568.003 is a sub-technique of Dynamic Resolution and applies to command-and-control behavior on ESXi, Linux, macOS, and Windows. ATT&CK does not provide object-level detection text, but the relationship to DET0262 indicates a detection strategy exists for Dynamic Resolution through DNS Calculation. SOC teams should validate whether detections correlate DNS responses with subsequent outbound connections, especially cases where the contacted IP or port is derived from DNS response data rather than matching an expected returned address or standard service port. IR teams should preserve DNS resolver logs, endpoint network telemetry, and firewall/proxy records together so calculated C2 paths can be reconstructed.
Likely telemetry
- DNS query and response logs, including returned IP addresses
- Endpoint network connection events showing destination IP, destination port, process, host, and timestamp
- Firewall, proxy, or egress gateway logs for outbound connection attempts and allowed/blocked traffic
- EDR or host telemetry linking processes to DNS activity and subsequent network connections
- Network flow records that can show timing relationships between DNS responses and outbound sessions
Detection direction
- Validate correlation logic between DNS responses and later outbound connections from the same host or process, rather than relying only on domain or IP reputation.
- Look for unusual destination ports selected shortly after DNS responses, particularly when the connection pattern does not align with normal application behavior.
- Tune carefully for legitimate software that performs dynamic DNS use, load balancing, CDN access, or nonstandard service ports to reduce false positives.
- Confirm coverage on all supported ATT&CK platforms present in the environment: ESXi, Linux, macOS, and Windows.
- Use the related DET0262 strategy as the ATT&CK-linked detection reference, while testing locally because the supplied technique object contains no official detection text.
Mitigation priorities
- Strengthen egress control so outbound traffic is limited by business need, not only by static denied destinations.
- Ensure DNS logging and endpoint/network telemetry are retained long enough to support incident reconstruction.
- Require SOC content to correlate DNS, process, and network events where telemetry supports it.
- Review exceptions for nonstandard outbound ports and document business justification for audit and incident response readiness.
- During incidents, treat suspicious DNS activity and follow-on network connections as one investigation chain rather than separate alerts.
Analyst notes and limits
The key defensive value is proving whether a DNS response influenced a later C2 connection. The supplied ATT&CK relationship to APT12 provides historical context that the group uses this technique, but it should not be interpreted as current activity or attribution in any local environment without additional evidence.
ATT&CK provides no official detection text for this object in the supplied fields. The summary is therefore based on the official description, platforms, command-and-control tactic, the parent Dynamic Resolution relationship, the DET0262 detection-strategy relationship, and listed references. Local baselines are required to distinguish malicious DNS calculation from legitimate dynamic network behavior.
DNS Calculation
Adversaries may perform calculations on addresses returned in DNS results to determine which port and IP address to use for command and control, rather than relying on a predetermined port number or the actual returned IP address. A IP and/or port number calculation can be used to bypass egress filtering on a C2 channel.[1]
One implementation of DNS Calculation is to take the first three octets of an IP address in a DNS response and use those values to calculate the port for command and control traffic.[1][2][3]
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.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1568 | Dynamic Resolution | This object subtechnique of Dynamic Resolution. |
Groups, software, and campaigns
G0005: APT12
All related ATT&CK context
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.1 | Current bundle | d897959119b8… |
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]
Meyers Numbered Panda
Meyers, A. (2013, March 29). Whois Numbered Panda. Retrieved January 14, 2016.
Open source URL -
[2]
Moran 2014
Moran, N., Oppenheim, M., Engle, S., & Wartell, R.. (2014, September 3). Darwin’s Favorite APT Group [Blog]. Retrieved November 12, 2014.
Open source URL -
[3]
Rapid7G20Espionage
Rapid7. (2013, August 26). Upcoming G20 Summit Fuels Espionage Operations. Retrieved March 6, 2017.
Open source URL -
[4]
mitre-attack T1568.003Open 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.