Building My Honeypot: A Journey into Attack Visibility

Sep 10

Why I Built a Honeypot

As a cybersecurity professional, I spend most of my time defending against threats. But defense alone doesn’t always provide the bigger picture. I wanted to see what attackers actually do in the wild — the commands they run, the tools they drop, and the persistence tricks they try. That curiosity is what pushed me to set up a honeypot.

For this project, I chose Cowrie — a medium-interaction SSH and Telnet honeypot that simulates a Linux system. It records every login attempt, command, and file transfer. Perfect for gathering raw data on attacker behavior.

My Setup

I spun up a DigitalOcean droplet running Ubuntu Server. This gave me a clean, isolated VM that I could safely expose to the internet.

Environment

OS: Ubuntu 22.04 LTS
Service: Cowrie honeypot
Logging: JSON logs shipped to my internal OpenCTI instance
Network exposure: SSH traffic forwarded to Cowrie on port 2222

Hardening

While the goal is to lure attackers, it’s equally important to ensure they can’t pivot out of the honeypot. I hardened the droplet by:

Running Cowrie as a non-privileged user
Blocking all unnecessary inbound ports (only SSH open)
Using fail2ban + firewall rules to protect the management SSH port (different from the honeypot one)
Keeping system packages up to date

Deploying Cowrie

Installation was straightforward:

# Update packages
sudo apt update && sudo apt upgrade -y

# Install dependencies
sudo apt install git python3 python3-venv python3-pip libssl-dev libffi-dev build-essential -y

# Clone Cowrie
git clone https://github.com/cowrie/cowrie.git
cd cowrie

# Create a virtual environment
python3 -m venv cowrie-env
source cowrie-env/bin/activate

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

Then I configured cowrie.cfg to:

Run on port 2222
Emulate a fake file system with common Linux binaries
Log output in JSON format

Log Shipping

The real fun started when I integrated Cowrie with OpenCTI. Every login attempt, successful or not, and every command run gets funneled into my threat intelligence platform. This allows me to pivot from IP addresses → domains → malware families, and enrich attacker infrastructure in near real time.

Here’s a snippet of my shipper configuration (simplified):

output:
  type: file
  path: /var/log/cowrie/cowrie.json

shipper:
  enabled: true
  send_success: true
  send_failures: true
  destination: http://opencti.local:8080

Early Results

Within hours of exposing the honeypot, I saw traffic.

Common passwords: root/123456, admin/admin, root/toor
Commands: attackers immediately tried enumerating system info (uname, cat /etc/*release*) and pulling crypto-mining scripts from pastebins.
Persistence attempts: I’ve already caught injected SSH keys and cronjob modifications.

Each event becomes a story, and every story adds context to how real-world attackers behave.

Lessons Learned

Don’t just expose a honeypot without hardening the host — assume compromise.
Logging is everything. The real value isn’t just catching attackers, but learning from the data.
Small tweaks (like enabling notifications for both successful and unsuccessful logins) make analysis far more effective.

What’s Next

I plan to:

Enrich honeypot events with threat intel feeds inside OpenCTI
Build detection rules for observed TTPs
Share periodic write-ups of attacker behaviors

This honeypot is more than a research tool — it’s a way to stay sharp, continuously learn, and give back to the cybersecurity community.

👉 If you’re interested in the logs or configs I used, drop a comment or reach out on LinkedIn. I’ll keep publishing updates as my honeypot continues to collect attacker activity.

Trae Morris https://traemorris.net