Kraken Botnet Infiltration

Earlier this month a number of articles surfaced on the research and disagreements with regards to the size and classification of a large bot net named Kraken. At the front line of the debate was SecureWorks and Damballa.

Secureworks claims Kraken is actually Bobax and estimates the bot net to include over 185,000 compromised systems. Damballa disagrees stating that Kraken is an entirely new bot net with a size over twice as large as Storm. Semantics aside no one disagrees that Kraken/Bobax is among the largest of the known bot nets if not the largest.

Cody and I thought it would be interesting to examine Kraken with the specific goal of infiltrating the bot network. We started with a sample from Offensive Computing and working from there eventually concluded that we would indeed be able to infiltrate and take over increasingly larger portions of the Kraken bot net.

Cody did most of the manual labor of protocol dissection, reverse engineering the encryption routines and eventually creating a fake Kraken server capable of overtaking a redirected zombie. His detailed write up on the reverse engineering process is available under "Owning Kraken".

The key to overtaking the botnet is understanding how the overall client-server architecture works. Kraken infected systems attempt to "phone home" to a master command and control server by systematically generating sub-domains from various dynamic DNS resolver services such as dyndns.com.

By reverse engineering the list of names and successfully registering some of the sub-domains Kraken is looking for, we can emulate a server and begin to infiltrate the network zombie by zombie. Stated simply, Kraken infected systems world wide start to connect to a server we control.

We monitored Kraken connections for a period of one week (seven days). In that time we have received over 1.8 million requests from infected systems worldwide. Of these requests over 65,000 came from unique IP addresses.

This number still does not accurately capture the true infection count monitored. Why? Think about the systems who are constantly rebooted, assigned a new IP address and then re-connect to the command and control server.

We can do better thanks to the fact that the initial request from the Kraken zombies contains an encryption key generated in such a manner that makes it constant per system but unique across systems.

Counting at this level of granularity leaves us with 25,000 truly unique infections monitored over seven days ... and growing, we are seeing a fairly uniform number of new infections a day.

Applying a reverse DNS lookup over this set of IP addresses reveals that the bulk of the monitored infected user base is home broadband users. The source country distributions break down as follows:

The initial Kraken zombie request also contains a version field which we parsed and found to contain the following distribution:

Various estimates place the overall size of the botnet to be somewhere between 185,000 and 600,000 zombies. This means that within a single week we would have been able to take over anywhere from 4% to 14% of the infected population ... and this is where we entered into a moral dilemma and ethical discussion. We have the ability to successfully redirect infected systems.

We have the ability to provide an 'update' through the existing Kraken protocol that can simply remove the Kraken zombie. Is it wrong to do so? Although this discussion is similar to that of writing "good worms" that roam the internet patching vulnerable servers, there is a key difference in that a good worm can't be stopped.

Once it has been released it is a self spreading uncontrollable entity. In our specific case however we have the ability to cease at any point. It is simply a one to one relationship. An infected system connects to us, we supply a simple binary to kill the target process, we never hear from the infected system again and neither can the actual botnet owners command and control servers.

Cody and I both are pro "cleansing". Dave Endler on the other hand is against. The arguments for pro-cleansing are obvious, the arguments against are a little more complicated. The most interesting of points that Dave brought up is the corner case of what happens if we accidentally crash the target system?

What if that target system is responsible for someone's life support? Yes the system is already infected with a SPAM delivering zombie capable of receiving arbitrary updates from malicious actors, but at least for now it's running and carrying out the rest of it's functionality. As director of DVLabs, Dave's opinion overshadows that of our own so we simply sit and monitor. What are your personal thoughts on the matter?