marco
blog
Menu:
Analysis of a Botnet Takeover
April 14, 2011
Some time ago, the IEEE Security & Privacy magazine accepted our paper Analysis of a Botnet Takeover, a new version of our CCS paper on Torpig.
The main differences with older versions of this work are two. First, we removed some of the more academic parts and rewrote the text to make it more appealing to a general readership. Second, and more interestingly, we added an "Aftermath" section, where we look back at the Mebroot/Torpig botnet one year after the original take-over, at the light of new data we collected since then. The main conclusions of this updated look at Torpig, unfortunately, were that the botnet has evolved, becoming more sophisticated and arguably harder to take over, and has remained relatively stable in size.
Some asked if our research ended up helping the bad guys, for example, revealing a weakness in their operations (the hijackability of their C&C system) and prompting them at fixing it. The answer is no: the possibility of hijacking DGA-based botnets was proved beyond any doubt, roughly at the same time, by the Conficker Working Group, who successfully stalled Conficker by sinkholing they domains it relies on for rendezvous.
Another question we are often asked is whether it would have been to possible to stop the botnet, by using some kind of "kill switch" or "kill command". This has long been considered a no-starter in the security community due to its possible unintended consequences. The classic argument goes typically as follows: it is very hard to test the correct functionality of this kill switch (if it exists) on all possible configurations of infected machines; therefore, it may be possible that the kill command causes a crash on some configuration. What if the machines that are so affected happen to be performing some critical task (for example, controlling health equipment)? It is very likely that this stance will be rediscussed at the light of the recent Coreflood takedown, in which a kill command was employed to neuter Coreflood bots.
The Coreflood takedown, and similar earlier actions, also indicates a possible answer to another common question: how to actually take down this botnet? The combinations of sinkholing, active stopping, and legal actions have given so far the most effective results. It remains to be seen if concerns about unintended consequences and intervention of governments on individuals' computers will prevent more widespread uses of this tactic.
We also added to the paper a fairly comprehensive discussion of the ethical and legal aspects of our research, both to clarify what we did and why and to help researchers in a similar position to ours. Yet again, I'm sure that the Coreflood takedown will spark new discussions on these topics.
Here is the paper abstract:
Botnets, networks of malware-infected machines that are controlled by an adversary, are the root cause of a large number of security problems on the Internet. A particularly sophisticated and insidious type of bot is Torpig, a malware program that is designed to harvest sensitive information (such as bank account and credit card data) from its victims. In this paper, we report on our efforts to take control of the Torpig botnet and study its operations for a period of ten days. During this time, we observed more than 180 thousand infections and recorded almost 70 GB of data that the bots collected. While botnets have been "hijacked" and studied previously, the Torpig botnet exhibits certain properties that make the analysis of the data particularly interesting. First, it is possible (with reasonable accuracy) to identify unique bot infections and relate that number to the more than 1.2 million IP addresses that contacted our command and control server. Second, the Torpig botnet is large, targets a variety of applications, and gathers a rich and diverse set of data from the infected victims. This data provides a new understanding of the type and amount of personal information that is stolen by botnets.
