SecurityAnalyticsSecurityOperations

The Day I Became a Digital Beekeeper – Luring Real Threats into My Windows Honeypot

Rakshit Shetty

Rakshit Shetty

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
Screenshot of log entries displaying authentication attempts showing failed login attempts with timestamps, user names, source IP addresses, and action status, illustrating security events related to a honeypot monitoring system.

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:

An overview of log entries from a honeypot depicting various request statuses and attempted access by different IP addresses, showcasing real-time security threat monitoring.

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.

A screenshot of security logs indicating multiple brute-force access attempts, displaying timestamps, user statuses, and high-severity alerts from various IP addresses.

Here one of the attacker IP was also tagged as malicious by VirusTotal:

Dashboard view showing IP 106.51.65.233 with information on country, owner, and source classification in a threat intelligence platform.

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, scanning

Threat Intel Summary & DNIF Visuals 

Top Countries Observed

  • Chile
  • Vietnam
  • Tunisia
  • Brazil

Timeline of attack based on Source Country:

Bar chart visualization displaying attack data over time, with different colors representing various source countries.

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:

A stacked bar chart visualizing network activity over several days, showing requests allowed, denied, logged in, and objects accessed during specific timestamps.

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