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
VMWare ESXi is perfect for a self contained lab, but as I’m used to having full access to a ‘real’ network there are a few things I miss not having control over for testing and other things. The biggest of these is a spanf port (or mirror port depending on your hardware). If you’re not familiar, the basic premise is to configure one (or more ports) to reproduce any traffic flowing through any port(s). This provides packet level access for debugging network problems, passing to an I[D/P]S, etc.
ESXi doesn’t provide this functionality, but does allow you to set a vSwitch to be ‘promiscuous’. Unfortunately this isn’t as controllable as a span/mirror port as (from the quick tests I’ve run) essentially turns the vSwitch into a vHub. Not a problem in my lab environment but you probably want to give it some serious thought before enabling in a production environment; do you really want every server on the network to be able to see all traffic on the (virtual) wire?
To make the change in ESXi you need host -> Configuration -> Networking and set the properties as shown below:
Once this change is made, any guests connected to the vSwitch can all see any of the network traffic on that switch.
For testing you can build a quick lab scenario with 3 live boot BackTrack systems. Each machine has a different role; server, client and ‘sniffer’. The sniffing machine is now able to view direct communication between the other two systems. Using wireshark’s Follow TCP stream functionality shows the conversation:
Markus keeps adding great features and functionality to Dionaea, when I read the post introducing a new web interface carniwwwhore I couldn’t help thinking I’d got lucky timing, start of a week’s vacation and no real plan for what to do with it. I’ve struggled previously with some of my Dionaea setups, largely because my system was running Debian, whilst Dionaea was built under Ubuntu; doesn’t cause too many problems, just a bit of google-fu, headscratching and stupidity that could have been avoided.
From this background I looked through the carniwwwhore pre-reqs with dread, plenty of version requirements that weren’t upto date with my Debian setup; so it’s time to bite the bullet and build a fresh system with Ubuntu. Unlike some of my previous setups, installation/compilation worked flawless, working on the same distro as the lead dev definitely makes life easier. If you’re looking for a fresh Dionaea installation, go with Ubuntu, you won’t regret it.
(oh, and carniwwwhore? Vacation got the better of me so it’s added to the to-do list; watch this space…)
I’ve tried messing around with SSH port forwarding in the past, but always struggled to get my head around what I was trying to connect to where, and ultimately didn’t result in anything useful. This time around I’ve put in some dedicated time to get to the bottom forwarding ports within SSH tunnels. And I’m glad I did, my with only a handful of connections the possibilities are making my head spin.
To help my head get around problems I encountered I found a number of resources helpful.
Example Scenario: A server (10.0.0.100) on an internal LAN has web services that need to be accessed, but has no remote access through the firewall. Luckily, there is remote access to an SSH server (10.0.0.200) sat on the same LAN.
ssh -L 8000:10.0.0.100:80 ssh-server.somedomain.tld
This connects to the machine at ssh-server.somedomain.tld and, once authenticated, forwards 10.0.0.100:80 to port 8000 on the local machine. Now accessing the remote services is as simple as pointing your browser to http://127.0.0.1:8000.
The same functionality can be achieved using configuration files. For example, edit ~/.ssh/config:
LocalForward 127.0.0.1:8000 10.0.0.100:80
To establish a connection with the configuration file in place simply run; ssh tunnel.
The port forward will remain active for as long as the SSH session is connected. If you don’t need to interact with the SSH session in addition to the forwarded port passing ssh the -fN flags will cause the session to be backgrounded once authentication can be established.
If you haven’t already, I suggest you investigate the possibilities within your own environment; and if an evil grin doesn’t spread across your face then you still don’t fully get it
I’m trying to do a better job of documenting the systems that make up InfoSanity. To do that it’s everyone’s favourite, a wiki. In this case I went with DokuWiki, for no real reason other than it came up first on a Google search. Installation is simple on a Debian based system, just the usual: apt-get install dokuwiki. So far so good, but I’m wondering how long I can actually keep the documentation upto date…
At the same time I came across the the BeerWare license from my Twitter feed (sorry, can’t find original message, thanks to whoever pointed me in the right direction. The license was created by Poul-Henning Kamp, and does a good job of summing up my feelings toward the tools/scripts I’ve released the last few years:
/* * ---------------------------------------------------------------------------- * "THE BEER-WARE LICENSE" (Revision 42): * <phk@FreeBSD.ORG> wrote this file. As long as you retain this notice you * can do whatever you want with this stuff. If we meet some day, and you think * this stuff is worth it, you can buy me a beer in return Poul-Henning Kamp * ---------------------------------------------------------------------------- */
So, why not combine the two together? DokuWiki has the ability to apply one of several standard licenses by default, but unfortunately BeerWare isn’t one of them. To correct this obvious mistake edit /etc/dokuwiki/license.php to include:
$license['beerware'] = array(
‘name’ => ‘Beerware License’,
‘url’ => ‘http://en.wikipedia.org/wiki/Beerware’,
n.b. I struggled to find a better license location that just deals with the license, if anyone finds better let me know.
Now it’s just a matter of editing the main dokuwiki config file, /etc/dokuwiki/dokuwiki.php:
$conf['license'] = ‘beerware’;
<UPDATE>Live download mirror: carnivore.it</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.
- 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?
N.B. there have been several mirror’s and downloads established, the most reliable download source I’ve used is Markus’ mirror at carnivore.it
I’ve been a bit lax in writing this post; around a month ago Miguel Jacq got in contact to let me know about a couple of errors he encountered when running InfoSanity’s mimic-nepstats.py with a small data set. Basically if your log file did not include any submissions, or was for a period shorter than 24hours the script would crash out, not the biggest problem as most will be working with larger data sets but annoying non the less.
Not only did Miguel let me know about the issues, he was also gracious enough to provide a fix, the updated script can be found here. An example of the script in action is below:
cat /opt/dionaea/var/log/dionaea.log| python mimic-nepstats_v1-1.py
Statistics engine written by Andrew Waite – http://www.infosanity.co.uk
Number of submissions: 84
Number of unique samples: 39
Number of unique source IPs: 65
First sample seen: 2010-06-08 08:25:39.569003
Last sample seen: 2010-06-21 15:24:37.105594
System Uptime: 13 days, 6:58:57.536591
Average daily submissions: 6
Most recent submissions:
2010-06-21 15:24:37.105594, 184.108.40.206, emulate://, 56b8047f0f50238b62fa386ef109174e
2010-06-21 15:18:08.347568, 220.127.116.11, tftp://18.104.22.168/ssms.exe, fd28c5e1c38caa35bf5e1987e6167f4c
2010-06-21 15:17:08.391267, 22.214.171.124, tftp://126.96.36.199/ssms.exe, bb39f29fad85db12d9cf7195da0e1bfe
2010-06-21 06:29:03.565988, 188.8.131.52, tftp://184.108.40.206/ssms.exe, fd28c5e1c38caa35bf5e1987e6167f4c
2010-06-20 23:34:15.967299, 220.127.116.11, http://18.104.22.168/trying.exe, 094e2eae3644691711771699f4947536
– Andrew Waite
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.
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 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/qpop.sh $ipsrc $sport $ipdst $dport”
add linux_mail tcp port 143 “sh scripts/unix/linux/suse8.0/cyrus-imapd.sh $ipsrc $sport $ipdst $dport”
add linux_mail udp port 161 “perl scripts/unix/linux/suse8.0/fake-snmp.pl public private –config==scripts/unix/general”
bind 10.x.y.x linux_mail
# 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/apache.sh $ipsrc $sport $ipdst $dport”
add linux_web udp port 161 “sh scripts/unix/general/snmp/fake-snmp.pl $ipsrc $sport $ipdst $dport”
bind 10.x.y.z linux_web
# Linux Development Box (EVERYTHING installed)
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/proftpd.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 22 “sh scripts/unix/linux/suse8.0/ssh.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 23 “sh scripts/unix/linux/suse8.0/telnetd.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 25 “sh scripts/unix/linux/suse8.0/sendmail.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 79 “sh scripts/unix/linux/suse8.0/fingerd.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 80 “sh scripts/unix/linux/suse8.0/apache.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 110 “sh scripts/unix/linux/suse8.0/qpop.sh $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/cyrus-imapd.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 515 “sh scripts/unix/linux/suse8.0/lpd.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 3128 “sh scripts/unix/linux/suse8.0/squid.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 8080 “sh scripts/unix/linux/suse8.0/squid.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 8081 “sh scripts/unix/linux/suse8.0/squid.sh $ipsrc $sport $ipdst $dport”
add linux_dev udp port 53 proxy 22.214.171.124:53
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/fake-snmp.pl public private –config=scripts/unix/general”
add linux_dev udp port 514 “sh scripts/unix/linux/suse8.0/syslogd.sh $ipsrc $sport $ipdst $dport”
bind 10.x.y.z linux_dev
# Windows Mail Server
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/exchange-smtp.sh $ipsrc $sport $ipdst $dport”
add win_mail tcp port 110 “sh scripts/win32/win2k/exchange-pop3.sh $ipsrc $sport $ipdst $dport”
add win_mail tcp port 143 “sh scripts/win32/win2k/exchange-imap.sh $ipsrc $sport $ipdst $dport”
add win_mail udp port 161 “perl scripts/unix/general/snmp/fake-snmp.pl public private –config=scripts/unix/general”
bind 10.x.y.z win_mail
# Windows Web Server
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/msftp.sh $ipsrc $sport $ipdst $dport”
add win_web tcp port 80 “sh scripts/win32/win2k/iis.sh $ipsrc $sport $ipdst $dport”
add win_web udp port 161 “perl scripts/unix/general/snmp/fake-snmp.pl public private –config=scripts/unix/general”
bind 10.x.y.z win_web
# Windows ‘Dev’ Server
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/msftp.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 25 “sh scripts/win32/win2k/exchange-smtp.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 80 “sh scripts/win32/win2k/iis.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 110 “sh scripts/win32/win2k/exchange-pop3.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 143 “sh scripts/win32/win2k/exchange-imap.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 389 “sh scripts/win32/win2k/ldap.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 5901 “sh scripts/win32/win2k/vnc.sh $ipsrc $sport $ipdst $dport”
add win_dev udp port 161 “perl scripts/unix/general/snmp/fake-snmp.pl 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) – 126.96.36.199 2027 10.3.1.15 445: 48 S [Windows XP SP1]
2010-04-17-16:42:05.4878 tcp(6) – 188.8.131.52 2027 10.3.1.15 445: 48 S [Windows XP SP1]
2010-04-17-16:42:06.0341 tcp(6) – 184.108.40.206 2027 10.3.1.15 445: 48 S [Windows XP SP1]
2010-04-17-16:43:00.3707 tcp(6) – 220.127.116.11 1450 10.3.1.6 445: 64 S [Windows 2000 RFC1323]
2010-04-17-16:43:00.9051 tcp(6) – 18.104.22.168 1450 10.3.1.6 445: 64 S [Windows 2000 RFC1323]
2010-04-17-16:43:01.4310 tcp(6) – 22.214.171.124 1450 10.3.1.6 445: 64 S [Windows 2000 RFC1323]
2010-04-17-16:43:27.1202 tcp(6) – 126.96.36.199 1103 10.3.1.5 445: 48 S [Windows XP SP1]
– Andrew Waite
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
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