Most security tools are defensive. They sit at the perimeter, wait for something bad to happen, and try to block it. A honeypot flips that logic entirely. Instead of blocking attackers, you invite them in, watch everything they do, and walk away with intelligence.
I wanted to understand what real attacker behavior looks like before it reaches production systems, so I built a Python-based honeypot that simulates SSH, HTTP, and FTP services, captures everything that touches those services, and generates a structured attacker intelligence report with every event mapped to MITRE ATT&CK.
Here is how I built it and what I learned.
The Problem with Passive Defense
Security teams spend most of their time defending known attack surfaces. Firewalls, IDS rules, SIEM alerts. The problem is that all of those tools respond to attacks. They do not teach you how attackers think, what credentials they try first, which vulnerabilities they probe before going deeper, or how a brute force attempt transitions into a web shell attempt.
Honeypots answer those questions. They are decoys with no legitimate users, so every connection is suspicious by definition. There is no noise to filter. Everything logged is an attack.
The gap I saw in most beginner honeypot setups is that they stop at logging. You get an IP address and a timestamp. I wanted something that went further: credential capture, behavioral pattern detection, attack type classification, and automatic MITRE ATT&CK mapping so the output was actually useful to a SOC analyst.
What I Built
The system runs three fake services simultaneously using Python's standard library only. No external dependencies, just socket, threading, json, re, and collections.
SSH on port 2222 accepts any connection and logs every username and password combination attempted. It never grants access. It just listens, captures, and flags IPs that exceed a brute force threshold.
HTTP on port 8080 handles incoming web requests and scans each one for attack signatures: SQL injection strings, web shell upload attempts, directory traversal patterns, admin panel probes, and general vulnerability scanning behavior.
FTP on port 2121 captures login attempts, flags anonymous login attempts, and detects default credential usage.
Every single event, regardless of service, gets mapped to a MITRE ATT&CK technique in real time. SSH brute force maps to T1110. Port scanning maps to T1046. SQL injection maps to T1190. Web shell attempts map to T1505.003. The full mapping table covers nine attack patterns across all three services.
The Intelligence Report
Logging raw events is useful. Summarizing them into an intelligence report is what makes a honeypot operationally valuable.
After a session ends, either via Ctrl+C on a live run or automatically after a simulation, the tool generates a report that shows:
Total events and unique attacker IPs
Brute force IP flags
Event breakdown by service, visualized as bar charts in the terminal
Top attacker IPs with their specific attack types listed
MITRE ATT&CK technique frequency across the session
Unique credential combinations attempted, with default credential flagging
The JSON logs that feed this report are structured to be SIEM-ready. They can pipe directly into Splunk, Elastic, or Microsoft Sentinel without transformation.
Here is a sample of what a session report looks like:
HONEYPOT ATTACKER INTELLIGENCE REPORT
=================================================================
Total Events : 31
Unique Attackers: 7
Brute Force IPs : 2
EVENTS BY SERVICE
SSH ████████████████ 16
HTTP ████████████ 12
FTP ███ 3
TOP ATTACKER IPs
45.33.32.156 10 events | sql_injection, web_shell_attempt, database_probe
203.0.113.42 9 events | ssh_login_attempt, port_scan [BRUTE FORCE]
MITRE ATT&CK TECHNIQUES OBSERVED
T1110 Brute Force 9x
T1046 Network Service Scanning 8x
T1190 Exploit Public-Facing Application 3x
T1505.003 Web Shell 1x
CREDENTIALS ATTEMPTED (11 unique)
admin : admin [DEFAULT CRED]
root : password
pi : raspberry
Demo Mode
One thing I built specifically for testing and demonstrations is a --simulate flag. Running python3 honeypot.py --simulate --report generates a full simulated attack session without needing live internet traffic or exposed ports. It runs through SSH brute force, HTTP probing, FTP anonymous login attempts, and port scanning behavior, then generates the full report.
This means anyone cloning the repo can see exactly what the tool does in under 30 seconds without any infrastructure setup.
What This Looks Like in Practice
Deploy this on an AWS EC2 instance or DigitalOcean droplet with the ports exposed to the internet. Within hours, you will see real traffic. Bots and automated scanners hit open ports constantly. What you capture tells you a lot:
The most commonly attempted SSH credentials globally are still admin:admin, root:password, and pi:raspberry. Default credential hygiene matters.
HTTP scanners probe for /admin, /wp-login, /.env, and SQL injection strings before any human has looked at your site.
Brute force attempts rarely come from a single IP. Distributed credential stuffing is the norm.
All of that becomes structured threat intelligence when it runs through this tool.
Technical Design Decisions
A few choices I made deliberately:
Standard library only. No pip installs, no dependency conflicts, no version issues. The tool runs on any Python 3 environment out of the box.
Threading per service. Each fake service runs on its own thread so SSH, HTTP, and FTP capture simultaneously without blocking each other.
Threshold-based brute force detection. Rather than flagging every failed login, the tool tracks attempt counts per IP and raises a brute force flag only after a configurable threshold is crossed. This mirrors how real SOC alert rules work.
ATT&CK mapping at the event level. Instead of tagging sessions with a technique at the end, each individual event carries its ATT&CK technique ID as it is logged. This makes the data immediately usable for threat hunting queries.
Takeaways
Building this project reinforced something I keep coming back to: defenders who understand how attackers operate are better at their jobs. A honeypot is not just a trap. It is a training dataset for your threat model.
The credential lists alone are valuable. Seeing T1046 show up before T1190 in a session tells you that the attacker scanned for services before attempting exploitation. That sequencing is exactly what ATT&CK is designed to capture.
If you are building out a SOC capability or studying for a blue team role, I would strongly recommend deploying a honeypot, even a simple one, and spending time reading the logs. The patterns you see will show up again in your SIEM.
Links
GitHub: honeypot-attacker-intelligence
Portfolio: sankethsubhas.pages.dev
Questions or feedback? Drop them in the comments. If you have deployed a honeypot and captured interesting traffic patterns, I would like to hear what you saw.
Top comments (0)