AdversaryGraph public intelligence page

This page is part of Threat Matrix, the public browser workspace for the main AdversaryGraph platform. Use it for ATT&CK pivots, actor and technique context, similarity leads, detection coverage review, and analyst-ready investigation paths.

Validation disclaimer: TTP overlap, actor similarity, generated summaries, and coverage findings are investigation leads, not attribution proof or operational validation without analyst review.

Main AdversaryGraph project Documentation Malware Analysis GitHub

T1568.001 · command-and-control · 4 actors · 0 correlated reports

Fast Flux DNS

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 combination of round robin IP addressing and short Time-To-Live (TTL) for a DNS resource record. The simplest, "single-flux" method, involves registering and de-registering an addresses as part of the DNS A (address) record list for a single DNS name. These registrations have a five-minute average lifespan, resulting in a constant shuffle of IP address resolution. In contrast, the "double-flux" method registers and de-registers an address as part of the DNS Name Server record list for the DNS zone, providing additional resilience for the connection. With double-flux additional hosts can act as a proxy to the C2 host, further insulating the true source of the C2 channel.

Open detection, hunting, mitigation, and evidence workspace

Detection logic

In general, detecting usage of fast flux DNS is difficult due to web traffic load balancing that services client requests quickly. In single flux cases only IP addresses change for static domain names. In double flux cases, nothing is static. Defenders such as domain registrars and service providers are likely in the best position for detection.

Observed actors

Correlated CTI and IR reports

Cyber Knowledge context

Use these routes to move from the ATT&CK behavior into explanation, implementation, evidence handling, validation, and defensive operations. Relevance is generated from explicit identifiers/names and governed topic mappings; it is not attribution evidence.

MITRE mitigations

No ATT&CK mitigation relationship is published for this technique. Apply risk-based controls and verify scope.

MITRE detection strategies and analytics

DET0485 · Detection Strategy for Dynamic Resolution using Fast Flux DNS
  • AN1331 · Analytic 1331 — Identify repeated DNS resolutions where the same domain name returns multiple IPs in short succession, combined with low TTL values and high query volume from unusual processes. Correlate with process lineage (e.g., Office apps spawning abnormal DNS lookups).
  • AN1332 · Analytic 1332 — Monitor resolver logs and auditd events for domains resolving to a rotating set of IPs within very short TTL intervals. Correlate high query rates from non-browser applications (e.g., python, curl).
  • AN1333 · Analytic 1333 — Use unified logs to identify processes issuing repeated DNS queries where the resolved IP addresses change frequently within very short TTL values. Correlate with outbound network traffic to validate C2-like patterns.
  • AN1334 · Analytic 1334 — Monitor ESXi syslog and esxcli outputs for abnormal DNS resolver behavior, such as frequent domain-to-IP changes or unauthorized modifications of DNS settings used by management agents. Correlate domain lookups with short TTL values.
MITRE detection source

Continue the investigation