This is Part 2 of the “The Art of Digital Deception” series, where theory meets chaos.
In this post, we go beyond the build. The honeypot was live—open to the world like digital flypaper—and within hours, it began drawing in curious crawlers, brute-force bots, and opportunistic threat actors from across the globe.
From SSH brute-forcing by Russian IPs, SQL injection attempts on our HR portal, to credential stuffing attacks on a fake corporate dashboard, every move was logged, parsed, and visualized inside DNIF SIEM.
This isn’t just a report—it’s firsthand threat intelligence harvested from a trap I built, watched, and learned from.
We’ll break down:
- The first hits and how fast they arrived
- TTPs used across fake services like SSH, HTTPS, FTP, RDP, and Telnet
- IOC and behavior-based observations
- How to turn honeypot logs into practical detection rules and correlation logic
Whether you’re building your honeypot or just want to see what real attackers do when they think no one’s watching, this story is your front-row seat.
Picture This
It’s 2 PM. I’m sipping coffee, watching my terminal light up with incoming SSH brute-force attempts. A Chile IP is attempting to access Administrator:password123 on port 22. Another attacker from Vietnam is probing the HR portal for Admin access.
This wasn’t a nightmare—it was my honeypot doing its job.
Chapter A: The First Ping—4 hrs In
It took 4 hrs after deployment for the first SSH brute-force attempt. The attacker from Chile tried logging in as:
- SYSTEM
- de
- usuario
- Administrador
All within 30 seconds.
Logs:
{"EventTime":"2025-05-06 13:26:53","Hostname":"EC2AMAZ-SLH9V8U","Keywords":-9218868437227405312,"EventType":"AUDIT_FAILURE","SeverityValue":4,"Severity":"ERROR","EventID":4625,"SourceName":"Microsoft-Windows-Security-Auditing","ProviderGuid":"{54849625-5478-4994-A5BA-3E3B0328C30D}","Version":0,"Task":12544,"OpcodeValue":0,"RecordNumber":278281,"ActivityID":"{A12CE3CB-BE74-0001-40E4-2CA174BEDB01}","ProcessID":628,"ThreadID":6968,"Channel":"Security","Message":"An account failed to log on.\r\n\r\nSubject:\r\n\tSecurity ID:\t\tS-1-0-0\r\n\tAccount Name:\t\t-\r\n\tAccount Domain:\t\t-\r\n\tLogon ID:\t\t0x0\r\n\r\nLogon Type:\t\t\t3\r\n\r\nAccount For Which Logon Failed:\r\n\tSecurity ID:\t\tS-1-0-0\r\n\tAccount Name:\t\tde\r\n\tAccount Domain:\t\t-\r\n\r\nFailure Information:\r\n\tFailure Reason:\t\tUnknown user name or bad password.\r\n\tStatus:\t\t\t0xC000006D\r\n\tSub Status:\t\t0xC0000064\r\n\r\nProcess Information:\r\n\tCaller Process ID:\t0x0\r\n\tCaller Process Name:\t-\r\n\r\nNetwork Information:\r\n\tWorkstation Name:\t-\r\n\tSource Network Address:\t186.10.24.214\r\n\tSource Port:\t\t57784\r\n\r\nDetailed Authentication Information:\r\n\tLogon Process:\t\tNtLmSsp \r\n\tAuthentication Package:\tNTLM\r\n\tTransited Services:\t-\r\n\tPackage Name (NTLM only):\t-\r\n\tKey Length:\t\t0\r\n\r\nThis event is generated when a logon request fails. It is generated on the computer where access was attempted.\r\n\r\nThe Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.\r\n\r\nThe Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).\r\n\r\nThe Process Information fields indicate which account and process on the system requested the logon.\r\n\r\nThe Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.\r\n\r\nThe authentication information fields provide detailed information about this specific logon request.\r\n\t- Transited services indicate which intermediate services have participated in this logon request.\r\n\t- Package name indicates which sub-protocol was used among the NTLM protocols.\r\n\t- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.","Category":"Logon","Opcode":"Info","SubjectUserSid":"S-1-0-0","SubjectUserName":"-","SubjectDomainName":"-","SubjectLogonId":"0x0","TargetUserSid":"S-1-0-0","TargetUserName":"de","TargetDomainName":"-","Status":"0xc000006d","FailureReason":"%%2313","SubStatus":"0xc0000064","LogonType":"3","LogonProcessName":"NtLmSsp ","AuthenticationPackageName":"NTLM","WorkstationName":"-","TransmittedServices":"-","LmPackageName":"-","KeyLength":"0","ProcessName":"-","IpAddress":"186.10.24.214","IpPort":"57784","EventReceivedTime":"2025-05-06 13:26:55","SourceModuleName":"in_eventlog","SourceModuleType":"im_msvistalog"}
Chapter B: HR Portal Exploited by a Script Kiddie
A Japan IP started fuzzing hrms with Shellshock vulnerability:
() { ignored; }; echo Content-Type: text/html; echo ; /bin/cat /etc/passwd
is a classic example of the Shellshock vulnerability, also known as Bashdoor. It targets systems that use GNU Bash (the Bourne Again Shell) as the command interpreter for processing environment variables—particularly those passed through CGI scripts on web servers.
Below are more attempts from the same source:
Chapter C: HTTPS Login Abuse—Stuffing Attempts
https_service.py got hammered with credential dumps from:
- Pastebin lists
- RockYou-style passwords
- Even “letmein” and “welcome123”
Behavior:
They checked for:
- File upload capabilities
- Admin login route
- Tokens in session cookies
They really believed it was real. That’s how good the bait was.
Chapter D: FTP Foolery
Attackers tried to exfiltrate files. The trap? Files didn’t exist.
One attacker spent over 6 minutes trying to download every directory, unaware it was all fake.
Chapter E: RDP Gets Brutal
14,000+ brute-force attempts in 24 hours.
- Most used Admin
- Tools: Hydra, xfreerdp, custom scripts
Windows Event Logs recorded failed login bursts every few seconds. DNIF’s correlation engine flagged behavior as high-volume authentication failures.
Here one of the attacker IP was also tagged as malicious by VirusTotal:
Chapter F: Telnet—Legacy Never Dies
Bots tried root:root, admin:admin, guest:guest on port 23.Most gave up within 2 tries. One persistent IP kept retrying every hour.
What We Learned
1. Brute-force attacks begin almost immediately
Honeypots are discovered within minutes.
2. Most attackers are bots or scripts
Only a few showed human creativity.
3. Service realism matters
The better the fake, the longer they stay—and the more data we collect.
4. HTTPS ≠ Safety
Attackers prefer TLS. They believe real dashboards live behind 443.
5. Logs Are Gold
With a good logging format and DNIF parsing rules, honeypots become intelligence platforms.
Sample Threat Intel Artifacts
IOC Summary:
FieldExampleIP106.52.65.233Usernamesadmin, test, AdministratorToolsHydra, sqlmap, MedusaTTPsBrute-force, SQLi, scanningThreat Intel Summary & DNIF Visuals
Top Countries Observed
- Chile
- Vietnam
- Tunisia
- Brazil
Timeline of attack based on Source Country:
Top Usernames Attempted:
Most Targeted Ports
- RDP (3389)
- SMB (445)
- SSH (22)
- HTTP (80)
Timeline of attack based on Destination Port:
Timeline of attack based on Action observed on DNIF:
Tools and Tactics (TTPs) Used
- Port scanning with Masscan/Nmap
- Brute-force via Hydra/Medusa
- Credential stuffing
- Shellshock vulnerability
Use in Detection Engineering:
- Block repeat offenders
- Build detection rules for fake endpoint access
- Train ML models with labeled behavior
- Enhance correlation rules in DNIF based on trap triggers
Final Thoughts: Would I Do It Again?
Absolutely. Honeypots are no longer just research toys—they’re active defenders.
Future Enhancements
- Add fake Outlook Web Access (OWA)
- Enable real DB interaction in a sandbox
- Replay attack sessions for training