Safeguard
Application Security•

Dynamic Resolution: Detecting Shifting C2 Destinations (T1568)

Malware can compute where to call home, which defeats static blocklists. What MITRE documents for T1568, the DNS signals to log, and the mitigations.

Safeguard Security Team
4 min read

If malware always called the same address, one firewall rule would end the story. MITRE T1568, Dynamic Resolution, is the family of tricks that avoids this. It sits under the command and control tactic and applies to ESXi, Linux, macOS and Windows.

How attackers use it

Adversaries dynamically establish connections to command and control infrastructure to evade common detections and remediations. MITRE says this can be done with malware that shares an algorithm with the infrastructure that receives its communications. The calculation can adjust parameters such as the domain name, IP address or port number.

It can also serve as a fallback channel. When contact with the primary server is lost, the malware may use dynamic resolution to re-establish command and control.

The parent technique has three subtechniques, each with its own guide in this series: Fast Flux DNS (T1568.001), Domain Generation Algorithms (T1568.002) and DNS Calculation (T1568.003). They change different things: the IP addresses behind one name, the name itself, and the port derived from an answer.

How to detect it

MITRE's detection strategy centers on DNS behavior tied to the process that makes it.

  • Windows and general: high-frequency or anomalous DNS queries from processes that do not normally generate network requests, such as Office applications or system utilities, and pseudo-random or high-entropy domain lookups that suggest a DGA.
  • Linux: repeated failed lookups or connections to high-entropy domain names in /var/log/audit/audit.log and DNS resolver logs, correlated with process lineage such as Python, bash or unusual daemons.
  • macOS: anomalous DNS resolutions triggered by apps that are not network apps, repeated connections to newly registered or algorithmically generated domains, correlated with endpoint process telemetry.
  • ESXi: changes to DNS resolver configuration and repeated queries to unusual external domains by management agents, seen in esxcli and syslog records, along with unauthorized changes to VM or host network settings that redirect lookups.

Four signals recur across all of them:

  1. Many failed lookups, which show as a high NXDOMAIN rate.
  2. High-entropy or word-salad names.
  3. Short TTLs with rotating answers.
  4. A process that has no business making DNS queries making them.

How to reduce the risk

MITRE lists two mitigations.

  1. Network Intrusion Prevention. Network detection and prevention systems with signatures for specific malware can mitigate this at the network level. MITRE adds that malware researchers can reverse engineer variants and determine future infrastructure, but that this is time and resource intensive.
  2. Restrict Web-Based Content. In some cases a local DNS sinkhole can help prevent behaviors associated with dynamic resolution.

A practical reading: force all endpoints to use your own resolvers, log every query with the client name, and block direct DNS to the Internet from everything else. Without that, you cannot see or sinkhole anything.

Check your own environment

  • Do all hosts have to use your resolvers, with outbound port 53 blocked elsewhere?
  • Do your resolver logs show the client, query, response code and TTL, and are they retained for months?
  • Is Sysmon event ID 22 collected on Windows hosts? It records DNS queries along with the process image.
  • Can you report NXDOMAIN counts per host per hour?
  • On servers, is there a short allowlist of destinations, so that a query for an unknown domain stands out?

A read-only look at an answer and its TTL:

dig +noall +answer example.com A

Handling alerts

DNS alerts are noisy. Browsers, CDNs, software update services and some security tools produce rotating answers and lots of failed lookups. Cut through it by looking at who asked. A browser asking is ordinary. A word processor, a script interpreter or a management agent asking for many random names is not. Then verify with the connection that follows: if a host resolved a strange name and opened a short connection to an address, check the process and the destination.

Where it connects to other techniques

Dynamic resolution is usually part of a larger command and control setup, including fallback channels and other application layer protocols. If you find one, look for the primary channel as well. Mapping the full set of destinations is part of scoping.

Quick check

What are the three subtechniques of dynamic resolution?

Fast flux DNS, domain generation algorithms and DNS calculation.

Why is a DNS sinkhole useful here?

It stops hosts from reaching known malicious or algorithmically generated names by answering the lookup with a harmless address, at lower cost than reverse engineering each malware family.

Which four signals recur across platforms?

Many failed lookups, high-entropy names, short TTLs with rotating answers, and unexpected processes making the queries.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.