honeyblog

I am quite happy to see that mwcollect and nepenthes join their forces again and develop one tool together. After about a year of concurrent development, the future will bring just one tool (nepenthes daemon) and the mwcollect Alliance. In addition, you can find the subversion repository at http://svn.mwcollect.org/browser.

More information is available at http://mwcollect.org/, the new meta-portal which hosts information related to malware collection.

At Sicherheit 2006, I gave a talk about the Leurre.COM Honeypot Project. The slides from the talk "Learning More About Attack Patterns With Honeypots" are now available.

Last week, Niels Gedicke finished his diploma thesis "HoneyDVD" at the Laboratory for Dependable Distributed Systems. His work resulted in a bootable DVD which sets up a couple of honeypots - together with the Honeywall CDROM Roo some kind of "instant honeynet". Unfortunately the performance is rather bad, so you need decent hardware to run the HoneyDVD.

More information about the project are available in the thesis. The ISO of the HoneyDVD is also available - beware: it's an 8 GB download...

At the 21st Annual Computer Security Applications Conference (ACSAC 2005) back in December 2005, several people from Eurecom presented a paper about automated script generation for honeyd.

The paper entitled "ScriptGen: an automated script generation tool for honeyd" by Corrado Leita, Ken Mermoud, and Marc Dacier presents a tool to generate scripts that can then be used together with honeyd. The basic steps of the tools are:

1. Deploy a honeypot and record all network traffic


2. Build a state machine based on the captured data


3. Simplify the state machine and generate a corresponding honeyd script

The results are promising and can presumably help to easily build new scripts for honeyd. In overall, this tool is similar to HoneyBee. Honeybee can also automatically create new honeyd scripts, but relies on a scanner to actively learn the characteristics of a protocol.

Abstract:
Honeyd is a popular tool developed by Niels Provos that offers a simple way to emulate services offered by several machines on a single PC. It is a so called low interaction honeypot. Responses to incoming requests are generated thanks to ad hoc scripts that need to be written by hand. As a result, few scripts exist, especially for services handling proprietary protocols. In this paper, we propose a method to alleviate these problems by automatically generating new scripts. We explain the method and describe its limitations. We analyze the quality of the generated scripts thanks to two different methods. On the one hand, we have launched known attacks against a machine running our scripts; on the other hand, we have deployed that machine on the Internet, next to a high interaction honeypot during two months. For those attackers that have targeted both machines, we can verify if our scripts have, or not, been able to fool them. We also discuss the various tuning parameters of the algorithm that can can be set to either increase the quality of the script or, at the contrary, to reduce its complexity.

As introduced in the precious entry about the paper "Modeling Botnet Propagation Using Time Zones" by Dagon et al., there are diurnal patterns in botnet propagation. I also examined this phenomenon back in August last year. My data set is by no means as comprehensive as theirs and my analysis is rather unsophisticated, but the results are similar.

One of my nepenthes sensors is running within a Class B network (/16 in CIDR notation) of a university. It is only reachable by hosts within this network and has no real connectivity to the Internet. It just serves as a kind of early-warning system to detect infected hosts within this network. Within the period of July 6 and August 15, 2005, the sensor observed 580 suspicious connections, i.e., infection attempts by other machines. The following figure shows the distribution of number of infection attempts per time of day.



As you can see, there are periods with less and periods with more connections attempts. Since the sensor is only reachable from machines within the same network, only those machines can cause infection attempts. This is important since all infection attempts are caused by computers in the same timezone, thus we do not have to take timeshifts into account. The distribution follows the sleep-wake rhythm of humans: during night (especially between 3 and 5:30 am), the sensor receives almost no infection attempts. In the morning (7 until 9 am), people turn on their computers and the malware begins to spread. There is a spike during the working hours between 2 and 6 pm – presumably corresponding to people who use their infected computer. Between 6 and 9 pm, we see again a period with rather low activity, in which only several people apparently use the computer. And before going to bed (around 10 pm), seemingly many people turn on their computer and connect to the Internet. The malware benefits from this situation and tries to spread further...

I also plotted the distribution over time, i.e., the number of infection attempts received per minute for the whole period:



There are days in which the sensor did not receive any suspicious traffic at all (e.g., July 17 and 18), but there are also periods in which we clearly see that a bot tries to spread aggressively since the sensor receives many infection attempts in a short amount of time. Especially the time between July 23 and July 31 is noticeable since several pieces of malware propagate within the network in this period of time. This is something that is hard to model since predicting the propagation attempts over time is hard - a new vulnerability can quickly lead to increased botnet propagation...