Tengu Botnet: When the Hardware Watchdog Defeats Forensics
08.08.2026 iot-forensicsmiraianti-forensicsembedded-linux
In late July 2026, Nozomi Networks Labs published an analysis of a new Mirai variant called Tengu — and in doing so delivered a textbook case of how a legitimate embedded-Linux safety feature can be repurposed into an anti-forensics weapon. A new Mirai-derived IoT botnet can force an infected Linux device to reboot once its main process is killed, giving its persistence mechanisms another opportunity to relaunch it. The malware, dubbed Tengu, was discovered by a machine-learning system the company uses to identify malware families that do not match known signatures. Initial access follows the well-worn Mirai playbook: Nozomi Networks Labs observed the dropper reaching its honeypots through Telnet credential brute force.
The Watchdog Trick: Turning a Safety Feature Against Responders
The forensic significance centers on a mechanism normally intended to keep embedded devices stable. The hardware watchdog timer is a purpose-built safety circuit found in essentially all embedded Linux devices — routers, IP cameras, digital video recorders, smart home hubs. Its job is to force a system reset if the main software stops responding, protecting remote or unattended devices from permanent lockups. Tengu inverts this protection: a background worker masquerades as [kworker/0:0], reopens the watchdog device if available, arms it with an approximately 30-second timeout, and sends keepalive signals only while the main malware process remains alive.
When a responder kills the main process, the keepalive stops, and the consequence is severe: it can also leverage the hardware watchdog timer; if the main process is killed, the watchdog is left unfed, causing a device reboot, which then allows Tengu’s other persistence methods to reactivate. For forensic practice, this means the complete loss of volatile evidence: running process lists, open network connections, in-memory forensic artifacts — everything a responder would need to document the infection — disappears, while Tengu has planted itself across systemd service entries, init.d scripts, shell startup files, and cron directories. The device comes back online with the malware running again, and a responder who didn’t know about the watchdog trick will almost certainly conclude the device is now clean.
Recovery is further complicated by direct sabotage of the tools responders would use afterward: Tengu also uses memfd_create to run entirely from RAM, impersonates a system daemon, and corrupts reboot utility ELF headers to hamper recovery. This is reinforced by self-integrity checks: Tengu monitors its own running state and checks whether its code has been changed. The malware reads memory-mapping information from the Linux proc filesystem, calculates a baseline SHA-256 value for part of its code, and repeatedly compares the result to identify tampering.
What This Means for IR Practice
The real risk isn’t Tengu itself — it’s how transferable the technique is. The finding matters beyond this single variant: the technique Tengu uses is not a device-specific exploit, but an architectural property present in virtually every embedded Linux device on the market, which means any Mirai-family malware author can now copy it. History suggests this propagation is close to inevitable: the original Mirai botnet, built by three college students in 2016, established a pattern that has repeated ever since: once a capability appears in the Mirai ecosystem, it propagates through successor variants.
For responders, the operational sequence must change: the core change Tengu demands from incident responders is sequencing: evidence collection must happen before any action that could trigger a reboot, because a reboot will destroy the evidence. Nozomi advises responders to capture volatile artifacts — running process lists, open network connections, in-memory forensics — before attempting to terminate the process. Remediation itself now requires far more than a power cycle: because simple reboots fail to eradicate the malware, remediation demands labor-intensive manual interventions, including complete factory resets, firmware reflashing, or total hardware sanitization.
For DFIR teams responsible for IoT and edge devices, Tengu is less a single IOC list than a wake-up call: standard playbooks built around “kill the process, then analyze” need a fundamental rewrite for embedded Linux — with live memory capture, network traffic snapshots, and integrity verification of recovery binaries as mandatory first steps, long before any kill signal is ever sent.
← Back to overview