Ancient: a Linux IoT botnet that hides its C2 lookup in DNS-over-TLS

Routers, cameras and other small Linux-based devices are rarely watched as closely as servers, and many still accept Telnet logins. That makes them a steady target for botnets: malware that turns compromised devices into a network run from a command-and-control (C2) server. Between 4 and 5 October 2026 our Telnet honeypot let us observe a botnet family that names itself "ancient": its delivery, three versions of its installer and its C2.

Two things set it apart from routine honeypot traffic. It looks up its C2 server over DNS-over-TLS, so the lookup does not show up in ordinary DNS logs. And it talks to that server with its own protocol, which opens with the four-byte tag ANCT. Several feeds currently label its binaries as generic "Mirai", but its C2 protocol is not Mirai's.

We have not found a public write-up of this family, its markers or its ANCT tag. Not finding one is not the same as it being new, and we welcome pointers to earlier reporting.

How it reached our honeypot

On 4 October 2026 at 15:37 UTC, an already-infected device at 94.154.43[.]138 logged in to our Telnet honeypot and told it to download a shell script, persist.sh, from a server at 89.163.157[.]131 on port 8080. Over the next four hours the same device ran 34 commands and downloads. It fetched three different versions of the script and two builds of the bot for 64-bit x86.

The script is a dropper: its job is to install the actual bot. It checks the processor type and picks one of 13 builds, from ARM and MIPS to x86, PowerPC, SuperH and m68k. It tries whichever download tool the device has, saves the bot as a hidden file called .ancient, starts it in the background and sets up persistence: a cron job every five minutes, rc.local, an init script and, in the latest version, a login script under /etc/profile.d. Finally it reports a status such as ANCIENT_STARTED or ANCIENT_NOCONN back to the loader.

Three versions in four hours

The three versions show the authors at work. Version 2 refuses to start a second copy of the bot. Version 3 picks a filesystem that survives a reboot, adds more persistence locations, and fixes a bug: every version checks whether the bot has a connection open on its C2 port, but versions 1 and 2 looked for the port number in the wrong byte order, so they always reported ANCIENT_NOCONN. Version 3 corrects this and explains the fix in a comment, which shows the authors are testing against real devices.

What the analysis showed

We ran the x86-64 bot in our isolated sandbox, where a router logs every connection and blocks anything not explicitly allowed.

• It stays quiet while traced. Under a tracer (strace), the bot made no network connections until the tracer detached. It appears to stay idle while observed this way.

• It hides its C2 lookup. With only Cloudflare's DNS-over-TLS resolver (1.1.1.1 on port 853) reachable, the bot immediately resolved zyrec2.duckdns[.]org over the encrypted channel, with plain DNS as a fallback. It then made 33 attempts, all blocked, to reach 89.163.157[.]131 on port 35342, the same server that hosted the dropper. Monitoring that relies on port-53 DNS logs or a DNS sinkhole would only see a TLS session to a public resolver.

• It speaks its own protocol. To confirm the C2 was live, we allowed that one destination for a single ten-minute window on 5 October 2026 (02:01 to 02:11 UTC), with everything else still blocked. The bot sent the four bytes ANCT, then 32 bytes consistent with a key exchange; the server answered with 36 bytes, and the rest was encrypted. The server held the session for the full ten minutes but sent no instructions. The bot uploaded about 1.8 MB of encrypted data, content unknown.

We sent the server nothing beyond what the bot itself sent, and contacted it only that once. Open questions remain: the key exchange and cipher behind the handshake, what the bot uploads, and how this campaign relates to earlier use of the same DuckDNS name, which ThreatFox has listed as a Mirai C2 since June 2026.

What defenders can do

• Close Telnet and replace default passwords. This bot arrived through a Telnet login. Devices should not expose Telnet unless they need it, and none should keep factory credentials.

• Treat DNS-over-TLS from devices as a signal. An IoT device connecting to port 853 on public resolvers is worth a look. Where devices should use your own resolvers, blocking outbound port 853 keeps their DNS visible.

• Look for the protocol tag. Outbound TCP sessions whose first four bytes are ANCT, especially to port 35342, match this family's handshake.

• Check hosts for the persistence files. Files named .ancient anywhere, /etc/init.d/.ancient, /etc/profile.d/.ancient.sh, or a cron line running .ancient every five minutes. ANCIENT_* status strings in Telnet session logs point to the dropper.

• Use the published rules. Our repository has a YARA rule for the dropper (no false positives across about 500 honeypot samples), Suricata rules for the handshake and the C2 and payload endpoints, and a Sigma rule for the host persistence files.

Key indicators

All 17 indicators, including full SHA-256 hashes for the three dropper versions and both bot builds, are in the finding's iocs.csv. The full technical write-up has the timeline and the defanged dropper versions.

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 offline in an isolated lab whose internet access is fail-closed, and contact a C2 only when needed to confirm it is live: briefly, with only that destination reachable. We check every indicator against existing feeds before reporting it. More on our research page and in our methodology.

Indicators shared with ThreatFox, URLhaus and AbuseIPDB as ksi_digital. For this finding we reported the C2 to ThreatFox and its address to Spamhaus, and notified the hosting provider on 5 October 2026. Corrections are welcome: open an issue on GitHub or email christophe@ksi-digital.com.