malware

A common technique employed by spammers is to send spam mails with the help of botnets. In a typical setting, the spammer uses so called template-based spamming: the attacker sends the bots a spam template that describes the structure of the spam message to be sent. Furthermore, the attacker sends meta-data like recipient list, subject list, and a list of URLs that are used to fill in variables in the template. The bots then construct an email based on the template and the meta-data, and send this email to the targets. As a result, the actual work of handling the SMTP communication is moved from the control server to the bots. Nowadays this technique is used by most large spam botnets, like Waledac, Bobax, Rustock, Cutwail, and a lot of the other major spam botnets as Joe Stewart explained in detail.

Since spammers nowadays use such a tactic, we can also collect spam mails in a more efficient way: Instead of waiting at the end-user's mailboxes or spamtraps for mail messages to arrive and then decide whether or not this is spam, we directly interact with the servers that are used to send spam messages. The basic idea is that we execute spambots, i.e., malicious software dedicated to sending spam emails, in a controlled (honeypot) environment and collect all email messages sent by the bots. This enables us to directly interfere with botnet control servers to collect current spam messages sent by a specific botnet.

We describe this idea in more detail in a short paper that was published at DIMVA'09. The paper is also available on this blog.

Abstract: With increasing security measures in network services, remote exploitation is getting harder. As a result, attackers concentrate on more reliable attack vectors like email: victims are infected using either malicious attachments or links leading to malicious websites. Therefore efficient filtering and blocking methods for spam messages are needed. Unfortunately, most spam filtering solutions proposed so far are reactive, they require a large amount of both ham and spam messages to efficiently generate rules to differentiate between both. In this paper, we introduce a more proactive approach that allows us to directly collect spam message by interacting with the spam botnet controllers. We are able to observe current spam runs and obtain a copy of latest spam messages in a fast and efficient way. Based on the collected information we are able to generate templates that represent a concise summary of a spam run. The collected data can then be used to improve current spam filtering techniques and develop new venues to efficiently filter mails.

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/.

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/

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.

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.