A canary honeypot is a system that mimics a production system and is deployed to serve as an early detection mechanism in the event of a network breach. These honeypots can operate in two different formats; either as an exploitable or non-exploitable honeypot. In this chapter we discuss the difference between these types of honeypots, and discuss considerations for the practical deployment of honeypots for NSM detection. This includes discussion of several popular honeypot applications, such as Honeyd, Kippo, and Tom’s Honeypot, along with examples of their use. This chapter also briefly introduces the concept of Honeydocs, and how to create them.
Network Security Monitoring; Detection; Intrusion Detection System; IDS; NIDS; Detection; Honeypot; Kippo; Honeydoc; Honeyd; Tom’s Honeypot; LaBrea
Phase One: Identify Devices and Services to be Mimicked
Phase Two: Determine Canary Honeypot Placement
Phase Three: Develop Alerting and Logging
By definition, a honeypot is a security resource whose value lies in being probed, attacked, or compromised. In practice, a honeypot often takes the form of either a system or a piece of software that mimics a system or service that is intentionally vulnerable. This system is placed so that an attacker will find the system and exploit it. What the attacker is usually unaware of however, is that the honeypot contains no real data of value and is isolated from other network devices. Network defenders can then use the detailed logging information collected by the honeypot to derive tools, tactics, and procedures used by the attacker.
It is rare to find honeypots on production networks, as it can seem counterintuitive to place a device on a production network that is designed to be breached by an attacker. As a matter of fact, most honeypots are only found in research or academic environments. However, some organizations with mature NSM capabilities have looked to honeypots as an advanced form of detection in their environments. In this chapter we will define the canary honeypot and take a look at different types of honeypots that can be used for NSM purposes. In addition, we will discuss the issue of canary honeypot placement, logging, and best practices for implementation. We will also look at some popular honeypot software solutions.
Before going any further, I should make it absolutely clear that this chapter will discuss some controversial defense tactics. Some organizations steer away from the use of honeypots for legal reasons, which we won’t address here (that’s between you and your lawyer). Other organizations simply don’t understand how to properly secure their environments to ensure that an attacker can’t leverage a compromised honeypot in an unexpected manner, or they just don’t understand how a honeypot can have operational value. Regardless of your disposition towards honeypots, I must stress that the implementation of honeypots for NSM can be a labor-intensive process and is generally only suited for mature SOC environments with 24 × 7 monitoring.
Canaries were originally used as an early warning system by the mining industry. Before technology could be used to gauge the severity of lethal gases in mineshafts, miners would place canaries in cages in these shafts. The canary was more susceptible to lethal gases such as methane, so if the canary became ill or died, the miners knew they were in danger and they should evacuate the mine shaft or take some other type of corrective action, such as opening more ventilation shafts. This same concept helps define the canary honeypot.
A canary honeypot is a system that mimics a production system and is deployed so that it can serve as an early detection mechanism in the event of a network breach. These honeypots can operate in two different formats; either as an exploitable or non-exploitable honeypot.
An exploitable canary honeypot is one that actually uses software to mimic real services, but in a manner that presents some form of vulnerability to an attacker. When the attacker exploits this vulnerability, they are usually provided some limited access to a simulated environment designed to make them believe that they are interacting with a real system. While this is occurring, the honeypot software also generates extensive logs detailing the method the attacker used to breach the faux-service, and their actions within the simulated operating environment. This alerting can also be combined with other forms of detection, including IDS signatures, to aid analysts in utilizing the canary honeypots as a detection resource.
A non-exploitable canary honeypot provides the same legitimate services as the production box it is mirroring, but isn’t designed to be exploited by an attacker in the traditional sense. The only difference between these honeypots and a legitimate production system is that no other legitimate systems are actually communicating with the honeypot. This means that any connection initiated with this system is suspicious. While an attacker won’t actually be able to access this system, if they attempt to log on to it, scan it, or otherwise interact with it, then any signature, anomaly, or statistical detection mechanisms that are deployed in the environment should be configured to generate alerts based upon the attacker actions. This is a similar concept to the Darknet example we looked at with Bro in chapter 10.
Because neither of these honeypot types represents a real business-related service, there is no legitimate reason for anyone to connect to them. While it wouldn’t be possible to utilize this level of extensive logging and alerting with a real production system due to the number of false positives that would be generated, this is a great solution for a system that nobody should ever be communicating with in the first place.
It is important to realize that a canary honeypot isn’t designed to detect an attacker who is gaining initial access into your network. Instead, they are designed to detect the actions of an attacker who has already gained an initial foothold in the network and is attempting to further their level of access. Regardless of how sophisticated attackers might be, they will still take the path of least resistance towards their goals, maintaining only as much stealth as necessary. The prevalence of social engineering and targeted phishing attacks has made defending the perimeter and performing detection across this boundary difficult.
Honeypots are categorized by the level of interaction they provide and are most commonly designated as either low interaction or high interaction. Organizational goals, the assets you are protecting, and the services you wish to emulate will help define the level of interaction needed for your honeypot deployment.
A low interaction honeypot is software-based, and is designed to emulate one or more services. The level of interaction they provide is dependent upon the service being emulated and the software itself. For instance, Kippo is a low interaction honeypot that mimics the SSH service. It allows an attacker to log in to the service and even to browse a fake file system. However, it never allows an attacker to access a real component of the underlying operating system.
A high interaction honeypot is actually configured to mirror a production system, and is designed to give an attacker full reign of an operating system in the event that they are lured into compromising it. This system will be configured to utilize extensive system and file system logging, and will also be subject to a very exhaustive set of IDS rules and monitoring. High interaction honeypots will often exist as virtual machines so that they can be reverted back to a known clean snapshot with relative ease.
When implementing a high interaction honeypot, special precautions must be taken to limit the attacker’s ability to use the system as a staging point for attacks against the production system. They must be allowed to compromise the machine and perform some level of activity without being able to use their control of the system to take advantage of legitimate systems on the network.
High interaction honeypots are useful for intelligence gathering in relation to sophisticated adversaries. However, they require an incredible amount of labor and diligence in their setup, and require constant and rigorous monitoring.
Overall, low interaction honeypots are easier to configure and maintain. They also introduce the least amount of risk into an environment because of their simplicity. If your goal is detection, as it would be in an NSM environment, low interaction honeypots are usually the best fit. This book will focus on low interaction honeypots for NSM detection.
As with all aspects of NSM, the deployment of canary honeypots should be thoroughly planned in relation to the threats faced by your organization, as discussed with the Applied Collection Framework in Chapter 2. With those results in hand, planning the deployment of one or more canary honeypot systems should involve three major steps:
1. Identify the devices and services to be mimicked
2. Determine Canary Honeypot Placement
Let’s examine each of these phases in depth.
Based upon the risk assessment you completed while planning for your NSM collection needs, you should have an idea of which network assets are considered high priority. These are prime targets for having their services replicated with a honeypot system. The goal of this deployment is that a canary honeypot will generate an alert when it has been compromised, serving as an early warning indicator that similar high priority services might be targeted next, or in a worse scenario, that they have already been compromised.
This strategy is best served by deploying honeypot software that will emulate services offered by critical systems. Realistically, software doesn’t exist that will emulate EVERY service that might be critical to your organization, but there are solutions that will emulate a lot of the more common services found in organizations.
As an example, let’s consider an environment in which the most critical network assets were identified as a group of Windows servers that are not externally accessible, and host a proprietary internal application used by the finance department. These Windows servers are part of a domain, and are managed via the Remote Desktop Protocol (RDP). Mimicking the internal application as a honeypot might be difficult to do, but the RDP service is a perfect candidate for being emulated with a honeypot. Tom’s Honeypot, which we will discuss later, provides the ability to mimic an RDP server and will generate an alert when someone even attempts to log in to this server. While it may not be feasible to actively log and examine every RDP login for the other Windows servers, actively reviewing alerts generated from the RDP honeypot is certainly feasible. This is because nobody should ever try to log on to this system since it is not exposed to the Internet.
In another scenario, we have an organization that has several Linux servers that host the back end databases associated with their public facing e-commerce site. The Linux servers are not public facing, and the only services they have running internally are SSH for server management and MySQL for the databases. In this case, both services can be mimicked as honeypots. The SSH service can be mimicked with an SSH honeypot like Kippo, and the MySQL service can be mimicked with a tool like Tom’s Honeypot. Again, nobody should ever log into these particular honeypot systems, so any access to these systems should generate an alert and serve as a warning of a potential internal compromise or an impending attack against your critical systems.
Once you’ve determined which services you intend to emulate, you must place honeypot systems within your network. While placement may seem as simple as deploying the honeypot applications on a host and plugging it into the network, there are other considerations that must be accounted for.
First, you should ensure that the honeypot is placed on the same network segment as the assets it is mimicking. If the honeypot is placed in another segment, then its compromise might not actually indicate that an attacker has made their way into the segment you are trying to protect. As an example, consider Figure 12.1.
In this figure, multiple network segments are shown. The network segment containing the most critical network assets from a threat perspective is the research segment. This is where the canary honeypot systems are placed. Legitimate servers have complementary honeypot systems placed in the network segment alongside them. The Linux File Servers are accompanied by an SSH honeypot, the Windows Application Servers are accompanied by an RDP honeypot, and the Web Servers are paired with an HTTP honeypot.
The primary goal of the honeypot system is to generate alert and log data when someone attempts to access the system or service. With that in mind, you should be certain that your placement of the honeypot allows data to be transmitted to an NSM sensor or log collection device. In Figure 12.1, Sensor B would be responsible for performing detection for this network segment by analyzing data entering and leaving the segment.
Beyond the mechanics of ensuring that the honeypot is functioning properly for its role, you should also ensure that the amount of actual communication that the honeypot can participate in is limited. While the honeypot should be able to respond to the same types of requests as the legitimate assets it mimics it should be prevented from actually initiating communication with other hosts. This can be done with thorough firewall rules on the router that is upstream from the honeypot. In figure 12.1, this upstream router would be the Research Network Router.
The final step in canary honeypot deployment is developing the logging and alerting that will notify analysts that an attacker is interacting with the honeypot system.
First and foremost, you should always be aware of the capabilities of the honeypot software you are using. In some cases, you may find the software has the ability to generate data that can serve as an alert. This might include the ability to generate something like a MySQL database entry or a Syslog event. If this isn’t an option, then you might need to combine the honeypot software with another detection mechanism to generate an alert.
When considering how to best generate alerts from a canary honeypot without using the honeypot software itself, you must consider where the NSM sensor is placed in relation to the honeypot systems. In Figure 12.1, a sensor is placed directly upstream from the critical network segment where the honeypots exist. If an attacker accesses those honeypots from another internal network segment, you can utilize the network detection mechanisms used by that sensor, such as Snort/Suricata, Bro, or a statistical detection tool to generate alerts for honeypot interaction.
Since any interaction with the honeypot should be considered abnormal, you can generate alerts from normal communication sequences in the context of the service being mimicked. For example, IDS signatures for the following events would be appropriate for Figure 12.1:
1. SSH Honeypot – Detecting SSH server banner being transmitted
2. RDP Honeypot – Detecting an RDP login
In a scenario where an attacker is interacting with a honeypot system from a device that they control inside the critical network segment, this sensor would probably not be able to detect the attacker’s actions since that communication wouldn’t traverse the sensor boundary. This can be remedied by configuring a host-based detection mechanism on the honeypot host itself so that alert data can still be generated. This might be a capability inherent to the honeypot software, or might require a third party tool such as OSSEC for host-based detection, or even a custom script. In our example, the host based mechanism could report directly to Sensor B, or another upstream system that is collecting log data.
Once an alert has been generated, an analyst should have the ability to access the logs generated by the honeypot system to determine what the potential attacker did with the system. The amount of detail available in these logs will usually be dependent upon the honeypot software itself, but you should strive to make these logs as verbose as possible. Since the potential for false positives while using canary honeypots is so low, this results in fewer logs, so there isn’t much danger of exceeding your storage capacity or generating an overwhelming flood of log data. Remember that any activity occurring on a honeypot is considered suspicious, because no legitimate user should ever attempt to communicate with it.
With that said false positives can be generated. This is commonly the case with network auto discovery type services, and legitimate internal scanning. This phase of honeypot deployment should also include tuning out false positives, which can be done by excluding honeypot IP addresses from scanning services, or tweaking the detection mechanisms used in conjunction with the honeypot systems.
There are several freely available low interaction honeypots. The remainder of this chapter will be devoted to discussing how a few of these tools can be used as canary honeypots for NSM.
When someone brings up the history of honeypot software, the discussion typically begins with Honeyd. The Honeyd utility was developed by Niels Provos over ten years ago, and provides the ability to emulate hosts as a low-interaction honeypot. Honeyd has been the de facto low-interaction honeypot solution for years, and is so popular that a lot of modern honeypot solutions borrow from its functionality. While it hasn’t been significantly updated in some time, it is still very functional and serves a great purpose as a canary honeypot utility. While there has been more than one version of Honeyd on Windows, the original Honeyd runs exclusively on Unix based operating systems, and that is the version that we will cover here.
The flexibility of Honeyd lies in its ability to emulate a large number of systems and services with a simple configuration file. A single Honeyd instance can spawn dozens, hundreds, and even thousands of honeypot systems. Not only this, but Honeyd will utilize operating system fingerprinting information to mimic the characteristics of the OS down to the layer three and four characteristics that might be expected. When an attacker attempts to determine the operating system of the device they are interacting with, most automated tools will tell them that it is whatever OS you have specified in the Honeyd configuration file, even if that isn’t the true OS that the Honeyd honeypots are running on.
The best way to show the functionality of Honeyd is to demonstrate it in practice. Installing Honeyd can be accomplished via building from source, or using a package manager like APT, with the following command:
apt-get install honeyd
To run Honeyd, we will have to create a configuration file. A default configuration file that contains a few different examples of how the file is structured is provided at /etc/honeypot/honeyd.conf. We will create our own configuration file that is a bit simpler and build upon it. In this example, let’s try to configure a honeypot that mimics a Windows Server 2003 device with only typical Windows ports (135, 139, and 445) open.
First, we must configure a few default settings for Honeyd. These lines are:
set default default tcp action block
set default default udp action block
set default default icmp action block
These first four lines tell Honeyd block all inbound communication to its honeypots unless otherwise specified. Think of this as a default deny rule on a firewall.
Next, we can create a honeypot by using the create command and specifying the name of the honeypot. In this case we will call it ansm_winserver_1:
We want to emulate a Windows Server 2003 device, so we will use the set command along with the personality option to accomplish this.
set ansm_winserver_1 personality “Microsoft Windows Server 2003 Standard Edition”
The personality reference is drawn from the fingerprints database used by the popular Nmap port and vulnerability scanning application. The default installation of Honeyd uses the file /etc/honeypot/nmap.prints for these fingerprints, but this file isn’t even close to being up to date. If you’d like to reference the personality of a modern operating system that isn’t including in the default nmap.prints file, you can create your own entry from the updated Nmap fingerprint database at https://svn.nmap.org/nmap/nmap-os-db. Keep in mind that fingerprints from modern versions of Nmap might require some modification to work properly with Honeyd.
Now that we have created the honeypot itself, we have to configure the ports we want to appear open. In this case we want the three ports that are typically indicative of a Windows system, which are TCP ports 135, 139, and 445.
add ansm_winserver_1 tcp port 135 open
add ansm_winserver_1 tcp port 139 open
add ansm_winserver_1 tcp port 445 open
Our last step is to provide our honeypot with a MAC address and an IP address so that it can communicate on the network. This is done with the set and bind commands, respectively.
set ansm_winserver_1 ethernet “d3:ad:b3:3f:11:11”
bind 172.16.16.202 ansm_winserver_1
At this point, we’ve created everything we need to get this simple honeypot up and running. Assuming you’ve saved these configuration lines into a file named ansm.conf, you can execute Honeyd with the following command:
sudo honeyd –d –f /etc/honeypot/ansm.conf
The –d switch is used to tell Honeyd not to run in daemon mode. This is done so that we can see its output on the screen. The –f switch is used to specify the location of the configuration file we’ve created. Now, we can test Honeyd by port scanning the honeypot we created in the configuration file. The output of this scan is shown in Figure 12.2.
As you might expect, Honeyd has performed extensive logging of this scanning. These logs are stored in Syslog format in /var/log/syslog by default, which makes it incredibly easy to ship this log data to a third party tool like ELSA or Logstash. The log output of our scanning activity is shown in Figure 12.3:
At this point, our honeypot is extremely limited in functionality. While an attacker can scan this host and find open ports (the result of a TCP three-way handshake), they will not actually be able to interact with the host. In cases where you would like to emulate a Windows host that doesn’t provide any services beyond that of a domain controller or file sharing server, the functionality we have now would suffice perfectly for a canary honeypot. Since nobody should ever be communicating with this system, you could place it under the visibility of an IDS sensor that uses a rule like this:
alert ip !$TRUSTED_MS_HOSTS any - > $MS_HONEYPOT_SERVERS [135,139,445] (msg:“Attempted Communication with Windows Honeypot on MS Ports”; sid:5000000; rev:1;)
This rule will detect any TCP or UDP communication to this honeypot (assuming it is included in the $MS_HONEYPOT_SERVERS variable), except for systems in an approved $TRUSTED_MS_HOSTS variable. This variable should be used to exclude communication from devices like domain controllers, or update and management servers such as WSUS and SMS.
To be prepared for scenarios in which a system in the same network segment as this honeypot might attempt to communicate with it, you should also use some type of detection mechanism that can generate alert data from the honeypot server itself. Since Honeyd generates log data in Syslog format, this can be done easily by pushing Syslog data to another host that is capable of generating alerts based upon this data, or by using a host-based IDS tool like OSSEC.
While the current configuration works great for mimicking simple services, the functionality of Honeyd doesn’t stop there. It can also emulate more advanced services by invoking scripts that are tied to specific open ports. As an example, let’s edit our Windows 2003 honeypot so that it will emulate a web server. To do this, add the following line after the other open port designations:
add ansm_winserver_1 tcp port 80 “sh /usr/share/honeyd/scripts/win32/web.sh”
If an attacker attempts to port scan this device now, they would see that port 80 is open, indicating that a web server is present on this system. If that same attacker then actually connects to the system with a web browser, they would actually be presented with a web page. This page is contained with the web.sh script that is called, and can be customized to resemble another web server in your environment. In addition to its standard logging to syslog, Honeyd will log the HTTP client request header of the attacker attempting to connect to the fake web server. This is shown in Figure 12.4.
This level of logging allows you to profile the tools that the attacker is using while attempting to access your infrastructure. For instance, in Figure 12.4 you can see that the attacker is using the Chrome browser (User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.65 Safari/537.36) and the US English character set (Accept-Language: en-US,en;q = 0.8).
In this case, the following IDS rule would detect communication with this canary honeypot:
alert tcp any any - > $WEB_HONEYPOT_SERVERS 80 (msg:“HTTP GET Request to Web Honeypot”; content:“GET”; http_method; sid:5000000; rev:1;)
This rule will generate an alert for any HTTP GET request to this host, assuming it is included in the $WEB_HONEYPOT_SERVERS variable in the IDS engine you are using. If you want to make a more content-specific rule, embed a particular content string in the HTML of the honeypot website, and create a rule that detects that specific string. Honeyd has several scripts that emulate a variety of services in a similar manner, including scripts to emulate SMTP, SNMP, TELNET, POP, and other services. These scripts all provide varying levels of interaction, so you should test them thoroughly to see if they might be a good fit in your environment.
In this chapter we only scratched the surface of Honeyd’s capabilities. In addition to what we’ve shown here, Honeyd also has to ability to redirect an attacker to another system, or even masquerade as a routing device. While it isn’t necessarily as robust as some other honeypot solutions that focus on emulating a single service, its ability to spawn dozens of honeypot systems makes it immensely useful as a canary honeypot for NSM detection. If you want to experiment more with Honeyd, you should check out their documentation at http://honeyd.org/.
The next platform we will look at is one that I’ve already mentioned a few times in this chapter, the Kippo SSH honeypot. Kippo is a low interaction honeypot that simulates an SSH server, and it is designed to detect brute force attempts and log attacker interaction with a simulated shell environment.
Kippo is useful as a canary honeypot because the SSH protocol is commonly used to manage both Unix-based devices and network devices like switches and routers. When an attacker gains a foothold onto the network, a couple of scenarios exist where the attacker might try to access devices using the SSH service:
1. The attacker will attempt a brute force or dictionary attack against the SSH server to gain access
2. The attacker will attempt to guess the password of a user to gain access
3. The attacker will attempt to log into the service with credentials already obtained through some other means
The first scenario might be detectable if the attacker performs these attacks across a sensor boundary where alerts might be triggered. However, if an attacker attempts to perform the brute force attack against a device on the same network segment, then network-based detection won’t be possible. The same applies for the second scenario, but a lower volume of authentication attempts further complicates that scenario. While a brute force or dictionary attack will generate a great deal of traffic that could easily be detected by an IDS signature or some type of statistical detection, an attacker simply guessing passwords for a user might not meet the thresholds for alert generation. In the third scenario, network based detection is nearly impossible through traditional means, because an attacker using legitimate credentials would look almost identical to a user authenticating normally. Our only chance of detecting this type of activity would be through some type of anomaly based detection that notices a user logging into this service from a system they don’t normally use.
As a defender, we can gain leverage against this type of attack by deploying an SSH honeypot like Kippo into a network segment where high priority assets exist. Since nobody should ever log into this system, any login attempt or exchange of network traffic beyond standard broadcast or update traffic should trigger an alert. This places us in a situation where all three scenarios above are detectable, and the canary honeypot can effectively serve as an early warning that someone is in the network performing an unauthorized activity. As an added advantage, if the attacker attempts to use credentials they have obtained through other means, this will become clear to us and incident response can occur, assuming that other services that user has access to might be compromised. The only false positives here might occur when an admin accidentally attempts to log into one of these systems.
You can download Kippo from https://code.google.com/p/kippo/. Since Kippo is a Python script, no compiling or installation is required, and you can run Kippo by executing the start.sh file that is contained in the Kippo directory. Kippo is highly configurable via the kippo.cfg file, but for our purposes here, we will leave the default configuration file intact.
If you are following along and have executed Kippo, then you should be able to connect back in to its faux SSH environment. The default configuration has Kippo launch its SSH service on port 2222. You should set up your honeypot to use whatever port is common within your environment, such as the default port 22.
At baseline, Kippo will log any attempt to log into the service, complete with the username and password used in the attempt. These files are logged by default in the log/kippo.log directory. A sample output from this log is shown in Figure 12.5.
Kippo can be configured to allow a potential attacker to log into its simulated file system by specifying a user account and password that will allow for successful authentication. This username and password is specified in the data/userdb.txt file, and is username “root” and password “123456” by default. If an attacker utilizes this username and password combination, they will be presented with a fake file system that they can browse around in, and that even allows them to create and delete files, shown in Figure 12.6.
As you might expect, the attacker’s actions in this environment are logged thoroughly as well. An example of one of these logs is shown in Figure 12.7.
In the example above, we can see that the attacker attempts to send the /etc/passwd file back to the host they logged in from the SCP and FTP commands. The SCP and FTP clients aren’t available in this environment, so the system indicates that the commands aren’t found. The default kippo.log file doesn’t show verbose output of these commands, but this information can be found in the log/tty folder. This folder contains a detailed binary log file of the actions taken in every terminal spawned by the software. Each file name is based upon the timestamp of when the terminal is initialized. These files aren’t easily viewable in plaintext, and are designed to be played back with Kippo’s playlog.py utility in the util/ folder. This utility will replay as if you were sitting over the attacker’s shoulder watching their interaction with the terminal. This shows the command input in real time, and captures every keystroke, backspace, and pause. This output is very impressive when used in presentations. Figure 12.8 shows the playlog.py output for the attack sequence shown in Figure 12.7. You can see the more verbose output of the id command that isn’t shown in the base kippo.log file.
The additional level of interaction that Kippo provides with its fake file system is useful for gaining intelligence related to an attacker’s motives or tactics. Often, the first thing an attacker does when they gain access to a system is to download additional files from an external site. This might include malware, a keylogger, a backdoor, or a rootkit that will further their attack goals. When they attempt to download these tools in the Kippo environment, you can see the remote host they are attempting to access and the tools they attempt to download. This incredibly useful intelligence can be used to help shape collection, detection, and analysis strategy.
The native Kippo logging format is fairly easily parseable by other tools, and it also provides the option to log to a MySQL database, which can be useful for incorporating Kippo data into another tool. To enhance detection, IDS signatures and other detection mechanisms can be paired with the honeypot server itself. This is generally the preferred method for alerting on honeypot interaction. For instance, the following Snort/Suricata IDS rules can be used to indicate an attempt to authenticate to a honeypot system.
alert tcp $HONEYPOT_SERVERS $SSH_PORTS - > any any (msg:“ET POLICY SSH Server Banner Detected on Expected Port – Honeypot System”; flow: from_server,established; content:“SSH-”; offset: 0; depth: 4; byte_test: 1,>,48,0,relative; byte_test:1,<,51,0,relative; byte_test:1,=,46,1, relative; reference:url,doc.emergingthreats.net/2001973; classtype:misc-activity; sid:2001973; rev:8;)
alert tcp any any <> $HONEYPOT_SERVERS $SSH_PORTS (msg:“ET POLICY SSH session in progress on Expected Port – Honeypot System”; threshold: type both, track by_src, count 2, seconds 300; reference:url,doc.emergingthreats.net/2001978; classtype:misc-activity; sid:2001978; rev:7;)
The first rule shown above (SID 2001973) detects the SSH server banner being transmitted to a client. The second rule (SID 2001978) detects an SSH session in progress. These rules are provided by Emerging Threats, and you should note that I’ve modified them here to only detect traffic occurring to systems identified by the $HONEYPOT_SERVERS variable, which would have to be configured on your sensor for these rules to work.
Utilizing rules like these, you should be alerted whenever a sensor detects that someone has interacted with the SSH service on the honeypot system. At this point, you can reference the log data generated by Kippo to assess the extent of the interaction. Remember, this activity can only be detected if an attacker accesses the honeypot in a manner where the sensor can see it. To perform detection against events occurring from within the same network segment, you would have to generate alerts from the Honeypot system itself. There are a couple of ways to do this, such as sending Kippo logs to syslog and alerting on certain events, or using a host-based detection program such as OSSEC.
Kippo has a few more features that aren’t covered here, and a number of additional utilities and third party enhancements that are worth looking into. You can learn more about all of this at https://code.google.com/p/kippo/.
The last honeypot we will look at is Tom’s Honeypot, which was developed by Tom Liston, the developer of one of the earliest production honeypots, the LaBrea Tar Pit. Tom’s Honeypot is a low interaction Python honeypot that is designed to mimic a few specific services that are commonly targeted by attackers. These services include:
• Remote Desktop Protocol (RDP) (TCP/3389)
• Microsoft SQL Server (MSSQL) (TCP/1433, UDP/1434)
• Virtual Network Computer (VNC) (TCP/5900)
• RAdmin (Remote Administration) (TCP/4899)
Tom’s Honeypot listens on specified ports for communication related to these services. When an attacker attempts to access one of these services, an alert is generated in the tomshoneypot.log file.
Since Tom’s Honeypot is just a Python script, all you need to do to run it is install a prerequisite (the Python Twisted module) and then use Python to run it. The following command will install the prerequisite in Security Onion:
sudo apt-get install python-twisted
The script can be obtained from http://labs.inguardians.com/tomshoneypot. It can be executed by running the following command:
By default, Tom’s Honeypot runs with all of its available services turned on. If you only want to run a subset of these services, you will have to manually edit the script and comment the appropriate sections out. These sections are:
reactor.listenTCP(1433, fMSSQL, interface = interface)
reactor.listenTCP(3389, fTS, interface = interface)
reactor.listenTCP(5900, fVNC, interface = interface)
reactor.listenTCP(22292, fDump, interface = interface)
reactor.listenTCP(4899, fRAdmind, interface = interface)
reactor.listenUDP(1434, uFakeMSSQL(), interface = interface)
reactor.listenUDP(5060, uFakeSIP(), interface = interface)
If you don’t want to run a particular service, simple place a pound symbol at the beginning of that services line. This will cause the Python interpreter to skip this line and forgo starting a listener on the ports tied to these services.
As an example, let’s take a look at one of these services. The RDP protocol is used for remote desktop administration of Windows hosts. In a common attack scenario where an attacker has gained a foothold onto the network, they will typically do some scanning to determining what other targets they can access. The RDP service typically utilizes port 3389, and when an attacker sees this port open they will usually try to connect to it with an RDP client. If the attacker has gained users’ credentials through some other means, the RDP service could allow them to take control of the server and begin pillaging data. Even if the attacker doesn’t have a user’s credentials, they could still use the RDP server to attempt to guess a user’s password, or simply to enumerate the version of Windows running on the machine.
In this case of Tom’s Honeypot, a fake RDP server will run over port 3389 to entice an attacker to interact with the service. When the attacker attempts this, the device they are attacking from will complete a three-way TCP handshake with the honeypot, and will then initiate an RDP connection request; however, the honeypot will not generate a response back. A typical attacker will usually assume this is because some type of host restriction is in place, or that the service is simply malfunctioning. However, this is occurring because there is no legitimate RDP service to log into, and instead of providing an RDP server to log into, Tom’s Honeypot simply logs the access to the fake system. An example of such a log is shown in Figure 12.9.
In the logs shown above, you’ll notice five individual entries. Four of these entries include a “Login” field. While Tom’s Honeypot won’t generate an interactive screen that an attacker can attempt to log into, it takes advantage of the fact that an RDP client will attempt to transmit a cookie during its initial negotiation request. This RDP cookie doesn’t have anything to do with authentication, but it does contain a username that is used for terminal services identification. The first log in Figure 12.9 doesn’t show any result for this field because no RDP cookie was present during that connection attempt, but the following four log entries have values present. The second and third entries show two different IP addresses attempting to make connections to the honeypot with RDP cookie usernames values of “a” and “j”. The last two log entries show two attempts from the IP address 192.0.2.234, using the RDP cookie username “NCRACK_USER.” The Ncrack tool is an authentication-cracking tool that can be used to attack RDP servers. This would indicate that 192.0.2.234 is attempting to obtain unauthorized access to the honeypot system.
The other fake services provided by Tom’s Honeypot work in a similar manner. Figure 12.10 shows an example of logs generated from the MSSQL and SIP honeypot services.
Two logs are shown in Figure 12.10. The first log shows data obtained from an attacker attempting to communicate with Tom’s Honeypot via a MS SQL client (TCP port 1433). Note that this output shows information about the client used to connect to the fake MS SQL service.
The second log shows someone attempting to communicate with the honeypot via the SIP protocol (UDP 5060), which is commonly used by Voice over IP (VoIP) services. In this case, we see that this traffic is associated with the Sipvicious tool, which is used for scanning, enumerating, and auditing SIP services.
Tom’s Honeypot is an actively developed project, and it is likely that by the time this book is published, even more features will have been added. If you want to learn more about Tom’s Honeypot, you can visit the project site at http://labs.inguardians.com/tomshoneypot/.
When conceptualizing information security, we often focus on protecting systems and processes. While this is certainly a worthwhile venture, it usually isn’t the systems and processes that we are actually trying to protect; it is the data that resides within them. That is where a honeydoc comes into play.
A honeydoc is a specialized form of “honey technology.” Instead of mimicking a legitimate system and logging access to that system, a honeydoc mimics a legitimate document, and logs access to that document.
In a typical deployment, a honeydoc containing a bunch of false data is created and placed alongside legitimate data. Along with the false data, the honeydoc will contain some type of hidden code that references a third party server. The goal here is that an attacker who succeeds in accessing secure data will eventually open this honeydoc, and their system will connect to the third party system. The third party system will, of course, log any details it can about the client that has opened to document.
There are a number of ways to create a honeydoc, but the most common method involves including code in the document that will force the generation of an HTTP request when the document is opened. While these requests can be blocked or subverted, they are often fairly successful when dealing with an inexperienced or hasty attacker.
As an example, let’s create a honeydoc using a Microsoft Word document. The quickest way to do this is to create a plain text document devoid of any special formatting. This can be done from the terminal or from a tool like Notepad or Textedit. This document should contain a set of fake data that might be of interest to an attacker, like a list of fake users or password hashes. With the data in place, you should surround the data with the < html > and </html > tags to designate it as web content. As a last step, we can place the content that will generate the request to our web server. This can be done by using the HTML < img > tag, but instead of providing the URL location of an image, we will provide a serialized URL to our web server, like this:
< img src = “http://172.16.16.202/doc123456”>
In a real world scenario, this URL would point towards a public IP address or domain name. It is important that each honeydoc is serialized, so that you can keep track of requests generated from each document. The resulting honeydoc you’ve created should look similar to Figure 12.11.
The last step in this process is to save this document in the appropriate format. This is usually going to be a .doc or .docx file for compatibility with an application like Microsoft Word. Now, when you open this document Word will attempt to download the image file referenced in the < img > tag, but instead, will generate a GET request to your web server. For the purposes of this example, I pointed a honeydoc to a Honeyd server, which generated the output in Figure 12.12.
With this log data, you could easily generate an alert that will notify analysts that a honeydoc has been accessed. Since honeydocs will often reside next to real data, it is always possible that a legitimate user could access a honeydoc mistakenly, but this shouldn’t be a common occurrence.
Honeydocs aren’t restricted to text documents. This scenario could be applied to other types of files including HTML pages, PDF files, or even XLS files. If you want to experiment with the creation and tracking of a Honeydoc without setting up a web server, the Honeydocs.com service was launched with the goal to automate the creation of Honeydocs, as well as the tracking of honeydoc campaigns (or stings, as they call them). You can register at honeydocs.com for free, which allows for the creation of a single sting that can contain multiple honeydocs. For a fee, you can create more stings and utilize the Honeydoc service to generate e-mail or SMS alerts whenever a honeydoc you’ve created is accessed. Figure 12.13 shows an example of the Honeydocs.com web interface.
Figure 12.13 The Honeydocs.com Web Interface
I’ve seen honeydocs of various types used in a variety of detection and response scenarios with great success. However, I must provide the warning that honeydocs aren’t entirely covert, and even a relatively unskilled attacker will be able to notice a document attempting to communicate with an external host. This could expose the third party server to probes by the attacker, so you should ensure that this host is secure, and ideally, located away from your corporate network. It should also be unattributable to your organization. In a best case scenario, the attacker doesn’t notice the honeydoc “phoning home” at all. If they do notice, you will want to minimize risk as much as possible. With all of this said, great care should be taken when implementing honeydocs, as with the other technologies discussed in this chapter.
In this chapter we’ve taken a look at the application of canary honeypots in an NSM environment. This includes the placement of canary honeypots, alerting and logging considerations, and a few different honeypot software solutions that can serve this purpose. We also took a quick look at honeydocs and how they can be used for NSM detection. While honeypots have traditionally been reserved for research purposes, the strategies discussed here can make canary honeypots an incredibly useful detection mechanism in the fight against the adversary.