A Mirai botnet that hides its servers in plain DNS

A botnet has to tell its bots where to report, and that address is the weak spot. Put an IP in the binary and anyone who runs the sample finds it, lists it and gets it taken down. The Mirai kit we caught on 9 October 2026 doesn't do that. Its bots look up a domain name, but the address in the DNS answer isn't the server either. It's the server's address scrambled with a fixed key. A sandbox that runs the bot sees the domain, and nothing else that points to the servers.

We worked out the key without contacting anything, confirmed it against the live DNS records, and then let the bot reach the two servers it decoded, for a few minutes, in our isolated lab. Neither server was on any public feed. Both are now on ThreatFox, and we've reported them to their hosting provider and the domains to their registrar.

How it reached our honeypot

At 18:07 UTC on 9 October 2026, a machine at 45.90.163[.]37 logged in to our Cowrie Telnet honeypot with the default admin password and piped a small script from 176.65.139[.]40 into the shell. The script downloads eleven builds of the same bot, one for each kind of processor it might find on a router, camera or server, and starts each one. It's a typical Mirai delivery: the attacker doesn't know what device it has broken into, so it tries everything.

Our honeypot records what attackers fetch but doesn't run it. The builds were already on MalwareBazaar, collected by abuse.ch from the same server, so we took them from there instead of touching the attacker's machine.

A bot that ignores its own DNS answer

Our lab runs samples offline. It answers every DNS lookup with a local address, so a bot that looks for its server gives the name away, and when it tries to connect we see where.

This bot behaved strangely. It scanned the internet for more Telnet devices to infect, which is normal for Mirai. It looked up seris[.]gd over and over, more than once a second, and a second domain, myrepis[.]gd, once. But it never connected to the address it was given. A bot that keeps asking and never uses the answer usually means the answer is transformed before use, and that our local address turned into something the bot rejected.

Working out the key

So we changed only the answer. When seris[.]gd resolved to 198.51.100.77, an address reserved for documentation that can't exist on the internet, the bot tried to connect to 33.67.234.20. When it resolved to 203.0.113.1, it went to 44.112.255.88. Compare the numbers byte by byte and both pairs differ by the same key: XOR with E7.70.8E.59. The MIPS build did exactly the same thing, so the key doesn't depend on the device type.

Then we looked up the real records through public DNS:

The last line settled it. The backup domain decodes to 176.65.139[.]40, the very server the attack script came from. Random numbers don't do that.

Confirming it live

For a few minutes we let the bot reach only those two decoded addresses, with everything else blocked. Both servers answered. The first, 159.65.67[.]52, accepted the bot at 01:58 UTC on 10 October and held the connection for about three minutes while the bot checked in every 30 seconds. The second, 206.189.164[.]5, did the same at 02:22 UTC. Neither sent a command while we watched, so we can't say what the botnet is being used for right now. Each connection used a different random port, so the server address is the thing to block, not a port.

Why this matters

Most automated sandboxes answer DNS with a fake local address, the way ours does by default. For this kit they'll report a domain and some Telnet scanning, and no server address at all. A sandbox with real DNS does a little better, but it shows a connection to an address that never appeared in any DNS answer, which is easy to misread as a scan or a decoy.

It also changes what's worth blocking. Nothing ever connects to the addresses published in DNS, so blocking those does nothing. Blocking the domain names works, and so does blocking the decoded servers. And because moving the botnet is just a DNS edit, anyone tracking it can check the two domains, apply the key and see where the servers are now, without running the malware again.

What defenders can do

• Block the domains and the decoded servers. Add seris[.]gd and myrepis[.]gd to DNS blocklists, and 159.65.67[.]52 and 206.189.164[.]5 to firewall blocklists. Don't rely on the A records themselves.

• Close Telnet. This arrived over Telnet with a default password. A router or camera that exposes Telnet to the internet will be found within hours. Turn it off or firewall it, and change default passwords.

• Watch for the lookups. A device on your network querying seris[.]gd or myrepis[.]gd is infected.

• Mind your sandbox's DNS. If you analyse IoT malware, a bot that resolves its domain and never connects is a hint to try changing the DNS answer before calling it a dead sample.

Key indicators

All hashes, defanged, are in the finding's iocs.csv, with the full technical write-up next to it.

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.