Creating an Internet-Exposed Cowrie Honeypot

Overview

This was a project that had been sitting on my “to do list” for several months. I had come across the idea of deploying a honeypot a while back and knew it would be a valuable hands-on exercise, but like many things, it kept getting pushed aside by day-to-day work and other priorities. I finally set aside some time to focus on it, and once I started working through the setup, everything came together fairly quickly.

Within a few hours I was able to stand up the full environment: deploying the server, installing and configuring Cowrie, exposing the honeypot to the internet, and forwarding the logs into Elastic for analysis. What had initially felt like a larger project ended up being very approachable once I broke it down into smaller steps.

More importantly, the project reinforced how valuable it is to actually build and test these types of environments rather than just reading about them. Being able to watch authentication attempts, attacker commands, and session activity appear in the SIEM in real time made the entire exercise both practical and rewarding. It also reminded me that many of the projects we postpone often only require a focused block of time to get up and running.

One of the most valuable ways to understand attacker behavior is to let them interact with a system designed to observe their activities. In this project, I deployed a Cowrie SSH honeypot on an AWS EC2 instance and integrated it with Elastic SIEM to capture and analyze attack activity.

This setup allowed me to observe:

• SSH brute force attempts
• Credential harvesting behavior
• Commands executed by attackers
• Potential malware downloads

Data was forwarded into Elastic, allowing investigation through Kibana Discover and dashboards.

Objectives

The primary goals of this project were:

• Deploy a publicly accessible honeypot
• Capture attacker activity through Cowrie logs
• Forward logs to a central SIEM
• Analyze attack data through Elastic Discover
• Simulate realistic attacker interaction for investigation practice

Tools and Platforms Used

Lab Architecture

The final architecture routes attacker SSH traffic directly into the honeypot while forwarding logs to the SIEM.

Internet
   │
   │ SSH attempts
   ▼
AWS EC2 Server
   │
   │ Port redirect
   ▼
Cowrie Honeypot 
   │
   │ JSON logs
   ▼
Filebeat
   │
   ▼
Elastic Cloud
   │
   ▼
Kibana Discover

Investigation Setup

Step 1 — Provisioning the Server

An Ubuntu server was deployed in AWS using EC2.

Step 2 — Accessing the Server

Initial administrative access used SSH with a private key.

Step 3 — Installing Cowrie

Cowrie was installed under a dedicated user account to isolate the honeypot process.

Create user:
sudo adduser cowrie
Switch user:
sudo su - cowrie
Clone the repository:
git clone https://github.com/cowrie/cowrie.git
cd cowrie
Install dependencies:
python3 -m venv cowrie-env
source cowrie-env/bin/activate
pip install --upgrade pip
pip install -r requirements.txt

Step 4 — Starting the Honeypot

Cowrie was first started manually to verify proper installation and then later added to run as a service.

Step 5 — Redirecting SSH Traffic

Attackers expect SSH to run on port 22, but Cowrie runs on 2222.

To capture all incoming SSH attempts, traffic to port 22 was redirected using iptables.

Step 6 — Sending Logs to Elastic

Cowrie stores logs as structured JSON.

Filebeat was installed to forward these logs into Elastic.

Lessons Learned

1. Port redirection is essential

Attackers target port 22 by default, so redirecting traffic ensures the honeypot captures realistic attack attempts.

2. Structured logs simplify analysis

Cowrie’s JSON logs integrate seamlessly with SIEM platforms like Elastic.

3. Honeypots generate valuable behavioral data

Unlike simple log collection, honeypots capture attacker decision-making and tactics.

Conclusion

Through this project, I successfully deployed a fully functional SSH honeypot integrated with Elastic SIEM. I exposed the honeypot to the internet and configured telemetry to be forwarded into Elastic, allowing me to observe and analyze attacker activity in near real time. This setup provided a practical environment for monitoring SSH attacks and investigating the behavior of systems interacting with the honeypot.

This environment now provides an excellent platform for:

• threat hunting practice
• SOC investigation workflows
• building detection rules
• studying attacker techniques

Most importantly, it reinforces how visibility and telemetry are critical components of effective security monitoring systems behave. This prepares me to detect, investigate, and respond to threats effectively. Stay tuned for my next write up on the logs that were collected and analyzed using Kibana.