Making a Honeypot With Cowrie to Catch Hackers

Making a Honeypot With Cowrie to Catch Hackers

So a few months ago, I wrote about how to set up your own VPN with Algo and I demonstrated how to do it live at Radical Networks. I created a demo VPN and invited all of the attendees at the workshop to share it with me. A week later, however, I received this email:

Digital Ocean detected a DDOS attack originating from my server! How could that be possible? I wondered. I was the only one who knew the login password to it. At first, I assumed it was someone torrenting way too much on the VPN, but then I followed up with Digital Ocean and learned a few more things:

I must have been hacked, I realized. The password I used live-coding the VPN setup was ridiculously weak. Like, top 40 passwords weak, probably. I was live-coding!! :sob: While chatting with my friend Tek about it, he suggested that I make a honeypot for fun and to take revenge back at those pesky hackers.

We setup Cowrie, an open source honeypot that you can deploy on Ubuntu or Debian, and I learned a lot of amazing things. But before I get into what I learned, what is a honeypot?

What is a honeypot?

A honeypot is a simulated server environment that tricks hackers into thinking they’ve hacked into your server. It can be configured to let all sorts of username/password combinations log into it. Once the hacker logs in thinking they’ve guessed the correct password, they’re actually inside of a self-contained bubble with its own fake file system. The honeypot logs the password and username they used, tracks and logs every command that the hacker types in, and it also saves anything that the hacker downloads. This is a great way to get your hands on some real malware and reverse engineer it!

Within a day, over a dozen different people/bots logged into the honeypot we set up. I can only assume having seen this activity that there must be hundreds if not thousands of bots scanning the web for servers and trying to brute-force their way in at any given moment.

Then within two days, Cowrie downloaded its first piece of malware! In the future, we’re going to analyze it to find out more about what it does and how it works. I particuarly look forward to writing about that.

Making your own honeypot with Cowrie

Cowrie is an open-source honeypot that you can install onto a linux server like Ubuntu or Debian. For this step by step guide, I’m assuming you’ve already got access to an Ubuntu or Debian server. If not, head on over to Digital Ocean or your favorite cloud hosting provider and rent one!

For more information on installing Cowrie, you can check out their installation guide on Github.

Step 1:

Move the actual SSH port.

We’re going to want the hacker bots to think they’re entering the server through a real SSH port. This is port 22 by default. Because of this, it’s a good defense to move the SSH port on all of your servers anyway! In this case, we’ll move the actual SSH port to a different one and let our honeypot make port 22 act like the real one.

nano /etc/ssh/sshd_config

I changed mine to port 22222, so that means logging back into the server will require me to type:

ssh <username>@<server_IP> -p 22222

Step 2:

Install the pre-requisite software onto the server.

We’re installing:

sudo apt-get update && sudo apt-get install python-pip python-virtualenv git libmpfr-dev libssl-dev libmpc-dev libffi-dev build-essential libpython-dev authbind

Step 3:

Create a Cowrie User and configure Authbind for them.

Next we’ll create a non-root user who’ll be in charge of running the honeypot and listening on port 22.

adduser cowrie

then run the following commands to configure Authbind for this user to listen to port 22.

What is Authbind? According to the description “authbind allows a program which does not or should not run as root to bind to low-numbered ports in a controlled way”. This means, it allows our honeypot to take over port 22, which is normally reserved for super secure server access.

# Create an Authbind file
sudo touch /etc/authbind/byport/22

# Set cowrie as the owner
sudo chown cowrie:cowrie /etc/authbind/byport/22

# Enable full read/write/execute permissions
sudo chmod 777 /etc/authbind/byport/22

Step 4:

Switch to the Cowrie user and download Cowrie with Git.

# Switch user to Cowrie
su cowrie

# Enter into Cowrie's home directory
cd ~

# Clone the Git repository
git clone

# Enter into the directory that was created from Git
cd cowrie

Step 5:

Create a Python Virtual Environment and install the Python dependencies.

# From ~/cowrie
# Start the virtual environment
virtualenv cowrie-env

# Enter inside of it 
source cowrie-env/bin/activate

# Install the python dependencies
pip install -r requirements.txt

Step 6:

Configure Cowrie

First we need to tell Cowrie to listen to port 22 (by default it listens on 2222, but that’s not a port where we’re likely to be visited on).

# Rename the config file to use it
mv cowrie.cfg.dist cowrie.cfg

# Open the config file
nano cowrie.cfg

Inside the config file, look for the line:

listen_endpoints = tcp:2222

and change that line to say:

listen_endpoints = tcp:22

…and have a good read through the configuration file! A lot of these settings can be used to make your honeypot more convincing to human hackers. Some (completely optional) examples:

  • change the hostname hostname = name-of-your-server
  • Playing with ~/cowrie/data/fs.pickle if you want to create an authentic-looking fake file system, apparently.
  • Playing with files in ~/cowrie/honeyfs because this is where you can create fake files stored in the fake fs.pickle directories for people to find and read with the cat command.
  • Set an alternative fake-auth method by setting auth_class = AuthRandom and auth_class_parameters = 2, 5, 10 instead of using the UserDb file. This will randomly allow a successful login after any 2-5 failures, and it will store up to 10 of the lucky username/password combos that got in for future use.
  • Cowrie also supports logging to Slack, an XMP server, or dedicated honeypot sites like VirusTotal, HpFeeds,, and, that aggregate everyone’s honeypot data and provide analysis of it.

Step 7:

Configure the allowed Usernames / Passwords

# Open the userdb file
nano ~/cowrie/data/userdb.txt

This is where you set which usernames and passwords to allow hackers into your honeypot with. You can allow all passwords with the * symbol and deny a specific password with the ! symbol. The lines are evaluated in order, so put your denied passwords at the top and then use * at the bottom of the list.



means that it will deny entry with password 123456 but will allow access with any other password as long as the username is root.

Some common usernames I’ve seen people try are:

  • root
  • admin
  • oracle
  • developer

Step 8

Start Cowrie!

# Start Cowrie!
authbind ~/cowrie/bin/cowrie start

That’s it! Your honeypot should be up and running if you see this message:

Testing out your honeypot

We should pretend like we’re a hacker and test our honeypot to see if it works now!

If you try to SSH into your server now, however, you’ll get an error saying:

This is because you previously logged into the server when it WASN’T a honeypot. Since setting up the honeypot, the RSA keys for the server have changed and your computer now thinks someone has compromised the server. Of course, you meant to do that, so to test out your honeypot you’ll have to include options:

-o UserKnownHostsFile=/dev/null and -o StrictHostKeyChecking=no

like so:

# Tell you computer to ignore the Known Hosts File and login as a username and password that the userdb.txt file will accept.
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no root@<server_ip>

Once you’re inside, let’s download something.

# download the HTML from
curl -o output.html

Now exit and lets check our honeypot for this activity!

Checking your honeypot for rewards

In your honeypot, the key folders to check are:

  • ~/cowrie/log for activity logs
  • ~/cowrie/dl for downloads

In the /dl folder, you’ll see all of the files that people have downloaded. If you’re unsure which file is yours, check for the output line in the logs. You can open it up with the cat command and read it.

It’s important to note that executing these files is extremely dangerous and you shouldn’t be playing around with them on your personal, work, or treasured friend’s computer. You should keep them safe and locked away in a virtual machine somewhere maybe. Handle them with care!!


My honeypot captured malicious activity within minutes. Someone or something logged in with root and then promptly logged out. Within a day, I had my first bit of malware downloaded. Studying this malware is all part of the fun so check back in the future for when I write a blog post about that someday.

Big thanks to Tek who gave me this idea and set this up with me on Tmux!

digital-security   sys-admin-stuff

Because every coding blog needs a comments section.

Please keep comments respectful! Harassment and general arrogance will not be tolerated.