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.