Behind the 404s: what an IoT botnet's loader was hiding

On 9 October 2026 we wrote about a botnet server, 85.137.53[.]167, that kept answering our honeypot with error pages. Machines kept logging in to our Telnet honeypot and asking it for a loader script, and it kept saying "not found". We found its command server anyway, through an older bot that other researchers had collected.

A day later the server started answering. This post is about what it served, what the bot did when we ran it, and why the loader looked familiar. (Updated 12 October: the command server has since moved behind a tunnel; see the update below.)

The loader arrives

At 16:12 UTC on 10 October, a machine at 45.153.34[.]18 logged in to our honeypot over Telnet as root with the password vizxv, one of the factory passwords Mirai has been trying on cheap cameras and video recorders since 2016. It downloaded a short script called wget.sh from 85.137.53[.]167 and ran it. Nine minutes later it did the same again with another old factory password, xc3511.

Our honeypot records what attackers download but never runs it. So we ran the script ourselves, in our isolated lab, with the lab allowed to reach that one server and nothing else.

What the loader does

The script is about 80 lines long. It works out what kind of processor the device has, picks one of 19 bot builds to match (ARM, MIPS, x86, PowerPC, RISC-V and others), downloads it, and starts it in the background. If the right build isn't available it tries eight common ones in turn.

It also throws away any download smaller than 4 KB. That detail explains the error pages: on a real victim, the 404 page we were served would have been rejected and the loader would have moved on. The errors weren't a trap for researchers. The server just wasn't ready yet.

In our lab, the loader fetched akuma_x64, a bot for 64-bit PCs and servers. Nobody had uploaded it to MalwareBazaar, the public malware library, so we did.

The bot calls home

Once running, the bot copied itself to /var/tmp/systemd-network-helper, a name picked to look like part of Linux's own service manager. It also carries a ready-made service file under that name, plus startup scripts for routers and Android devices, so it can come back after a reboot.

Then it tried to reach its command server: the same machine, 85.137.53[.]167, but on port 25565. The older bot we wrote about used port 3169. Port 25565 is the default port for Minecraft servers, a choice that may help the traffic blend in on networks where people play games.

We let the bot reach that one address for five minutes. The server accepted the connection straight away. The bot introduced itself with its processor type and a label, telnet.akuma, which tells the operator which channel it came in through. After that the two sides exchanged a two-byte "still here" message every minute. No attack commands came while we watched, so we can't say what this botnet is being used for.

A familiar script

To help others detect the loader, we wrote a YARA rule for it and ran it over everything our honeypot has collected. It matched two files: this loader, and one we caught on 4 October from a different server, 143.20.154[.]42.

The two scripts are the same template: same structure, same 4 KB check, same error message, with the bots renamed and a few more processor types added. They were also delivered by the same group of Microsoft Azure machines, which run the script with the word telnet as its argument. But the bot behind the October 4 script is a different, much smaller program, with its own command server.

Our reading is that one operator, or one kit passed between operators, kept the loader and the machines that spread it, and swapped the bot. We can't tell which from what we've seen.

Update, 12 October: the server moved behind a tunnel

A day after this post went up, the bot builds changed. The server now hands out separate builds for three channels, Telnet, Android and a new one for video recorders (DVR), and rebuilds them often.

We ran the newest builds in our lab. They no longer call 85.137.53[.]167 at all. Instead they connect to 5.tcp.eu[.]ngrok[.]io on port 16747. ngrok is a legitimate tunnelling service: the operator runs a small program next to the real server, and ngrok's shared servers pass connections through to it. The real server's address stays hidden.

We let one bot reach that tunnel for five minutes. ngrok accepted it, and the bot introduced itself as akuma.dvr, so the label now names the channel. The server behind the tunnel didn't answer that time.

What it means in practice: blocking 85.137.53[.]167 no longer cuts these bots off. Don't block ngrok's addresses either, because thousands of legitimate users share them. Watch for outbound connections to ngrok TCP tunnels on port 16747, and ask whether your network needs to reach ngrok tunnels at all. Our detection rules on GitHub are updated to match the new label and the tunnel.

What defenders can do

• Close Telnet and change factory passwords. Every step of this started with a Telnet login using a password that has been public for ten years.

• Look for the disguise. A file at /var/tmp/systemd-network-helper, or a service called systemd-network-helper.service, is not part of Linux. Treat the device as infected.

• Block the servers. 85.137.53[.]167 (all ports, especially 3169, 24380 and 25565), 143.20.154[.]42 and 91.92.47[.]97.

• Use the rules. We published YARA rules for the loader and the bot, a Suricata rule for the bot's check-in, and a Sigma rule for the files it leaves behind. The YARA rules matched nothing else in about 92,000 honeypot captures and 142 recent IoT malware samples.

Key indicators

All indicators, defanged, are in the finding's iocs.csv. The full technical write-up has the timeline, the side-by-side loader comparison, the check-in bytes and the detection rules.

How we work

KSI Digital runs a WordPress bait and a Cowrie SSH/Telnet honeypot that record attacks and keep the files attackers download. We analyse samples in an isolated lab that is offline by default. When a live check is needed, only the destinations we name are reachable, for a few minutes, and everything else the sample tries is dropped. We publish what we find on our research page and on GitHub under CC BY 4.0, and we report servers to the public threat feeds and to the providers that host them.