Tengu Botnet Weaponizes Linux Watchdog for Persistence

Nozomi Networks Labs has documented Tengu, a Mirai-derived DDoS botnet that spreads via Telnet credential brute force and carries an unusual persistence mechanism: it uses the compromised Linux device’s hardware watchdog timer to trigger a reboot when defenders kill its process, giving its dropper components another chance to relaunch the infection.

The watchdog mechanism

Hardware watchdog timers are a reliability feature in embedded systems, not a security one. The running software is expected to issue a periodic reset signal to the watchdog; if that signal stops — because the software crashed or hung — the hardware fires and reboots the device automatically. The design premise is that a silent process is a failed process.

Tengu inverts that. When the botnet’s main process is killed by a defender, it stops issuing the watchdog signal. The timer counts down and fires. The device reboots. Tengu’s dropper components, installed separately during the initial compromise, then get another shot at reinstalling the botnet process. From the outside, the reboot looks like recovery. It’s reinfection.

Access and capability

Tengu gains initial access through Telnet brute force against weak and default credentials — the same attack path Mirai used in 2016 and that successive generations of IoT botnets have relied on since. Nozomi Labs observed the dropper reaching its honeypot infrastructure through this vector. Once on the device, the botnet supports 25 distributed denial-of-service attack types.

What this adds to incident response

The watchdog trick doesn’t make Tengu impossible to remove. It introduces a gap in the standard embedded Linux IR sequence: kill the process, confirm it’s gone, proceed. That sequence assumes process termination is the last meaningful step before the device is clean. When killing the process triggers a reboot, the question becomes whether the dropper components were also removed before the hardware timer fired. If not, the reboot delivers the infection a second time.

The underlying problem — malware that persists across reboots — is familiar. The mechanism here is new enough to be worth flagging for anyone whose incident response procedures treat process-kill as a terminal step on embedded Linux hardware.

Mitigation for the access vector is the same as it’s always been: disable Telnet exposure, replace default credentials across the device fleet, isolate management interfaces from the data plane. The device population that Telnet-based botnet families keep successfully targeting has had a long time to be closed off. On a related note, Dysphoria recently adopted blockchain-based C2 to resist law-enforcement disruption after an earlier takedown — a different approach to the same operational problem of making infrastructure hard to evict.