A new **Mirai**-derived botnet named **Tengu** has emerged, capable of utilizing a compromised Linux device's hardware watchdog to trigger a reboot when its primary process is terminated. This cunning tactic allows **Tengu**'s other persistence mechanisms to relaunch the botnet, ensuring its continued operation.  **Nozomi Networks Labs** first observed the dropper reaching their honeypots through **Telnet** credential brute force attacks. ### Advanced Capabilities and Persistence **Tengu** is equipped with 25 different distributed denial-of-service (**DDoS**) methods, making it a potent threat. Beyond **DDoS**, it can establish a **SOCKS5** proxy, execute arbitrary shell commands, and harvest system and network data. The malware also boasts self-update capabilities and can retrieve additional **Executable and Linkable Format (ELF)** or **Android Package (APK)** payloads. **Nozomi** identified architecture-specific samples for **i386**, **amd64**, **MIPS**, **ARM**, **PowerPC**, and **m68k**, indicating a broad targeting scope. While no specific vendor, device model, or operator has been named, and the extent of its spread or real-world **DDoS** victims remains undocumented, the report clearly outlines **Tengu**'s formidable capabilities. ### Unprecedented Self-Defense **Nozomi Networks Labs** highlighted **Tengu**'s persistence and self-defense code as particularly noteworthy among **Mirai** variants. Researchers noted that "Most Mirai variants implement few, if any, of these self-defense capabilities." Upon execution, **Tengu** forks a detached guardian process that monitors the main malware every 60 seconds, relaunching the binary if it ceases operation. It can also create fake **systemd** services, add **init** and **RC** scripts, modify shell startup files, and mark its installed binary as immutable. A **cron**-based persistence routine is also present, though its reference to `/proc/self/exe` appears incomplete. ### Hardware Watchdog Exploitation A particularly insidious mechanism involves abusing the device's hardware watchdog. A background worker, masquerading as `[kworker/0:0]`, reopens the watchdog device if available, arms it with an approximately 30-second timeout, and sends keepalive signals only as long as the main malware process is active. Should the main process be killed, the watchdog stops receiving signals, leading to a device reboot. This allows **Tengu**'s other persistence mechanisms a fresh opportunity to relaunch the botnet. Furthermore, **Tengu** carries a hardcoded list of reboot and shutdown utilities. It overwrites their **ELF** headers with the string `ELFOOD`, effectively disrupting the normal commands defenders might use to restart or safely power down a compromised device. ### Command and Control Infrastructure The analyzed sample was configured to communicate with a command-and-control (**C2**) server at `64[.]89.163.8` over **TCP** port `9931`. While registration, heartbeat traffic, and command output are transmitted in plaintext, server commands and updates leverage a custom **ChaCha20/Poly1305**-like authenticated encryption scheme. **Tengu** can also fetch a **C2**-supplied content identifier from an **InterPlanetary File System (IPFS)** gateway on the same server, validate it as an **ELF** or **APK**, and then execute or install it. **Nozomi** assesses that the **APK** path likely targets poorly secured **Android TV boxes** or similar devices, though no confirmed **Android** victims have been documented. ### Independent Verification and Mitigation **URLhaus** independently recorded 17 malware **URLs** at `64[.]89.163.8` starting June 17, 2026, including a shell script, multiple **ELF** files tagged as **Mirai**, and an **APK**. While these records confirm malicious **Mirai**-related hosting at the address, they do not specifically identify the files as **Tengu**, nor do the **SHA-256** hashes match the sample hash published by **Nozomi**. Defenders are urged to take proactive measures, starting with the removal of internet exposure for **Telnet** and other unnecessary administrative services, and replacing all default credentials. **Nozomi** also recommends updating firmware, segmenting **Internet of Things (IoT)** networks, and thoroughly reviewing **systemd** services, **init** scripts, shell startup files, and **cron**-related paths before returning any suspected device to service.