Infiltrating botnets

I read an interesting paper this morning written by folks at the University of Mannheim and Institut Eurecom. In the paper they present results of research in which they monitored the P2P botnet of Storm, with a view to understanding, measuring and potentially being able to disrupt it [1]. The work was presented in the recent LEET 08 meeting [First Usenix workshop on large-scale exploits and emergent threats 2].

In the paper, Holz et al. infiltrated the Storm P2P networks in order to better understand the communications used. Of course, there has been previous research in this area, including some excellent articles published by Joe Stewart [3,4]. Nonetheless, the paper is definitely still worth a read.

Certain areas of information security research come with the baggage of legal and ethical issues. Even if an activity is deemed legal, the researcher may be faced with the question of whether it is ethically permissable. The monitoring of botnets is definitely an area where the researcher hits such dilemnas. Researchers may choose to execute malware within some form of controlled environment in order to monitor its behaviour. Historically, the controlled environment may have had no external connectivity (for many types of malware it is unnecessary). But increasingly, effective behaviour monitoring dictates some external connections, usually involving modified firewalls and the like in order to have some ‘control’ over incoming and outgoing data.

If the research is to go beyond pure monitoring, additional issues have to be considered. In their paper Horz et al. discuss the feasibility of actually polluting the Storm P2P network, that is, interacting with it in some way in order to cause disruption. The goal of this type of research is clear and many would consider well-intentioned (to ultimately lessen the malicious capability of the botnet). But researchers have to take extreme care to avoid falling foul of the law. In particular (within US law at least), potential violation of the Computer Fraud and Abuse Act (CFAA) needs to be considered (intentionally sending code/data, causing damage, without authorisation, etc etc).

Within the same LEET 08 meeting, I noticed another paper that attempts to address some of the legal issues [5]. Again, a worthy read, particularly for any researcher working in an area ‘close to the line’.