Honeypots for Windows

Long thought of as toys for security administrators who have too much time on their hands, honeypots are gaining an increased presence on corporate networks. Honeypots are nonproduction computer assets set up for the express purpose of being a potential target for unauthorized activities. Although honeypots can mimic any computer resource (e.g., router, print server), they most often mimic legitimate production servers and workstations.

Early on, security professionals mainly used honeypots to learn about malicious attackers (hereafter called intruders) and their tactics. Honeypots have proven their value in this area. For example, using honeypots, the Honeynet Project (http://www.honeynet.org) learned that the majority of attacks are automated by malicious mobile code (i.e., viruses, worms, and Trojan horses) and scripts. Although manual attacks aren't as common, patient intruders will find exploitable holes. Using honeypots, the project members uncovered complex intruder undergrounds involved in widespread commercial fraud and learned and publicized new intruder tricks before they could become pervasive zero-day exploits (i.e., vulnerabilities that attackers discover and exploit before they become widely known to the general public and security professionals).

Although setting up a honeypot to learn about intruders and their tactics is worthwhile, most organizations will find greater value in using honeypots to distract intruders from legitimate resources and to serve as an early warning system. Unlike firewalls and Intrusion Detection Systems (IDSs), honeypots don't produce numerous false positives. By definition, a honeypot is a nonproduction asset, and any activity that takes place on it is considered malicious until proven otherwise.

For a honeypot to attract intruders, it has to appear as a legitimate production asset. Thus, in a pure Windows environment, administrators might create honeypots that mimic common Windows ports and services. However, honeypots didn't originate in the Windows world but rather the UNIX/Linux universe. Although a few Windows honeypot solutions exist, they don't have the sophistication, feature set, or support that their UNIX/Linux counterparts offer. This situation might be somewhat surprising given that most of the world's networks are Windows networks. Vendors are just starting to address this gap, and some Windows solutions are beginning to rival their UNIX/Linux counterparts. And in true Windows fashion, the Windows solutions are becoming easier to configure and deploy than the UNIX/Linux ones. This review will look at virtual honeypots designed for the Windows world and includes both commercial and open-source solutions.

Real vs. Virtual Honeypots
Honeypots can be real or virtual. A real honeypot runs production software (e.g., Windows Server 2003, Microsoft Exchange Server, Microsoft IIS) on dedicated hardware. A real honeypot is one of the best targets you can offer to an intruder. It looks and responds like a real production asset—and as long as the data it contains is updated, the honeypot has little chance of being identified as such.

The problem with real honeypots is that they're generally difficult and time-consuming to set up and control. Setting up a real honeypot might take as many hours as setting up a legitimate production asset. More important, because the software is real, after the intruder gains access to it, preventing the intruder from using the newly compromised asset to attack other, legitimate assets can be difficult. Although many real UNIX/Linux honeypots have mechanisms to prevent the compromise of legitimate assets (called data-control mechanisms in honeypot lingo), few Windows honeypots have them.

Virtual honeypots offer an emulated environment in which the software limits what the intruder can do. In most cases, potential damage to legitimate assets is significantly curtailed, if not impossible. Most virtual honeypots offer weakly emulated TCP and UDP ports and services. Virtual honeypots can simulate open ports, closed ports, or ports that contain a responding service.

Virtual honeypots that only open a port and record an intruder's initial probe are called simple port listeners. Slightly more advanced port listeners can reply with basic open or closed response packets, which might appear more realistic and intrigue the intruder more. These honeypots record the information that the intruder sends, then they respond with the appropriate network protocol reply (e.g., a SYN packet). The honeypots don't send any other data, and the intruder's connection is never successful. For a network administrator, this interaction might be enough because it indicates unauthorized activity within the perimeter and minimizes subsequent risk.

Many virtual honeypots simulate services on well-known ports that would interest an intruder, such as SMTP or FTP. These honeypots go beyond the initial protocol handshake by having the emulated service respond to the intruder. An emulated service that returns only a mimicked banner reply is called a banner service. For example, an intruder's connection to TCP port 25 (SMTP) might return a simulated Exchange banner connection response. An emulated service that responds with minimum output in response to input is called a simple or standard service. For example, probes to FTP port 21 might prompt intruders for their logon name and password, which the honeypot records. If an intruder uses current or old logon information versus a random guess, the intruder might be an insider or might have successfully compromised the system in the past.

Simulated services, especially those trying to mimic IIS or FTP, often offer greater levels of emulation. Some virtual honeypots provide fake subdirectories, files, and responses. Other virtual honeypots allow service-port probes to be relayed to other computers hosting legitimate software but ensure the intruder is still attacking a nonproduction resource. Generally, the better the service emulation, the more interesting the target becomes to intruders. The longer the intruders stay around, the more information you can collect. However, most virtual honeypots are considered low-interaction, which means they don't offer sophisticated levels of emulation.

Selection and Evaluation Criteria
Numerous honeypots are available, so I had to narrow the field. To be included in this review, the honeypot had to run natively on Windows platforms and mimic multiple common Windows ports and services. I didn't consider honeypots that specialize in only one facet of defense (e.g., tarpits, antispam) or have minimal features because they tend to arrive and disappear in a few months and offer limited support.

Four honeypots—Honeyd-WIN32 0.5, KeyFocus's KFSensor, Network Security Software's (NETSEC's) SPECTER 7.0, and VMware (an EMC subsidiary) Workstation 4.0—met all the selection criteria. (Table 1 outlines other notable honeypots that can run in a Windows environment but didn't meet the other selection criteria.) To evaluate the four honeypots, I used the following evaluation criteria:

Honeyd-WIN32
Honeyd-WIN32 is the Windows-ported version of Honeyd, the open-source darling of the UNIX honeypot world. Written by Niels Provos in 2002 as a low-interaction UNIX/Linux honeypot, Honeyd enjoys widespread support, a fairly extensive feature set, demonstrated scalability, and a moderately active development community. (For more information about the original Honeyd for UNIX/Linux, go to http://www.honeyd.org.) In 2003, Michael Davis created the open-source Windows version of Honeyd. Honeyd is currently in version 0.8, whereas Honeyd-WIN32 hasn't been updated since version 0.5. Although Honeyd-WIN32 lacks a user-friendly GUI, its price (free) and features make it a popular choice among honeypot administrators.

Unlike the other honeypots in this review, Honeyd-WIN32 can partially emulate hundreds of OSs at the IP stack level. In Honeyd-WIN32 lingo, the OS IP stack being emulated is called a personality. Honeyd-WIN32's IP stack emulation lets it mimic Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP), TCP, and UDP packets at a level that its competitors can't. The ability to simulate TCP flags, Time to Live (TTL) settings, timestamps, network latency, and routing paths lets Honeyd-WIN32 simulate more realistic scenarios at the network level. Honeyd-WIN32 achieves this simulation by mapping its lower-layer responses to the OS fingerprinting databases of Xprobe2 (a fingerprinting utility by Fyodor Yarochkin and Ofir Arkin) and Insecure.org's Network Mapper tool (Nmap), instead of letting the underlying host OS respond. This feature is important because, for example, if the host computer is running Win2K Server and the honeypot is emulating Windows NT Server 4.0, the intruder might notice the minor IP stack discrepancies that exist. To accomplish the IP stack emulation, Honeyd-WIN32 requires an IP network address that's different from that of the host computer. This requirement significantly complicates new installations for most users and involves setting up static routes on the host.

Honeyd-WIN32 is extremely flexible. One instance of it can emulate one or more OS personalities, thousands of IP addresses, and thousands of ports. The OSs that Honeyd-WIN32 can emulate include every flavor of Windows, UNIX, Linux, Sun Microsystems' Sun Solaris, FreeBSD, and Cisco Systems' IOS Software. Honeyd-WIN32 can support any number of UDP and TCP ports, each of which you can configure to be open, closed, or blocked (as if a firewall is involved). You can even have the honeypot respond with an emulated service. Using any scripting language that the host supports, you can employ scripts or compiled programs to create services beyond simple port listeners. The scripted services ensure that intruders won't be compromising additional real hosts from within the honeypot.

Installing Honeyd-WIN32 can be a bear. Before you can run Honeyd-WIN32, you must install WinPcap (free packet-capture architecture for Windows at http://winpcap.polito.it) so that Honeyd-WIN32 can interact with arriving packets before the underlying host IP stack does. After installing Honeyd-WIN32, you must create a text configuration file that tells Honeyd-WIN32 the personalities to load, the ports and services to offer, and the states of those ports and services. You can download and install already created service scripts, most of which are written in Perl or the UNIX/Linux shell-scripting languages. You have to install the scripting environments and engines needed to support the language used in the selected service script.

You should also install an IDS (to detect and provide alerts for security events) and a packet sniffer (to capture network packets). Most Honeyd-WIN32 administrators use the open-source Snort system (http://www.snort.org) for the IDS and the free Ethereal software (http://www.ethereal.com) for the packet sniffer. As with any open-source solution, installation errors are easy to make and troubleshooting them can make reading Windows event log messages seem fun. To complicate matters, because Honeyd-WIN32 is a ported product, you don't always know whether the problem is with Honeyd in general or only the ported version.

Besides the complex installation, the biggest downside of Honeyd-WIN32 is that it's a low-interaction honeypot with no complex Windows services emulations. Although Honeyd-WIN32 excels on the network layer, it falls short on the application layer. If you want to mimic a Windows computer, you must determine which ports to offer and develop (or find) appropriate scripts. Although Honeyd-WIN32 is useful for capturing an intruder's initial investigations, it won't keep an intruder busy for very long if you don't include fully simulated applications and emulated data sets.

Honeyd-WIN32's real-time logging activities are limited to summarized packet and connection information displayed in the command console, as Figure 1 shows. Honeyd-WIN32 stores this same information, sometimes with more detail, in a text-based log file. Each scripted service can also have a separate, specialized log to capture even more related information.

Honeyd-WIN32 is the most popular Windows honeypot in use today. Other honeypot vendors support its scripts and have attempted to copy its feature set. Unfortunately, like most powerful open-source tools, Honeyd-WIN32 takes a fair amount of text-based configuration and patience to install and use. Even then, its lack of complex scripted services and lack of Windows-specific configuration options dampen its overall use as a full-featured honeypot.

KFSensor
KFSensor appears to be the only virtual honeypot in this review with a clear sense of what it takes to appear to be a Windows host. Like Honeyd-WIN32, KFSensor is a low-interaction honeypot. Unlike Honeyd-WIN32, KFSensor comes with 77 preconfigured ports (58 TCP ports and 19 UDP ports). Most of the ports are found in typical Windows environments, although KeyFocus has thrown in some arbitrary Trojan horse ports to attract intruders scanning for vulnerable hosts. The installation is simple—you just download the software and execute. Helpful GUI wizards guide the way, letting you input information during each step. Additional wizards and documentation are available with each click of the mouse.

KFSensor offers simple service emulation for IIS, FTP, Telnet, and Exchange. Connections to IIS result in a standard Under construction page. Connections to port 25 result in a realistic Exchange text banner reply, and the service emulation accepts a limited number of basic SMTP commands. KeyFocus could have easily done the same for other common Exchange server ports, such as the POP3 and IMAP ports, but for some reason didn't. KFSensor does basic mimicking of Terminal Services for RDP connections, Symantec's pcAnywhere, Citrix MetaFrame, Virtual Network Computing (VNC), WinGate, and more. You can use control codes and scripts to customize each port and service emulation. During testing, the pcAnywhere remote client thought it was briefly connected to a live host connection before terminating.

KFSensor accurately mimics open NetBIOS and Windows RPC ports, giving the honeypot a realistic Windows response. Unlike the other honeypots in this review, KFSensor is the only honeypot to offer this feature out of the box. This functionality puts KFSensor in the top echelon of Windows honeypots.

KFSensor understands the importance of alerts and logging. KFSensor's GUI tracks security events by several different characteristics, including port, time, attacker, and severity. As Figure 2 shows, you can define which events correlate to what levels of severity, and trigger logs and alerts accordingly. You can have KFSensor email (in regular or short message formats) formal alerts, write them to the Windows event log, or record them on a syslog server. (UNIX/Linux administrators commonly report and log security events on syslog servers. Although Windows has no native syslog services or reporting tools, several Windows-based syslog services exist to fill the gap, such as Kiwi Enterprises' Kiwi Syslog Daemon, which you can download for free at http://www.kiwisyslog.com.) You can also have KFSensor interact with any external alerting or logging program you choose. KFSensor is sophisticated enough to let you decide how many seconds to wait before sending additional alerts and what severity level the event needs to be before initiating an alert. This feature is especially helpful because it lets you avoid, for example, receiving hundreds of separate alerts at 2:00 a.m. from a simple port scan.

KFSensor excels at nearly everything it does, but it has some weaknesses:

Priced at $990 for a single copy, KFSensor is the most expensive honeypot software in this review. However, if you want a feature-packed Windows honeypot that's easy to install and use, KFSensor is the clear choice for you.

SPECTER
SPECTER contains many unique features but doesn't have the detailed Windows emulation and flexibility of its competitors. SPECTER is among the easiest honeypots to install and configure, although perhaps this ease results from its lack of features and customization.

SPECTER's GUI is unique in that it attempts to display almost every possible configuration option on one screen, as Figure 3, page 37, shows. I found the GUI too busy, and during testing, the GUI edges were cut off when the screen was in 800 * 600 resolution. In addition, most of the configuration windows don't have the Close and Minimize control buttons typically found in Windows applications. Both the online Help file and the help available on SPECTER's Web site could be greatly improved.

SPECTER can emulate 14 OSs (Windows OSs include Windows XP, Win2K, NT, and Windows 98 but not Windows 2003) and many of the ports an intruder might expect to see. However, SPECTER emulates only 11 legitimate (i.e., nonmalicious) network services: DNS, Finger, FTP, POP3, IMAP4, HTTP, Secure Shell (SSH), SMTP, Sun RPC, Telnet, and a generic trap. Three of those services (i.e., Finger, SSH, and Sun RPC) aren't routinely found on Windows systems. SPECTER also emulates three potentially malicious Trojan horse ports: NetBus, SubSeven, and Back Orifice 2000 (BO2K).

You can only enable or disable the ports or services; you can't customize them, add ports or scripts, or extend the honeypot's response beyond what's already hard-coded. Furthermore, SPECTER won't display or log intruder attempts to any other ports on the host, which is a significant limitation for what could be a real honeypot contender. You would almost have to be lucky to notice an intruder with this honeypot.

On the plus side, the banner emulation of SMTP, FTP, HTTP, and POP return Windows-specific information but not updated versions. You can configure each emulated OS with a character. You can choose from five characters: Open (the OS acts like a badly secured system), Secure (the OS acts like a well-secured system), Failing (the OS acts like a machine with various hardware and software problems), Strange (the OS acts unpredictably), and Aggressive (the OS communicates as long as necessary to collect information about the intruder, then reveals its true identity to try to scare the intruder away). It would be better if you could customize the security setting for each emulated service on each OS.

For every point of inflexibility or strangeness, SPECTER offers a unique feature that I would like to see included in the other contenders. One such feature is the ability to collect information about the intruder by using intelligence modules, such as finger, traceroute, and portscan. This feature can save you time in the forensic analysis after an attack, although using these options might alert the intruder. I wish other honeypots would offer this option.

SPECTER comes with decoy data that you can use to make the honeypot look more legitimate, thereby enticing intruders. For example, SPECTER comes with fake password files, with varying levels of difficulty. Or instead of sending the password file when the intruder requests it, the honeypot can send a warning text message. SPECTER also generates programs that the intruder can download. These programs leave hidden markers on the intruder's computer. Supposedly, law enforcement agencies can use these markers as evidence in court. The concept is intriguing. However, to date, no law enforcement agency has used them this way, so their validity and legality remains untested. (Another untested legality concerns administrators' liability when using any honeypot. For more information about this topic, see the sidebar "A Small Consideration.")

SPECTER offers other interesting features as well. For example, it has a remote administration client that's nearly as functional as the local client, an online update button to check for new releases, several methods of alerting and logging, and a log-analyzer engine to parse logs for notable events.

I've been following SPECTER for the past year. Although it has an opportunity to be a major player in the Windows honeypot market, it appears dated and a bit neglected by its developer. Its biggest drawback is the lack of port emulations and customization options. Pricing starts at $599 for a light version and $899 for the full version.

VMware Workstation
Although not specifically designed for honeypot use, administrators frequently use VMware Workstation to create realistic-looking honeypots and even networks of honeypots, called honeynets. Figure 4, page 38, shows VMware Workstation's GUI. VMware Workstation can run one or more OSs, each within a virtual machine session. Each session runs real software and can react like a production asset. VMware Workstation supports Windows (i.e., Windows 2003, XP, Win2K, or NT) and Linux as the host OS.

VMware has added features that make VMware Workstation attractive for honeypot use:

Unlike the other honeypots in this review, VMware Workstation's honeypots aren't virtual. The honeypots are real systems running real OS software, which means that the honeypots respond fairly accurately to requests from the IP stack to the application layer. In addition, after you've set up a session on a real honeypot, recovering and redeploying after an intruder's attack is easy. However, using real honeypots created with VMware Workstation has some disadvantages:

Still an Immature Market
Overall, the honeypot market is still maturing, much like the early days of firewalls and IDSs. Although some UNIX-based honeypots have enterprise-level features (e.g., stealthy data control, clandestine kernel-based monitoring), none of the Windows-based honeypots have them. But as is often the case, the best Windows-based honeypots are leading the way in providing user-friendly GUIs.

If you can afford $990, the clear winner in the Windows honeypot market is KFSensor. KFSensor is the only honeypot software to target the Windows environment as its primary audience, and its developer takes an active interest and provides frequent updates. KFSensor also provides user-friendly GUIs—the type of GUI to which Windows users have become accustomed—to install the honeypot and configure its many features. Plus, KFSensor is the only honeypot to natively support NetBIOS and Windows RPC.

Honeyd-WIN32 is a powerful, free honeypot that offers versatility and scalability. Its ability to emulate IP stacks and Windows services is among the strongest in the field. However, Honeyd-WIN32's complicated setup, missing GUI, lack of updates, and lack of NetBIOS emulation makes it the best honeypot only in its price range.

SPECTER is a product with a lot of promise and more than a handful of unique features. Its major drawback is its hard-coded limitation of 14 services and limited customization. Whether its developer improves it or lets it languish will determine whether SPECTER becomes a major honeypot player in the future. For now, I can't recommend this honeypot when compared with its more flexible competitors.

VMware Workstation is a great choice for administrators who are looking for a high-emulation honeypot. It provides a very realistic honeypot environment for intruders to explore, but its increased functionality also makes it difficult to control any intruders. It's an ideal virtual environment in which to set up monitoring utilities, and virtual sessions can be reset with a click of the mouse.