How to Fingerprint Popular honeypots from Your Laptop

A beginner-friendly, step-by-step guide using Docker, AWS Spot, and the open source honeypot-auditor

Shodan can whisper “honeypot.” Protocol behavior is louder.

If you are new to defensive cybersecurity (blue teaming), you might think honeypots are decoy systems designed to trick attackers and are completely indistinguishable from real production servers. In reality, honeypots rely on fake software responses (“emulators”) that often leave subtle technical clues behind.

Checking if a host is a honeypot based on its network behavior is called fingerprinting.

In this tutorial, you will set up a cloud lab on AWS (free tier) for under $0.05/hour, deploy three legendary honeypots using Docker, and run honeypot-auditor 1.0.0 directly from your local computer to fingerprint them over the internet.

Safety & Scope: Only scan systems you own or have explicit permission to test. In this lab, we configure AWS firewalls so that only your local IP address can talk to these decoy servers. Do not leave honeypot ports wide open to the internet unless you want uninvited malware scripts attacking your instance within minutes or even seconds.

Key Concepts for Beginners

Before touching the terminal, let’s demystify the terms used in this lab:

• Honeypot: A security mechanism set up to detect, deflect, or study attempts at unauthorized use of information systems by simulating network services to look real.
• Low vs. Medium Interaction: A low-interaction honeypot (like Dionaea) only emulates basic network protocols and drops connections quickly. A medium-interaction honeypot (like Cowrie) provides a fake shell where an attacker can type commands and perform deeper interaction.
• Honeyscore: A probability score (0% to 100%) calculated by honeypot-auditor estimating how likely a host is to be a decoy system.
• AWS Spot Instance: Spare computing capacity in AWS available at up to a 90% discount compared to standard rates. Perfect for temporary disposable labs.
• AWS Security Group: A virtual firewall that controls inbound and outbound network traffic to your cloud instance.

Lab Architecture

[ Your Local Laptop / Workstation ]
 └─ Python Virtual Environment
     └─ honeypot-auditor 1.0.0
           │
           │  (Remote WAN probes across the internet)
           ▼  (AWS Security Group locked strictly to YOUR_IP/32)
[ AWS EC2 Spot Instance (Ubuntu 24.04) ]
 └─ Docker Engine & Docker Compose
     ├─ Cowrie Honeypot       (SSH on :2222, Telnet on :2223)
     ├─ Dionaea Honeypot      (FTP, HTTP, SMB, SIP, VNC, Redis, MySQL, MSSQL)
     └─ OpenCanary Honeypot   (SSH, HTTP, MySQL, FTP, Redis)

Prerequisites

• An AWS Account with basic permissions to create EC2 instances and Security Groups.
• AWS CLI v2 installed and configured on your local machine (aws sts get-caller-identity works).
• A local terminal with Python 3.10+ and Docker installed locally (optional, but helpful).

Step 1: Find Your IP and Provision the Firewall

To make sure random internet bots don’t mess up your lab test, you must restrict access to your public IP.

Open a terminal on your local computer:

Bash

# 1. Get your current public IP address
export MY_IP=$(curl -s https://checkip.amazonaws.com)
echo "Your public IP is: $MY_IP"
# 2. Set your default AWS region
export AWS_DEFAULT_REGION="us-east-1"
# 3. Create a dedicated Security Group in AWS
SG_ID=$(aws ec2 create-security-group \
  --group-name "honeypot-lab-sg" \
  --description "Inbound access for honeypot lab from local IP only" \
  --query 'GroupId' --output text)
echo "Security Group Created: $SG_ID"
# 4. Allow inbound traffic on honeypot ports ONLY from your public IP address
aws ec2 authorize-security-group-ingress \
  --group-id "$SG_ID" \
  --protocol tcp \
  --port 2000-30000 \
  --cidr "$MY_IP/32"
# 5. Allow SSH access (port 22) to manage the VM
aws ec2 authorize-security-group-ingress \
  --group-id "$SG_ID" \
  --protocol tcp \
  --port 22 \
  --cidr "$MY_IP/32"

Step 2: Launch the AWS Spot Instance

Launch a lightweight Ubuntu 24.04 instance attached to the Security Group you just built.

# Launch a t3.medium Spot Instance
INSTANCE_ID=$(aws ec2 run-instances \
  --image-id ami-0c7217cdde317cfec \
  --instance-type t3.medium \
  --security-group-ids "$SG_ID" \
  --instance-market-options '{"MarketType":"spot"}' \
  --query 'Instances[0].InstanceId' --output text)
echo "Spot Instance ID: $INSTANCE_ID"
# Wait for instance to start running
aws ec2 wait instance-running --instance-ids "$INSTANCE_ID"
# Grab the Public IP of your new instance
TARGET_IP=$(aws ec2 describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[0].Instances[0].PublicIpAddress' --output text)
echo "=========================================="
echo "Target AWS Instance Public IP: $TARGET_IP"
echo "=========================================="

Step 3: Deploy the Honeypots via Docker

Now, SSH into your newly created AWS instance (or use AWS SSM Manager) to set up Docker and run the three decoys.

Connect to your instance from your local machine:

ssh ubuntu@$TARGET_IP (use certificate)

Once connected to the AWS Instance terminal, run the following block to install Docker and prepare your environment:

# Update Ubuntu packages and install Docker
sudo apt-get update && sudo apt-get install -y docker.io docker-compose-v2
sudo usermod -aG docker ubuntu
newgrp docker
# Create a project folder for the honeypots
mkdir ~/honeypot-lab && cd ~/honeypot-lab

Now create a docker-compose.yml file to run all three honeypot frameworks simultaneously:

cat << 'EOF' > docker-compose.yml
version: '3.8'
services:
  # 1. Cowrie: Medium-interaction SSH/Telnet decoy
  cowrie:
    image: cowrie/cowrie:latest
    ports:
      - "0.0.0.0:2222:2222"   # Fake SSH
      - "0.0.0.0:2223:2223"   # Fake Telnet
    restart: always
  # 2. Dionaea: Low-interaction malware collector
  dionaea:
    image: dinotools/dionaea:latest
    ports:
      - "0.0.0.0:2121:2121"   # Emulated FTP
      - "0.0.0.0:8081:8081"   # Emulated HTTP
      - "0.0.0.0:1445:445"    # Emulated SMB
      - "0.0.0.0:5060:5060"   # Emulated SIP
      - "0.0.0.0:5900:5900"   # Emulated VNC
      - "0.0.0.0:26379:6379"  # Emulated Redis
      - "0.0.0.0:13306:3306"  # Emulated MySQL
      - "0.0.0.0:11433:1433"  # Emulated MSSQL
    restart: always
  # 3. OpenCanary: Modular canary decoy
  opencanary:
    image: thinkst/opencanary:latest
    ports:
      - "0.0.0.0:3222:22"     # Fake SSH banner
      - "0.0.0.0:8080:80"     # Fake HTTP banner
      - "0.0.0.0:3306:3306"   # Fake MySQL
      - "0.0.0.0:2122:21"     # Fake FTP
      - "0.0.0.0:6379:6379"   # Fake Redis
    restart: always
EOF

Start all three honeypot stacks:

docker compose up -d

Verify that all services are up and listening on external interfaces (0.0.0.0):

docker compose ps

You can now disconnect/exit the SSH session on the remote server:

exit

Step 4: Install honeypot-auditor on Your Laptop

Now switch back to your local machine terminal. We will install the auditor tool locally so we can scan the AWS server across the WAN.

# Create an isolated Python virtual environment on your computer
python3 -m venv ~/.venv/hpa
source ~/.venv/hpa/bin/activate
# Upgrade installer tools and install honeypot-auditor 1.0.0
pip install -U pip wheel
pip install 'honeypot-auditor[full]==1.0.0'
# Confirm installation
honeypot-auditor --version
# Output should show: honeypot-auditor 1.0.0

Step 5: Execute Remote WAN Scans

Now that the honeypots are live on AWS and locked down to your IP, let’s run remote audits against each stack.

Why explicit port flags (-p) matter:

If you don’t specify target ports with -p, the auditor checks standard default ports across the target host. Because we are hosting three distinct honeypot applications on one VM using non-standard ports (e.g., Cowrie SSH on 2222 vs. OpenCanary SSH on 3222), target isolation (-p) ensures we evaluate each honeypot software stack independently.

Run these three commands in your local computer terminal:

# Store your target AWS Public IP in an environment variable
export TARGET_IP="YOUR_AWS_PUBLIC_IP_HERE"  # Replace with actual IP
mkdir -p ./hpa-reports
# 1. Audit Cowrie (SSH/Telnet decoy)
honeypot-auditor --target $TARGET_IP -p 2222,2223 \
  --ports ssh=2222,telnet=2223 \
  --timeout 10 -v --output ./hpa-reports/cowrie.json
# 2. Audit Dionaea (Multi-protocol decoy)
honeypot-auditor --target $TARGET_IP -p 2121,8081,1445,5060,5900,26379,13306,11433 \
  --ports ftp=2121,http=8081,smb=1445,sip=5060,vnc=5900,redis=26379,mysql=13306,mssql=11433 \
  --timeout 10 -v --output ./hpa-reports/dionaea.json
# 3. Audit OpenCanary (Lightweight canary decoy)
honeypot-auditor --target $TARGET_IP -p 3222,8080,3306,2122,6379 \
  --ports ssh=3222,http=8080,mysql=3306,ftp=2122,redis=6379 \
  --timeout 10 -v --output ./hpa-reports/opencanary.json

Note: We use --timeout 10 on WAN scans to account for internet network latency and packet processing overhead.

Step 6: Interpret the Fingerprinting Results

To view a summary scoreboard of your audit results, execute this short Python snippet locally:

python3 - <<'PY'
import json, pathlib
root = pathlib.Path('./hpa-reports')
for name in ('cowrie', 'dionaea', 'opencanary'):
    file_path = root / f'{name}.json'
    if file_path.exists():
        r = json.loads(file_path.read_text())
        hits = [i for i in r['indicators'] if i.get('triggered') and not i.get('suppressed')]
        print(f"{name:12} Honeyscore: {r['score']:<5} Level: {r['threat_level']:<20} Triggers: {len(hits)}")
PY

How honeypot-auditor Decides a Host is Fake

• High-Fidelity Signatures (ssh.kex_facade): Cowrie relies on Python's Twisted networking library. Real OpenSSH servers negotiate encryption algorithms in a specific sequence. Cowrie's negotiation sequence is unique and instantly gives it away, earning an automatic High Signal trigger.
• Protocol Buffet (corroboration.protocol_buffet): Dionaea runs a massive menu of emulated services on a single machine. While an individual service anomaly might just look like a misconfigured server, running 8 distinct low-interaction protocols on one IP triggers cross-protocol aggregation rules, instantly flagging it as a honeypot rack.

Step 7: Clean Up AWS Resources

Once your lab is finished, terminate your AWS EC2 Spot instance and delete the Security Group so you don’t accumulate unnecessary charges.

Run on your local computer:

# Terminate the AWS EC2 instance
aws ec2 terminate-instances --instance-ids "$INSTANCE_ID"
# Wait until instance is fully shut down
aws ec2 wait instance-terminated --instance-ids "$INSTANCE_ID"
# Delete the temporary Security Group
aws ec2 delete-security-group --group-id "$SG_ID"
echo "Lab cleanup complete. Total cost incurred: ~$0.02"

Beginner Troubleshooting Guide

Key Takeaways: What We Learned

In less than an hour and for a couple of cents in cloud compute, we moved past simple banner grabbing and evaluated real decoy behavior across a live network boundary.

Here is what this hands-on lab demonstrated:

• Behavior beats banners: Low-interaction honeypots can fake software headers, but replicating raw protocol handshakes is much harder. Cowrie was instantly identified not because of its SSH banner, but because of its underlying Python Twisted Key Exchange (ssh.kex_facade).
• The “Protocol Buffet” trap: Exposing a massive array of different emulated services (FTP, SMB, HTTP, Redis) on a single IP address creates cross-protocol correlation patterns that high-confidence scoring models immediately pick up on.
• Target isolation matters: Running multiple decoys on non-standard ports requires strict scoping (-p). Without isolated port targeting, signature checks against one container spill over into another, skewing audit reports.

Where to Go From Here

Now that you have a working lab environment and an understanding of fingerprinting mechanics, here is how you can take this knowledge further depending on your focus:

1. For Blue Teams & Deception Engineers

• Harden your decoys: Take the JSON reports generated by honeypot-auditor and use them as a patch list. Can you configure Cowrie or OpenCanary to obscure their default KEX algorithms or sync their banner responses with real production servers?
• Distribute your stacks: Instead of running a “protocol buffet” on a single instance, test placing individual low-interaction containers across different subnets or behind reverse proxies to break cross-protocol correlation.

2. For Red Teams & Pentesters

• Automate pre-exploitation checks: Incorporate behavioral protocol audits into your initial reconnaissance phase to avoid burning active payloads on low-interaction traps.
• Inspect passive signals: Experiment with running honeypot-auditor using --passive-first or --safe-mode flags to measure how much fingerprinting data you can extract without triggering aggressive logging on the target host.

3. For Tool Developers & Researchers

• Build custom detection engines: Inspect the honeypot-auditor source code on GitHub to see how the 29 protocol engines evaluate TCP responses. Try writing a custom YAML signature or Python plugin for an obscure or emerging honeypot framework.

Resources & Links

• Honeypot auditor web page
• GitHub Repository
• HPA Scoring Documentation

Probe responsibly, scan only what you own, and leave no test instances running on your AWS bill.