Watching the Hackers: Building an SSH Honeypot with Cowrie

The Endless Noise of SSH Brute-Force

If you manage a Linux server with a public IP, your /var/log/auth.log is likely a graveyard of failed login attempts. It’s a relentless stream of automated scripts from every corner of the globe.

A few years ago, a brute-force attack hit my personal server at 3:00 AM, and ever since, I’ve been obsessed with hardening my setups. But blocking IPs with Fail2Ban or moving SSH to port 2222 only hides the problem. It doesn’t tell you what the attacker planned to do if they actually guessed the password.

Driven by curiosity, I spent the last six months running a digital decoy. I used Cowrie, a medium-interaction SSH and Telnet honeypot designed to let attackers think they’ve won. Instead of a locked door, I gave them a fake room with a hidden camera.

What exactly is Cowrie?

Cowrie is a Python-based application that emulates a vulnerable Unix system. When a hacker connects, they aren’t touching your actual operating system. They are trapped in a sandbox. We call it “medium-interaction” because it provides a functional shell where attackers can execute commands or change passwords, yet they remain isolated from your host’s kernel and hardware.

Here is what makes Cowrie so effective for threat intelligence:

• Deceptive Filesystem: It mimics a standard Debian environment. Attackers can ls, cd, and cat files that exist only in Cowrie’s memory.
• Full Session Replay: Every single keystroke is recorded. If an attacker types a password, Cowrie logs it. If they spend twenty minutes navigating directories, you can replay the entire session like a movie.
• Malware Interception: When an attacker uses wget or curl to pull down a rootkit, Cowrie intercepts the download. It saves the file in a quarantined folder for you to analyze later.

Setting the Trap: Deploying Cowrie on Ubuntu

I recommend running your honeypot on a cheap, $5-a-month VPS. This keeps malicious traffic isolated from your production infrastructure. Here is the workflow I used to get my trap live.

Step 1: Move the Real SSH Service

Before the honeypot can take over port 22, you must move your actual SSH service to a different port. I usually pick something obscure like 8822. If you skip this, you’ll lose access to your server the moment Cowrie starts.

# Edit the SSH configuration
sudo nano /etc/ssh/sshd_config

# Change 'Port 22' to 'Port 8822'
sudo systemctl restart ssh

Double-check that your firewall allows traffic on 8822 before you disconnect. Getting locked out of your own honeypot is an embarrassing mistake I’ve made exactly once.

Step 2: Prepare a Non-Privileged User

Security is about layers. Cowrie should never run as root because a vulnerability in the honeypot itself could compromise the host. Create a dedicated user with limited permissions.

sudo apt-get update
sudo apt-get install git python3-virtualenv libssl-dev libffi-dev build-essential authbind virtualenv -y

sudo adduser --disabled-password cowrie
sudo su - cowrie

Step 3: Install the Environment

Clone the repository and set up a Python virtual environment. This keeps the honeypot’s dependencies from interfering with your system’s Python libraries.

git clone http://github.com/cowrie/cowrie
cd cowrie

virtualenv --python=python3 cowrie-env
source cowrie-env/bin/activate

pip install --upgrade pip
pip install --upgrade -r requirements.txt

Step 4: Customize the Deception

To make the server look like a legitimate target, you need to tweak the configuration. Copy the default template and edit the hostname. I named mine srv-prod-01 to make it look like a high-value production target.

cp etc/cowrie.cfg.dist etc/cowrie.cfg
nano etc/cowrie.cfg

In the [ssh] section, ensure it is set to listen on port 2222. We will use a firewall rule to point the real port 22 traffic here.

Step 5: Redirect Port 22 Traffic

Since non-root users cannot bind to ports below 1024, we use iptables to forward incoming traffic from port 22 to Cowrie’s port 2222. This keeps the process invisible to the attacker.

# Run this as root
sudo iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 2222

Six Months of Data: What I Learned

After running this setup for half a year, the data was staggering. My small VPS collected over 50GB of raw logs and captured 382 unique malware samples. Most of the traffic was automated, but the patterns were fascinating.

The Most Guessed Credentials

Bots don’t just guess admin/admin. They are surprisingly specific. The top five combinations I recorded were:

1. root / root (34,000+ attempts)
2. root / 123456
3. admin / admin
4. root / password
5. oracle / oracle

I also saw a massive surge in attempts for app/app and guest/guest, likely targeting misconfigured cloud instances.

Post-Exploitation Tactics

Once a bot “broke in,” the behavior was almost always scripted. Within 0.5 seconds of logging in, the bot would run uname -a and cat /proc/cpuinfo. It wanted to know if the hardware was worth using for crypto-mining or a DDoS attack.

I captured one particularly clever script that attempted to download a binary, rename it to [kworker/u:1] to look like a kernel process, and then wipe the .bash_history. Because Cowrie logs at the application layer, the attacker’s attempt to hide was useless. I could see the exact URL where the malware lived, which I then reported to the hosting provider’s abuse team.

The Human Element

Using the playlog utility, I watched a few human attackers navigate the system. Unlike bots, humans are hesitant. They type whoami, then wait. They check last to see if anyone else is watching. Watching a real person realize they are in a fake environment—usually after they try to install a kernel module and fail—is the ultimate reward for a security researcher.

The Bottom Line

Running Cowrie turns security from a boring defensive chore into an active intelligence operation. It won’t replace your firewall or your SSH keys, but it provides context that standard logs can’t match. By watching the hackers, you learn exactly what they are looking for before they ever find your real data. If you have a spare server and an hour of time, I highly recommend setting this up. The things you’ll see in your logs will completely change how you approach server hardening.