Know Your Enemy:
Fast-Flux Service Networks

An Ever Changing Enemy

The Honeynet Project & Research Alliance

Last Modified: 13 July, 2007


One of the most active threats we face today on the Internet is cyber-crime.  Increasingly capable criminals are constantly developing more sophisticated means of profiting from online criminal activity.  This paper demonstrates a growing, sophisticated technique called fast-flux service networks which we are seeing increasingly used in the wild.  Fast-flux service networks are a network of compromised computer systems with public DNS records that are constantly changing, in some cases every few minutes.  These constantly changing architectures make it much more difficult to track down criminal activities and shut down their operations.   

In this paper we will first provide an overview of what fast-flux service networks are, how they operate, and how the criminal community is leveraging them, including two types which we have designated as single-flux and double-flux service networks.  We then provide several examples of fast-flux service networks recently observed in the wild,. Next we detail how fast-flux service network malware operates and present the results of research where a honeypot was purposely infected with a fast-flux agent.  Finally we cover how to detect, identify, and mitigate fast-flux service networks, primarily in large networking environments.  At the end we supply five appendixes providing additional information for those interested in digging into more technical detail. 


The goal of fast-flux is for a fully qualified domain name (such as to have multiple (hundreds or even thousands) IP addresses assigned to it.  These IP addresses are swapped in and out of flux with extreme frequency, using a combination of round-robin IP addresses and a very short Time-To-Live (TTL) for any given particular DNS Resource Record (RR). Website hostnames may be associated with a new set of IP addresses as often as every 3 minutes.  A browser connecting to the same website every 3 minutes would actually be connecting to a different infected computer each time.  In addition, the attackers ensure that the compromised systems they are using to host their scams have the best possible bandwidth and service availability. They often use a load-distribution scheme which takes into account node health-check results, so that unresponsive nodes are taken out of flux and content availability is always maintained.  

A second layer is often added for security and fail-over: blind proxy redirection.  Redirection disrupts attempts to track down and mitigate fast-flux service network nodes.  What happens is the large pool of rotating IP addresses are not the final destination of the request for the content (or other network service). Instead, compromised front end systems are merely deployed as redirectors that funnel requests and data to and from other backend servers, which actually serve the content. Essentially the domain names and URLs for advertised content no longer resolve to the IP address of a specific server, but instead fluctuate amongst many front end redirectors or proxies, which then in turn forward content to another group of backend servers. While this technique has been used for some time in the world of legitimate webserver operations, for the purpose of maintaining high availability and spreading load, in this case it is evidence of the technological evolution of criminal computer networks.  

Fast-flux “motherships” are the controlling element behind fast-flux service networks, and are similar to the command and control (C&C) systems found in conventional botnets.  However, compared to typical botnet IRC servers, fast-flux motherships have many more features. It is the upstream fast-flux mothership node, which is hidden by the front end fast-flux proxy network nodes, that actually delivers content back to the victim client who requests it. Flux-herder mothership nodes have been observed to operate successfully for extended periods of time in the wild. These nodes are often observed hosting both DNS and HTTP services, with web server virtual hosting configurations able to manage the content availability for thousands of domains simultaneously on a single host. Until late March 2007, we observed the appearance of only two primary upstream mothership hosts deployed and serving the many thousands of domains in flux, suggesting that this technique was primarily developed and utilized by small number of groups or individuals.  Domain registrations of .hk, and .info were found to be among the most heavily utilized TLDs for registering fast-flux domains, but this registration abuse is most certainly shared amongst all registrars (as occasionally .com and other TLD domains are also witnessed). 

We have categorized two different types of fast-flux networks, single-flux and double-flux. Everything you have read up to this point discusses single-flux networks.  Double-flux has an additional layer of protection by also constantly changing the IP addresses for the Authoritive Name Servers.  Below we give examples of each, starting with single-flux. 


In Figure 1 below we demonstrate a single-flux network.  We compare a normal web browser communicating directly with a typical website against the case of a single-flux service network, where the end user’s browser communication is proxied via a redirector (the ¨flux-bot¨ or ¨flux-agent¨). When a victim believes that they are browsing, their browser is actually communicating with the fast-flux service network redirector which redirects the requests to the target website. Single-flux service networks change the DNS records for their front end node IP address as often as every 3-10 minutes, so even if one flux-agent redirector node is shut down, many other infected redirector hosts are standing by and available to quickly take its place. We have found these fast-flux networks to be composed of primarily compromised home computers.

Fast-flux networks are responsible for many illegal practices, including online pharmacy shops, money mule recruitment sites, phishing websites, extreme/illegal adult content, malicious browser exploit websites, and the distribution of malware downloads. Beyond our regular observation of new DNS and HTTP services, other services such as SMTP, POP, and IMAP can be delivered via fast-flux service networks. Because fast-flux techniques utilize blind TCP and UDP redirects, any directional service protocol with a single target port would likely encounter few problems being served via a fast-flux service network. 


Double-flux networks are a more complex technique providing an additional layer of redundancy. Specifically, both the DNS A record sets and the authoritative NS records for a malicious domain are continually changed in a round robin manner and advertised into the fast-flux service network.  From our observations of double-flux networks active in the wild, DNS and HTTP services are both served from the same upstream mothership node. Figure 2 below demonstrates the difference between a single-flux service network and double-flux service network.  Please note that in the figure below that request caching is not taken into account and that the outbound request would usually emanate from the client's preferred nameserver instead of the client itself.

On the left-hand side, we depict a single-flux lookup: the client wants to resolve the address First, it asks the DNS root nameserver which name server is responsible for the top-level domain .com and receives an answer (omitted in the picture). In a second step, the client queries the .com nameserver for the domain and receives as an answer a referral to the nameserver Now the client can query the authoritative DNS server for the actual IP address of the address The authoritative nameserver answers with an IP address that the client can then attempt to initiate direct communication with. For a normal DNS lookup, the answer IP address usually remains constant over a certain period of time, whereas for single-flux nodes, the answer changes frequently.

At the right hand side, we depict a DNS lookup for an address within a double-flux domain. Again, the client wants to look up the address Once again, the first step (lookup at root nameserver) is omitted for sake of brevity. Next, the client queries the nameserver responsible for the top-level domain .com for the authoritative nameserver for the domain In a third step, the client then queries the authoritative DNS server for the address However, this authoritative nameserver is actually part of the double-flux scheme itself and its own IP address changes frequently. When a DNS request for is received from the client, the current authoritative nameserver forwards the queries to the mothership node for the required information. The client can them attempt to initiate direct communication with the target system (although this target system will itself be a dynamically changing front end flux-agent node).


¨Traditional¨ cyber-crime activities such as phishing typically require an attacker to compromise one or more victim computer systems (either individually or via mass auto-rooters) and establish a fake or fraudulent web site. Content would then be advertised to victims either by mass emailing or more targeted marketing (spear phishing), often through other compromised computer systems and botnets. The computer systems hosting the malicious content would be identified either by public DNS name or directly by IP address embedded within the email lure messages.  These types of scams are identified relatively quickly by security professionals and can be quickly shut down. As the average time of survival was reduced for these phishing websites, criminals began to add additional layers of protection, such as server address obfuscation or utilize groups of proxy servers to redirect network. Such systems are limited in scale and can still be tracked down fairly quickly with international co-operation. We are now seeing the next evolutionary step, the fast-flux network. In the end, it’s all about Return on Investment (ROI) for the criminals, and fast-flux service networks provide a reliable way to maximize the returns on their criminal activities for relatively low effort.  Fast-flux service networks offer three major advantages to operators of Internet based criminal activity.  

The first advantage is found in both legitimate and criminal operations: simplicity.  Only one suitably powerful backend server (or mothership) host is needed to serve the master content and DNS information.  The published URLs (such as via phishing lures) point to front end proxy redirectors, which then transparently redirect client connection requests to the actual malicious back end server or servers. This makes the content delivery infrastructure much simpler for criminals to manage.  Instead of having to build (or compromise) and maintain many servers to host their phishing or malicious websites, they now require only a small number of well managed core systems to host their scam sites and malware, whilst other attackers can specialize in building and operating reliable fast-flux service networks to deliver their malicious content.  

The second advantage is that front-end nodes are disposable criminal assets that can offer a layer of protection from ongoing investigative response or legal action.  When a security professional is responding to an incident and attempts to track down a malicious website hosted via a fast-flux service network, they typically recover only a handful of IP addresses corresponding to disposable front-end nodes which may be spread across multiple jurisdictions, continents, regional languages and time zones, which further complicates the investigation.  Because of the proxy redirection layer, an electronic crimes investigator or incident responder will often find no local evidence of the hosting of malicious content on compromised front end systems, and traffic logging is usually disabled so audit trails are also limited. 

Thirdly, fast-flux service networks extend the operational lifespan of the critical backend core servers that are hidden by the front-end nodes. It can take much longer to identify and shut down these core backend servers due to the multiple layers of redirection – particularly if these nodes are hosted in territories with lax laws and criminal-friendly ‘bullet-proof’ hosting services. Very few operational changes have been observed in live backend servers during the extensive monitoring of fast-flux service network cores, which is a testament to the success of this operational model. 


Having explained the underlying principles, we will now look at a fast-flux service network from the point of view of a criminal and review the basic steps required to setup a fast-flux service network. First, our criminal(s) registers a domain for their attack.  An example would be a bogus domain name that appears similar to a bank, or a site promoting pharmaceutical drugs.  In our case, we will use’.  Based on our research, the domain extensions .info and .hk are some of the most commonly abused Top Level Domains (TLD’s). This is may be due to the fact that resellers for these domain registrars are more lax in their controls than other TLDs.  Often these false domains are registered by fraudulent means, such as using stolen credit cards and bogus or otherwise invalid registrant account detail. The criminal(s) will often already have control of a network of compromised systems to act as their redirectors, or they can temporarily rent a botnet.  In addition, registrations for the domains are often the cheapest.   The criminal(s) then publish Name Server (NS) records that either point to bullet-proof hosting, or at any of the proxy/redirects flux-agent nodes under their control.  Examples of bullet-proof hosting providers could include DNS services operated from Russia, China, or many other countries around the world.  If the criminals do not have access to this type of hardened service, they will host the DNS services on their own compromised systems, and often the mothership node that is hosting the master web sites can also be found serving DNS services.   We will now review two actual deployments. 

Single-Flux: A Money Mule
First we will review the DNS records for a single-flux service network.  This is a real world example demonstrating a money mule recruitment scam.  A money mule is someone that acts as an intermediary in transferring or withdrawing money often involved in fraud.  For example, a criminal will steal money out of someone’s bank account, transfer it to the money mule’s bank account, then have the money mule withdraw the funds and send them to a location for pickup, perhaps in a different country.   What is unique about some current money mule scams is that the money mule may think they are working for a legitimate company, not realizing they are acting on the behalf of criminals in money laundering schemes.  Often the money mule is actually just another victim in a chain of other victims.  

Below are the single-flux DNS records typical of such an infrastructure. The tables show DNS snapshots of the domain name taken approximately every 30 minutes, with the five A records returned round-robin showing clear infiltration into home/business dialup and broadband networks.  Notice that the NS records do not change, but some of the A records do.  This is the money mule web site.  

 ;; WHEN: Sat Feb 3 20:08:08 2007 1800 IN A [] 1800 IN A [SBIS-AS - AT&T Internet Services] 1800 IN A [] 1800 IN A [] 1800 IN A [] 1800 IN NS 1800 IN NS  87169 IN A [HVC-AS - HIVELOCITY VENTURES CORP]  87177 IN A []

Single-flux nets appear to apply some form of logic in deciding  which of their available IP addresses will be advertised in the next set of responses.  This may be based on ongoing connection quality monitoring (and perhaps a load-balancing algorithm).  New flux-agent IP addresses are inserted into the fast-flux service network to replace nodes with poor performance, being subject to mitigation or otherwise offline nodes. Now let’s take a look at the DNS records of the same domain name 30 minutes later and see what has changed: 

 ;; WHEN: Sat Feb 3 20:40:04 2007 (~30 minutes/1800 seconds later) 1800 IN A [] NEW 1800 IN A [] NEW 1800 IN A [] 1800 IN A [] 1800 IN A [] 1800 IN NS 1800 IN NS  85248 IN A [HVC-AS - HIVELOCITY VENTURES CORP]  82991 IN A []

As we see, highlighted in bold two of the advertised IP addresses have changed. Again, these two IP addresses belong to dial-up or broadband networks. Another 30 minutes later, a lookup of the domain returns the following information: 

 ;; WHEN: Sat Feb 3 21:10:07 2007 (~30 minutes/1800 seconds later) 1238 IN A [] NEW 1238 IN A [SBIS-AS - AT&T Internet Services] This one came back! 1238 IN A [] NEW 1238 IN A [] NEW 1238 IN A [CNT Autonomous System] NEW 1238 IN NS 1238 IN NS  83446 IN A [HVC-AS - HIVELOCITY VENTURES CORP]  81189 IN A []

Now, we observe four new IP addresses and one IP address that we saw in the first query. This demonstrates the round-robin address response mechanism used in fast-flux networks. As we have seen in this example, the A records for the domain are constantly changing.  Each one of these systems represents a compromised host acting as a redirector, a redirector that eventually points to the money mule web site.  A significant response issue is that the incident responders do not know the ultimate destination of the money mule site unless they have access to one of the redirector nodes.  This creates a far more dynamic and robust environment for the criminals.  Next we will consider double-flux networks, where criminals add an additional layer of complexity to improve their security. 

Double-Flux: MySpace
Double-flux is where both the NS records (authoritative name server for the domain) and A records (web serving host or hosts for the target) are regularly changed, making the fast-flux service network much more dynamic. For double-flux techniques to work, the domain registrar has to allow the domain administrator the ability to frequently change the NS information, which is not something that usually occurs in normal domain management.  

In the example below, we observe a phishing attack directed against the popular social networking web site MySpace. The attacker has created a bogus website called  This fake website appears visually to be the real MySpace web site, but instead harvests MySpace user authentication credentials from anyone who is tricked into logging in to the fake site.  To make it harder for security professionals to shut down the fake site, both the NS and A DNS records are constantly changing. Observing DNS activity in such incidents, it is very common to detect a consistent pattern of between five to ten A record in a set of round-robin responses, in addition to a five NS record round-robin response set for any double-flux domain. This signature is becoming the hallmark for identifying double-flux domains. In the table below, observe that these DNS records are constantly changing: 

 ;; WHEN: Wed Apr 4 18:47:50 2007 177 IN A [] 177 IN A [] 177 IN A [] 177 IN A [] 177 IN A [] 108877 IN NS 108877 IN NS 108877 IN NS 108877 IN NS 108877 IN NS IN A [] IN A [] 854 IN A [] 854 IN A [] 854 IN A []

About 4 minutes later, for the same domain, only the A records have changed.  Notice that the NS records have remained the same. 

  ;; WHEN: Wed Apr 4 18:51:56 2007 (~4 minutes/186 seconds later) 161 IN A [] NEW 161 IN A [] NEW 161 IN A [] NEW 161 IN A [] NEW 161 IN A [] NEW 108642 IN NS 108642 IN NS 108642 IN NS 108642 IN NS 108642 IN NS 608 IN A [] 608 IN A [] 608 IN A [] 608 IN A [] 608 IN A []

Checking again one and a half hours later, the NS records for this domain have migrated and five new NS records appear. Similar to the previous example, we see that the A and NS record are hosted at dial-up or broadband providers, indicating that these are compromised hosts used by an attacker for nefarious purposes: 

 ;; WHEN: Wed Apr 4 21:13:14 2007 (~90 minutes/4878 seconds later) 3596 IN A [] NEW 3596 IN A [] NEW 3596 IN A [] NEW 180 IN A [] NEW 3596 IN A [] NEW


Flux node agents share the most essential and basic capabilities of the traditional, but minimalist IRC-based bot in several ways: they regularly phone home to announce their continued availability, they check for updates, perform download operations, and allow for the execution of arbitrary commands on the local operating system by a remote attacker.  However, almost without exception, fast-flux Command and Control (C&C) activity observed in the wild thus far has been HTTP protocol based.   

The ability of Fast-flux agents to proxy or redirect TCP services appears to be an outgrowth from the redirect functions of legacy IRC bots that possess optional UDP proxy or redirect capabilities.  The bundling of these features enables a fast-flux service network to become a powerful criminal tool and helps to make the fast-flux service network operator less easily detectable.  The fast-flux front end nodes will either act on command or execute hard-coded instructions to redirect inbound traffic received on configured ports to a specifically chosen upstream fast-flux mothership node. Several fast-flux service network operations have been observed maintaining distributed nodes that act primarily in performing availability and connection quality tests of individual flux-agents within the fast-flux service network.  For an example of the development cycle of fast-flux malware, refer to Appendix A. For an example of the infection process for the malware, refer to Appendix B.  Below we summarize two commonly used malware that have adopted fast-flux capabilities. 

The networks based upon these malware variants have been erected to provide a robust platform for sending large volumes of unsolicited email (spam). They have been very successful in this goal and employ advanced techniques such as the constant automated creation of many malware variants to frustrate anti-virus signature creation. Infected machines download these updates on a regular schedule in order to increase the amount of time it takes for a system to be cleaned and taken offline. These updates must be hosted on websites, so if their public IP addresses remain static, the update sites can potentially be taken down fairly easily. Until recently, a strategy of auto-generating pseudo-random domain names which moved around was used to protect such download sites. Starting in May 2007, the criminal organization behind this spam business moved to a fast-flux service network model. This group is now hosting their DNS services and malware download sites via fast-flux service networks and appear to be enjoying continued success in their criminal endeavor.

The biggest competitor of the Warezov/Stration gang is perhaps the criminal organization operating a very large spam sending network based on the family of malware variants dubbed Storm/Peacomm/Peed. They employ a UDP-based P2P model for botnet command and control. This is a highly robust way to operate a large distributed network if the complexities of managing peer lists and minimizing latency can be overcome. They have also employed novel techniques to counter anti-spam solutions, such as generating image-based spam on the fly on the endpoints flux-agent nodes themselves, rather than simply relying on template based messaging. These images are randomized in ways which frustrate the OCR (object character recognition) technologies used in some anti-spam products and have been most commonly used to facilitate fraudulent pump and dump stock spam schemes. In June 2007 this group was observed attempting to modify their P2P network to support fast-flux style networking. This is a significant advance for spam-sending malware and requires further study. 


We have discussed several real world examples captured in the wild.  Now let’s take a closer, more detailed look at an incident.  In this case, we deliberately infected a honeypot system with a fast-flux agent.  The system was contained in a controlled Honeywall environment. The malware we used was called weby.exe and had the MD5 hash 70978572bc5c4fecb9d759611b27a762 . The binary was executed in a sandbox environment with a Honeywall gateway providing data control and data capture capabilities.  Post-infection analysis of the captured system and network data identified the following activity:  

  1. First, the system resolved the domain name  This is most likely a basic Internet connectivity check.  The malware component needs to first determine that it has access to the Internet and DNS is resolving.
  1. The malware binary then registers with its owner.  This is performed by connecting to a virtual web host with an HTTP GET request and a URL query string that contains information about the infected host.  This is not a Command and Control (C&C) channel, instead it is nothing more than an announcement to the malware administrator that another victim system has been successfully infected.   The HTTP GET request was submitted with the following form (query string named variable values are omitted). The complete HTTP GET request is shown in Appendix C, where we show a full example of a registration request by a flux-agent. &user= &status= &version= &build= &uptime= 

  1. The fast-flux registration server (mothership) response to the announcement/registration step is “Added Successfully!”  This we perceive to mean that the infected system has been successfully added to the fast-flux service network.  A new victim is standing by for malicious duty.
  1. The next step is for the infected system to obtain a configuration file by hourly polling of a settings file on a remote web server.  This is where the flux agent learns details including what ports to bind and where the mothership is located and which incoming traffic will be redirected upstream to the mothership.  In this case, the fast-flux agent submits a HTTP GET request to another virtual web host that only happens to share the same IP as used by the registration interface. 

    For which the server responds with what appears to be a consistent 197 byte binary/encoded configuration response.   We are still attempting to reverse engineer complete details of this session.   For full packet payload of the binary/encoded configuration response, please refer to Appendix D. 

  1. Finally the system downloads a suspiciously named DLL plugin_ddos.dll, whose naming might suggest to some that it is a denial of service component.  For more information on this session, refer to Appendix E.


To give you a better feel of the scope of fast-flux service networks and how many systems are typically involved, below we provide statistics about one specific fast-flux service network. This example was involved in delivery of a PharmaShop scam.  Key points include: 

We collected data from 03 February 2007 to 11 February 2007.   The domain itself was created January 02, 2007 at 15:11 and was terminated February 13, 2007 at 04:26 EST.  To gather our information we queried DNS every 2 minutes and then collected information on the IP addresses assigned to the domain name and how those IP addresses (A and NS records) changed over time. A total of 3,241 unique IP addresses were utilized in this fast-flux service net during the study. Of these unique IP addresses, 1,516 were advertised as Authoritative NS records. 2,844 were short lived TTL A record round robins used for HTTP proxy/redirect. 256 different Autonomous Systems (AS's) were represented in the infection base. 181 AS’s served fluxDNS, and 241 AS’s served fluxHTTP redirection.  This may be an indicator of provider policies regarding inbound blocking policies of either UDP 53 or TCP 80 into subscriber populations.   Below is a table highlighting the AS’s that had the most infected systems as part of the fast-flux service network. This example was chosen because it was monitored at the highest resolution (every 2 min). To date over 80,000 flux IPs have been logged so far with over 1.2 million unique mappings.  

      AS Breakdown for DNS Flux Networks 
      • Total#    AS#
      • 331          7132 (SBC/ATT)
      • 300         1668 (AOL)
      • 47            11427 (RR)
      • 40            33287
      • 35            11426
      • 28            3356
      • 27            33491
      • 27            20115
      • 25            7015
      • 25            13343
      AS Breakdown for HTTP Flux Networks 
      • Total#      AS#
      • 668            7132 (SBC/ATT)
      • 662            1668 (AOL)
      • 75               3356
      • 73               11427
      • 51               33287
      • 46              33491
      • 40              20115
      • 39              11426
      • 37              7015
      • 36              11351

      Your browser may not support display of this image. Your browser may not support display of this image.


Our goal is to not only to explain the threat of fast-flux service networks, but also offer advice on how to identity and mitigate them. We provide several suggestions that highlight potential steps that can be taken and provide a brief overview of possible mitigation strategies. However, this is not a complete overview, since this complex topic deserves a paper on its own.  

It can be very difficult to detect and shut down fast-flux service networks. The detection of domain names being served by a fast-flux service network depends upon multiple analytical passes over DNS query results, with increasing flux detection accuracy gained by employing a scoring mechanism to evaluate multiple relatively short lived DNS records, taking into account including the number of A records returned per query, the number of NS records returned, the diversity of unrelated networks represented and the presence of broadband or dialup networks in every result set. This concept of analyzing short TTLs with the associated scoring of result sets per domain or hostname from multiple successive TTL expiration periods can work in identifying the use of fast-flux service networks.   

First, service providers can detect upstream mothership nodes by probing any suspected flux-agent proxies in specific ways.  Assuming that the suspect flux-agent is in fact a proxy redirecting TCP port 80 or perhaps UDP port 53 traffic to some as of yet unknown host upstream, the use of any specially crafted request with an otherwise low probability of occurrence in the wild may enable egress/Internet bound IDS sensors to alert on network events that in turn identify the mothership. The basic idea is to send out probe packets and then observe them on their way from the flux-agent to the actual mothership. You will likely need to do additional heavy lifting to identify any other fast-flux service net infrastructure components that include the distributed health/availability/connection quality monitoring hosts, in addition to the phone-home and registration mechanisms.    

The following example demonstrates a flux mothership host discovery process which leverages IDS sensor deployments.  This is accomplished most simply through the use of a Base64 encoded text string, in this case it is “helloflux” which is then delivered through a flux agent as part of an HTTP request or DNS query.  We do this essentially to exercise the full network communications path using easily detectable strings. This can be accomplished with the following two steps for use with any flux agent reported by DNS monitoring of provable flux domains.  The following two Snort signatures trigger on HTTP and DNS communication that contains the Base64 encoded string “helloflux” (aGVsbG9mbHV4IAo). We set up these signatures on different IDS sensors across the network and then in a second step inject a message into the fast-flux service network. If one of the IDS sensors picks up the message, we can trace to which destination it is really sent by the flux-agent. 

alert tcp $HOME_NET 1024:5000 -> !$HOME_NET 80 (msg: "FluxHTTP_Upstream_DST"; flow: established,to_server; content:"aGVsbG9mbHV4IAo"; offset: 0; depth: 15; priority: 1; classtype:trojan-activity; sid: 5005111; rev: 1;) 

alert udp $HOME_NET 1024:65535 -> !$HOME_NET 53 (msg: "FluxDNS_Upstream_DST"; content: "|00 02 01 00 00 01|"; offset: 0; depth: 6; content:"aGVsbG9mbHV4IAo"; within: 20; priority: 1; classtype:trojan-activity; sid: 5005112; rev: 1;) 

The following simple shell scripts injects the Base64-encoded string “helloflux” (aGVsbG9mbHV4IAo) one for a HTTP request and then another for a DNS request. With the help of the Snort signatures from above, we can then trace the path of the strings through the network. 

$ echo ;
# Simple shell script to test
# suspected flux nodes on your managed networks
echo " aGVsbG9mbHV4IAo" | nc -w 1 ${1} 80
dig +time=1 @${1} 

If a service provider lacks IDS capability in the user space, yet has the capability to report on NetFlow, this mechanism can also be used to detect fast-flux service networks. This is not as good as the IDS-based detection method presented above, but looking for TCP 80 and/or UDP 53 into user IP space is a start. This kind of traffic should normally not occur and is thus a sign of a possible flux-agent.   The following listing provides some further ideas to stop this kind of threat. In brackets, we list which party could implement such mitigation policies: 

  1. Establish policies to enable blocking of TCP 80 and UDP 53 into user-land networks if possible (ISP)
  2. Block access to controller infrastructure (motherships, registration, and availability checkers) as they are discovered. (ISP)
  3. Improving domain registrar response procedures, and auditing new registrations for likely fraudulent purpose. (Registrar)
  4. Increase service provider awareness, foster understanding of the threat, shared processes and knowledge. (ISP)
  5. Blackhole DNS and BGP route injection to kill related motherships and management infrastructure. (ISP)
  6. Passive DNS harvesting/monitoring to identify A or NS records advertised into publicly routable user IP space. (ISPs, Registrars, Security professionals, ...)

This is just a very brief overview of how fast-flux service networks can be mitigated, and further research is required in this subject area. 


Fast-flux service networks demonstrate an evolutionary step for online crime operations.  Fast-flux service networks create robust, obfuscating service delivery infrastructures that make it difficult for system administrators and law enforcement agents to shut down active scams and identify the criminals operating them.  The robustness, obfuscation capabilities, scalability and increased availability of fast-flux service produce an increased Return on Investment (ROI) for the criminals who operate them. Just as in legitimate business, the Internet represents a huge economic business model for online crime, which unfortunately means that we can expect techniques such as fast-flux service networks to continue to evolve. Often emerging threats such as fast-flux service networks are a step ahead of security professionals, and it looks likely that this particular arms race will continue into the foreseeable future. 


A paper of this complexity requires the input and cooperation from many people and organizations.  In particular the Honeynet Project would like to thank the following people: 

  • The SANS Internet Storm Center
  • Multiple service provider networks
  • David Watson of the UK Honeynet Project (reviewer)
  • Thorsten Holz of the German Honeynet Project (reviewer)
  • Fyodor of the Honeynet Project (reviewer)
  • David Dittrich of the Honeynet Project (reviewer)
  • Jamie Riden of the UK Honeynet Project (reviewer)
  • Earl Sammons of the Honeynet Project (reviewer)
  • Georg Wicherski of the German Honeynet Project (reviewer)
  • Nico Fischbach of the French Honeynet Project (reviewer)
  • Christian Seifert of the NZ Honeynet Project (reviewer)
  • Christine Kilger (design artist)