Alerting

		Chapter 10 - Honeypot Monitoring Honeypots for Windows by Roger A. Grimes Apress 2005

A honeypot system must have a way of alerting its administrator when activity has occurred. The most common alert method uses a separate software system, like an IDS or protocol analyzer, to generate alerts.

Alert Considerations

Alert messages should be kept short, so they can be sent to pagers and cell phones, which are the preferred methods of receiving a high-priority alert. Alert messages should be brief and to the point, but with enough information to allow the administrator to assess the current situation. An alert message should carry the following information at a minimum:

• Date and time of alert

• Message text indicating identified threat

• Priority

• Location of threat

• Classification

The following line shows an example of an alert message:

 07-04-03 01:03:04.2345 High priority; Slammer probe; worm; DMZ IIS 6.0 honeypot; 

Typically, the alert is sent to an Internet e-mail address that corresponds to an alphanumeric pager or cell phone. Since sending messages via the Internet can sometimes be unreliable, especially during a high-priority attack. Many alert systems use dial-up modems that connect to the pager or cell phone company’s proprietary messaging service. Sending alerts via the console works only if you are on the local network when the alert is sent. Sending an alert via e-mail won’t mean much if you aren’t reading your e-mail that very second, and it will mean less if it’s buried in hundreds of other e-mail messages.

Alerting is more of an art than it initially sounds. If you simply set up an alerting mechanism to go off each time honeypot activity occurs, you could end up with a backlog of a hundred alerts in a few minutes. The alerting system must be smart enough to alert you only once for each related event. This is called alert or message throttling. The idea is that after the system alerts you, it should sit idle for a predetermined amount of time if further activity appears to be coming from the same source and at the same priority level.

Also consider who should be alerted. If you are out of town or otherwise unavailable, who should respond in your place? You may even want to define response time guidelines according to the threat level. Whatever your alerting mechanism is, it should be reliable above all else. Some honeypots offer heartbeat messages, which are regular messages sent at predefined intervals just to verify that the honeypot and alert mechanisms are working.

Alerting Programs

Most monitoring and logging programs have their own alerting mechanisms. If they don’t, then they usually allow an external program or script to be run.

For instance, the logging workstation that captures all traffic into or out of the honeypot could be running the Snort IDS (covered in Chapter 9). Snort can be configured to send an alert anytime it notices any traffic to or from the honeypot system. Snort analyzes the traffic, and if it can identify a specific exploit in the traffic contents, it generates a specific type of alert. Snort can send alert messages a number of different ways, including e-mail, SNMP, pager, cell phone, or console message. Figure 10-10 shows the SMTP alert configuration options available in the Snort GUI IDScenter configuration console from Engage Security (http://www.engagesecurity.com). The IDScenter Snort console is free. It allows alerting to predefined program files (such as NET SEND), SMTP messages, audible beeps, and interfaces to additional Snort alert plug-ins.

Figure 10-10: Snort IDScenter SMTP alerting options

In Windows, you can use the NET SEND command, Msg.exe, and many other programs. These programs can be used for sending short console messages across networks.

NET SEND

NET SEND has been around since at least Windows 95. NET SEND is a subcommand under the larger umbrella functionality available using the Net.exe program. Whereas the NET command is usually used to map drive shares (such as NET USER X: \\fileserver\sharename) or list users (NET USERS), it can also be used to send console messages. Each message arrives with a bell sound to alert any nearby users.

Note 

For NET SEND to work, the Messenger service must be enabled on the computers involved. Because of potential spam message harassment, the Messenger service is disabled by default in Windows Server 2003 and Windows XP Service Pack 2. Windows 9x computers need to run Winpopup.exe to accept NET SEND messages.

NET SEND can send messages to a user, domain, workgroup, or IP address. Messages can be up to 128 characters long. NET SEND’s syntax is as follows:

 NET SEND {<user> or /domain:<domain> or /users or <IPAddr>} <message> 

The /domain parameter will send the supplied message to all users in the specified domain or workgroup. The /users option will send the message to all users with active connected sessions to the computer it is sent on. On Windows XP Service Pack 2, when sending to a single user, the /domain parameter must also be entered. The message can be plainly typed without any quotation marks unless you use nontext characters, such as a backslash.

Here are two NET SEND examples:

 NET SEND hpadmin There are UDP probes on Honeypot3  NET SEND 192.168.1.56 “Honeypot experiencing activity/Port 135” 

There are even ways to incorporate other external programs to extend the functionality of NET SEND. For instance, with a bit of command-line coding and the free Showmbrs program, you can send messages to aWindows group (http://www.jsiinc.com/SUBB/tip0700/rh0757.htm).

NET SEND is often used by other monitoring tools as a quick and easy way to alert the administrator to honeypot activity, although it does not scale well over routed networks. Figure 10-11 shows an example of a NET SEND message.

Figure 10-11: A NET SEND console alert message

Windows Event Triggers

Windows XP and Server 2003 even allow the NET SEND command to be triggered off of a local or remote Windows event log message. The very useful and powerful Eventtriggers.exe program allows trigger events, as they are called, to be created, deleted, listed, and queried. Once created, trigger events are active until deleted, even surviving a system reboot. Trigger events are something you could perhaps run on a real OS Windows honeypot without the hacker immediately being aware of them.

The EVENTTRIGGERS command syntax is as follows:

 EVENTTRIGGERS /Create [/S system [/U username [/P [password]]]]  /TR triggername /TK taskname [/D description]  [/L log] { [/EID id]  [/T type] [/SO source] } [/RU username [/RP password]] 

Table 10-3 explains the EVENTTRIGGERS /Create options. Type in EVENTTRIGGERS /? or EVENTTRIGGERS /Create /? to see the full syntax options.

Table 10-3: EVENTTRIGGERS /Create Options

Parameter	Variable	Description
/S	system	Specifies the remote system to connect to.
/U	[domain\]user	Specifies the user context under which the command should execute.
/P	[password]	Specifies the password for the given user context. Prompts for input if omitted.
/TR	triggername	Specifies a friendly name to associate with the event trigger.
/L	log	Specifies the NT event log(s) to monitor events from. Valid types include Application, System, Security, DNS Server Log, and Directory Log. The wildcard (*) may be used, and the default value is *.
/EID for.	id	Specifies a specific event ID the event trigger should monitor
/T	type	Specifies an event type that the trigger should monitor for. Valid values include ERROR, INFORMATION, WARNING, SUCCESSAUDIT, and FAILUREAUDIT.
/SO	source	Specifies a specific event source the event trigger should monitor for.
/D	description	Specifies the description of the event trigger.
/TK	taskname	Specifies the task to execute when the event trigger conditions are met.
/RU	username	Specifies the user account (user context) under which the task runs. For the system account, the value must be "".
/RP	password	Specifies the password for the user. To prompt for the password, the value must be either * or none. The password is not needed for the SYSTEM account

You can create as many trigger events as you like, and display them using the EVENTTRIGGERS / query /v command.

Trigger events can be used along with the NET SEND command for alerting purposes. For example, the following EVENTTRIGGERS command will alert the administrator if an invalid password is used during a login to a honeypot:

• EVENTTRIGGERS.exe /create /l security /eid 529 /tr IncorrectHPLogon /tk “NET SEND administrator Incorrect Logon to Honeypot1”

This trigger event, called IncorrectHPLogon, would trigger event ID 529 (Bad Password or User Account Name), and send a message to the administrator.

This example would trigger an alert if the security log were cleared:

• Eventtriggers.exe /create /l security /eid 517 /tr LogCleared /tk “Net Send administrator Honeypot Log Cleared”

The EVENTTRIGGERS command is very versatile. See http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/eventtriggers.mspx for more details.

Other Alert Utilities

There are a plethora of other utilities that you can use to send alerts from your honeypot or monitoring system. One of the most popular choices is a public domain utility called Blat (http://www.blat.net). Blat is basically a very small SMTP client that allows messages and files to be sent using the SMTP protocol to port 25 (or any other port number). It uses multiple sender profiles and allows for retrying if the receiving computer is busy. There is a DLL version that can be directly installed and renamed to send messages directly from the honeypot. You can send messages with predefined subjects, messages, and attached files. It’s perfect for sending alerts to e-mail systems, cell phones, pagers, PDAs, and so on. It is commonly called by scripts and programs needing more functionality than NET SEND can provide.

Other message-sending programs include Net Send Command Line and Net Send Lite (http://www.rjlsoftware.com), Febooti Command Line (http://www.febooti.com), and WinMessenger (http://www.vypress.com). ServerSentry (http://www.datatribe.net) will also monitor Windows event logs and services, and send trigger messages.