Tengu botnet uses Linux hardware watchdogs to survive process termination

Nozomi Networks Labs disclosed Tengu on July 27, 2026, describing a Mirai-derived botnet that can reboot compromised Linux devices when defenders terminate its main process. The malware supports 25 DDoS methods and targets systems through Telnet credential brute force.

Why process termination is not enough

Tengu turns a device’s hardware watchdog into a self-defense tool. A background worker disguised as [kworker/0:0] arms the watchdog with an approximately 30-second timeout and sends keepalive signals only while the primary malware process is running.

If that process is killed, the signals stop and the watchdog can reboot the device. The restart gives Tengu’s remaining persistence mechanisms another chance to relaunch the installed binary, complicating incident response across Linux and IoT environments.

“Most Mirai variants implement few, if any, of these self-defense capabilities,” the Nozomi researchers said.

Persistence, payloads and network capabilities

A detached guardian checks the main process every 60 seconds and restarts it if necessary. Tengu can also create a fake systemd service, add init and RC scripts, modify shell startup files, and mark its binary immutable. Its cron routine appears unfinished or broken.

The botnet can run a SOCKS5 proxy, execute shell commands, collect system and network data, update itself, and retrieve ELF or APK payloads. Samples were identified for i386, amd64, MIPS, ARM, PowerPC, and m68k. The APK capability may target poorly secured Android TV boxes, although no Android infections were confirmed.

Tengu also corrupts the ELF headers of hardcoded reboot and shutdown utilities with the string ELFOOD, potentially disrupting normal recovery commands. Its analyzed configuration used TCP port 9931 for command-and-control traffic; registration, heartbeats, and command output were transmitted in plaintext.

Nozomi did not identify an operator, infection total, affected vendor, device model, or confirmed DDoS victim. For businesses, the practical response is to disable internet-facing Telnet, rotate default credentials, update firmware, segment IoT networks, and review systemd, init, shell startup, and cron paths before restoring a suspected device.