"Automatically Generating Models for Botnet Detection"

Friday, July 17. 2009
One of the papers that we will publish at the European Symposium on Research in Computer Security (ESORICS'09) focusses on the problem of detecting bots within a given network. Previous research focussed for example on detecting bots using human-generated signatures and anomaly detectors (e.g., BotHunter) or correlating the activity of individual hosts in order to find machines that react in lockstep (e.g., BotMiner or TAMD). We present a system that automatically generates signatures which encapsulate the behavior of an infected machine. The important observation is that the principle behind bots is that they receive a command from the botherder and then respond in a specific way. Using real-world traces of many botnets we show that it is possible to spot the bot responses in the network traces using a change point detection algorithm. Based on this information we can then identify the commands and we use all information to then encode a signature which we map into Bro rules. Experiments in different networks show that this approach outperforms BotHunter. More information about the approach is available in the paper and all the gory details are published in a technical report.

Abstract: A botnet is a network of compromised hosts that is under the control of a single, malicious entity, often called the botmaster. We present a system that aims to detect bots, independent of any prior information about the command and control channels or propagation vectors, and without requiring multiple infections for correlation. Our system relies on detection models that target the characteristic fact that every bot receives commands from the botmaster to which it responds in a specific way. These detection models are generated automatically from network traffic traces recorded from actual bot instances. We have implemented the proposed approach and demonstrate that it can extract effective detection models for a variety of different bot families. These models are precise in describing the activity of bots and raise very few false positives.

This work is a collaboration with Peter Wurzinger, Leyla Bilge, Jan Goebel, Christopher Kruegel, and Engin Kirda. And the word cloud on the top of the posting is generated with the help of http://www.wordle.net/.

Ready or Not?

Monday, April 13. 2009
Several days ago, I finally handed in my dissertation with the title "Tracking and Mitigation of Malicious Remote Control Networks". The thesis was reviewed by Prof. Freiling and Prof. Kruegel and my defense is at the end of the month. The thesis itself deals with different methods to study malicious remote control networks, i.e., a mechanism that enables an attacker the control over a large number of compromised machines for illicit activities. Typical examples of this kind of remote control networks are botnets and fast-flux service networks. The thesis summarizes the work from the last few years and the resulting publications.
Once my defense is over I will post a link to my thesis, it is not yet public. For now I'm really happy that my PhD studies are (almost) over, looking forward to new challenges in the future :-)

And another good news arrived today via e-mail:
On behalf of the 18th USENIX Security Symposium (USENIX Security '09) program committee, I am delighted to inform you that your paper #108 has been accepted to appear in the conference.

Title: Return-Oriented Rootkits: Bypassing Kernel Code Integrity
Protection Mechanisms
Authors: Ralf Hund (University of Mannheim)
Thorsten Holz (University of Mannheim)
Felix Freiling (University of Mannheim)

This year's selection process was very selective, and your paper was one of only 26 papers accepted out of 176 submissions. Congratulations!

LEET'09 Taking Place Soon

Tuesday, April 7. 2009
Join us at the 2nd USENIX Workshop on Large-Scale Exploits and Emergent Threats: Botnets, Spyware, Worms, and More (LEET'09), which will take place in Boston, MA, on April 21, 2009. LEET '09 will focus on the underlying mechanisms used to compromise and control hosts, the large-scale "applications" being perpetrated upon this framework, and the social and economic networks driving these threats. Sessions include Malware Analysis, Ethics in Botnet Research, Malware Behavior, and more.

The full program is available at http://www.usenix.org/events/leet09/tech/.

LEET '09 will also include a session for Work-in-Progress reports. We encourage you to submit an abstract or proposal for a 5-minute presentation on your preliminary work to leet09wips@usenix.org.

Connect with the broad community of researchers and practitioners who focus on worms, bots, spam, spyware, phishing, DDoS, and the ever-increasing palette of large-scale Internet-based threats in fostering the development of preliminary work in this diverse area and stimulating discussion of thought-provoking ideas.

Find out more and register today at http://www.usenix.org/leet09/

Conficker Detection

Thursday, April 2. 2009
The Internet did not break down yesterday due to Conficker, it seems like the topic was hyped a bit too much by the media.
In case you want to quickly check whether or not your machine is infected with the worm, you can use a simple check developed by Joe Stewart from SecureWorks. Simply go to http://honeyblog.org/junkyard/conficker/ and check which images your browser shows:
Conficker (aka Downadup, Kido) is known to block access to over 100 anti-virus and security websites.

If you are blocked from loading the remote images in the first row of the top table above (AV/security sites) but not blocked from loading the remote images in the second row (websites of alternative operating systems) then your Windows PC may be infected by Conficker (or some other malicious software).

If you can see all six images in both rows of the top table, you are either not infected by Conficker, or you may be using a proxy server, in which case you will not be able to use this test to make an accurate determination, since Conficker will be unable to block you from viewing the AV/security sites.

Furthermore, the Honeynet Project recently released a paper entitled "Know Your Enemy: Containing Conficker" which presents in detail several methods to detect the worm based on network characteristics,

Abstract:
The Conficker worm has infected several million computers since it first started spreading in late 2008 but attempts to mitigate Conficker have not yet proved very successful. In this paper we present several potential methods to contain Conficker. The approaches presented take advantage of the way Conficker patches infected systems, which can be used to remotely detect a compromised system. Furthermore, we demonstrate various methods to detect and remove Conficker locally and a potential vaccination tool is presented. Finally, the domainname generation mechanism for all three Conficker variants is discussed in detail and an overview of the potential for upcoming domain collisions in version .C is provided. Tools for all the ideas presented here are freely available for download including source code.

ICANN: Initial Report of the GNSO Fast Flux Hosting Working Group

Thursday, January 29. 2009
Fast-Flux Service Networks is a phenomenon I covered in this blog a couple of times earlier on. We als published two papers on this topic and made the data collected during our study available. Back in May 2008 ICANN had formed a working group to address this problem which should answer the following questions:
  • Who benefits from fast flux, and who is harmed?

  • Who would benefit from cessation of the practice and who would be harmed?

  • Are registry operators involved, or could they be, in fast flux hosting activities? If so, how?

  • Are registrars involved in fast flux hosting activities? If so, how?

  • How are registrants affected by fast flux hosting?

  • How are Internet users affected by fast flux hosting?

  • What technical (e.g. changes to the way in which DNS updates operate) and policy (e.g. changes to registry/registrar agreements or rules governing permissible registrant behavior) measures could be implemented by registries and registrars to mitigate the negative effects of fast flux?

  • What would be the impact (positive or negative) of establishing limitations, guidelines, or restrictions on registrants, registrars and/or registries with respect to practices that enable or facilitate fast flux hosting?

  • What would be the impact of these limitations, guidelines, or restrictions to product and service innovation?

  • What are some of the best practices available with regard to protection from fast flux?

Since a few days the initial report of this working group is available and the report is an interesting read. Public comments should be sent directly to ICANN until February 15, 2009 - so if you have comments, please send them to ICANN.