On July 1 We Said Engineering Effort Predicts a Botnet's Future Better Than Its Size. Twenty-Seven Days Later an Unrelated Family Proved It — and Its Kill Switch Is Your Own Incident Response.

On July 1 we published an argument about a botnet nobody needed to care about yet. RustDuck was small. It was not knocking over major services. On a threat-severity chart it barely registered. The post said to watch it anyway, and it said why in one line:

A small botnet built like a durable product is not a small threat that will stay small. It is a large threat in its early, cheap-to-stop phase.

That is a testable claim, and the honest way to treat a testable claim is to come back to it. Twenty-seven days later something happened that tests it — not the way we expected, and in a way that makes the underlying point larger than the one we made.

What we were reading in RustDuck

The evidence in that post was entirely about construction, not damage. The operators were rewriting a working botnet from C into Rust — a rewrite nobody undertakes on a whim, in a language chosen because it is harder to reverse-engineer. Key derivation had moved to HKDF-SHA256. Some variants rotated encryption keys every ten minutes.

What has been documented since fills that picture in further. QiAnXin's XLab team has tracked RustDuck since February 2026. The Rust builds encrypt command-and-control traffic with ChaCha20-Poly1305. There is a dynamic weight-scoring system for detecting sandboxes and debuggers — not a single check that returns true or false, but a scoring model that accumulates signals. Propagation runs on two legs: brute force against Telnet and SSH, and exploitation of known flaws in TP-Link and ZTE firmware, Android ADB, Jenkins and ThinkPHP.

None of that is what you build to make a quick nuisance. Rotating keys are what you build when you expect somebody to be capturing your traffic. A sandbox-scoring model is what you build when you expect somebody to be running your binary in a lab. Every one of those choices costs the operator time and buys them nothing today. They are only rational if the operator expects a fight they have not had yet.

Then Tengu turned up, and it is not RustDuck

Nozomi Networks published research today on a botnet called Tengu. We want to be precise about this before drawing any conclusion from it: Tengu is not RustDuck. It is a Mirai variant, a different lineage entirely, and its initial access is the oldest trick in the IoT book — Telnet brute force against factory-default credentials, the same vector Mirai used in 2016. Nothing about it descends from the thing we wrote about.

And it makes the same class of investment.

Tengu's command-and-control address is XOR-obfuscated in the binary and resolved only at runtime. Its commands from the operator are protected with ChaCha20/Poly1305 — the same authenticated-encryption construction as RustDuck, the same one your browser uses for TLS. It computes a SHA-256 baseline over part of its own code from the Linux proc filesystem and re-checks it continuously to detect tampering. It watches for writable memory mappings, because that is what an analyst's tooling leaves behind. It masquerades in process listings as systemd-journald and uses kernel-worker names like [kworker/0:0]. It runs from memory. It maintains a detached guardian process whose only job is to restart the payload if the main process dies, and it establishes persistence across systemd units, init scripts, shell startup files and cron.

Two families with no shared ancestry, disclosed twenty-seven days apart, independently arriving at runtime-resolved obfuscated C2, modern AEAD encryption, active anti-analysis, and process-name camouflage. Down to the same cipher.

That is convergent evolution, and it is the finding. Our July 1 claim was about one botnet's trajectory. The correct and larger version of it is this: the engineering floor for the whole category has moved. These are not two clever operators. This is what a competent IoT botnet is now expected to include, the way TLS became table stakes for a login page. If your mental model of "IoT botnet" still means a sloppy Mirai fork with a hardcoded C2 in cleartext, that model retired sometime in the last quarter and nobody sent a notice.

The part that inverts your incident response

Tengu's anti-removal mechanism deserves to be understood in detail, because it is the most elegant hostile idea we have written about this month and because the correct response to it is the opposite of your training.

Embedded devices — routers, cameras, DVRs — ship with a hardware watchdog. It is a physical timer circuit whose entire purpose is reliability: software must periodically send it a keepalive signal, and if the signal stops, the watchdog concludes the system has hung and forces a hard reset. It is one of the most benign components in the device. It exists to save you.

Tengu forks a child process whose only job is to pet that watchdog.

So when a responder does the industry-standard first thing — identify the malicious process, kill it — the child dies alongside the parent, the keepalives stop, and roughly thirty seconds later the hardware resets the device. Since Tengu runs from memory, the reboot destroys the only forensic evidence that ever existed. And because it has persistence written across systemd, init, shell profiles and cron, it comes back on boot.

Read the sequence again, because the elegance is in who does the work. The responder pulls the trigger. The malware does not defend itself, does not detect the analyst and self-destruct, does not race anything. It arranges the board so that the defender's own correct-looking action executes the anti-forensics, using a hardware circuit the device manufacturer installed for reliability. The kill command is the wipe command. You cannot patch that, because the watchdog is not the bug.

It is a close cousin of a pattern we have tracked before — attacks that win by removing the artifact a defense assumes will be there. This one is the mirror image: it wins by weaponising an artifact the defense assumes is friendly.

Nozomi's own guidance is the right guidance and it is worth repeating in plain words: capture volatile artifacts before you terminate anything. Running process list, open network connections, memory image. On a device with a thirty-second watchdog, that window is as short as it sounds. If your embedded-device IR runbook currently begins with "kill the suspicious process," that runbook now destroys your evidence and does not remove the infection.

Our receipt, stated flat

Nozomi published Tengu's C2 today: [64.89.163.8](https://analytics.dugganusa.com/stix/register?ref=ioc-click&q=64.89.163.8).

We queried our own corpus. It has been there since 2026-06-21, ingested via the tweetfeed community feed at confidence 70 — thirty-seven days before the research that gave it a name. Independently, URLhaus has served mirai-tagged ELF payloads out of /hiddenbin/ at that same address, and its next-door neighbour 64.89.163.7 sits in our index too.

Now the part we are obliged to say, because we published a correction nine days ago for getting exactly this wrong. That is not a detection lead and we are not going to call it one. Our record's source is feed-tweetfeed — a third-party community feed, not our honeypot, not our scanning, not github-hunt. The credit for spotting that address early belongs to the community researchers who listed it and to URLhaus, both of whom are unrelated to Nozomi and both of whom predate the disclosure. What we did was carry it.

The honest claim is a distribution claim, and it is still worth something: anybody pulling our blocklists has been able to block Tengu's command-and-control since June 21, for free, thirty-seven days before it had a name. That is the whole argument for a feed that aggregates and redistributes — not that we saw it first, but that a defender who cannot afford four subscriptions got the benefit of them anyway.

We have now attributed that indicator to Tengu in our feed, citing Nozomi, so a customer searching the family name finds it rather than a bare IP with no story. Nozomi also published SHA-256 hashes across x86, AMD64, MIPS, ARM, PowerPC and m68k builds plus a YARA rule — go get those from them directly; that is their work and it deserves the click.

Where this leaves the July 1 call

Partly right, and right about the wrong thing, which is the most useful outcome an argument can have.

We said watch RustDuck because its engineering predicted its future. We cannot yet score that specific prediction — RustDuck has not become a headline botnet in twenty-seven days, and anyone claiming a four-week window settles a question about a multi-year build is selling something. That verdict is still open and we will come back to it again.

What did get settled is the general form. Engineering investment is a leading indicator, it is readable months before the damage numbers move, and it is not confined to one family. Tengu is a second, independent sample. If we had been tracking the category the way we tracked the actor, Tengu's construction quality would have been visible as a signal before its cleverest feature was disclosed — and the tell would have been the same tell: somebody spending real money on not being caught by a defender who has not shown up yet.

The practical version, for anyone triaging a botnet they have not heard of: stop opening with how big it is. Open with how well it is built. Size tells you what it did last month. Construction tells you what it intends.

We hold this at 95 percent. Tengu's technical detail is Nozomi's research and RustDuck's is XLab's — we have verified neither in a lab, and the convergent-cipher observation, while real, is drawn from two samples, which is a pattern and not yet a law. The watchdog behaviour in particular is described by its researchers rather than reproduced by us. What we did verify ourselves is the boring part, and it is the part with your name on it: that C2 address has been sitting in a free blocklist you could have pulled since June.

---

Every indicator in this post is in the feed. Free.

1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.

Get your free key → analytics.dugganusa.com/stix/register