Archive for the ‘Lab’ Category

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

2009: A review

Well, the year is nearly over and it seems everyone is in a reflective mode so I thought I’d join in. And I’m glad I did, didn’t really just how turbulent year I’ve had. I’d better (on pain of death) start with the none technical, as it is around 12 months since I got engaged to my long-time girlfriend.

Back to the technical: The InfoSanity blog went live in February with the first post. Originally I was far from confident that I would be able to keep up blogging as I had a ‘fear’ of social media and web2.0, but nearly a year on I’m still here and despite some peaks and troughs posting articles regularly. I’ve found it a great platform for getting ideas out of my head and into practice, hopefully I’ve managed to be of benefit to others in the process.

Lab environment: February was also when I purchased the server for my virtual lab environment. This has got be the best buy of the year, providing a solid framework for testing and experimenting with everything else I have done this year. Lab environments also seem to be one of the areas that gathers a lot of interest from others, the two posts discussing configuration of virtual networks and guest systems were InfoSanity’s most popular posts this year by a good margin. In the process of improving my lab environment I also read Thomas Wilhelm’s Professional Penetration Testing book and reviewed it for the Ethical Hacker Network, for which I’m indebted to Don for organising.

Wireless: Included in my long list of purchases this year was an Alfa AWUS036H wireless card and a BU-353 GPS¬†Reciever. This resulted in a basic attempt to write a utility to create maps from the results of wardriving with Kismet, whilst the short development time of the project was enjoyable it was promptly shelved once people introduced me to Jabra’s excellent giskismet. It also resulted in the creation of the still to be field-tested, James Bond-esque warwalking case.

Honeypots: Whilst I had had Nepenthes honeypot system running before the turn of the year, I hadn’t really worked with it in earnest until the first post on the subject in February, and subsequent statistic utilities. These posts also became the topic for my first experience with public speaking, for local (and rapidly expanding) technical group, SuperMondays. As the technology has improved the honeypot system has recently been migrated over to Nepenthes’ spiritual successor Dionaea. Over the year I have also had the pleasure and privilege of talking with Markus Koetter (lead dev of Nepenthes and Dionaea) and Lukas Rist (lead dev of Glastopf), these guys *really* know their stuff.

Public Speaking: As mentioned above I gave my first public talk for SuperMondays, discussing Nepenthes honeypots and the information that can be gathered from them. Unfortunately (or thankfully) there is only limited footage available for the session as the camera’s battery ran out of juice. My second session was for a group of Northumbria University’s Forensics and Ethical Hacking students as an ‘expert speaker’, and I still think they mistook me for someone else. This time a recording was available thanks to a couple of the students, full review and audio available here. My public speaking is still far from perfect, coming out at a rapid fire pace, but I’m over my initial dread and actually quite enjoy it. Hopefully they’ll be additional opportunities in the future.

Friends and Contacts: Throughout the year I have ended up in contact with some excellent and interesting people; from real-world network events like SuperMondays and Cloudcamp, old school discussions in forums (EH-Net) and IRC channels, to the ‘2.0’ of Twitter (@infosanity btw). Along with good debates and discussions I’d also like to think I’ve made some good friendships, too many people to name (and most wouldn’t want to be associated ūüėČ ) but you know who you are.

So that’s the year in brief, couple of smaller activities along the way, from investigating newly released attack vectors to trying my hand at lock picking. In hindsight it has been one hell of a year, and with some of the side projects in the pipeline I’m expecting 2010 to be even better. Onwards and upwards.

— Andrew Waite

Categories: Honeypot, InfoSec, Lab, Presentation

Fuzzy hashing, memory carving and malware identification

2009/12/15 Comments off

I’ve recently been involved in a couple of discussions for different ways for identifying malware. One of the possibilities that has been brought up a couple of times is fuzzy hashing, intended to locate files based on similarities to known files. I must admit that I don’t fully understand the maths and logic behind creating fuzzy hash signatures or comparing them. If you’re curious Dustin Hurlbut has released a paper on the subject, Hurlbut’s abstract does a better job of explaining the general idea behind fuzzy hashing.

Fuzzy hashing allows the discovery of potentially incriminating documents that may not be located using traditional hashing methods. The use of the fuzzy hash is much like the fuzzy logic search; it is looking for documents that are similar but not exactly the same, called homologous files. Homologous files have identical strings of binary data; however they are not exact duplicates. An example would be two identical word processor documents, with a new paragraph added in the middle of one. To locate homologous files, they must be hashed traditionally in segments to identify the strings of identical data.

I have previously experimented with a tool called ssdeep, which implements the theory behind fuzzy hashing. To use ssdeep to find files similar to known malicious files you can run ssdeep against the known samples to generate a signature hash, then run ssdeep against the files you are searching, comparing with the previously generated sample.

One scenarios I’ve used ssdeep for in the past is to try and group malware samples collected by malware honeypot systems based on functionality. In my attempts I haven’t found this to be a promising line of research, as different malware can typically have the same and similar functionality most of the samples showed a high level of comparison whether actually related or not.

Another scenario that I had developed was running ssdeep against a clean WinXP install with a malicious binary. In the tests I had run I haven’t found this to be a useful process, given the disk capacity available to modern systems running ssdeep against a large HDD can be a time consuming process. It can also generate a good number of false positives when run against the OS.

After recently reading Leon van der Eijk’s post on malware carving I have been mulling a method for combining techniques to improve fuzzy hashing’s ability to identify malicious files, while reducing the number of false positives and workload required for an investigator. The theory was that, while any unexpected files on a system are not desirable, if they aren’t running in memory then they are less threatening than those that are active.

To test the theory I infected an XP SP2 victim with a sample of Blaster that had been harvested by my Dionaea honeypot and dumped the RAM following Leon’s methodology. Once the image was dissected by foremost I ran ssdeep against extracted resources. Ssdeep successfully identified the malicious files with a 100% comparison to the maliciuos sample. So far so good.

With my previous experience with ssdeep I ran a control test, repeating the procedure against the dumped memory of a completely clean install. Unsurprisingly the comparison did not find a similar 100% match, however it did falsely flag several files and artifacts with a 90%+ comparison so there is still a significant risk of false positives.

From the process I have learnt a fair deal (reading and understanding Leon’s methodolgy was no comparison to putting it into practice) but don’t intend to utilise the methods and techniques attempted in real-world scenarios any time soon. Similar, and likely faster, results can be achieved by following Leon’s process completely and running the files carved by Foremost against an anti-virus scan.

Being able to test scenarios similar to this was the main reason for me to build up the my test and development lab which I have described previously. In particular, if I had run the investigation on physical hardware I would likely not have rebuilt the environment for the control test with a clean system, losing the additional data for comparison, virtualisation snap shots made re-running the scenario trivial.

–Andrew Waite

P.S. Big thanks to Leon for writing up the memory capture and carving process used as a foundation for testing this scenario.

Automated Malware & ESXi frustrations

I recently read Christian Wojner’s excellent paper on Mass Malware Analysis and it re-ignited my desire to build an automated environment to improve and speed up my current malware analysis capabilities. The paper details a step by step for duplicating Wojner’s environment, but I as I don’t have any spare equipment I’ve been looking for alternative routes.

Fortunately the paper also explains the theory, thought process and design of the system so that the reader can modify to suit their own requirements. To achieve this I’ve been trying replace the Xubuntu and Virtual Box host with my existing¬† ESXi environment detailed in previous posts.

With a bit of Googling the vSphere CLI became the obvious choice to replace the control component for the infected machine in the automated malware environment. provides the functionality to both stop/start virtual guests and to revert the guest to previous snapshots, exactly what is needed for the malware analysis environment. The commands to be utilised would be (– is a double dash): –server <ESXi Host> –username <user> –password <pass> /path/to/guest.vmx getstate –server <ESXi Host> –username <user> –password <pass> /path/to/guest.vmx start –server <ESXi Host> –username <user> –password <pass> /path/to/guest.vmx stop –server <ESXi Host> –username <user> –password <pass> /path/to/guest.vmx revertsnapshot

This should have been enough to adapt Wojner’s control scripts to use ESXi instead of Virtual box, but it appears that for the first time I’ve encountered a crippled feature not available in the VMware’s free offering. Running the stop/start/revert commands results in the below exception:

SOAP Fault:
Fault string: fault.RestrictedVersion.summary
Fault detail: RestrictedVersionFault

So that’s that, unless I happen to win the lottery (which I don’t play) or someone is able and willing to provide a full ESX license to a struggling researcher (which I don’t expect to happen) I’m back to looking for a replacement Wojner’s VirtualBox control process. On with the next…

Andrew Waite

Virtual lab network

2009/10/13 1 comment

The previous post on lab machines seemed to generate a high level of interest so I thought it may be worthwhile to expand further and share my lab’s network setup.

My recent exploration of the Vyatta platform’s capabilities has provided a simple method for segregating and connecting lab networks without requiring a hardware router. I currently split my network into three seperate subnets.

  •¬†¬†¬†¬†¬†¬† – Physical network for none virtual machines
  • – Primary lab subnet
  • – Secondary lab subnet

InfoSanity's ESXi Lab environment

The primary lab subnet contains the majority of my victims. Helpfully the machines configured as part of Metasploit Unleashed and most of the machines released by (De-ICE level1 and Hackerdemia) both use the subnet. To fit I’ve configured my custom machines to match. While providing additional targets, the custom machines in the primary lab double as my malware analysis environment (with the Vyatta appliance powered off to provide isolation).

My secondary lab subnet currently only contains the single publically available level 2 De-ICE machine. In the future I’m intending to expand the usage of the secondary lab by dual-homing one or more of the of the lab machines and demoing pivot and techniques to use one a compromised machine to attack otherwise inaccessible targets.

With the machines and environment detailed above and in the previous post I’ve managed to develop a highly versatile lab environment for both tool/exploit development and training/practice. Not bad for a total outlay of under ¬£200 plus some time and effort.

Andrew Waite

Categories: Lab

Virtual lab machines

Since working through and reviewing Wilhelm’s ‘Professional Penetration Testing’ I’ve been trying to build up and improve my personal lab environment, still running ESXi and still running on my HP Proliant ML110 . Having just about got all of my target machines in place I thought this would be a good place to list the machines in my lab, and to share the sources for others looking for a test environment themselves.

ESXi Inventory listing

ESXi Inventory listing

Off the back of the Professional Penetration Testing book I include the machines created and maintained on;

  • The De-ICE LiveCDs – Example target machines, goal is to gain root access.
  • Hackerdemia – “The Hackerdemia Project is a LiveCD that provides both an instructional platform (in the form of a wiki) and an attack target to practice newly acquired skills.”
  • pWnOS – Target machine created by a member of forums, Bond00.

The recent release of Metasploit Unleashed has provided a new excellent source of information for anyone looking to learn the ins and outs of the Metasploit framework. The material provides a guide for setting up two targets used throughout the courseware:

  • An XP machine from NISTs FDCC project, with instructions for downgrading the security and running SQL Express
  • A Ubuntu 7.04 machine running Samba

From my own experimentation I also run:

  • Two XP machines (SP1 & SP2) – mainly used for malware analysis
  • A Debian 4.0 victim –¬† for working with Linux exploits and shellcode
  • BackTrack 4 – as an attack platform
  • LiveCD – Used for running additional liveCDs in the lab that aren’t permanent residence, often Samurai or Helix (before it went commercial)

For most testing I will run only a handful of the above machines at any one time, just whatever is necessary for a particular scenario. However I am able to run all the above at the same time to test scanning and information gathering tools, nmap, Nessus, etc.

If you’re looking to develop information security skills and get hands on experience using the relevant tools and techniques I’d fully suggest reading through the links above. The amount and quality of freely available information is outstanding, and as my kit proves it doesn’t take great hardware to take advantage.

Andrew Waite

<Update>If you’re running a Mac take a look at phenotyne’s post for getting similar environments working under Apple hardware</Update>

Categories: Lab