A new Mirai-derived botnet called Tengu introduces a hardware-level persistence mechanism that defeats the most common IoT malware remediation method: killing the malicious process. When defenders terminate Tengu’s main process, the bot exploits Linux’s hardware watchdog timer to trigger a device reboot — and on reboot, Tengu’s other persistence mechanisms get another chance to relaunch. Nozomi Networks Labs observed Tengu reaching honeypots through Telnet credential brute force. The botnet supports 25 distributed denial-of-service attack methods, including both volume-based and protocol-specific techniques.
The Hardware Watchdog Trick That Defeats Process Kill
Linux hardware watchdog timers are designed as a reliability mechanism: if a critical process fails to regularly reset the watchdog, the kernel assumes the system has hung and triggers a reboot. This is an intended safety feature in embedded systems and networking hardware, where an unresponsive device needs automatic recovery without human intervention.
Tengu inverts this design. When the botnet’s main process is killed by a defender or by a competing process competing for resources, the watchdog timer stops receiving its keepalive signals. The kernel interprets the missing signal as a system hang and initiates a reboot — restoring the device to a state where Tengu’s persistence mechanisms can reactivate. The defender who killed the process has inadvertently triggered the device’s own recovery system to restart the infection.
Why This Breaks Standard IoT Malware Cleanup Procedures
The typical approach to cleaning a Mirai-variant infection on an IoT device follows a simple sequence: kill the malware process, restart the device, and change the credentials that allowed initial entry. Because most Mirai variants do not persist across reboots — they survive only in memory — a clean reboot after process termination is usually sufficient to evict the infection.
Tengu’s watchdog reboot mechanism disrupts this procedure at two points. Killing the process triggers an automatic reboot rather than clean device operation, and the reboot itself is not a clean state — it is an attacker-controlled event timed to relaunch persistence. Cleaning a Tengu-infected device may require a full firmware reset rather than a process kill and reboot, and on devices where factory resets do not restore clean firmware, physical intervention or reflashing from a verified image may be the only complete remediation path.
25 DDoS Attack Methods and the Botnet’s Expanded Capability Profile
Beyond the persistence innovation, Tengu supports 25 distributed denial-of-service attack methods. Mirai-derived botnets have historically built value through raw volume: large infected device fleets launching high-bandwidth floods. Tengu’s 25-method attack catalog includes both volume-based attacks — designed to exhaust bandwidth — and protocol-specific techniques that target weaknesses in specific protocols rather than relying purely on throughput.
Telnet Credential Brute Force as the Infection Vector
Nozomi Networks Labs documented Tengu reaching honeypots through Telnet credential brute force — the same infection vector that made the original Mirai botnet effective in 2016. A large population of Linux-based IoT devices — routers, IP cameras, NVRs, and embedded systems — ships with Telnet enabled and default credentials that many operators never change. That population has been a reliable source of botnet recruitment for nearly a decade, and Tengu’s operators have not needed to develop a novel infection vector when the existing one continues to work.
The persistence of Telnet-based credential attacks reflects a gap between device security standards and real-world deployment: devices are manufactured with open management interfaces and weak defaults, sold to consumers who lack the technical background to change them, and then deployed on networks for years or decades. Firmware updates and credential changes address the problem, but adoption in the IoT segment remains low.
What Defenders Need to Know About Tengu Remediation
For devices already compromised by Tengu, standard process-kill-and-reboot remediation will not work and may trigger the watchdog reboot cycle. Affected devices should be isolated from the network before remediation, and the remediation procedure should involve a full factory reset or firmware reflash from a verified image rather than a simple restart.
Organizations managing Linux-based IoT device fleets should audit for Telnet credential exposures, confirm that default passwords have been changed across all managed devices, and monitor network traffic for Tengu’s known Telnet brute-force signatures and DDoS command patterns. The hardware watchdog technique represents an evolutionary step in botnet persistence that defenders should account for when building IoT incident response procedures — cleanup playbooks written for memory-resident Mirai variants will not be adequate against Tengu.
