Fast Flux is Back! Luckily, You Can Detect and Neutralize It.
In case you missed it, Fast flux is back. This time it’s in the newest variant of the infamous Gameover ZeuS botnet, which has apparently been revived following a massive international takedown in early June this year.
In case you’ve forgotten, Fast flux is a veteran technique used by botnet operators to hide malware and phishing sites by rapidly changing DNS records. Under this method, a fully-qualified domain name will have hundreds or even thousands of IP addresses associated with it. These addresses are swapped using a simple Round Robin methodology and given very short Time-to-Live (TTL). This enables a given DNS Resource Record to be associated with a new IP address as frequently as every three minutes.
Fast flux has long been used by hackers to communicate with their botnets, to hide the origin of their attacks (their “mothership”), and to conceal the IP addresses from which they operate.
The bad news is that Fast flux has been in use so long because it truly is highly-resilient.
The good news is that it is this very familiarity, which carries with it a distinctive footprint, making Fast flux vulnerable to detection in enterprise networks.
How to Detect Fast Flux in Real-Time in Your Network
Finding Fast flux activity in your network is really a needle-in-a-haystack situation. It’s a real challenge. But it can be done, and with a minimum of false positives.
Usually botnet’s utilizing Fast flux service networks have other behaviors that can be detected, such as sending out spam, exhausting CPU cycles crypto mining and participating in DDOS etc. These are excellent behaviors to build sensors around, however, in this post we will focus on the C&C channel alone.
Here’s how we did it at LightCyber
The Scenario: Our research was run on one of our customer’s networks which has 5,043 hosts, of which 3,471 are workstations.
The Challenge: In the entire network we saw, on average, access to 1,257 new domains daily. One or more of these domains was hiding Fast flux activity. For our filter to be effective for our network, we defined a maximum rate of one false positive per week. This may seem like a very high benchmark but this is the quality we aspire to at LightCyber. In this particular scenario this translates to 7*1,257 (8,799) new domains.
The System: Our aim was to build a filter to weed out suspicious activity and find the Fast flux domain.
Looking at this statistical problem, we needed to find ways to distinguish malicious domains (those that are associated with Fast flux service networks) from benign domains.
1. Domains accessed multiple times – It’s also a given that malicious accesses will be repetitive, at least to some extent. This enables us to eliminate the majority of previously-unseen domains, which are statistically visited only once.
2. Low TTL – For Fast flux networks to be effective, they need to be specifically able to cope with agents that are turned on and off. Thus, they need to create A records with very low TTL. Typical TTLs of Fast flux service networks are lower than 300 seconds (5 minutes).
3. Distinct number of A records – As the A records (the association of a domain name with an IP address) represent agents belonging to agents, we expected a very high number of distinct A records associated with each malicious domain.
4. Rapid change of A records (RRset) – Comparing the A records in the RRset between DNS responses, we expected to see a big difference – whereas for benign domains, the change doesn’t occur as rapidly.
The above would have given us enough to initially differentiate between the benign domain population and the potentially malicious domain population, but this wasn’t enough to reach the benchmark of one false positive per week. This is because there were still quite a few benign domains that passed all the above tests – leading us to extraneous and resource-sapping false positives. A good example would be network hosts that access CDN (content distribution networks), ad networks, load-balancing, etc. We knew we could do even better!
Fortunately, with a little more sophistication we achieved our desired degree of accuracy by adding some more filters:
5. Popularity – Assuming that hosts infected with a specific strain of malware represent the minority of the host population within the network, we expected malicious domains to be looked up by a small percentage of the network during the tested time frame. This is especially useful at this stage, since CDN and ad networks tend to be popular among peers in the same organization.
6. Homogeneity of IPs associated with the domain – Malicious Fast flux service networks are randomly scattered around the world. This is very different than benign networks used for load-balancing, content distribution, and the like. For the latter, the IPs associated with the domain are far from randomly picked. They tend to belong to one or a small set of networks or ASNs (Autonomous System Networks), which may even point to the same company. We expected the entropy of these sets in regard to malicious domains to be exceptionally high.
Combining all of these filters, we achieved our desired level of accuracy – identifying Fast flux activity while keeping false positives to a bare minimum.