Tengu Botnet Weaponizes Linux Hardware Watchdogs to Prevent Process Termination

A newly identified Mirai variant named Tengu botnet is turning low-level Linux system resilience features against defenders, weaponizing hardware watchdogs to reboot compromised IoT devices whenever security tools or incident responders terminate its primary process. Identified in late July 2026 by Nozomi Networks Labs, Tengu demonstrates a rare level of defensive evasion and persistence for IoT-focused malware. While traditional botnets rely on simple autostart scripts or volatile memory execution, Tengu ensures that any attempt to kill its active payload triggers an uncontrolled system reset—giving its secondary persistence mechanisms another chance to reinstate the malware upon reboot.

Watchdog Weaponization and Persistence Mechanics

Hardware watchdogs are low-level hardware timers common in embedded Linux devices, routers, and single-board systems. Designed to automatically reboot a hung or unresponsive kernel, a Linux hardware watchdog driver expects a user-space daemon to periodically write keepalive signals (commonly referred to as “kicking” or “feeding” the watchdog) to the watchdog device interface. If the keepalive signal ceases for a preconfigured duration, the hardware timer expires and triggers a hard system reboot.

Tengu abuses this mechanism by spawning a background worker process that masquerades under the benign kernel thread name [kworker/0:0]. This worker thread opens the watchdog device, configures a timeout interval of approximately 30 seconds, and continuously issues keepalive signals—but only while Tengu’s main malware process remains operational. If an administrator or endpoint protection script kills the principal malware process, the worker stops feeding the watchdog. Within 30 seconds, the hardware watchdog triggers an abrupt system reset.

Once the compromised host reboots, Tengu relies on multiple redundant persistence mechanisms to re-establish execution:

• Process Guardian: A detached guardian process polls every 60 seconds to inspect the status of the primary bot process, automatically re-executing the binary if it terminates without triggering a full system reset.
• Init & Service Scripts: The bot installs a fake systemd service, modifies /etc/init.d/ and RC startup scripts, and injects startup commands into system-wide and user shell startup files.
• File System Immutability: Tengu sets the immutable file attribute (chattr +i) on its installed binary, preventing unprivileged deletion or overwrite attempts by local tools.
• Cron Jobs: A scheduled cron routine is included in the malware code, although analysis shows its reference to /proc/self/exe is currently broken or unfinished in analyzed samples.

To further impede live response efforts, Tengu includes a hardcoded list of common Linux system shutdown and reboot binaries (reboot, shutdown, etc.). The malware overwrites the Executable and Linkable Format (ELF) headers of these utilities with the string ELFOOD. This intentionally corrupts the administrative binaries, causing native shutdown or restart commands to fail when defenders attempt a controlled reboot.

Capabilities, C2 Infrastructure, and Payload Delivery

Initial access relies on automated Telnet brute-forcing against exposed administrative ports, consistent with classical Mirai propagation tactics. Nozomi Networks Labs recovered architecture-specific samples targeting i386, amd64, MIPS, ARM, PowerPC, and m68k platforms, highlighting broad multi-architecture compilation across embedded systems.

Once running, Tengu functions as a versatile remote access and DDoS platform capable of:

• Launching up to 25 distinct Distributed Denial-of-Service (DDoS) flood vectors.
• Running an embedded SOCKS5 proxy server to pivot traffic through infected edge nodes.
• Executing arbitrary shell commands and exfiltrating local system and network configuration data.
• Fetching and installing secondary ELF payloads or Android Package (APK) files.

Command-and-control (C2) communications observed by researchers were configured to contact 64[.]89.163[.]8 over TCP port 9931. Initial registration, heartbeat packets, and command execution outputs are sent in cleartext, whereas incoming server tasking and software updates use a custom ChaCha20/Poly1305-like authenticated encryption scheme.

Tengu also incorporates an InterPlanetary File System (IPFS) gateway integration. The malware can retrieve C2-supplied Content Identifiers (CIDs) from an IPFS service running on port 8080 of the C2 host, validate the fetched payload as an ELF executable or an APK, and execute or install it locally. The presence of APK validation logic indicates that the threat actors are positioning the malware to compromise exposed Android TV boxes or embedded Android hardware, though active Android infections have not yet been confirmed in published telemetry.

Independent data from URLhaus logged 17 malicious URLs hosted at 64[.]89.163[.]8 beginning June 17, 2026, including shell scripts, Mirai-tagged ELF payloads, and an APK installer. All listed URLs were marked offline as of July 28.

Operational Blast Radius and Incident Response

Because Tengu explicitly targets the software tools and process controls used during manual triage, standard live-response workflows will fail or inadvertently trigger a host reboot that reinstates the malware. Organizations operating IoT fleets, edge routers, or embedded Linux appliances should adjust triage playbooks accordingly.

Defenders should immediately apply the following mitigations:

• Perimeter Hardening: Remove direct internet exposure for Telnet (TCP 23) and other cleartext administrative protocols. Disable default vendor credentials across all deployed hardware and restrict management access to isolated management VLANs or encrypted VPN conduits.
• Network Isolation During Triage: If a host is suspected of infection, do not attempt to kill suspicious processes or run standard reboot / shutdown commands. Isolate the device at the switch port or firewall level first to prevent C2 communication and lateral movement.
• Persistence Inspection: Before returning a suspicious device to service, audit all systemd service units, /etc/init.d/ entries, shell configuration files (.bashrc, /etc/profile), and cron directories. Inspect executable file attributes using lsattr and remove immutable flags (chattr -i) before attempting file removal.
• Firmware Flashing: Due to Tengu’s multiple persistence hooks and binary corruption mechanisms, out-of-band factory resets or full offline firmware reflashing represent the safest path to clean recovery.