Chasing CnC Servers - Part 1

There are two general ways a complex problem can be solved, using a good approach or a bad one.  The only good thing about the bad approach is that it will usually be simpler to understand and implement, but in the long run one will find that shortcuts don't always work. The good thing with most humans is that they learn from their mistakes and move forward.  This is what we are seeing happen at the moment within the anti-malware industry.  Host based anti-virus products are shifting their focus from signature based detection to advanced behavioral analysis and memory forensics.  Network based sensors which used to rely heavily on DNS and IP black lists for detecting phishing attacks, SPAM emails and botnet command and controls are moving towards advanced protocol analysis and emulation.

The purpose of this series is to discuss limitations and challenges involved in using black lists (DNS & IP) for network based anomaly detections.  I will focus more on the problems of tracking botnets using their control server identities alone. I will also discuss if there are better techniques available to detect compromised (botted) machines and terminate CnC channels to prevent further damage.

Catch me if you can. Bot herders are well aware that their botnets can easily be identified and destroyed if they don't switch their CnC servers for an extended period of time. The shutdown of McColo crippled the world's largest spam botnets in one go because they were not moving their CnCs quickly. Today, bot herders have learnt their lesson, the average life span of a CnC domain is very short, sometimes not more than a few days. Hence the continuous effort to update your blacklist is a race condition in which the bad guys will always be one step ahead.

Here are some statistics from FireEye's Malware Analysis & Exchange (MAX) network, showing how quickly bot herders of the top botnets switch their command and control servers.

CnC servers found to be active during last 10 days.

These domains were discovered without prior knowledge and result from seeing huge traffic samples across many networks.  These CnCs quickly emerge and disappear.  Bot herders keep moving to the next CnC when they see the old ones on publicly available black lists.

Let's take another example. Zeus Tracker is a well known on-line resource which is dedicated to hunting Zeus command and control servers.

As of today high level statistics from Zeus Tracker are as follows:

• ZeuS C&C servers tracked: 1476
• ZeuS C&C servers on-line: 511

There are two things which are worth noticing here.  First the total number of CnCs known to Zeus tracker and the second thing is the number of off-line/dead command and controls i.e 1476 - 511 = 965. One can see that bot herders move quickly to new CnCs leaving the old ones as orphans. That's the main reason that, despite the exceptional effort being put by the community behind Zeus tracker, Zbot is still one of the most widespread families of malware. 

Similar challenges are involved when it comes to detecting spam, exploit and phishing attacks using the domains or servers involved.  This can be proved by seeing the growing size of IP and DNS lists offered by reputable sources like spamhaus and malwaredomains.  We know that despite these black lists, every day our mailboxes are cluttered with junk emails and drive by attacks are on the rise like never before.

Before I wrap up this post. I would like to briefly describe some of the alternatives.

Shoot at first sight

Post infection anomaly detection/prevention is very important but should only be considered as a last resort. The theory that an inbound infection cannot be stopped and stopping the outbound communication can prevent all the damage is just like saying don't build walls around your house, instead be ready for a fight. For instance, the best way to kill SPAM is by stopping SPAM botnets infecting systems and so on.

I will dedicate a complete post on the effectiveness of stopping inbound infections and how it can be combined with post infection malware detection (like using CnC communication) and prevention to build multiple lines of defense.

Say 'Yes' to CnC communication structure

It's common sense that when it comes to malware detection, one should rely on attributes which are less likely to change over time.  CnC communication structure and a bot's network behavior should be a preferred detection method over chasing specific CnC coordinates.  Very much like modern AVs which are preferring behavior analysis over static binary signatures.

Today I discussed ineffectiveness of anomaly (especially botnet) detection based on chasing ever changing command and control servers. But this is not the only issue with this approach. High false alarms (false +ves) are expected as well. I will discuss it in detail in my next post.

Atif Mushtaq @ FireEye Malware Intelligence Lab

Detailed Questions/Comments : research SHIFT-2 fireeye DOT COM