October 1, 2026
Unmasking Deception: A Beginner’s Guide to Detecting Honeypots with Honeypot-Auditor v1.0.3
TL;DR: The release of honeypot-auditor v1.0.3 introduces over 16 new strategies (totaling nearly 100 ) for Red and Purple teams to detect…
By Whengomarket
6 min read
TL;DR: The release of honeypot-auditor v1.0.3 introduces over 16 new strategies (totaling nearly 100 ) for Red and Purple teams to detect fake host environments. In this 15-minute lab tutorial, you will use pre-built Docker configs to launch dd-honeypot (DataTrap) locally across 5 protocols (SSH, Telnet, MySQL, Redis, Postgres), run a
--deepaudit, and achieve a verified 100% Honeyscore .
In the ever-evolving cat-and-mouse game of cybersecurity, deception technology has become a cornerstone of modern defensive strategies. Blue teams deploy honeypots, fake systems, services, and credentials to lure attackers, monitor their techniques, and slow down their lateral movement. But what happens when you are on the offensive side? For Purple and Red teams tasked with researching and testing internal deception environments, distinguishing a legitimate corporate server from a booby-trapped honeypot is critical. Falling for a honeypot means wasted time, burnt infrastructure, and immediate attribution by the Blue team.
The latest release of honeypot-auditor introduces more than 16 new detection strategies designed to fingerprint modern honeypots across various protocols. With these additions, the tool now boasts nearly 100 different strategies to determine if a remote host is a valid service or a cleverly disguised trap.
In this comprehensive, step-by-step beginner tutorial, we are going to dive deep into how you can set up a safe, localized deception lab and use the new auditor to expose it.
The Value of the Pre-Packaged Deception Lab
Before we jump into the command line, let's talk about the lab environment we will be using. If you have ever tried to manually configure a multi-protocol honeypot for testing, you know it can be a nightmare. You have to configure simulated file systems, set up mock database responses, and often hook into cloud-based Large Language Models (LLMs) to generate dynamic responses for attackers.
Our lab utilizes dd-honeypot, an open-source honeypot by ThalesGroup. Normally, DataTrap relies heavily on AWS Bedrock to dynamically generate responses to attacker commands. If you don't have AWS credentials, the honeypot breaks.
This is where the immense value of the provided Dockerfile and honeypot configuration files comes in.
The developers of the honeypot-auditor tutorial have done the heavy lifting for you. Inside the docs/tutorials/dd-honeypot-lab-demo/ directory, you will find ready-to-deploy Docker environment.
- Zero Configuration Required: The
Dockerfilelayers five pre-written honeypot configurations (SSH, Telnet, MySQL, Redis, and PostgreSQL) directly on top of the official DataTrap image. - Offline & Free: The included
data.jsonlfiles provide pre-seeded datasets of common commands and responses. Because these responses are hardcoded, the honeypot can answer the auditor's probes without needing to fall back to an expensive AWS Bedrock LLM. You get a fully functional deception environment offline. - Instant Reproducibility: Instead of spending hours reading documentation to set up five different fake services, you can spin up the entire deception environment in less than two minutes using a single Docker command.
This pre-packaged approach removes the friction of infrastructure setup, allowing Red and Purple teams to focus entirely on what matters: detection and analysis.
0. Prerequisites for the Lab
Everything in this tutorial will run locally on your machine (127.0.0.1), making it a 100% safe and authorized lab exercise. You will need:
- Docker Desktop: Ensure Docker is installed and running (
docker --version). - Python 3.10+: Required for the auditor (
python3 --version). - Git: To clone the repository (
git --version). - Netcat (
nc): For optional reachability checks.
Safety Note: Never point honeypot-auditor at systems you do not own or lack written permission to test.
First, clone the repository and navigate to the root directory:
git clone https://github.com/mziqudhd92/honeypot-auditor.git
cd honeypot-auditorgit clone https://github.com/mziqudhd92/honeypot-auditor.git
cd honeypot-auditor1. Install honeypot-auditor
To keep your system's Python environment clean, it is best practice to use a virtual environment. From the root of the cloned repository, run the following:
python3 -m venv .venv
source .venv/bin/activate # On Windows use: .venv\Scripts\Activate.ps1
pip install -e ".[full]"
honeypot-auditor --versionpython3 -m venv .venv
source .venv/bin/activate # On Windows use: .venv\Scripts\Activate.ps1
pip install -e ".[full]"
honeypot-auditor --versionYou should see honeypot-auditor 1.0.3 printed to your terminal. You are now armed with nearly 100 deception-detecting heuristics!
2. Build the Honeypot Lab Image
Now, let's navigate to the heavily optimized lab folder we discussed earlier.
cd docs/tutorials/dd-honeypot-lab-democd docs/tutorials/dd-honeypot-lab-demoWe will use Docker to build the image. This command reads the provided Dockerfile, pulls the base DataTrap image, and injects the five offline honeypot configurations.
Bash
docker build -t dd-honeypot-lab .docker build -t dd-honeypot-lab .You will see Docker executing the build steps. Wait until it successfully exports the image tagged as dd-honeypot-lab.
3. Start the Target Deception Container
We will run the container in detached mode (-d) and map the honeypot's internal ports to your host machine's ports.
docker run -d --name dd-honeypot-lab \
-p 127.0.0.1:2222:22 \
-p 127.0.0.1:23:23 \
-p 127.0.0.1:3306:3306 \
-p 127.0.0.1:6380:6379 \
-p 127.0.0.1:5433:5432 \
dd-honeypot-labdocker run -d --name dd-honeypot-lab \
-p 127.0.0.1:2222:22 \
-p 127.0.0.1:23:23 \
-p 127.0.0.1:3306:3306 \
-p 127.0.0.1:6380:6379 \
-p 127.0.0.1:5433:5432 \
dd-honeypot-labWhy change the ports? We are intentionally mapping SSH to 2222, Redis to 6380, and PostgreSQL to 5433 to ensure they don't collide with legitimate services you might already have running on your host machine (like macOS Remote Login). Binding to 127.0.0.1 ensures these fake services are isolated to your local machine and not exposed to your wider network.
4. Verify the Honeypot Services
Let's ensure the trap is set. Check the Docker logs:
docker logs dd-honeypot-lab 2>&1 | grep -E "Found 5 honeypots|running on port|running on 0|Telnet|Found honeypot folder"docker logs dd-honeypot-lab 2>&1 | grep -E "Found 5 honeypots|running on port|running on 0|Telnet|Found honeypot folder"You should see output confirming that the SSH, Telnet, MySQL, Redis, and Postgres honeypots have successfully started.
Next, do a quick network check to ensure the ports are open and listening on your host:
for p in 2222 23 3306 6380 5433; do
nc -z -w 1 127.0.0.1 $p >/dev/null 2>&1 && echo "port $p: open" || echo "port $p: CLOSED"
donefor p in 2222 23 3306 6380 5433; do
nc -z -w 1 127.0.0.1 $p >/dev/null 2>&1 && echo "port $p: open" || echo "port $p: CLOSED"
doneIf all ports report as open, your deception environment is live.
(Note: Don't worry if the Docker logs start showing "Unable to locate credentials" or MySQL errors later. This is expected noise because we bypassed the AWS fallback!)
5. Execute a Basic Audit
Now it's time to play Red Team. Return to the repository root directory (where your virtual environment is active) and unleash the auditor.
cd ../../.. # Navigate back to the repo root
honeypot-auditor --target 127.0.0.1 \
-p 2222,23,3306,6380,5433 \
--ports ssh=2222,telnet=23,mysql=3306,redis=6380,postgres=5433 \
--output audit-dd-basic.json \
-vcd ../../.. # Navigate back to the repo root
honeypot-auditor --target 127.0.0.1 \
-p 2222,23,3306,6380,5433 \
--ports ssh=2222,telnet=23,mysql=3306,redis=6380,postgres=5433 \
--output audit-dd-basic.json \
-vUnderstanding the command:
--target 127.0.0.1: Scans our local machine.-p: Restricts the scan only to the ports we opened, saving time.--ports: This is crucial! Because we mapped services to non-standard ports (like SSH on 2222), we must explicitly tell the auditor which protocol lives on which port to prevent it from sending the wrong probes to the wrong services.
Within a minute, the tool will analyze the responses using its extensive strategy set. You will see a beautiful terminal UI output resulting in:
Honeyscore: 100.0% (Confirmed Honeypot)
The auditor caught it perfectly.
6. Unleashing the Deep Audit
While the basic audit is great, v1.0.3 really shines when you enable --deep. Deep mode activates advanced detection axes, including shell semantics, OS coherence, SSH/HASSH fingerprinting, protocol state-machine fuzzing, co-tenancy, and latency analysis.
Run the deep scan:
honeypot-auditor --target 127.0.0.1 \
-p 2222,23,3306,6380,5433 \
--ports ssh=2222,telnet=23,mysql=3306,redis=6380,postgres=5433 \
--deep \
--output audit-dd-deep.json \
-vhoneypot-auditor --target 127.0.0.1 \
-p 2222,23,3306,6380,5433 \
--ports ssh=2222,telnet=23,mysql=3306,redis=6380,postgres=5433 \
--deep \
--output audit-dd-deep.json \
-vIn the verbose output, you will see exactly how the auditor caught the honeypot:
- Arbitrary Auth (deep.auth_curve): The SSH service accepted random, gibberish credentials across multiple attempts. Real servers don't do this; honeypots do it to capture payloads.
- Shell Semantics: The honeypot failed basic arithmetic commands or returned rigid, pre-programmed error messages (
Command not handled). - Protocol State-Machine Leaks: The MySQL honeypot returned out-of-sequence errors (
Expected seq(1) got seq(0)) when fuzzed with malformed authentication sequences. - Co-tenancy: The auditor recognized the statistical improbability of an SSH, Telnet, Redis, and Database server all living on the exact same host, immediately flagging it as a "responsive IT lure."
By combining nearly 100 different strategic checks, the auditor paints an undeniable picture, ensuring Red Teams don't waste precious time trying to exploit a mirage.
7. Analyzing Results and Cleaning Up
The resulting audit-dd-deep.json file contains a wealth of data mapping exactly which of the 100 heuristics were triggered. You can parse it easily:
python3 - <<'EOF'
import json
r = json.load(open("audit-dd-basic.json"))
print("Score:", r["score"], "→", r["threat_level"])
for t in r["triggered"]:
print(" HIT:", t["id"])
EOFpython3 - <<'EOF'
import json
r = json.load(open("audit-dd-basic.json"))
print("Score:", r["score"], "→", r["threat_level"])
for t in r["triggered"]:
print(" HIT:", t["id"])
EOFAny score over 60% is a "Confirmed Honeypot," and thanks to the multi-protocol corroboration of DataTrap, our lab easily scored 100%.
Once your testing is complete, tear down the lab gracefully:
docker rm -f dd-honeypot-lab
deactivatedocker rm -f dd-honeypot-lab
deactivateConclusion
Deception engineering is a fascinating field. Blue teams are building smarter, more resilient traps, but tools like honeypot-auditor v1.0.3 ensure offensive teams have the forensic capabilities to spot them.
By utilizing the expertly crafted Docker and JSON configuration files provided in the lab, you were able to bypass complex cloud setups and instantly spin up a multi-protocol honeypot. You then successfully leveraged the newest version of the auditor, utilizing its 100+ detection strategies to mathematically prove the environment was a trap.
For Purple Teams, this lab is more than just a tutorial — it is a blueprint for testing your own internal deception environments and understanding exactly what an advanced adversary sees when they scan your network. Happy hunting!