Search Results

Keyword: ‘honeyd’

HoneyD network architecture

I was recently asked about the network configuration I use for my honeyd sensor. I had thought I’d already written about this so initially went to find the article on honeyd configuration; but my memory was wrong and the original post only covered configuring the guest systems, not the honeyd host itself. So, as I now have a pretty(ish) network diagram showing my setup I may as well correct the earlier omission.

<DISCLAIMER: This may not be the best network design for running honeyd, this is merely how my environment is configured and it works for me as a research platform. As usual, your mileage may vary, especially if your use-case differs from my own>

As can be seen, the design has three distinct network segments:

  • Publicly route-able IPs
  • Internal network for honeypot hosts
  • Virtual network for honeyd guest systems. These IP addresses sit on loopback interface on the host, with a static route on the firewall to pass all virtual traffic to the honeyd host.

Using a perimeter firewall with NAT/PAT capabilities allows easy switching between emulated systems and services if your public IP resources are limited; a large network of guests can be configured in advance and left static, then a quick firewall change is all that is required to expose different systems to the world.

Additionally, as much as honeypot systems are designed to be compromised and collect information of malicious attacks (or perhaps more correctly, because of this) , low-interaction systems like honeyd is designed to avoid full compromise. If something goes wrong and the host system gets fully compromised, a (sufficiently configured) perimeter firewall provides some control of outgoing traffic, limiting the attackers options for using the honeypot sensor to attack other systems.

Not much to it really; if you use an different setup and/or can suggest ways to improve the setup let me know, always looking to improve my systems where possible.

— Andrew Waite

Categories: honeyd, Honeypot, InfoSec, Lab

Determining connection source from honeyd.log – cymruwhois version

2010/05/03 1 comment

InfoSanity’s script has been useful for analysing the initial findings from a HoneyD installation, but one of weaknesses identified in the geolocation database used by the script was that a large proportion of the source IP addresses connecting to the honeypot environment weren’t none within the database. Markus pointed me in the direction of the cymruwhois (discussed previously)python module as an alternative. I’ve re-written the initial script, below:

from cymruwhois import Client
import sys

logfile = open('/var/log/honeypot/honeyd.log', 'r')
source = []
for line in logfile:
    source.append(line.split(' ')[3])

src_country = []
src_count = []


for res in results:
    country = results[res].cc
        pos = src_country.index( country )
        src_count[pos] += 1
        src_country.append( country )
        src_count.append( 1 )

for i in range( 0, ( len( src_country ) - 1 ) ):
    sys.stdout.write( "%s:\t%i\n" %( src_country[i], src_count[i] ) )

So far this has resulted in far fewer unknown source locations, 249 using geoip compared to 3 using cymruwhois. The downside unfortunately is performance, the cymruwhois communicates with a remote host to gather information compared with the geolocation database that is already stored locally on the machine. Both perform some local caching of results/data however so I would expect the performane difference to decrease as larger datasets are analysed.

Using the newer script, based on the same 24hr data set, the top ten host countries communicating with InfoSanity’s honeyd environment are:

RU:     397
US:     234
TW:     179
BR:     158
CN:     123
RO:     107
DE:     101
IT:     96
JP:     91
AR:     86

— Andrew Waite

24hrs of HoneyD logs

After an initial setup and configuration of HoneyD I took a snapshot of the honeyd.log file after running for a 24hr period.

Running honeydsum against the log file generated some good overview information. There were over 12000 connections made to the emulated network, averaging one connection every 7 seconds. Despite the volume of connections, each source generally only initiated a handful of connections, likely looking for a single particular service before moving on.

Top 10 Source Hosts
Rank     Source IP       Connections
1       3066
2      984
3           65
4          65
5             57
6        48
7            39
8               37
9       30
10          30

The summaries from honeydsum also suggest that the rate of incoming connections is generally constant. The only real variation to this was between 17:00 and 18:00, but the spike coincides with the source IP running an ordered port sweep against a single target IP address, starting at TCP1042 and running up to around TCP 1300. Not sure why anyone is scanning this particular port range (if anyone can provide any additional information to slake my curiosity I’d appreciate it) but this event explains the outliers in both the above and below summary tables, highlighting the dangers of working with a small data set.

Connections per Hour
Hour  Connections
00:00      329
01:00      325
02:00      281
03:00      366
04:00      360
05:00      322
06:00      300
07:00      299
08:00      258
09:00      369
10:00      317
11:00      324
12:00      423
13:00      367
14:00      351
15:00      479
16:00      486
17:00   3590
18:00      498
19:00      515
20:00      576
21:00      441
22:00      397
23:00      311

The below table summarises the targetted resources within the environment. It shouldn’t come as a surprise that the most popular targets were tcp ports 445 and 135, but this is the case even though the honeyd configuration does not have any services listening on those ports. From this I would suggest that if you are trying to gather data on a particular port or service that you employ a filter (firewall/ACL/etc.) to block the noise before it reaches honeyd to keep the log files relevant.

Top 10 Accessed Resources
Rank   Resource    Connections
1           445/tcp         7349
2           135/tcp         1086
3             8/icmp           123
4              22/tcp           102
5            1433/tcp          95
6           8080/tcp          73
7           4899/tcp          52
8           5900/tcp          39
9         10000/tcp         39
10           3/icmp            38

In addition to running honeydsum the data set was run through InfoSanity’s script, top 10 sources are listed below. The results are likely skewed as the largest ‘location’ for the results is ‘none’ according to the GeoIP Country Lite database being used. One feature of the result set is that the country linked to the public IP addresses used by the honeyd environment did not feature in the list, as infrastructure improves and botnets become more prevalent today’s malware no longer needs to target ‘closer’ IP addresses to remain efficient.

None:   692
United States:  196
Russian Federation:     123
Taiwan: 118
Brazil: 109
Germany:        99
Australia:      99
China:  90
Romania:        86
Italy:  82

— Andrew Waite

Categories: Honeypot, InfoSec, Malware

Honeydsum: HoneyD log analyser

2010/04/20 1 comment

Honeydsum is a script created by Lucio Henrique Franco and Carlos Henrique Peixoto Caetano Chaves for the Brazilian Honeynet project. As described by it’s Authors, it is:

a tool written in Perl designed to generate a text summary from Honeyd logs. The summaries may be produced using different parameters as filters, such as ports, protocols, IP addresses or networks. It shows the top source and port access and the number of connections per hour, and supports input from multiple log files. The script can also correlate events from several honeypots.

Using the script from the commandline is straightforward; simple invoke with a config file and pass the honeyd log to be analysed. In addition to the usual textual output honeydsum is also capable of generating HTML results providing a quick and easy visual. The download site also includes some sample output files, both text and html (tgz archive).

$ /usr/share/honeyd/scripts/honeydsum-v0.3/

Usage: -c honeydsum.conf [-hVw] log-file1 log-file2 … log-filen
-c   honeydsum.conf file.
-h   display this help and exit.
-V   display version number and exit.
-w   display output as web page (HTML).

The bulk of the text based output provides a list of connections made from external sources to the systems emulated by the HoneyD instance. Using the provided sample output as an example provides the information below; on a live and publically accessible system this output will be significantly longer:

Source IP        Resource  Connections        21/tcp       1      21/tcp       1     11/icmp       1     11/icmp       1
IPs             Resources  Connections
4                       2        4

The end of the output contains the information that I find most useful. It provides several different summaries of all the traffic captured by the whole HoneyD environment. Summaries include:

The most frequent remote sources:

Top 10 Source Hosts

Rank  Source IP       Connections
1        3
2        2
3           1
4        1
5         1
6         1
7        1

Most requested emulated services/resources:

Top 10 Accessed Resources

Rank Resource    Connections
1    21/tcp             4
2    11/icmp            4
3    53/udp             2

— Andrew Waite

Categories: honeyd, Honeypot, InfoSec, Tool-Kit

Determining connection source from honeyd.log

After getting a working HoneyD environment I wanted to better dig into the information provided by the system. First up was a quick script to get a feel for where the attacks/connections originate from. For location functionality GeoIP is the package for the job, as we’re using both Debian and Python installing the required tools is as simple as ‘apt-get install python-geoip’.

At first glance I really like the log format that is used by honeyd.log, it is nice an easy to parse from. From this I quickly knocked up a python script to parse the honeyd.log file, collect a list of unique source addresses and finally use GeoIP to determine (and count) the county of origin. The script (below) is basic, and most likely full of bugs but shows the ease with which tools can be forged to quickly gain the full value from the information collected by the HoneyD environment.

Version 0.01 is below; ignoring any likely bugs that need fixing the one thing that it definitely needs is to order the output, although I’m undecided if this should be alphabetically by country or by hit-count. Source Code:

import GeoIP
import sys

#log file location hard coded, change to suit environment
logfile = open(‘/var/log/honeypot/honeyd.log’, ‘r’)
source = []
for line in logfile:
source.append(line.split(‘ ‘)[3])

gi =

src_country = []
src_count = []
for src in set(source):
country =  gi.country_name_by_addr( src )
pos = src_country.index( country )
src_count[pos] += 1
src_country.append( country )
src_count.append( 1 )

for i in range( 0, ( len( src_country ) – 1 ) ):
sys.stdout.write( “%s:\t%i\n” %( src_country[i], src_count[i] ) )

Sample output:

# ./
Uruguay: 12
None:   249
Australia:      17
Lithuania:      11
Austria: 4
Russian Federation:     43
Jordan: 3
Taiwan: 29
Hong Kong:      3
Brazil: 39
United States:  54
Hungary: 23
Latvia: 10
Morocco: 1
Macedonia:      3
Serbia: 4
Romania: 44
Argentina:      23
United Kingdom: 12
India:  10
Egypt:  2
Italy:  33
Switzerland:    2
Germany: 43
France: 13
Poland: 27
Canada: 12
China:  23
Malaysia:       8
Panama: 1
Colombia:       6
Japan:  14
Israel: 9
Bulgaria:       9
Turkey: 6
Vietnam: 2
Mexico: 1
Chile:  1
Pakistan:       1
Spain:  7
Portugal:       4
Moldova, Republic of:   1
Antigua and Barbuda:    1
Venezuela:      3
Singapore:      1
United Arab Emirates:   1
Philippines:    2
Croatia: 1
Korea, Republic of:     4
Ukraine: 5
Georgia: 2
Bahamas: 1
Ecuador: 1
South Africa:   1
Peru:   1
Kazakhstan:     2
Costa Rica:     1
Bolivia: 1
Iran, Islamic Republic of:      2
Greece: 1
Bahrain: 1

— Andrew Waite

Categories: honeyd, Honeypot, InfoSec, Tool-Kit

Basic HoneyD configuration

After first getting HoneyD up and running previously for a proof of concept I’ve begun a wider implementation of HoneyD to function as the backbone for an upgraded research environment.

HoneyD’s key strength is it’s flexibility, HoneyD’s website contains some sample configuration files that show HoneyD emulating multiple systems running different OSes and applications, a large multi-site network and even a config file to create a honeypot environment for a wireless network. I’ve found these samples immensely useful references for developing custom templates for my own implementation.

At a bare minimum a HoneyD configuration file requires a defined default template, the current default template for this environment is borrowed from one of the sample files and is a tarpit, designed to slow down network sweeps and automated worms; similar to LaBrea tarpit.

create default
set default personality “Microsoft Windows XP Professional SP1”
set default default tcp action tarpit open
set default default udp action block
set default default icmp action open

HoneyD can emulate both Windows and ‘nix systems (and many less common systems), for initial deployment we’re going with an even mix of Windows and Linux host template, each each with a template for a e-mail, web and development server.

Linux configuration:

# Linux Mail
create linux_mail
set linux_mail personality “Linux 2.4.20”
set linux_mail default tcp action reset
set linux_mail default udp action block
set linux_mail default icmp action open
set linux_mail uptime 73921
add linux_mail tcp port 110 “sh scripts/unix/linux/suse8.0/ $ipsrc $sport $ipdst $dport”
add linux_mail tcp port 143 “sh scripts/unix/linux/suse8.0/ $ipsrc $sport $ipdst $dport”
add linux_mail udp port 161 “perl scripts/unix/linux/suse8.0/ public private –config==scripts/unix/general”
bind 10.x.y.x linux_mail

# Linux Web
create linux_web
set linux_web personality “Linux 2.4.20”
set linux_web default tcp action reset
set linux_web default udp action block
set linux_web uptime 13282
add linux_web tcp port 21 “sh scripts/unix/linux/suse8.0/proftpd $ipsrc $spor$ipdst $dport”
add linux_web tcp port 80 “sh scripts/unix/linux/suse8.0/ $ipsrc $sport $ipdst $dport”
add linux_web udp port 161 “sh scripts/unix/general/snmp/ $ipsrc $sport $ipdst $dport”
bind 10.x.y.z linux_web

# Linux Development Box (EVERYTHING installed)
create linux_dev
set linux_dev personality “Linux 2.4.20”
set linux_dev default tcp action reset
set linux_dev default udp action block
set linux_dev default icmp action open
set linux_dev uptime 8324
add linux_dev tcp port 21 “sh scripts/unix/linux/suse8.0/ $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 22 “sh scripts/unix/linux/suse8.0/ $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 23 “sh scripts/unix/linux/suse8.0/ $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 25 “sh scripts/unix/linux/suse8.0/ $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 79 “sh scripts/unix/linux/suse8.0/ $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 80 “sh scripts/unix/linux/suse8.0/ $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 110 “sh scripts/unix/linux/suse8.0/ $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 111″perl scripts/unix/general/rpc/bportmapd –proto tcp –host scripts/unix/general/rpc/hosts/debian –srcip $ipsrc –dstip $ipdst –srcport $srcport –dstport $dport –logfile /var/log/honeyd –logall”
add linux_dev tcp port 143 “sh scripts/unix/linux/suse8.0/ $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 515 “sh scripts/unix/linux/suse8.0/ $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 3128 “sh scripts/unix/linux/suse8.0/ $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 8080 “sh scripts/unix/linux/suse8.0/ $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 8081 “sh scripts/unix/linux/suse8.0/ $ipsrc $sport $ipdst $dport”
add linux_dev udp port 53 proxy
add linux_dev udp port 111″perl scripts/unix/general/rpc/bportmapd –proto udp –host scripts/unix/general/rpc/hosts/debian –srcip $ipsrc –dstip $ipdst –srcport $srcport –dstport $dport –logfile /var/log/honeyd –logall”
add linux_dev udp port 161 “perl scripts/unix/general/snmp/ public private –config=scripts/unix/general”
add linux_dev udp port 514 “sh scripts/unix/linux/suse8.0/ $ipsrc $sport $ipdst $dport”
bind 10.x.y.z linux_dev

Windows configuration:

# Windows Mail Server
create win_mail
set win_mail personality “Microsoft Windows Server 2003 Standard Edition”
set win_mail default tcp action reset
set win_mail default udp action block
set win_mail default icmp action open
set win_mail uptime 42256
add win_mail tcp port 25 “sh scripts/win32/win2k/ $ipsrc $sport $ipdst $dport”
add win_mail tcp port 110 “sh scripts/win32/win2k/ $ipsrc $sport $ipdst $dport”
add win_mail tcp port 143 “sh scripts/win32/win2k/ $ipsrc $sport $ipdst $dport”
add win_mail udp port 161 “perl scripts/unix/general/snmp/ public private –config=scripts/unix/general”
bind 10.x.y.z win_mail

# Windows Web Server
create win_web
set win_web personality “Microsoft Windows Server 2003 Standard Edition”
set win_web default tcp action reset
set win_web default udp action block
set win_web default icmp action open
set win_web uptime 12256
add win_web tcp port 21 “sh scripts/win32/win2k/ $ipsrc $sport $ipdst $dport”
add win_web tcp port 80 “sh scripts/win32/win2k/ $ipsrc $sport $ipdst $dport”
add win_web udp port 161 “perl scripts/unix/general/snmp/ public private –config=scripts/unix/general”
bind 10.x.y.z win_web

# Windows ‘Dev’ Server
create win_dev
set win_dev personality “Microsoft Windows Server 2003 Standard Edition”
set win_dev default tcp action reset
set win_dev default udp action block
set win_dev default icmp action open
set win_dev uptime 8826
add win_dev tcp port 21 “sh scripts/win32/win2k/ $ipsrc $sport $ipdst $dport”
add win_dev tcp port 25 “sh scripts/win32/win2k/ $ipsrc $sport $ipdst $dport”
add win_dev tcp port 80 “sh scripts/win32/win2k/ $ipsrc $sport $ipdst $dport”
add win_dev tcp port 110 “sh scripts/win32/win2k/ $ipsrc $sport $ipdst $dport”
add win_dev tcp port 143 “sh scripts/win32/win2k/ $ipsrc $sport $ipdst $dport”
add win_dev tcp port 389 “sh scripts/win32/win2k/ $ipsrc $sport $ipdst $dport”
add win_dev tcp port 5901 “sh scripts/win32/win2k/ $ipsrc $sport $ipdst $dport”
add win_dev udp port 161 “perl scripts/unix/general/snmp/ public private –config=scripts/unix/general”
bind 10.x.y.z win_dev

As others have should in the sample configs I’ve linked to above, this config barely scratches the surface of HoneyD’s capabilities but it is sufficient to rapidly get a working honeypot environment working and collecting attack information.

Something that frequently surprises anyone not involved in infosec on a daily basis is the speed at which a newly connected system on the Internet will be targeted by a malicious party. In this case the environment was functioning for under a minute before it received it’s first contact from the outside world, as shown in the timestamps from HoneyD’s log file:

2010-04-17-16:41:09.2549 honeyd log started ——
2010-04-17-16:42:04.9735 tcp(6) – 2027 445: 48 S [Windows XP SP1]
2010-04-17-16:42:05.4878 tcp(6) – 2027 445: 48 S [Windows XP SP1]
2010-04-17-16:42:06.0341 tcp(6) – 2027 445: 48 S [Windows XP SP1]
2010-04-17-16:43:00.3707 tcp(6) – 1450 445: 64 S [Windows 2000 RFC1323]
2010-04-17-16:43:00.9051 tcp(6) – 1450 445: 64 S [Windows 2000 RFC1323]
2010-04-17-16:43:01.4310 tcp(6) – 1450 445: 64 S [Windows 2000 RFC1323]
2010-04-17-16:43:27.1202 tcp(6) – 1103 445: 48 S [Windows XP SP1]

— Andrew Waite

Categories: honeyd, Honeypot, InfoSec, Lab

Starting with HoneyD

Since reading Virtual Honeypots I’ve been wanting to implement a HoneyD system, developed by Niels Provos. From it’s own site, HoneyD is:

a small daemon that creates virtual hosts on a network. The hosts can be configured to run arbitrary services, and their personality can be adapted so that they appear to be running certain operating systems. Honeyd enables a single host to claim multiple addresses – I have tested up to 65536 – on a LAN for network simulation. Honeyd improves cyber security by providing mechanisms for threat detection and assessment. It also deters adversaries by hiding real systems in the middle of virtual systems.

My initial experience getting HoneyD running was frustration to say the least. Going with Debian to provide a stable OS, the install process should have been as simple as apt-get install honeyd. While keeping upto date with a Debian system can sometimes be difficult, the honeyd package is as current as it gets with version 1.5c.

For reasons that I can’t explain, this didn’t work first (or second) time so I reverted to compiling from source. The process could have been worse, only real stumbling block I hit was a naming clash within Debian’s package names. HoneyD requires the ‘dumb network’ package libdnet, but if you apt-get install libdnet you get Debian’s DECnet libraries. On Debian and deriviates you need libdumbnet1.

HoneyD’s configuration has the ability to get very complex depending on what you are looking to achieve. Thankfully a sample configuration is provided that includes examples of some of the most common configuration directives. Once you’ve got a config sorted (the sample works perfectly for testing), starting the honeyd is simple: honeyd -f /path/to/config-file. There are plenty of other runtime options available, but I haven’t had time to fully experiment with all of them; check the honeyd man pages for more information.

As well as emulating hosts and network topologies, HoneyD can be configured to run what it terms ‘subsystems’. Basically this are scripts that can be used to provide additional functionality on the emulated systems for an attacker/user to interact with. Some basic (and not so basic) subsystems are included with HoneyD. Some additional service emulation scripts that have been contributed to the HoneyD project can be found here. As part of the configuration, HoneyD can also pass specified IP/Ports through to live systems, either more indepth/specialised honeypot system or a full ‘real’ system to combine low and high interaction honeypot.

I’m still bearly scratching the surface of what HoneyD is capable of, and haven’t yet transfered my system to a live network to generate any statistics, but from my reading, research and experimentation I have high expectations.

— Andrew Waite

Categories: honeyd, Honeypot, InfoSec, Lab, Tool-Kit

2010: A Review

Originally I wasn’t planning on reviewing this year, didn’t think that much had happened, but during some end of year house keeping came across the InfoSanity review of 2009 and wanted to keep the trend going. In keeping with last years review. I’ll start with the non-technical (again on pain of death 😉 ); wedding plans going strong so I should be a married man early 2011.

Back to the technical: Despite my initial concerns; the site, blog and research environment are still here and still growing. To all those who’ve read, contributed and (most importantly) told me I’m wrong over the past year (you know who you are), thank you.

Lab Environment(s): To complement the home lab established in 2009, 2010 saw the introduction of a hosted virtual lab which has provided the opportunity to easily try new (and old) technologies in the real world. As part of this InfoSanity has setup (and in some cases also removed) instances of honeyd, Dionaea, Amun and Kippo. These systems have also resulted in some new utilities being developed and released as I worked through various findings.

Whilst standing on the shoulders of giants (thanks Markus), some of the findings from the InfoSanity environment are now available publically. Although I really must complete both automating the process and including findings from other systems, 2011’s to-do list is already growing.

Public Speaking: For some reason I’ve still been asked to talk in public about topics I find fascinating; so thanks to the Disaster Protocol team for having me on the show. I felt it was a great discussion of honeypot technologies and infosec in general, and from feedback I’ve had others seem to agree.

Trying new things: Whilst trying to grow and mature over the year InfoSanity tried a few different themes and topics, some worked, like basic ssh hardening guidelines (potentially more to come in new year) and some didn’t, like the ‘Infosec Triads’ series. But if you don’t stretch yourself you’ll stop learning, so expect more posts that don’t quite work in 2011.

Friends, contact and groups: As with last year, the best part of 2010 has definitely been the people I’ve either continued talking to and/or working with and those I’ve met for the first time. 2010 saw a growth spurt in local and online groups I’ve been involved in, including the start of NEBytes, ToonCon and the Kippo User Group. There are also a huge number of awesome groups which I don’t get as much time to get involved with as I’d like; EH-Net, Group51, DissectingTheHack, Exotic Liability…the list goes on.

2011?: Who knows? Every time I try to make plans or predictions the Sky Fairies and Flying Spaghetti Monsters mock me, so I won’t try to make any. But whatever the outcome, I’m not expecting a letup in the pace, and can already see some exciting new opportunities on the horizon.

Another decade down, and a new year of opportunity ahead. See you all in 2011.

–Andrew Waite

Categories: Uncategorized

Mercury – Live Honeypot DVD

<UPDATE>Live download mirror:</UPDATE>

Mercury Live DVD was initially (I believe) announced in a post to the Nepenthes Mailing list. It is a remastered Ubuntu distribution with pre-installed honeypot applications and malware analysis tools created by John Moore. From the ReadMe:

This live DVD is a remastered version of Ubuntu 10.0 Beta LTS x86_32. It was designed due to my being disappointed with another reverse engineering malware live CD that was released recently. I have decided to call my creation MERCURY, which is an acronym for Malware Enumeration, Capture, and Reverse Engineering.

The Mercury live DVD contains tools used for digital forensics, data recovery, network monitoring, and spoofing. It should primarily be used as a honeypot or network monitoring platform as well as a laboratory and teaching aid. There are three honeypots installed – honeyd, nepenthes, and dionaea. Four, if you include netcat.

The majority of the additional applications reside in /opt:

  • Dionaea (0.1.0) – Dionaea is a malware collection honeypot focusing primarily on SMB emulation, covered on InfoSanity numerous times before.
  • FFP – Fuzzy Fingerprinting is a util to aid SSH MitM attacks.
  • jsunpack-n – Is a Javascript unpacker, perfect for analysis captured or potentially malicious URLs in more depth.
  • Kippo (svn rev.169) – Kippo is an low-medium interaction SSH honeypot, Also covered
  • mitm-ssh – Unsurprisingly, a utility for aiding man in the middle attacks against SSH connections.
  • Origami & pdftools – Two frameworks for analysing malicious PDF files.
  • Volatility – an excellent memory analysis toolkit
  • Zerowine-vm – A malware behavior analysis platform. I’ve covered ZeroWine here before, and whilst I find it useful for initial analysis I found it a pain to setup and get running. The fact this works out of the box on Mercury is enough reason alone to keep the .iso handy.

Other tools are installed on the system as started, access from standard locations (/etc, /usr/bin, etc.). I won’t try to list them all, but some highlights include:

  • Nepenthes – Dionaea’s predecessor
  • Honeyd – Honeypot system, perfect for emulating multiple different systems from one platform. Covered in more depth here.
  • John – John the Ripper, password cracker
  • ircd-hybrid – irc server daemon, useful for analysis irc-based malware’s interaction with command and control systems.
  • Snort – de-facto intrusion detection system.
  • Wireshark – Packet capture and network analysis tools.

I could go on, but I’m sure you get the idea.

Setting up a honeypot, and analysing the results, has never been easier. And I’m sure the toolkit’s functionality will also be useful in other scenarios; incident response, general network administration or as a safe learning platform. So what are you waiting for?

–Andrew Waite

N.B. there have been several mirror’s and downloads established, the most reliable download source I’ve used is Markus’ mirror at

Quick and Easy Nepenthes installation

I’ve just completed a new Nepenthes installation, and found the process far simpler than my first attempt as I didn’t compile from source.

Running on a Debian 5.0/Lenny server the install was both quick and easy, ‘apt-get install nepenthes’ handles install and dependencies nicely. The only issue I encountered was the permissions of files and directories within /var/log/nepenthes/. The contents had owner and group settings as root:root, as the nepenthes process should (and does under the default init.d script) drop permissions after initialisation this meant that the process was unable write to some of it’s logfiles, reducing the amount and quality of collected information. Thankfully this is easily fixed with a simple ‘chown -R nepenthes:nepenthes /var/log/nepenthes/*’.

I’ve frequently seen complaints/queries on the Nepenthes development mailing list that there are issues with Nepenthes’ hexdump functionality. While it isn’t enabled by default, using this install method works perfectly after uncommenting the “” line from /etc/nepenthes/nepenthes.conf, depositing collected dumps in /var/lib/nepenthes/hexdumps/.

Initial testing shows the system working nicely (not bad for 30 minutes work) and is beginning to collect new binaries and attack statistics. Next step is some integration with Honeyd to provide the start of a combined honeynet environment, more to come later.

— Andrew Waite

Categories: Honeypot, Nepenthes