Blocking a C2 domain or IP address only works if the malware keeps using it, and dynamic resolution is how adversaries make sure it does not. MITRE ATT&CK v20 tracks this as T1568 Dynamic Resolution, a Command and Control technique on Windows, Linux, macOS and ESXi: malware and infrastructure share an algorithm or service that changes the domain, IP address or port used for C2, often as a fallback when the primary channel is lost. The three sub-techniques are Fast Flux DNS (T1568.001), Domain Generation Algorithms (T1568.002) and DNS Calculation (T1568.003); the parent technique also covers dynamic DNS providers and wildcard DNS services. This guide covers the procedure examples ATT&CK records, the April 2025 joint advisory on fast flux, the v20 detection strategies, mitigations and how to measure them. It is for SOC analysts, DNS and network teams and threat intelligence staff. For DNS telemetry in general see the DNS Logging and Detection Guide.
Key takeaways
- Resolver logs are the primary sensor. Every v20 detection strategy for T1568 starts with DNS queries and responses joined to the process that asked.
- Fast flux is now a government priority. NSA, CISA, FBI and partners in Australia, Canada and New Zealand called it a national security threat in April 2025 and asked Protective DNS providers to detect and block it.
- DGAs fail loudly. Most generated domains are never registered, so bursts of NXDOMAIN responses to random-looking names from one host are a strong signal.
- Not all dynamic resolution looks random. SUNBURST built subdomains under one parent domain, and BRICKSTORM used sslip.io and nip.io to resolve straight to IP addresses, so entropy alone misses them.
- Sinkholes and Protective DNS are the listed controls. ATT&CK v20 names M1031 Network Intrusion Prevention and M1021 Restrict Web-Based Content, which includes a local DNS sinkhole.
How the technique and its sub-techniques work
| Technique | Mechanism | What the defender sees | Procedure examples in ATT&CK v20 |
|---|---|---|---|
| T1568 Dynamic Resolution (parent) | Dynamic DNS providers, wildcard DNS services or data published elsewhere tell the malware where C2 is | Queries to dynamic DNS zones, or to services that encode an IP address in the hostname | APT29 using dynamic DNS providers; Kimsuky using FreeDNS and No-IP; BRICKSTORM using sslip.io and nip.io; AsyncRAT and Remcos configured with dynamic DNS |
| T1568.001 Fast Flux DNS | One domain maps to many IP addresses swapped at high frequency using round robin and short TTLs; double flux also rotates the name servers | Low TTL, many distinct IPs per domain, IPs spread across networks and countries | Gamaredon Group, TA505, Amadey, njRAT, gh0st RAT operators |
| T1568.002 Domain Generation Algorithms | Malware and operator compute the same list of candidate domains from a seed and often the date; the operator registers only a few | Many NXDOMAIN responses, high-entropy or word-concatenated names, periodic changes | APT41 changing C2 servers monthly; Conficker seeding with the current UTC date; QakBot, Ursnif, AsyncRAT; CHOPSTICK using word lists as a fallback channel |
| T1568.003 DNS Calculation | Malware computes the real IP address or port from the returned DNS answer, for example from its first octets | Connections to ports or addresses that never appeared in a DNS answer, right after a lookup | APT12 using several variants, including multiplying the first two octets and adding the third |
ATT&CK ties dynamic resolution to T1008 Fallback Channels: when the primary server is lost, a DGA or flux domain re-establishes contact. That is why takedown or blocking of one domain is often followed by a quiet reconnection. See MITRE ATT&CK T1008 Fallback Channels.
Cases worth knowing
- SolarWinds (SUNBURST): ATT&CK records SUNBURST dynamically resolving randomly generated subdomains within a parent domain, and APT29 using dynamic DNS resolution in the campaign. NHI Mgmt Group's SolarWinds supply chain compromise analysis notes that up to 18,000 customers installed the tampered builds but SolarWinds said fewer than 100 saw command and control contact: resolution and selection decided who became a real victim.
- BRICKSTORM: Mandiant's September 2025 report describes the Go backdoor on network appliances and VMware vCenter and ESXi resolving C2 through sslip.io or nip.io, using DNS over HTTPS, never reusing C2 domains across victims, and averaging 393 days of dwell time. Its detection advice includes flagging DNS over HTTPS from appliance management IPs.
- Commodity RATs: AsyncRAT supports dynamic DNS and a DGA, Remcos uses dynamic DNS domains, and njRAT has used fast flux. See the AsyncRAT, Remcos and njRAT Commodity RATs Guide.
- Regional espionage and crime: ATT&CK records APT-C-36 using DuckDNS, No-IP and con-ip, and Operation Spalax using Duck DNS and DNS Exit. See the Blind Eagle Threat Actor Profile Guide.
- Fast flux in ransomware and state activity: the April 2025 joint advisory names Gamaredon using fast flux to limit IP blocking, Hive and Nefilim ransomware attacks using it, and bulletproof hosting providers selling fast flux as a service. See the Gamaredon Group Threat Actor Profile Guide.
What to detect and where
ATT&CK v20 has four detection strategies: DET0039 (parent), DET0485 (fast flux), DET0419 (DGAs) and DET0262 (DNS calculation). On Windows they rely on Sysmon Event ID 22 (DNSEvent) joined to Event ID 1 or Security 4688 and Sysmon 3; on Linux on resolver logs and auditd socket and connect calls; on macOS on the unified log; on ESXi on syslog and esxcli records, including changes to DNS resolver settings.
| Signal | Sub-technique | Telemetry | Tuning note |
|---|---|---|---|
| Bursts of NXDOMAIN responses to high-entropy or dictionary-concatenated names from one host | .002 | Resolver logs, Sysmon 22, network DNS sensors | Exclude browser prefetch and known anti-virus lookups; score per process |
| Domain resolving to many distinct IPs across several networks and countries with very low TTL | .001 | Resolver response logs, passive DNS, flow data | The advisory notes IPs may change every 3 to 5 minutes; allowlist CDNs |
| Name server set for a zone changing frequently | .001 (double flux) | Passive DNS, threat intelligence | Best done by Protective DNS or intelligence providers |
| Connection to an IP address or port that does not match the preceding DNS answer | .003 | Sysmon 22 joined with Sysmon 3, or Zeek dns.log with conn.log | Rare in normal software; review every hit |
| Lookups to dynamic DNS zones or IP-in-hostname services from servers, appliances or Office processes | Parent | Resolver logs with process context | Maintain a list of dynamic DNS and wildcard DNS zones |
| DNS over HTTPS from servers or appliance management interfaces | Parent | Proxy and firewall logs, TLS SNI | Mandiant's BRICKSTORM advice; servers rarely need their own DoH |
| Unauthorised change to host or hypervisor DNS resolver configuration | Parent | ESXi syslog, configuration management | Named in the v20 ESXi analytics |
Collect what the analytics need: query name, response code, answers and TTLs, the client IP and, on endpoints, the process. Encrypted DNS hides this from the network unless endpoints use your resolver; see the Encrypted DNS Enterprise Guide. Newly registered domains are a cheap companion signal, because DGA and flux domains are usually young; see the Newly Registered Domains Guide and the Passive DNS and DNS History Guide.
Mitigations
ATT&CK v20 lists M1031 Network Intrusion Prevention (signatures, plus the note that reverse engineering malware can yield the DGA so future domains can be predicted and blocked) and M1021 Restrict Web-Based Content (a local DNS sinkhole, at reduced cost). The April 2025 joint advisory adds DNS and IP blocking with non-routable responses, sinkholing to identify infected hosts, reputation filtering, more DNS and network logging, information sharing because fast flux domains are often active for only a few days, and allowlisting legitimate CDNs. The steps below are NHI Mgmt Group recommendations built on those sources.
- Force all DNS through resolvers you control: block outbound UDP and TCP 53 and known DoH endpoints except from your resolvers (NIST SP 800-53 SC-7(5)), so the logs and the blocks apply to everyone.
- Use Protective DNS: enable reputation, newly registered domain and DGA categories. The advisory warns that some providers may not block fast flux, so ask yours directly. See the Protective DNS Guide and the DNS Security and Protective DNS Buyer's Guide.
- Run a sinkhole: point known and predicted malicious domains to an internal sinkhole and log who connects; that list is your infected host list.
- Restrict dynamic DNS where business allows: block or alert on dynamic DNS and IP-in-hostname zones for servers and appliances first.
- Restrict egress for infrastructure: servers, appliances and hypervisors should resolve and reach only named destinations, which makes any new domain stand out. See M1037 Filter Network Traffic.
- Feed intelligence back: when malware analysis recovers a DGA, pre-block its upcoming domains, as M1031 describes.
Rolling it out and testing
- Start Protective DNS and DGA or NXDOMAIN analytics in log-only mode for two weeks and list legitimate low-TTL and random-looking services (CDNs, telemetry, anti-virus cloud lookups).
- Enforce blocking for servers and appliances first, then user devices, keeping the previous policy for rollback.
- Test in an authorised exercise with a benign DGA-style generator pointed at a test domain you own, and confirm Sysmon 22, resolver logs and the alert all fire.
- Run a sinkhole drill: add a test domain, query it from a lab host and confirm the host is identified.
Choosing an approach: small organisations get most value from a Protective DNS service with DNS forced through it. Large organisations should add process-level DNS telemetry, in-house DGA and flux analytics, passive DNS and a sinkhole, as described in the M1021 Restrict Web-Based Content and M1031 Network Intrusion Prevention guides.
Where identity fits
Service accounts, CI/CD runners and cloud workloads make DNS lookups too, and their behaviour is usually predictable. A build agent or service principal host that suddenly resolves dynamic DNS zones or random domains is a high-confidence signal, and egress allow lists keyed to workload identity make the anomaly obvious. BRICKSTORM shows the link: the same intrusion that resolved C2 through sslip.io also created temporary local vCenter accounts named like backup service accounts. See the MITRE ATT&CK T1078 Valid Accounts Guide.
Detection and measurement
- DNS path coverage: percentage of hosts whose DNS goes through logged, filtered resolvers, with direct port 53 and DoH blocked.
- Process attribution: share of Windows endpoints sending Sysmon 22 or equivalent EDR DNS events.
- Sinkhole hits: unique internal hosts reaching the sinkhole per month, and time to isolate each.
- Emulation detection: DGA and dynamic DNS test cases detected within one hour.
- Retention: DNS logs kept at least as long as typical dwell time; Mandiant's 393-day BRICKSTORM average often exceeded retention.
Common failure patterns
- Direct DNS and DoH allowed: malware uses its own resolver and your logs see nothing.
- Entropy-only DGA detection: dictionary DGAs and SUNBURST-style subdomains look ordinary; add NXDOMAIN rates, domain age and process context.
- Blocking CDNs as fast flux: low TTLs and many IPs are normal for CDNs; the advisory itself recommends allowlisting them.
- One-off domain blocks: a fallback DGA reconnects the implant; isolate the host, do not just block the domain.
- Unmonitored appliances and hypervisors: resolver changes and DoH from management interfaces go unseen.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| ATT&CK v20 | T1568, T1568.001, T1568.002, T1568.003; DET0039, DET0485, DET0419, DET0262; M1031, M1021 | Technique, detection strategies, mitigations |
| MITRE D3FEND (related techniques) | D3-DNSTA DNS Traffic Analysis; D3-DNRA Domain Name Reputation Analysis; D3-DNSDL DNS Denylisting | Analyse, score and block DNS |
| NIST SP 800-53 Rev. 5 | SC-21 Secure Name/Address Resolution Service (Recursive or Caching Resolver); SC-22; SC-7(5); SI-4(4) | Secure name resolution, deny-by-default egress, traffic monitoring |
| NIST CSF 2.0 | DE.CM-01; DE.AE-02 | Monitor networks; analyse adverse events |
| CIS Controls v8.1 | 9.2 Use DNS Filtering Services; 8.6 Collect DNS Query Audit Logs | Protective DNS and DNS logging |
| ISO/IEC 27001:2022 Annex A | 8.16 Monitoring activities; 8.23 Web filtering | Monitoring and filtering |
Practitioner checklist
- Force DNS through logged resolvers and block direct port 53 and unapproved DoH.
- Collect query, response code, answers, TTL and process for every lookup.
- Deploy NXDOMAIN-burst, entropy and domain age analytics per process.
- Flag domains with low TTLs and many IPs across networks, with a CDN allowlist.
- Alert on connections whose IP or port does not match the preceding DNS answer.
- Enable Protective DNS categories and confirm fast flux blocking with the provider.
- Run an internal sinkhole and treat every hit as an infected host.
- Monitor resolver configuration and DoH on appliances and ESXi hosts.
Standards and references
- MITRE ATT&CK: Dynamic Resolution (T1568)
- MITRE ATT&CK: Fast Flux DNS (T1568.001)
- MITRE ATT&CK: Domain Generation Algorithms (T1568.002)
- MITRE ATT&CK: DNS Calculation (T1568.003)
- NSA, CISA, FBI and partners: Fast Flux: A National Security Threat
- CISA: Alert on the fast flux joint advisory
- Google Cloud (Mandiant): Another BRICKSTORM
- MITRE D3FEND: DNS Traffic Analysis
Related NHI Mgmt Group resources: ATT&CK Command and Control Tactic · Command and Control (C2) Guide · DNS Security Guide · APT41 Threat Actor Profile · MITRE ATT&