Fast-flux networks: how botnets hide C2 behind rotating DNS

Ask a domain for its address twice, ninety seconds apart, and you expect the same answer. That assumption is what blocklists, sinkholes, and takedown letters are built on: a name points at an IP, you neutralise the IP, the name goes dark. Fast flux breaks the assumption on purpose. The domain answers with a different IP almost every time you ask, drawn from a pool of thousands of compromised home machines, and each of those machines is only a proxy. Block one and the next lookup hands you another. The thing you actually want, the command-and-control server behind them, never appears in a single DNS answer.

In April 2025 six national cyber agencies put their names on a joint advisory calling this a national security threat, which is unusual language for a technique first written up in 2007. This post works from the primary sources. What fast flux is at the DNS level, how single flux and double flux differ, the blind-proxy architecture that keeps the real server hidden, the detection math that has worked since the Holz paper at NDSS 2008, why that math keeps overlapping with legitimate CDNs, and what the 2025 advisory adds beyond the original research. It sits next to our pieces on domain generation algorithms and DNS resolution end to end; DGAs solve the problem of finding the C2 name, fast flux solves the problem of keeping that name resolvable.

The DNS assumption fast flux attacks

A normal recursive resolution returns one or a few A records with a time-to-live long enough to cache. A small site might answer with a single IP and a TTL of an hour. The resolver caches the answer for that hour and stops bothering the authoritative server. This is the entire economic basis of DNS caching, and it is also a liability for anyone running infrastructure they expect to lose, because a cached answer is a stable target.

Fast flux inverts the trade. The authoritative name server for the malicious domain answers with a short TTL, conventionally somewhere between 180 and 600 seconds, and rotates the A records on each refresh. The Honeynet Project’s 2007 write-up, Know Your Enemy: Fast-Flux Service Networks by William Salusky and Robert Danford, documented domains cycling their record set every few minutes. A resolver that caches an answer for three hundred seconds is forced back to the authoritative server twelve times an hour, and each visit can hand out a fresh set of IPs from the pool. The low TTL is not a tuning mistake. It is the mechanism.

The IPs in the pool are not the attacker’s servers. They are compromised consumer machines, the same population that has filled botnets for two decades: home routers, IoT cameras, broadband desktops on residential ISPs. Each one runs a small redirector that forwards whatever it receives on port 80 or 443 to a back-end the victim never sees. So when a phishing victim’s browser connects to one of those IPs, it talks to a stranger’s hacked router in Argentina or Morocco, and that router relays the session to the real phishing kit somewhere else entirely. The visible IP is disposable. The infrastructure behind it is not.

Single flux: rotate the address records

Single flux is the version most people mean when they say fast flux. The domain has one authoritative name server, stable, and that name server rotates the A records. The redirect layer is the bot pool; the DNS layer is fixed. The Honeynet authors described the canonical signature plainly: a domain whose A-record set turns over rapidly, drawn from a large pool of dissimilar IPs, served with a TTL low enough to defeat caching.

A real single-flux answer looks wrong to anyone who knows what a normal one looks like. Five A records for a small-business-looking domain, sitting in five different autonomous systems, three different countries, on residential broadband ranges that have no business hosting a public web service. Query again a few minutes later and three of the five have changed. The 2025 Bitsight study of one fast-flux operation tracked 2,960 unique IPs behind a set of 193 domains over 2024, with 82 percent of those IPs concentrated in ten countries and an average of around 151 distinct addresses seen per domain across the measurement window. Mexico alone supplied 831 of them. That is the shape: enormous IP churn, residential geography, and a striking ASN spread for what claims to be one small service.

What single flux does not hide is the name server. The NS record points somewhere fixed, and that fixed point is a weakness. Sinkhole or seize the authoritative name server and every domain it serves stops resolving, pool or no pool. Which is exactly the gap double flux closes.

Double flux: rotate the name servers too

Double flux applies the same rotation one level up, to the NS records. The fluxing domain’s authoritative name servers are themselves a rotating set of compromised hosts, also served with short TTLs. Now there is no fixed point at the DNS layer. Resolving the domain means first resolving its name servers (which change), then querying one of those name servers for the A records (which also change). Both layers ride on the same disposable bot population.

The term for the hidden back-end is the mothership, from the original Honeynet write-up. The redirector bots run blind proxy redirection: they accept the victim’s HTTP or DNS traffic and forward it upstream without any of the bots knowing where the mothership is or holding any content themselves. The Honeynet authors described control nodes that could push configuration to thousands of flux agents, switching the active redirect target on the fly. So even a captured bot tells an investigator very little. It has an upstream address that is itself probably another proxy, and it holds none of the phishing pages or malware it was serving. Take down any agent and the network routes around it. That property, resilience against the takedown of any single node, is the whole point of the design.

Double flux is rarer than single flux because it is more work to run and easier to spot once you know the signal. A domain whose NS records have a sub-ten-minute TTL and point at residential IP space is doing something no legitimate operator does. Authoritative name servers are supposed to be stable infrastructure. Watching them flicker is close to a confession.

A short history: Storm, Avalanche, and SAC 025

Fast flux did not arrive as a research curiosity. It arrived attached to the largest spam and phishing operations of the late 2000s, which is why the early documentation reads less like a paper and more like an incident report. The Rock Phish gang, active from around 2004, ran what looked in retrospect like proto-flux hosting for banking phishing pages. The technique reached its first mature form with the Storm Worm in 2007, the same year the Honeynet authors wrote it up, and Storm is the case study that made the name stick. Storm’s operators ran a peer-to-peer botnet whose infected machines doubled as the flux agents serving the spam and malware domains, so the same compromised population provided both the distribution and the hosting. Taking down a Storm domain meant chasing an address set that refreshed every few minutes across machines on every continent.

The regulator noticed quickly. In January 2008 ICANN’s Security and Stability Advisory Committee published SAC 025, an advisory on fast flux hosting and the DNS, which is one of the earliest formal acknowledgements that the naming system itself was being turned into an evasion layer. SAC 025 wrestled with a problem that has not gone away: the same low-TTL, multi-IP behaviour that defines fast flux is also legitimate operation for round-robin DNS and content delivery, so any registry-level countermeasure risks collateral damage to lawful operators. The committee stopped short of recommending a blanket technical fix for exactly that reason, and the difficulty it named in 2008 is the same difficulty the 2025 advisory navigates with layered scoring rather than hard rules.

The largest takedown in this lineage was Avalanche, a fast-flux hosting platform that served dozens of malware families and phishing campaigns for years before an international operation dismantled it in late 2016. Avalanche is the clearest illustration of fast flux as a platform rather than a single crew’s tool. It rented its double-flux infrastructure to whoever paid, which is the same business model the 2025 reporting describes in the bulletproof-hosting market, just earlier and at larger scale. The seizure required pre-registering and sinkholing an enormous set of domains across many registries simultaneously, because anything less would have let the operation route around the blocked names. That is the practical cost of the architecture: you cannot kill it one node at a time, so you have to coordinate a takedown that hits every layer at once.

What an investigator actually sees

Put the abstractions aside and look at the artefacts. An analyst handed a suspicious domain runs the lookups and reads the answer the way the flux-score reads it. The first thing that stands out is the TTL: a value in the low hundreds of seconds where a normal small site would have something between an hour and a day. The second is the A-record set, which is larger than a small site needs and, when reverse-resolved, lands on hostnames that look like consumer broadband. PTR records ending in the naming patterns ISPs use for dynamic residential pools, things that read like a customer line rather than a data-centre allocation. The third is the geography. Plotting the IPs in a single answer puts them in different countries, and plotting their ASNs puts them in unrelated networks that share no operator.

The reason no single one of these is enough is the CDN problem again. A real CDN has a low TTL and many IPs. A busy round-robin setup has several A records. A cloud-hosted service might span a couple of regions. What none of them has is the full stack of signals at once: low TTL and large churning IP set and broad ASN spread and residential reverse-DNS naming and geographic scatter, all on a domain that also turns up in a phishing feed. Each feature on its own produces false positives. The combination is what the flux-score and its descendants exploit, and it is why mature detection scores a domain across many features and over a time window rather than blocking on the first short TTL it sees. The same caution applies to anyone defending against the technique downstream, where the phishing kits served off a flux network add their own cloaking on top, so a scanner that resolves a flux domain may still be shown a benign decoy page.

There is one more artefact worth naming, because it ties the DNS layer to the proxy layer. Connect to two different IPs from the same flux answer and you often get byte-for-byte identical responses, because both bots are blind-relaying to the same mothership. That sameness is itself a signal. Legitimate load-balanced backends drift; they run different patch levels, return slightly different headers, sit in different time zones. A flux pool’s nodes are dumb pipes to one origin, so the content they serve is uniform even though the IPs serving it are scattered across the planet. An investigator who sees identical phishing pages from a Mexican broadband IP and a Moroccan one, both with sub-minute TTLs, is looking at a single origin wearing a thousand masks.

The detection math: flux-score and what it measures

The first rigorous detector came from Thorsten Holz, Christian Gorecki, Konrad Rieck, and Felix Freiling in Measuring and Detecting Fast-Flux Service Networks, presented at NDSS 2008 from measurements taken over two months in mid-2007. Their insight was that you do not need to watch a domain for hours to classify it. A couple of DNS lookups expose the structural properties that fast flux cannot avoid having.

They reduced a domain to three numbers from its DNS answers: the number of unique A records returned across the lookups (nA), the number of distinct autonomous systems those IPs belong to (nASN), and the number of distinct name-server records (nNS). Run the lookups, count, and feed the vector to a linear classifier. Training on 128 manually verified fast-flux domains and 5,803 benign ones, they fit a weight vector and a bias and got this flux-score:

1
f(x) = 1.32 · nA  +  18.54 · nASN  +  0 · nNS

A domain scores above the threshold when its flux-score exceeds the bias term; higher scores mean more fast-flux character. Two things stand out in those weights. The name-server count drops out entirely, weight zero, because in single flux the NS record is stable and carries no signal. And the ASN count is weighted roughly fourteen times more heavily than the raw IP count. That is the load-bearing observation of the whole paper. Many IPs is not damning on its own; a busy site can return many IPs. Many IPs spread across many unrelated autonomous systems is the tell, because it means the addresses come from a scattered population of compromised consumer machines on dozens of different ISPs rather than from one operator’s address space. The reported model hit 99.98 percent average accuracy under ten-fold cross-validation, with almost no false positives on the benign set.

Later detectors broadened the feature set. Production systems and academic follow-ups added the spread of reverse-DNS naming, the fraction of IPs on known residential or dial-up ranges, the geographic distance between IPs in a single answer, processor-architecture and uptime mismatches across the pool, and time-windowed behaviour rather than a single snapshot. The 2010 work on real-time fast-flux bot detection and a long line of passive-DNS data-mining papers pushed accuracy and lowered the lookup count further. But the Holz vector is still the clearest statement of the core idea, and the reason it has aged well is that the two signals it keeps, IP count and ASN spread, are properties an attacker cannot shed without giving up the resilience that made them choose fast flux in the first place.

Why this keeps colliding with CDNs

The honest difficulty in detecting fast flux is that legitimate infrastructure looks similar at a glance. Round-robin DNS returns multiple A records by design. Content delivery networks return different IPs to different clients, use short TTLs deliberately so they can steer traffic, and operate globally distributed servers. Holz’s paper opens by drawing exactly this contrast: a CDN like Akamai computes the nearest edge server and hands back a low-TTL answer that changes over time, which is, at the level of a single dig, not obviously different from a flux domain.

The flux-score separates them on the ASN axis. A CDN’s many IPs sit inside a small number of autonomous systems that the CDN operator controls. Cloudflare’s addresses are Cloudflare’s ASNs; Akamai’s are Akamai’s. The nASN term stays low, the score stays under the threshold. A fast-flux pool’s IPs are scattered across the autonomous systems of dozens of unrelated residential ISPs, because each IP is a different victim’s home connection. That is a structural difference, not a cosmetic one, and it is hard to fake. To mimic a CDN’s tight ASN footprint, an attacker would have to source their pool from a handful of networks, which reintroduces exactly the single points of failure they used fast flux to avoid.

The collision still bites in practice. The Holz authors themselves flagged that the weights and threshold need periodic retuning because attackers can try to mimic CDN behaviour, for instance by sorting and grouping IP addresses to look more concentrated. Anything that blocks on DNS churn alone risks taking out a legitimate CDN customer or a busy round-robin setup. This is the reason the 2025 advisory leans on layered scoring and reputation rather than a single hard rule, and the reason protective-DNS vendors pair the structural signals with curated threat intelligence instead of trusting the math by itself. The detection is good. It is not so good that you want it firing an automatic block on a borderline score.

What the 2025 CISA advisory adds

On April 3, 2025, CISA, the NSA, and the FBI, joined by the Australian Signals Directorate’s ACSC, the Canadian Centre for Cyber Security, and New Zealand’s NCSC-NZ, published the joint advisory Fast Flux: A National Security Threat (AA25-093A). The technique was eighteen years old by then. What changed enough to warrant six national agencies and the phrase “national security threat” was not the mechanism but its adoption, and a recognition that defensive coverage had a hole in it.

The advisory’s argument is that fast flux is now a gap in network defences, used both by ordinary cybercriminals and by state-linked actors, and that many protective-DNS services and providers were not reliably detecting or blocking it. It names real users of the technique. The Russia-linked espionage group Gamaredon has been observed rotating the IPs behind its domains daily to frustrate IP-based blocking. The phishing operation tracked as CryptoChameleon has leaned on fast flux. The widely-distributed Raspberry Robin loader has used it across its C2 footprint. Earlier ransomware operations including Hive and Nefilim are cited as having used fast flux as well. The common thread is that the technique is no longer exotic. It is a service you can rent.

That last part is the economic shift the advisory and the parallel 2025 vendor research surface most clearly. Fast flux has moved into the bulletproof-hosting market as a product. Bitsight’s 2025 reporting noted bulletproof hosts advertising fast flux as a paid feature, with pricing in the low hundreds of dollars per domain per month. When an evasion technique becomes a line item on a hosting invoice, its prevalence stops tracking the sophistication of individual crews and starts tracking the size of the criminal hosting economy. That is the change that made a 2007 technique worth a 2025 advisory.

On defence, the advisory recommends a layered approach rather than any single trick. Resolvers and security teams should log and analyse DNS query and response data looking for the structural anomalies the research identified: abnormally low TTLs, high IP churn for a single name, A-record sets spread across many ASNs and many countries, and inconsistencies between an IP’s geolocation and the domain’s claimed identity. It calls for correlating that DNS-layer signal with phishing and malware telemetry so a churning domain that also shows up in a phishing campaign is scored higher than churn alone. It pushes reputation-based filtering, sinkholing of identified fast-flux domains, and information sharing across providers. And it puts particular weight on protective DNS, the model where a recursive resolver checks each lookup against threat intelligence and refuses to resolve known-malicious names before any connection is attempted. The advisory’s pointed criticism is that PDNS providers should be doing this for fast flux specifically, and that the ones not blocking it are leaving the gap open.

None of these mitigations is novel on its own. Low-TTL and IP-churn analysis is the Honeynet observation from 2007; ASN-spread scoring is the Holz contribution from 2008; protective DNS is a decade-old product category. The advisory’s contribution is to assemble them into a baseline expectation and to put the authority of six governments behind the claim that not implementing them is now a national-security-relevant failure.

The asymmetry that keeps it alive

Fast flux endures because the cost structure favours the attacker at every layer. The bots are free, stolen from people who do not know their router is a proxy. The DNS rotation is a configuration choice that costs nothing. The mothership stays hidden behind layers of blind relays, so even a successful seizure of visible infrastructure yields a disposable node and no content. Defenders, meanwhile, have to run continuous DNS analytics, maintain reputation feeds, accept some false-positive risk against legitimate CDNs, and coordinate across providers to make blocking stick. The detection has been solved, in the narrow sense that a two-lookup flux-score has classified these domains at better than 99 percent accuracy since 2008. Deploying that detection everywhere it needs to run, at every recursive resolver on the internet, has not been solved, and that deployment gap is what the 2025 advisory is really about.

The technique has also outlived several of its own obituaries. Each time tracking improved, the answer was not a cleverer evasion but a move into the hosting market, where fast flux is now sold the way a CDN is sold, as a resilience feature for whatever you are hosting. The structural signal that gives it away has not changed in eighteen years, because it cannot: a service whose addresses are scattered across the autonomous systems of dozens of residential ISPs is, by construction, running on other people’s machines. You can rotate the records as fast as you like. The ASNs still tell on you.

Sources & further reading

• CISA, NSA, FBI, ASD’s ACSC, CCCS, NCSC-NZ (2025), Fast Flux: A National Security Threat (AA25-093A) — the April 2025 joint advisory naming fast flux a defensive gap and recommending layered, protective-DNS-centred mitigation.
• CISA (2025), NSA, CISA, FBI and International Partners Release Cybersecurity Advisory on “Fast Flux” — the launch alert summarising the advisory’s scope and partner agencies.
• Holz, Gorecki, Rieck, Freiling (2008), Measuring and Detecting Fast-Flux Service Networks — NDSS paper deriving the flux-score f(x) = 1.32·nA + 18.54·nASN + 0·nNS and the ASN-diversity insight.
• The Honeynet Project, Salusky and Danford (2007), Know Your Enemy: Fast-Flux Service Networks — the original write-up describing single and double flux, the mothership, and blind proxy redirection.
• Bitsight TRACE (2025), Fast Flux DNS: An Investigative 2025 Report — measurement of a live fast-flux operation, with IP counts, country concentration, and bulletproof-hosting pricing.
• The Hacker News (2025), CISA and FBI Warn Fast Flux Is Powering Resilient Malware, C2, and Phishing Networks — coverage detailing the named actors Gamaredon, CryptoChameleon, and Raspberry Robin.
• The Register (2025), CISA, FBI, nations warn of fast flux DNS threat — independent reporting on the advisory and the international partners behind it.
• OpenText Cybersecurity (2025), Fast flux: the evasive DNS tactic now considered a national security threat — vendor analysis of the advisory’s protective-DNS recommendation and low-TTL / high-churn signals.
• AhnLab ASEC (2024), Fast Flux Technique for Concealing Command and Control and Evading Detection — a reverse-proxy view of how flux agents shield the C2 server from blacklisting.
• Europol (2016), “Avalanche” network dismantled in international cyber operation — the November 2016 takedown of a double-fast-flux hosting platform, 800,000+ domains sinkholed across 30 countries.
• Wikipedia contributors, Fast flux — overview tying together the Honeynet origin, TTL ranges, the mothership architecture, and ICANN’s SAC 025 advisory of January 2008.