I've been a big fan of honeypots ever since I first learned about them in Clifford Stoll's The Cuckoo's Egg. His story about catching German hackers because of a 75-cent accounting error is a thrilling forensics journey. Today, I support honeypots because they are a must-have early-warning tool in any organisation.
If you can't stop the hacker or malware - it's hard to be perfect all the time - the next best thing is early warning. Placing a honeypot within your enterprise network, next to other valuable assets, assures that any rogue outsiders - or insiders - will be discovered quickly. If the hacker or malware touches the fake asset, it's done. Low cost and low noise equals high value.
Unfortunately, in order for most honeypots to work, you have to wait for the attacker to assault the honeypot head on from a remote location. This set of circumstances ignores the fact that most malicious hacking occurs from client-side attacks. A malicious phishing e-mail arrives in the user's inbox and waits for the user to click and pursue. This series of events allows the remote malware to activate on the box locally and allows it to return to the network over TCP port 80 outbound, which is allowed by most firewalls.
Many security researchers realised this loophole a few years ago, as browser-based malware began to overtake file attachment worms as the major means of hacking. Many computer defence companies now use client-side honeypots, known as honeyclients, to track and analyse these types of intruders.
The honeyclient is a honeypot that mimics, either manually or automatically, the normal series of steps a regular user would make when visiting various Web sites. A honeyclient can be fully patched or be left vulnerable to reveal more malware. The idea is to identify malicious software, computers that host malware, and - dare to dream! - even the miscreants that make malware.
Although Microsoft was far from the first to explore honeyclients, its Strider HoneyMonkey project was one of the first honeyclient endeavours to get widespread attention. Started by four Microsoft employees, the project has spread beyond its initial scope and has been highly successful.
Here's how it works: Malware and rogue links, new and old, are reported to other Microsoft teams. Based on those details, malicious Web sites are shut down, products are updated, and security teams educated. In at least one instance, an IE zero-day exploit was found by the Strider HoneyMonkey team; the site was taken down, and a solution was implemented before the exploit had time to spread widely.
A whole new honeyclient subculture is also making a name for itself apart from the normal honeypot folks. The Honeyclient Development Project, led by Kathy Wang, offers up a mailing list and the first open source honeyclient, along with an Outlook-based plug-in for collecting malicious URLs. Wang works full-time for Mitre, and rumour has it that they are working on a more sophisticated open source honeyclient to be released soon.
Many vendors have their own honeyclient initiatives, including StillSecure, Webroot, Websense, Sunbelt Software, and Site Advisor. StillSecure's honeyclient project is a good representative of vendor work.
Begun in August 2005 by Robert Danford, StillSecure SAT senior engineer and SANS ISC handler, StillSecure's honeyclient went live in December 2005 using four Windows XP machines. Each machine has varying states of protection, ranging from a default install of XP to highly secured end points protected with StillSecure's highest security policy.
Technologies used include StillSecure, Pezzonavante HoneyClient, Snort, Honeywall, IPTables, Squid, BIND, VMware, Norton and TrendMicro anti-virus, Spybot Search & Destroy, HijackThis, Blacklight Beta, various Sysinternals tools, Perl, VirusTotal, Ad-aware, and MySQL. The Pezzonavante HoneyClient was created by Danford with a lot of his work and ideas facilitated by the great folks at the SANS Internet Storm Center.
The clients all surf the same URLs simultaneously, at a rate of 150 to 300 URLs per hour, or 50,000 unique URLs each month. So far, they have collected approximately 4.6 million unique hits in four months. Collected information is used to build better versions of StillSecure's products, to share data, and to rate the practical effects of StillSecure's protection platforms. Thanks to the honeyclient, StillSecure doesn't have to rely on their customers to provide feedback - they have their own. Collected statistics are available at StillSecure's Web site (http://www.stillsecure.com/endpointindex).
Honeyclients are becoming prevalent enough that malicious attackers are trying to identify them and take them down. Several honeyclients have been DDoS attacked in recent months. Honeyclient proponents are even proactively thinking up ways malicious hackers could identify honeyclients, such as the use of transparent URLs.
In this method, a malicious phisher could include an invisible URL - a colour link on the same colour background - that would not be noticed and followed by the typical Web surfer. Invisible URLs would be readily swallowed up by an automated honeyclient, and in turn identify the Web surfer as a mechanized honeyclient. It seems that a war I didn't even know about two weeks ago is already being fought in its second stages.
Wang, Danford, and their honeyclient colleagues are working feverishly and passionately to improve honeyclient technologies, and honeyclients are already responsible for taking down thousands of malicious sites. Who says only malicious hackers can work together?