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