Tengu Botnet Restarts Vulnerable Linux Devices When Defenders Kill Its Process
A new botnet from Mirai called Tengu can use a vulnerable Linux device’s hardware watchdog to trigger a reboot when defenders kill its main process.
If that happens, Tengu’s other persistence methods get another chance to relaunch it. Nozomi Networks Labs spotted a dropper accessing its honeypots by brute force Telnet.
Tengu supports 25 denial-of-service (DDoS) methods. It can also run a SOCKS5 proxy, run shell commands, and collect system and network data. The malware can update itself and return additional downloads of Executable and Linkable Format (ELF) or Android package (APK).
Nozomi has listed architecture-specific samples for i386, amd64, MIPS, ARM, PowerPC, and m68k. The report does not identify a specific vendor or device model. It also means no operator, infection rate, or real-world DDoS victims. It shows what Tengu can do, not how widespread it is.
Defenders should start by removing Internet exposure to Telnet and other unnecessary administrative services and replace them with default credentials. Nozomi also recommends updating firmware, isolating Internet of Things (IoT) networks, and updating systemd utilities, init scripts, shell startup files, and cron-related methods before returning the suspect device to service.
Nozomi Networks Labs published its analysis on July 27, 2026. Nozomi said Tengu’s persistence and defensive code made it stand out among the Mirai-based samples it tracked. “Most Mirai species use few, if any, of these defensive abilities,” the researchers said.
Once running, the bot feeds a decentralized monitor that checks the main malware process every 60 seconds and restarts the installed binary when it stops. It can also create a fake systemd service, add init and RC scripts, modify shell startup files, and mark installed binaries as unmodified. A cron-based persistence process exists, but Nozomi said its directory in /proc/self/exe appears to be incomplete or broken.
The second method abuses the device’s hardware watchdog. A background worker pretends to be us [kworker/0:0]it also turns on the watchdog device if found, arming it for about 30 seconds, and sending keepalive signals only while the malware process is alive. Kill the process and the watchdog stops serving, allowing the device to reboot. Tengu’s other persistent methods may then try to reintroduce it.
Tengu also maintains a hard-coded list of restarts and shutdowns. It clears their ELF headers with the string ELFOOD, which can intercept commands that attackers can use to reboot or safely power on a compromised device.
The analyzed sample was configured to communicate with the command and control server (C2) at 64.[.]89.163.8 over TCP port 9931. Registration, heartbeat traffic, and command output are sent in clear text, while server commands and updates use a proven encryption scheme such as ChaCha20/Poly1305.
Tengu can also find the C2-provided content identifier from the InterPlanetary File System (IPFS) gateway on the same server, verify the result as an ELF or APK, and use or install it.
Nozomi checked that the APK method likely targeted poorly secured Android TV boxes or similar devices, but did not document any confirmed Android victims.
URLhaus independently recorded 17 malware URLs at 64[.]89.163.8 as of June 17, 2026. Records include a shell script, multiple ELF files marked as Mirai, and an APK. URLhaus’s latest paid upload entries were first seen on July 7, and all 17 URLs were offline as of July 28.
URLhaus does not recognize files as Tengu. As of July 28, there are no SHA-256 hashes listed in the host record that match the sample hash published by Nozomi. So its telemetry ensures only Mirai-related hosting at the address.
Hacker News has reached out to Nozomi Networks for more details about Tengu’s observed scale, infrastructure status, and sample connections, and will update the story with any response.
Neither Nozomi nor URLhaus detects whether the C2 service on port 9931 or the IPFS gateway on port 8080 was reachable. The URLhaus status only applies to its downloadable URLs. Nozomi also doesn’t mention that the C2 server is set to 64[.]89.163.8:9931 issued any commands.
