T1568.001 — Fast Flux DNS
Tactic: Command and Control · Platforms: Linux, macOS, Windows, ESXi
Adversaries may use Fast Flux DNS to hide a command and control channel behind an array of rapidly changing IP addresses linked to a single domain resolution. This technique uses a fully qualified domain name, with multiple IP addresses assigned to it which are swapped with high frequency, using a…
Sub-technique of Dynamic Resolution (T1568).
Sigma detection rules (4)
T1568.001 Dynamic Resolution: Fast Flux DNS
title: "T1568.001 Dynamic Resolution: Fast Flux DNS"
id: 7fb0479b-6ca8-4a15-a2a1-dbbe6ee46dce
description: 'Detects DNS query responses returning an unusually high number of distinct IP addresses for a single domain, a lightweight proxy for Fast Flux DNS''s round-robin IP-churn behavior (the previous version matched unrelated PowerShell/nslookup command lines performing DNS TXT-record lookups, which does not reflect Fast Flux DNS at all). True fast-flux detection requires tracking IP churn/TTL for a domain over time, which a single Sysmon DNSQuery event cannot fully express -- this rule flags multi-IP responses as the closest defensible single-event proxy; pair with a Sigma correlation rule (value_count of distinct QueryResults IPs per domain over a time window) for full coverage. Tune using: DNSQueryBurstThreshold, TimeWindow.'
references:
- https://attack.mitre.org/techniques/T1568/001
author: Shahrukh Khan
date: 2026-04-17
license: MIT
tags:
- attack.command-and-control
- attack.t1568.001
logsource:
category: dns_query
product: windows
service: sysmon
detection:
selection:
QueryResults|re: '(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3};){2,}\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}'
condition: selection
falsepositives:
- CDN, load-balanced, or GeoDNS services that legitimately return multiple A records for one domain (e.g. large SaaS providers, CDNs) -- allowlist known-good high-value domains.
- DGA burst-rate/TTL-churn detection genuinely requires time-window correlation that a single Sysmon DNSQuery event cannot express -- recommend a Sigma correlation rule pairing this with a distinct-IP-count-per-domain threshold.
level: medium
T1568.001 Dynamic Resolution: Fast Flux DNS
title: "T1568.001 Dynamic Resolution: Fast Flux DNS"
id: fec9fd9a-8fa1-4b75-be73-271edf774747
description: 'Fast Flux DNS is defined by rapid IP/TTL churn in DNS answers for a single domain name -- a property of DNS resolution/passive-DNS data (TTL values, answer-set changes over time) that auditd process-creation telemetry cannot observe or measure at all; auditd only sees that a resolver tool ran, never the TTL or the answer set it received, so the previously declared TTLThreshold tuning field can never be evaluated from this telemetry. The closest defensible Linux-observable proxy available from process telemetry is manual invocation of CLI resolution tools, which can indicate an operator/script re-resolving a domain because a previously cached IP went stale (as happens against fast-flux infrastructure) -- but this is a very weak, non-specific signal that also matches ordinary connectivity troubleshooting. Genuine fast-flux detection requires DNS resolver/passive-DNS logs with TTL and answer-set history, not auditd process events. Tune using: TTLThreshold, DomainReputationFeed.'
references:
- https://attack.mitre.org/techniques/T1568/001
author: Shahrukh Khan
date: 2026-06-17
license: MIT
tags:
- attack.command-and-control
- attack.t1568.001
logsource:
category: process_creation
product: linux
detection:
selection:
type: EXECVE
a0|endswith:
- '/dig'
- '/host'
- '/nslookup'
- '/getent'
condition: selection
falsepositives:
- Any legitimate manual DNS troubleshooting, monitoring script, or health-check that resolves a hostname; this signal alone cannot distinguish fast-flux churn from routine lookups and should be paired with a repetition/frequency correlation (same hostname resolved many times in a short window) and, ideally, real DNS/passive-DNS TTL data before actioning.
level: low
T1568.001 Dynamic Resolution: Fast Flux DNS
title: "T1568.001 Dynamic Resolution: Fast Flux DNS"
id: e7a7b144-e64f-41da-8f6b-5668739c67d3
description: 'Detection Strategy for Dynamic Resolution using Fast Flux DNS. (Retargeted to the network_connection macOS unified-log telemetry that actually captures this techniques behavior; see logsource below.) Tune using: DNSRotationRate, NewDomainThreshold.'
references:
- https://attack.mitre.org/techniques/T1568/001
author: Shahrukh Khan
date: 2026-03-20
license: MIT
tags:
- attack.command-and-control
- attack.t1568.001
logsource:
category: network_connection
product: macos
detection:
selection:
Image|endswith: '/curl'
DestinationHostname|exists: true
condition: selection
falsepositives:
- Detecting fast-flux requires correlating repeated DNS resolutions of the same hostname to many distinct IPs over a short window, which is not observable from a single unified log network_connection event; this rule cannot reliably distinguish fast flux from normal CDN or load-balanced traffic.
level: low
T1568.001 Dynamic Resolution: Fast Flux DNS
title: "T1568.001 Dynamic Resolution: Fast Flux DNS"
id: 76bef9bf-a9a4-4f2a-b0fe-fa9faf14567e
description: 'Detection Strategy for Dynamic Resolution using Fast Flux DNS. (Retargeted to the process_creation ESXi telemetry that actually captures this techniques behavior; see logsource below.) Tune using: ResolverConfigPaths, ExternalDomainWhitelist.'
references:
- https://attack.mitre.org/techniques/T1568/001
author: Shahrukh Khan
date: 2026-02-18
license: MIT
tags:
- attack.command-and-control
- attack.t1568.001
logsource:
product: esxi
service: shell
detection:
selection:
CommandLine|contains:
- 'esxcli network ip dns server add'
- '/etc/resolv.conf'
condition: selection
falsepositives:
- ESXi has no DNS query or TTL logging, so fast-flux resolution patterns cannot genuinely be observed from host logs alone; this rule only proxies via resolver configuration changes and requires an upstream DNS sensor to actually validate ExternalDomainWhitelist violations.
level: low
Related sub-techniques
Explore