Detect Fast Flux DNS in Sumo Logic CSE
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, swapped with high frequency using a combination of round-robin IP addressing and short Time-To-Live (TTL) DNS records. The simplest 'single-flux' method involves registering and de-registering addresses as part of the DNS A record list, with an average lifespan of five minutes per IP. The 'double-flux' method additionally rotates the DNS Name Server (NS) records for the zone, providing additional resilience by allowing additional hosts to act as proxies to the true C2 host. Real-world users of this technique include Amadey malware, TA505, gh0st RAT operators, njRAT, menuPass (APT10), and Gamaredon Group.
MITRE ATT&CK
- Tactic
- Command and Control
- Technique
- T1568 Dynamic Resolution
- Sub-technique
- T1568.001 Fast Flux DNS
- Canonical reference
- https://attack.mitre.org/techniques/T1568/001/
Sumo Detection Query
_sourceCategory=dns/logs
| json auto
| where RecordType in ("A","AAAA")
| where !Domain matches ".*(akamaiedge|cloudflare|fastly|amazonaws|azure|cloudfront|akadns|edgesuite).*"
| timeslice 1h
| stats dc(AnswerIP) as UniqueIPs, count() as QueryCount, values(AnswerIP) as IPList
by Domain, _timeslice
| where UniqueIPs >= 5 AND QueryCount >= 3
| eval risk = if(UniqueIPs >= 20, "critical", if(UniqueIPs >= 10, "high", "medium"))
| sort by UniqueIPs desc Detects fast flux DNS domains with high IP rotation rates using DNS query logs in Sumo Logic.
Data Sources
Required Tables
False Positives & Tuning
- Content Delivery Networks (Cloudflare, Akamai, AWS CloudFront, Fastly, Azure CDN) legitimately return many different IPs via anycast geo-routing — filter by known CDN domain suffixes or IP ranges
- Global load-balanced SaaS services (Microsoft 365, Google Workspace, Zoom, Salesforce) return different IPs per geographic region — allowlist by domain suffix
- Active/passive DNS failover configurations tested during disaster recovery drills — coordinate with network operations for change window exclusions
- Internal DNS round-robin for on-premises load-balanced applications with multiple backend nodes — document and allowlist by internal domain name
- Security research sinkholes — multiple decommissioned botnet C2 domains may resolve to sinkhole IPs operated by different vendors, appearing as high IP diversity
Other platforms for T1568.001
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Fast Flux DNS Resolution Pattern Simulation via PowerShell
Expected signal: Sysmon Event ID 22 (DNSEvent): 15 events with QueryName=example.com, QueryResults containing resolved IP addresses, Image=powershell.exe. Events appear approximately 800ms apart. Sysmon Event ID 1 for powershell.exe process creation with the full command line visible. PowerShell process exits after completion.
- Test 2Repeated DNS Resolution via nslookup Loop (Windows cmd.exe)
Expected signal: Sysmon Event ID 22: 20 DNS query events with QueryName=example.com, Image containing nslookup.exe. Sysmon Event ID 1: nslookup.exe process creation spawned by cmd.exe, repeated 20 times. Windows Security Event ID 4688 (if process command line auditing enabled) for each nslookup.exe invocation. DNS server at 8.8.8.8 will log 20 A record queries from the test host's external IP.
- Test 3Fast Flux TTL Inspection via dig Loop (Linux/macOS)
Expected signal: Linux auditd (if configured for EXECVE syscall auditing): dig process execution events with the command line arguments. Sysmon for Linux (if deployed): Event ID 22 DNS query events for each dig invocation. DNS server logs at 8.8.8.8: 10 A record queries from the test host over 30 seconds. Terminal output displays resolved IPs with TTL values — document the observed TTL range as a baseline for your test domain.
- Test 4Windows DNS Client Cache Forensic Inspection for Fast Flux Indicators
Expected signal: Sysmon Event ID 1: powershell.exe process creation with Get-DnsClientCache in the command line. No network events generated (local read-only operation). Output displays cached DNS A records with their remaining TTL countdown — entries with TTL < 300 seconds from external domains are candidate fast flux indicators. Multiple cache entries for the same domain with different IP addresses (Data field) are definitive evidence of IP rotation.
References (12)
- https://attack.mitre.org/techniques/T1568/001/
- https://resources.infosecinstitute.com/fast-flux-networks-working-detection-part-1/#gref
- https://resources.infosecinstitute.com/fast-flux-networks-working-detection-part-2/#gref
- https://www.welivesecurity.com/2017/01/12/fast-flux-networks-work/
- https://www.cisa.gov/sites/default/files/2024-05/fast-flux-advisory-aa24-131a.pdf
- https://unit42.paloaltonetworks.com/fast-flux-networks-revisited/
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1568.001/T1568.001.md
- https://learn.microsoft.com/en-us/azure/sentinel/dns-events
- https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon
- https://docs.microsoft.com/en-us/defender-endpoint/advanced-hunting-devicenetworkevents-table
- https://www.secureworks.com/blog/fast-flux-dns-detection
- https://www.caida.org/catalog/papers/2008_fast_flux_hosting/
Unlock Pro Content
Get the full detection package for T1568.001 including response playbook, investigation guide, and atomic red team tests.