I Left an SSH Server Wide Open. Here's What Happened in 26 Seconds.

The premise was simple: put a server with weak credentials on the internet and see what happens. Within hours, three separate attackers had found it. The last one deployed a full malware toolkit in 26 seconds flat.

No human was at the keyboard on their end. It was all automated.

The Setup

A honeypot is a deliberately weak system you put on the internet to study how attackers behave. I ran one inside a VM on a DigitalOcean droplet, with SSH exposed on port 22 and credentials set to root / password123. A DigitalOcean network firewall blocked all outbound traffic — enforced at the network level, outside the machine itself. Attackers could log in and do whatever they wanted, but they couldn’t call home, download tools, or actually harm anything.

The Noise

Before anything interesting happened, there were hundreds of failed login attempts. This is just the ambient background radiation of the internet — any publicly routable IP with port 22 open will start receiving brute-force attempts within minutes.

Failed password for root from 185.234.219.x port 54321 ssh2
Failed password for root from 45.33.32.x port 39847 ssh2
...

Against a properly configured server, this is all noise. Against password123, it’s eventually going to succeed.

Three Attackers, A Few Hours

Three separate IPs made it in on April 5th, within a few hours of each other.

Attacker 1 got in at 21:23 UTC, spent 107 seconds on the box, and left behind a single file — /var/tmp/.id — containing the honeypot’s own IP and credentials: 164.90.222.18:22:root:password123. The malware had automatically fingerprinted the machine and logged its own access details. This is how botnets grow: the toolkit catalogs every machine it touches, ready to report back to an operator who can put it to use — spam, scanning, or sold to other actors.

Attacker 2 logged in 61 minutes later and stayed for exactly 1 second — just long enough to confirm the credentials still worked, then left.

Attacker 3 followed 7 seconds later. This was the main event.

26 Seconds

From login to full compromise: 26 seconds.

In that window, the script installed persistence, dropped a malware binary, installed a backdoor, and disconnected. Here’s what it left behind:

A cron job at /etc/cron.hourly/gcc.sh — named to blend in among real system utilities. The script brings up every network interface, then launches the malware binary. On top of that, a direct /etc/crontab entry runs the same script every 3 minutes. Kill the malware process, and the cron job relaunches it before you’ve finished cleaning up.

A malware binary disguised as /lib/libudev.so — libudev is a real Linux system library, so it looks unremarkable in a quick ls /lib. It’s packed with no readable strings and fully daemonized. After spawning 5 worker processes under a randomly-generated name, it deleted itself from disk. The processes kept running with nothing to point to. If you’re hunting for malicious files, you won’t find one.

A Perl IRC backdoor running as /usr/sbin/httpd — masquerading as the Apache process. It was trying to connect to 86.122.140.30 on port 6667, the classic IRC port. IRC-based botnets have been around since the 1990s and are still in active use: the bot sits in a channel waiting for commands from the operator. Blocked by the firewall, stuck in SYN_SENT.

Day 2 — Still Running

I checked back 24 hours later. Both C2 connections were still stuck in SYN_SENT. The IRC bot had accumulated nearly 2 minutes of CPU time — not idle, just continuously retrying, blocked at every turn.

The worker binary had rotated names. Day one it was mkmsvsdicy, day two it was xokthwkvnr. The 3-minute cron was relaunching a fresh set of workers on every cycle, each time under a different name to defeat process-name detection.

The malware wasn’t giving up. It was just waiting. If the firewall rule had ever dropped, it would have checked in immediately.

Takeaways

Weak passwords don’t last. password123 on a publicly routable IP was discovered within hours. Automated scanners are sweeping the entire IPv4 space continuously.

Automation is fast. 26 seconds from login to full deployment, no human in the loop. The toolkit was pre-built and ready — all it needed was valid credentials.

The firewall saved everything. One rule — block all outbound traffic — neutralized the entire attack. Without it, the box would have been fully enrolled in the botnet within a minute.

Disable SSH password auth. All three attackers got in via password brute-force. One line in your SSH config closes this attack vector entirely.

IOCs

To check for this toolkit on your own systems:

Attacker IPs: 156.227.236.24, 2.57.122.189, 195.20.19.212

C2 infrastructure: 86.122.140.30:6667 (IRC), 141.98.10.115:1531 (unknown/mining)

Malware hash (MD5): 68c3d03da4eba61cbf291d24e6185252

Files to look for: /etc/cron.hourly/gcc.sh, /lib/libudev.so, /usr/lib/libudev.so, /var/tmp/.id