In-Depth

Sweet Enticement

Honey drops can help you detect attacks in progress--without sticking you with false positives.

• By Mark Burnett and James C. Foster
• 11/01/2004

You've just installed a brand new and expensive intrusion detection system (IDS) to counter growing security threats at your company. After fine-tuning the system, you get your first alert. A little investigation leads you nowhere, but by the time you're done, you have 10 new alerts. You check into each of them, and still they lead you nowhere. Before long your logs are filled with thousands of alerts and you're hopelessly swamped.

A scenario like this is unfortunately all too common. Many network administrators find themselves so overwhelmed with IDS alerts, they start to ignore them. It's not uncommon for an IDS to be configured with thousands of attack signatures ranging from automated worm detection to five-year-old Solaris exploits. When an IDS is activated to recognize these signatures across multiple systems in multiple locations, it exponentially increases the amount of data that correlation engines and human analysts have to parse and review.

Prioritizing these alerts is a complicated task, as is trying to determine what systems are at the greatest risk and what threats you must protect against. For example, it makes little sense to react to Unix attacks targeted at a Windows server. However, such attacks against multiple systems may indicate an enterprise-wide intrusion attempt that will require attention.

Most network-based IDS signatures are created in reaction to a new vulnerability, exploit or threat. That means 90 percent of the time you're playing catch-up to secure your systems against the latest threat. All the while, application-layer attacks continue to rise in popularity and obscurity. Few systems can detect custom SQL-injection or cross-site scripting attacks sent through an SSL-encrypted tunnel and even fewer can do so automatically. Even the most widely deployed intrusion detection system, Snort (www.snort.org), can't accurately detect these types of attacks.

While there are event correlation products and services available, they require a significant investment of both time and money. Another solution is to use a methodology called sure attack detection, which involves creating scenarios in which you can be absolutely positive an attack is in progress. You can accomplish sure attack detection in many ways. Here we will explore one method called honey drops.

Sweet Little Lures
Honey drops, sometimes called honey tokens, are small pieces of benign data that you place in strategic spots around your network to attract and identify intruders.

The concept of luring potential attackers with honey pots has been around for quite some time, even spawning operating system-, host- and network-based honeypot tools. Honeypots are essentially fake computers you set up on your network to attract hackers, enticing them to break into something that has no real value.

Honey drops take this concept one step further. You spread miniature tokens throughout your system that, when accessed, alert you to an intrusion. The tokens are unique strings that represent usernames, directories, files and even database records, depending on the types of intrusions you want to monitor.

There are several benefits to using honey drops, including:

• High Accuracy. Honey drops have an extremely low false positive rate compared to most IDS tools, because they let you analyze both inbound and outbound data streams.
• High Value. Honey drops let administrators and engineers focus on high value alerts among the thousands of garbage alerts triggered by a typical IDS.
• More Proactive. Because they rely on signatures written to known types of attacks, it's difficult for an IDS to consistently stay ahead of the hackers. By contrast, honey drops focus on protecting likely attack targets and will work regardless of the method of attack. You don't have to constantly wait for new signatures to be developed.

One disadvantage of using both an IDS and honey drops is that by the time they trigger, there's a good chance the attacker already has access to your system. But by placing honey drops at different locations, from your perimeter to your internal network, you stand a much better chance at catching an intruder.

The Hunt for Hackers
Once you have the honey drops dispersed throughout your network, you'll need some method of identifying when an intruder accesses one of them. Typical methods are:

• Using an IDS like Snort
• Creating an application-level filter like an ISAPI filter for IIS
• Monitoring application and system logs

We will focus on a unique strategy using a combination of two largely underutilized Windows technologies: Windows Management Instrumentation (WMI) and the COM+ Event System.

You use WMI to access management information in a Windows environment. The WMI framework provides a wealth of system information organized as classes that you can access through various interfaces. Most administrators access WMI through scripting languages like VBScript. For example, the following script will return a list of processes running on the current system:

Set objWMIService= GetObject("winmgmts:\\.\root\cimv2")
Set cItems = objWMIService.ExecQuery("SELECT * FROM Win32_Process",,48)
For Each objItem in cItems
 Wscript.Echo objItem.Caption
Next

The other key technology we use is the COM+ Event System, a system service that stores events produced by publishers and makes them available to subscribers. Windows provides a set of standard event consumers that subscribe to specific events. You define these events with a specially configured WMI query. The standard consumer classes perform actions based on the results of the WMI query. The actions available include:

• Run a WSH script
• Log the event to a text file
• Log the event in the Windows Event Log
• Send an e-mail message
• Execute a command

You can trigger an event based on any information available through WMI. For example, by using the Win32_Process class shown earlier, you can have the system send you an e-mail when a specific process dies or when someone creates a new process.

Subtle Bait
These standard consumers are a powerful system management tool you can use to help detect when someone accesses one of your honey drops. Say, for example, that you create a fake admin account to serve as a honey drop. Create the account with the following command:

net user dcsadmin * /add /active:no /comment:"password is 'admin'"

Type this command and hit Enter. You will be prompted to enter a password. Enter anything you want, as long as it isn't the word admin. Note there are several key elements here:

• The user name looks like an interesting account, but has a unique name that's easy to detect.
• The account is not set as active. You don't want an attacker using your honey drop against you.
• A fake password is mentioned in the comment. This is to lure an attacker to log in, but you can leave this out to be more subtle with your honey drop.

Now a hacker might soon come along and notice the password in the comment and, thinking the administrator is a complete fool, try to log in to that account using the password "admin." Of course, that login will fail and, if you have auditing enabled, the system will record a failed login event in the event log. That's where our event consumer comes into play.

Track the Attack
To use the standard consumers, you need to create a custom Managed Object Format (MOF) file that defines the events to which you want to subscribe. You can configure it to respond to changes to any of the class instances in the root\cimv2 namespace, as well as events from any external WMI event providers like the System Registry Provider.

In this case, we want to be notified whenever event ID 529—Unknown User Name or Bad Password—appears in the Windows Event Log. We need to define the events we want to subscribe to and bind those to the event consumer. We'll use the SMTPEventConsumer to send us an e-mail whenever someone tries to access our fake account.

To do this, download and extract the HoneyDropExample.mof file to %SystemRoot%\System32\wbem and edit it to include the fake admin account you created and your own e-mail and server information. Next, open a command prompt, change to the%SystemRoot%\System32\wbm directory, and type:

mofcomp honeydropexample.mof

If everything compiles correctly, try logging in (with the incorrect password) from another machine or use RunAs to login. Your login should fail, prompting an event log entry. WMI and our honey drop consumer should receive the event and send you an e-mail message reporting the failed log-in attempt. You should receive a similar e-mail whenever someone tries to log in to the fake account.

This particular example is very specific, and would not likely scale well. But with a little analysis of this situation, and by applying some creativity to your own network's security status, you can build a powerful and efficient honey drop detection system. Using honey drops will give you confidence that you're picking up on the most serious attacks, helping you rise up out of the quagmire of IDS false positives.