With the assumption that readers have read Part 1 of this topic, this article will contain the other part of this article, i.e. what benefits an attacker gets from flux networks, why it is difficult to detect flux networks in your environments, and recommended ways to detect a fast flux network.

How is Flux Advantageous for an Attacker?

The fast flux attack is a simple attack to conduct with high returns. Below are some of the advantages that fast flux networks, because of their design, offer to attackers:

  • Limited Audit Trails: Since a flux network provides proxy redirection layer front-end nodes, the design offers a layer of protection for any investigation to take place. Even when backtracking, investigations will only yield a handful of IPs relative to frond end nodes of a fast flux network.
  • Ease of operation: Attack buildup, because of its simple design, requires only one main node to host and serve DNS information. URLs point to front end proxy redirectors, which then transparently redirect client connection requests to the actual malicious back end server or servers. Because of this, now only a few servers are required to host malware sites.
  • Support for main nodes: because of the design, fast flux service networks extend the operational lifespan of the critical backend core servers that are hidden by the front-end nodes. Since a protection layer is put forward in the main node, it will take much longer to identify and shut down these core backend servers due to the multiple layers of redirection.

Why is Detection of Fast Flux Difficult?

Detecting a fast flux network from a legitimate server network is like separating milk from water, as fast flux networks are very difficult to detect and shut down. Consider the following:

  • For single flux networks, the only change in IP address is that of the target site. Fast flux service networks usually have several thousand A records for the same domain name. The TTL value for every A record is much less, thereby prompting DNS resolvers to query in short succession. This seems simple to detect by examining rapidly changing DNS records, but various load balancers today provide this kind of configuration in order to serve the client request fast. 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 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.
  • For double flux, both the NS Records as well as the A records change rapidly. The NS servers are a list of compromised machines having a back-end control to the attacker, thus they provide extra layer of protection for attacker to work without detection. Detecting double flux is twice as difficult as detecting single flux.

How to Detect Fast Flux

Having said that, and with techniques still being researched today, below are some of the suggested techniques to detect fast flux networks. It should be noted that entities that are covered for detection of fast flux networks covers ISP, domain registrars, service providers, etc.

  • Analyzing of TTLs with the result sets per domain from multiple successive TTL expiration periods can work in identifying the use of fast flux service networks.
  • ISPs should set up policies to block access to controller infrastructure and must enable blocking of port TCP 80 and UDP 53 into user land networks.
  • ISPs should create awareness among the linked up service providers about the threat, shared processes, etc.
  • ISPs should proactively identify and shutdown flux networks using BG route injection.
  • Domain registrars should do a proper auditing and fine tune the response procedures in order to identify any domain registration for any fraudulent purposes.
  • Service providers must start logging DNS queries in the network. The scope can be lessened to only outbound DNS queries, and a proper monitoring team should be active 24/7 for analyzing the DNS queries. Some events to look out for, as discussed earlier, events that return A records with a TTL value of less than 1800 seconds. Teams should also ensure that enough information is getting received in the logs, such as domain name, A records, and NS records, for proper analysis.
  • The security team can also map the IP address related to DNS query response with a TTL of less than 1800 seconds with ASN records, as correlating with ASN records can effectively filter out false positives for fast flux.
  • Cross-validation with Internet blacklists, spam lists, bot lists, etc, will make identification more effective.