Not actually interesting. The server held no customer information, useful credentials, production software, or access to anything I operate. It was a dedicated throwaway cloud VM on a disposable network, surrounded by controls intended to keep whatever arrived from going anywhere else.

But from the outside, it looked like a target.

Then I waited.

After roughly five hours, the honeypot had recorded 191 sessions, 4,535 events, and 2,322 commands. Bots reached 90 simulated successful logins. They generated 146 malware download events, attempted to use the SSH service as a tunnel, and delivered two files independently detected as Mirai variants.

Nothing escaped. No new outbound connection succeeded.

The five-hour scoreboard

The interactive SSH honeypot accounted for the richest activity, but it was not the only service being tested. The surrounding simulations recorded another 1,049 probes:

About 95 percent of that traffic targeted the fake MySQL service. The imbalance is a useful reminder that opportunistic scanning is not evenly distributed; automated campaigns concentrate on whatever their current playbook expects to monetize.

They did not stop at the login prompt

A simple port scan is background noise. The revealing part began after the honeypot pretended to accept credentials.

The most active session issued 297 commands. Rather than downloading one ready-made executable, the bot used hundreds of shell commands to assemble multi-architecture payload data byte by byte inside the simulated filesystem. It then attempted to mark the result executable and launch it.

That is a lot of work for a machine that never existed in the form the attacker imagined.

Another campaign tested writable locations and tried several delivery methods: HTTP, TFTP, and FTP. One captured shell script inspected /proc and killed processes whose executables were marked (deleted). That behavior is consistent with malware cleaning up stale processes or removing competing infections before taking over the host.

Across the run, the system recorded 75 captured download events and 71 failed attempts.

Mirai is still very much alive

Two captured artifacts were independently identified by Microsoft Defender as:

• Backdoor:Linux/Mirai.FX!MTB
• Backdoor:Linux/Mirai.GZ!MTB

Neither payload executed. Extracted inspection copies were quarantined, while the original evidence was retained separately for later analysis.

The credential spray around these sessions was heavily focused on routers, cameras, optical network terminals, and other embedded devices. Generic admin/admin appeared most often, surrounded by vendor-style default credentials that have been circulating in botnet dictionaries for years.

The internet keeps inventing new technology. Its malware, apparently, enjoys the classics.

The weirdest request: make my fake server a proxy

One visitor attempted to use the simulated SSH service as a tunnel to dns.google over TLS. The honeypot recorded the forwarding request and its TLS fingerprint, then discarded the forwarded traffic.

That attempt matters because it shows a goal beyond simply infecting the host. A compromised SSH server can also become infrastructure: a proxy, a relay, a place to conceal the origin of the next connection, or a stepping stone toward another target.

The fake server played along just far enough to reveal the intention. It never provided the tunnel.

The containment mattered more than the bait

This was not attached to my home network, business environment, or a customer system. It used a fresh public IP and a dedicated disposable VM with no agents, tunnels, trusted keys, reusable credentials, or links to other services.

The exposed services were simulations. Forwarding and new outbound connections were blocked. The system could record what an attacker tried without giving that attacker a useful machine to operate.

That boundary is the difference between observing hostile behavior and accidentally donating infrastructure to it.

What five hours taught me

The surprise was not that attackers eventually found an exposed server. The surprise was how quickly the activity progressed from broad probing to simulated logins, malware delivery, process cleanup, multi-architecture payload assembly, and attempted tunneling.

Nobody was sitting at a keyboard admiring the target. Most of this was automated infrastructure working through an old, efficient routine:

1. Find something exposed.
2. Try default credentials.
3. Determine what tools and writable paths exist.
4. Deliver a payload using whatever protocol works.
5. Remove competition.
6. Turn the host into part of something larger.

One disposable IP was enough to watch the whole playbook unfold.

The internet does not knock politely. It starts trying admin/admin immediately.