One of the primary data sources we use on the Splunk Security Research Team is attack data collected from various corners of the globe. We often obtain this data in the wild using honeypots—traps used to engage hackers, with the goal of uncovering new or unusual attack techniques and other malicious activities for research purposes. The nirvana state is a honeypot tailored to mimic the kind of attack/attacker you are hoping to study. To do this effectively, the honeypot must very closely resemble a legitimate system.
Honeypot classification breaks down into the following interaction levels:
Low: Low-interaction honeypots provide only limited interaction (hence the name). They emulate the most basic components of a system, in order to make a connection. They are not vulnerable to emulated exploits.
Medium: This type of honeypot allows some interaction, for example, a bash shell. It emulates pieces of a system, as opposed to a full OS. Like the low-interaction honeypot, it is not inherently vulnerable to the emulated exploits. If you are familiar with honeypots, you’ve probably heard of the infamous “Kippo,” which is a good example of a medium-interaction SSH honeypot.
High: A high-interaction honeypot allows full interaction with the system. Nothing is emulated. It usually a full/real operating system and/or service(s). Ideally, the high-interaction honeypot will be configured to be vulnerable to targeted exploits.
This blog post explains how to build a medium-interaction honeypot with Cowrie, an evolution (fork) of Kippo.
Cowrie includes a ton of new features that Kippo does not. Built to emulate a server with an exploitable/open SSH service and to capture any attackers’ interaction with the service, this medium-interaction honeypot was developed and is maintained by Michel Oosterhof, a fellow Splunker. Our researchers use it (among other tools) to study and collect data from common Internet-wide attacks.
For example, when we first started running Cowrie instances, we noticed many attempted SSH logins with the username “pi.” Our original configuration was not set to allow this user through, so we missed the first few attacks. Next, we adjusted our configurations to allow the user “pi” to log in. A week later, we saw the same attacker return. This time, we let him infect the system, only to find a malicious payload, which looks to have been seen before. (Tobias Olausson did a great job breaking down its behavior and analyzing it here if you’d like to know more about this experiment.)
Unfortunately, as I mentioned earlier, Cowrie and low-/medium-interaction honeypots, in general, do not provide a complete environment (OS). As such, they tend to suffer from being somewhat easy to detect. Further, they also often fail to catch attacks that leverage obscure system calls. This happened to us a few times, when attackers were able to recognize default content in Cowrie’s filesystem. It’s an issue that will plague any research team that runs honeypots. Basically, if you just throw a box out there with a default configuration, you will likely not catch very interesting things.
The image below shows one of those sessions wherein an attacker logged in and immediately exited the honeypot, after seeing that “richard” was the only user in the home directory.
We can mitigate some of Cowrie’s shortcomings by customizing it to appear more compelling to an attacker. Simple things, such as changing the default hostname of your honeypot, or more complex things, such as changing the emulated file system, yield great results. They go a long way towards making your attacker believe they are in a real system.
How to Get Started
Before we can get started with the most interesting part (analyzing data), we have to collect events from Cowrie. Fortunately, this tool provides a prebuilt output plugin for Splunk, using the HTTP event collector. It writes the events in JSON, which is automatically parsed.
Here is an example of the configuration:
enabled = true
url = https://<splunk.instance.address.com>/services/collector/event
token = <HTTP Collector Token>
index = cowrie
sourcetype = cowrie
source = cowrie
Please note that while the process is mostly self-explanatory, you will still need to create an http event-collection endpoint for Cowrie, using the instructions in Splunk Docs. Once you’ve gotten your events into Splunk, you can use various techniques to analyze the attackers’ behaviors at scale. The Tango community-supported Splunk app Tango Honeypot Intelligence does a great job at encapsulating some of these.
Stay tuned for another post on how the Splunk Security Research Team reads Cowrie results. Also forthcoming, we’ll share information on our custom-made high-interaction honeypot designed to circumvent some of Cowrie’s (and other medium-interaction honeypots’) shortcomings.
TL;DR: The Easy Button
We have created a bash script as an “easy button” to automatically configure a Cowrie instance to make it appear, as closely as possible, to be an Ubuntu 14.04 machine. In essence, the script will give your Cowrie instance a makeover, so that it becomes a more interesting and convincing target. If you want the meaty details on how we modified the configuration, our logic behind the changes, and more, check out the git repo.
Deploy run the following (ideally on a newly created AWS instance):
wget -q https://raw.githubusercontent.com/d1vious/splunk_cowrie/master/easy_button.sh
sudo ./easy_button.sh -s <splunk server url> -t <splunk HEC auth token>
Questions or comments? Please share them below!