The
Role of a Distributed Honeypot in a Post-Worm World.
By Roger Thompson
I can already hear the cries of “Huh?!?!? What’s this Post-Worm business…?”, but I think it’s correct. It’s not that people don’t write worms any more. They obviously do. And it’s not that they couldn’t write another CodeRed or Slammer. They obviously could. What I really mean by post-worm is that these days, it’s all being done for profit, and it’s now counter-productive to write a big-spreading worm like CodeRed. The perpetrators simply couldn’t “farm” all their victims properly.
Instead of big-spreading worms, worm-writers do controlled releases. They use bots, instead of worms, which allows them to stay under most radars. They evade scanners by using a new packer, or by tweaking their code so that it’s different enough to avoid detection for long enough to get hold of the victim pc. They use spam and faux-greeting cards to lure victims to websites where they attempt to use web-based exploits to run arbitrary code. Sometimes they use cunning social engineering instead of an exploit. (See figure 1.) Once they grab a pc, they install a remote backdoor, a keylogger, and with increasing frequency, a huge slew of adware. With alarming and increasing frequency, they protect their captures with rootkits or security token manipulation.
Figure 1 (If you’re not paying attention, closing the dialog gets you many unexpected presents)
What, then, does this mean for those of us trying to defend our organization’s computers? Well, a really good first step is being able to monitor and understand what they’re doing, which is where a modern distributed honeypot (like WormRadar) comes in.
I first wrote WormRadar a few years ago to detect worm variations. WormRadar would listen on ports that I knew to be wormy, or that I expected to become wormy, and would pretend to be a vulnerable service on that port. If something came along, such as CodeRed, WormRadar would make a capture, crc the non-variable portions of the code, declare it as either known or new, and would report it to WormRadar.com for prevalence charting. This worked great when there were just a few worms circulating, but when the ‘worm-wars’, between the Bagle/Netsky/MyDoom groups erupted in early 2004, it all became much more difficult. The bots and worms became open source. Bot (and worm) variations were released on a daily basis, and exploits were shared to the point where it became just about impossible to tell them apart.
Over the last few months, it has become apparent to me that instead of a static port monitor, something was needed that could be much more agile and flexible. In other words, I still wanted to measure worms and bots, but I needed to be more aggressive than waiting for them to knock on my IP address.
The first step was to add a form of dynamic firewall analysis. If you’re running ZoneAlarm, for example, WormRadar can monitor its logs and every hour can reconfigure its dynamic ports to reflect the ports in the Zone logs. In other words, if something starts beating on a new port, WormRadar can automatically start monitoring that port. If you’re not running a firewall that WormRadar understands, it can also optionally poll the WormRadar website and take a dynamic list of ports from there. What this means is that within about an hour of some new ports becoming active, all nodes on the WormRadar distributed network can be capturing samples.
The second step was to try to measure the stuff being advertised in spam. The idea is this… You create a mail address that is not actually used for real work, and just post a few messages to some usenet group, or leave it on a website for the harvesters to find. Anything that arrives in that mailbox is either spam, a phish or a worm. WormRadar pops that mailbox, extracts all the urls, and scans each in turn looking for malicious code or exploits.
The third step is to get as wide a representation of IP addresses and countries as possible, which means I need some more folks running WormRadar. J
Windows Deployment
If you’re interested, you need a pc running something like
ME, or preferably 2K or XP (the tcp stacks just
aren’t reliable enough on the older
For deploying within a NAT'd environment, you would obviously
need to setup port forwarding to the pot. Google for "port forwarding [your
router name]" to find specific details for your router.
E.g.
http://www.google.com.au/search?hl=en&q=port+forwarding+netgear&meta=
Unix Deployment
We've had a successful emulation on Linux via WINE available at :
The test bench was a Fedora Core 4 box with
wine-20050524-1fc3winehq.i386.rpm
Of course configuration existing services and pf / iptables has to be done. We would be enhancing this document to provide more tutorial style documentation with regards to setting up Unix WR nodes.
Industry Buzz
Microsoft has been conducting research via a similar approach with
http://www.research.microsoft.com/honeymonkey/article.aspx and we are unsure
as to how public their findings will be. Wormradar has a considerable public
interface via the main site that shows in real-time how things look at
http://www.wormradar.com
What you mostly need is a willingness to participate. You are also welcome to send in your comments / project ideas to info AT wormradar.com