Honeypots are a great way to learn more information about how different services are being exploited, to monitor malicious activity in an isolated environment and to gather information about subjects such as usernames, passwords, shell commands, etc. Some honeypots are also equipped with the ability to capture binaries transferred to the server, and further analysis of these can reveal undetected malware.
In this tutorial we will go over the installation and configuration of Cowrie and Dionaea – two powerful honeypots that complements each other nicely. Dionaea is a honeypot designed to emulate vulnerable services ranging from the network file sharing protocol for Windows (SMB) to SQL servers. Cowrie is designed to emulate a vulnerable SSH and Telnet server. Both of these honeypots are designed to capture the behavior of the attacker and to collect binaries transferred to the server by intruders.
The goal of this tutorial is to set up a honeypot server that can capture the behavior of an attacker as well as binaries such as ransomware worms. The setup will consist of the following two components:
- Dionaea: A honeypot designed to capture malware.
- Cowrie: A SSH and Telnet honeypot designed to log brute force attempts and the behavior of an attacker.
To complete this tutorial you are going to need root access to an Ubuntu 14.04 server, whose sole purpose is to be utilized as a honeypot. Both Cowrie and Dionaea are fairly safe to run, but they do not come with any guarantees – storing any sensitive information on the honeypot is therefore not advised.
The author of this tutorial utilizes a virtual server rented from DigitalOcean that has 1 CPU and 512MB memory, which only costs $5/month to operate.
Installing and configuring Dionaea
SSH into your honeypot and begin with the following two commands to ensure that the distribution is up-to-date:
$ sudo apt-get update $ sudo apt-get dist-upgrade
Make sure that the necessary tools are available in order to easily manage Personal Package Archive (PPA) resources:
$ sudo apt-get install software-properties-common
Now add the PPA which Dionaea resides in and update the cache of the package manager:
$ sudo add-apt-repository ppa:honeynet/nightly $ sudo apt-get update
You should now be able to install Dionaea through the package manager:
$ sudo apt-get install dionaea
Once Dionaea is installed, change directory to the Dionaea configuration directory and list the contents of it:
$ cd /opt/dionaea/etc/dionaea $ ls
You will now be presented the following file and directories:
The dionaea.cfg file holds general configuration about the honeypot, such as which modules the honeypot will make use of and details about the raw log files. The raw log file of Dionaea can accumulate to a size in the name of gigabytes within weeks, so consider disabling it by commenting it out, unless you need it for debugging:
[logging] #default.filename=/opt/dionaea/var/dionaea/dionaea.log #default.levels=all #default.domains=* errors.filename=/opt/dionaea/var/dionaea/dionaea-errors.log errors.levels=warning,error errors.domains=*
In the ihandlers-available directory, you will find tools Dionaea can make use of in order to process binaries or to log incidents. In the ihandlers-enabled directory, you will find those already enabled. If you want to enable an ihandler, you will have to make a symbolic link in the ihandlers-enabled directory that points to the ihandler you want to enable. Some ihandlers require configuration, so you should read about the specific ihandler in the official Dionaea documentation before enabling it.
The services are protocols such as SMB, FTP and MySQL that the honeypot mimics. These are enabled by using the same method as the ihandlers. By default, all available services are enabled. If you would like to disable a service, simply delete the symbolic link from the services-enabled directory.
This tutorial would like to make use of Dionaea’s ihandler for processing captured binaries with VirusTotal, if you would like this too you will need to register an account at virustotal.com, if you have not already got one. Once you have registered the account, sign in to it and head to the settings page. In the settings page you will be able to obtain a public API key, which Dionaea will use to communicate directly with VirusTotal.
First we need to edit the configuration file of the ihandler, which is the ihandler itself. Paste your API key between the empty quotes (you should still be in the /opt/dionaea/etc/dionaea directory):
$ sudo nano ihandlers-available/virustotal.yaml
Exit the file. We now need to enable the ihandler by creating a symbolic link to it from the ihandlers-enabled directory:
$ sudo ln -s ../ihandlers-available/virustotal.yaml ihandlers-enabled/virustotal.yaml
Dionaea will by default listen on the port 23 (Telnet) with its black hole service, which means it will open a connection when an entity tries to connect to the port, but it will not respond to it. This tutorial will utilize Cowrie for Telnet, this means we will have to remove port 23 from the black hole service of Dionaea:
$ sudo nano services-available/blackhole.yaml
Comment out the configuration of port 23 by putting a # in front of it, like so:
- name: blackhole config: services: # Telnet #- port: 23 # protocol: tcp
After you have decided on a configuration, you may start the honeypot:
$ sudo service dionaea start
Note: A simple Nmap scan of the server will reveal that it is running a Dionaea honeypot. Most of the attacks against Dionaea are automated, so this won’t matter. However, if you would like for the Dionaea honeypot to evade Nmap detection, check out the following tutorial:
Installing and configuring Cowrie
You are most likely logged into the server through SSH, which is the service Cowrie is designed to emulate. SSH runs by default on port 22, we need to change the original SSH service to listen to another port so Cowrie can make use of port 22:
$ sudo nano /etc/ssh/sshd_config
Remove the # from the following line and change the 22 to something else, like 2122.
# Port 22
Restart the SSH service (remember to use the new port next time you connect!):
$ sudo service ssh restart
We can now prepare to install Cowrie by installing some dependencies:
$ sudo apt-get install git python-virtualenv libssl-dev libffi-dev build-essential libpython-dev python2.7-minimal authbind
Create a new user responsible for running the cowrie honeypot (use default settings):
$ sudo adduser cowrie
Now we need to delete the password for the user. This way nobody will be able to sign into the user, but we can still switch to the user with the su command:
$ sudo passwd -d cowrie
Switch user to the newly created cowrie user and change directory to the its home folder:
$ sudo su cowrie $ cd
Clone the Cowrie honeypot from Github and change directory to it:
$ git clone http://github.com/micheloosterhof/cowrie $ cd cowrie
Make sure you are working from the directory /home/cowrie/cowrie:
$ pwd /home/cowrie/cowrie
Create a virtual environment for the Cowrie honeypot:
$ virtualenv cowrie-env
Activate the virtual environment:
$ source cowrie-env/bin/activate
Install some required python packages to the virtual environment:
(cowrie-env)$ pip install --upgrade pip (cowrie-env)$ pip install --upgrade -r requirements.txt
Exit from the virtual environment:
Generate a backup SSH key in case the python package Twisted is not compatible:
$ cd data $ ssh-keygen -t dsa -b 1024 -f ssh_host_dsa_key $ cd ..
Ensure that Twisted is able to reach the startup file for Cowrie sufficiently:
$ export PYTHONPATH=/home/cowrie/cowrie
There are ways an attacker may use to figure out that they are inside a Cowrie honeypot. The most notable sign is that there is only one directory under /home, which is named richard. Another sign is the that the server is using the hostname srv04.
The developers of Cowrie have included a tool that lets us rebuild the fictive filesystem, but offers little documentation as to how it works. It might be easier to just edit a few files in order to fix this.
First we need to change the hostname, this is done in the configuration file of Cowrie. By default, Cowrie comes with a configuration file that may be overwritten when performing upgrades to the it. Let’s make sure that Cowrie does not overwrite our configurations by making a second configuration file. Cowrie will read both configuration files, but configurations made in cowrie.cfg will take precedence:
$ cp cowrie.cfg.dist cowrie.cfg $ nano cowrie.cfg
Remove the # from the following line and change “srv04” into something else:
# hostname = srv04
While we are in the config file, we can also update Cowrie to listen to port 22 directly. Remove the # from the following line and change 2222 to 22:
# listen_port = 2222
Go down to the following line, and do the same – change 2222 to 22:
listen_endpoints = tcp:2222:interface=0.0.0.0
In the same config file, enable telnet by replacing false with true in the following line:
[telnet] # Enable Telnet support, disabled by default enabled = false
Make Cowrie listen to the correct port of Telnet, which is 23. Remove the hashtag and edit 2223 to 23:
#listen_port = 2223
Almost done, change 2223 in the following line to 23:
listen_endpoints = tcp:2223:interface=0.0.0.0
Save and exit. Now we can start fixing the richard-issue, edit the following file:
$ nano data/fs.pickle
Now we need to define which fictive user the filesystem is going to use. Find the following line and change “richard” into something else, like “admin” or “supervisor” (Hint: use ctrl+w to search for richard inside the file):
Exit and save the file, now edit the following file:
$ nano honeyfs/etc/passwd
Find the following line and change it according to the user that you defined above:
Exit and save, now edit the following file:
$ nano honeyfs/etc/group
Change the group name from richard to the previously defined user:
Save and exit, now for the next file:
$ nano honeyfs/etc/shadow
Swap “richard” with the new username:
Save and exit.
Excellent! We have now changed the username and hostname, now we need to administrate which passwords to accept:
$ nano data/userdb.txt
By default, Cowrie will allow any password except “root” and “123456”:
root:x:!root root:x:!123456 root:x:* richard:x:* richard:x:fout
This tutorial recommends to only allow one, slightly common, password for each user – this way you will gather more information about popular passwords. It is all about finding a balance between a not-so-common password and a not-so-obscure password – you will probably want to gather information from successful logins as well. Replace the above configuration with the one below:
Consult the following Top 10 000 password list if you need inspiration. Experiment with the results by moving from a top 100 password to a top 1 500 password and find what result suits you best:
Exit the from the user cowrie:
We have configured Cowrie to listen on port 22 and 23. However, this collides with two security issues: 1) Only privileged users may listen on ports below 1024 and 2) The Cowrie honeypot should not be executed by a privileged user.
The solution to this dilemma is Authbind, which lets us override the first rule in order to let our unprivileged cowrie user listen on port 22 and port 23 directly:
$ sudo apt-get install authbind $ sudo touch /etc/authbind/byport/22 $ sudo chown cowrie:cowrie /etc/authbind/byport/22 $ sudo chmod 770 /etc/authbind/byport/22 $ sudo touch /etc/authbind/byport/23 $ sudo chown cowrie:cowrie /etc/authbind/byport/23 $ sudo chmod 770 /etc/authbind/byport/23
Change the execution file of Cowrie to reflect that it is going to use Authbind:
$ sudo nano /home/cowrie/cowrie/bin/cowrie
Change the following from “no” to “yes”:
Switch back into the user cowrie again, because root should not start cowrie:
$ su cowrie
Start Cowrie and exit back to the original user:
$ /home/cowrie/cowrie/bin/cowrie start $ exit
Some useful places to know about
Captured binaries: /opt/dionaea/var/dionaea/binaries
Session transcripts: /opt/dionaea/var/dionaea/bistreams/YYYY-MM-DD
Captured binaries: /home/cowrie/cowrie/dl
Playback files: /home/cowrie/cowrie/log/tty
In this tutorial we have configured a server to run the honeypots Cowrie and Dionaea. Together they are emulating vulnerabilities on the following services:
|Microsoft SQL Server||1433||Dionaea|
|Microsoft EPMAP (aka. DCE/RPC)||135||Dionaea|
|DNS||53||Dionaea (black hole)|
|NTP||123||Dionaea (black hole)|
The information about the behavior of the attackers are currently residing in logs, which can be painful to sift through. In the next part of this tutorial, we will look at how we can visualize this data by utilizing the ELK stack.
Next tutorial: Visualizing the logs using the ELK stack
Execute Malware – Honeypots Revisited (March 21, 2017):
The official documents of Dionaea and Cowrie.
The official documentation of Dionaea:
The official Github page of Cowrie: