A new Mirai-derived botnet called Tengu can use a compromised Linux device’s hardware watchdog to trigger a reboot when defenders kill its main process.
If that happens, Tengu’s other persistence mechanisms get another chance to relaunch it. Nozomi Networks Labs observed the dropper reaching its honeypots through Telnet credential brute force.
Tengu supports 25 distributed denial-of-service (DDoS) methods. It can also run a SOCKS5 proxy, execute shell commands, and collect system and network data. The malware can update itself and retrieve additional Executable and Linkable Format (ELF) or Android package (APK) payloads.
Nozomi listed architecture-specific samples for i386, amd64, MIPS, ARM, PowerPC, and m68k. The report identifies no specific vendor or device model. It also names no operator, infection count, or real-world DDoS victims. It shows what Tengu can do, not how far it has spread.
Defenders should start by removing internet exposure for Telnet and other unnecessary administrative services and replacing default credentials. Nozomi also recommends updating firmware, segmenting Internet of Things (IoT) networks, and reviewing systemd services, init scripts, shell startup files, and cron-related paths before returning a suspected device to service.
Nozomi Networks Labs published its analysis on July 27, 2026. Nozomi said Tengu’s persistence and self-defense code made it stand out among the Mirai-derived samples it tracks. “Most Mirai variants implement few, if any, of these self-defense capabilities,” the researchers said.
Once running, the bot forks a detached guardian that checks the principal malware process every 60 seconds and relaunches the installed binary if it stops. It can also create a fake systemd service, add init and RC scripts, alter shell startup files, and mark its installed binary immutable. A cron-based persistence routine is present, but Nozomi said its reference to /proc/self/exe appears unfinished or broken.
A second mechanism abuses the device’s hardware watchdog. 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. Kill the process and the watchdog stops getting fed, allowing the device to reboot. Tengu’s other persistence mechanisms can then try to relaunch it.
Tengu also carries a hardcoded list of reboot and shutdown utilities. It overwrites their ELF headers with the string ELFOOD, which can interfere with the normal commands defenders may use to restart or safely power down a compromised device.
The analyzed sample was configured to communicate with a command-and-control (C2) server at 64[.]89.163.8 over TCP port 9931. Registration, heartbeat traffic, and command output are sent in plaintext, while server commands and updates use a custom ChaCha20/Poly1305-like authenticated encryption scheme.
Tengu can also obtain a C2-supplied content identifier from an InterPlanetary File System (IPFS) gateway on the same server, validate the result as an ELF or APK, and execute or install it.
Nozomi assessed that the APK path likely targets poorly secured Android TV boxes or similar devices, but did not document confirmed Android victims.
URLhaus independently recorded 17 malware URLs at 64[.]89.163.8 beginning June 17, 2026. The records included a shell script, multiple ELF files tagged as Mirai, and an APK. URLhaus’s most recent payload entries were first seen on July 7, and all 17 URLs were offline as of July 28.
URLhaus does not identify the files as Tengu. As of July 28, none of the SHA-256 hashes listed on its host record matched the sample hash published by Nozomi. Its telemetry therefore confirms only malicious Mirai-related hosting at the address.
The Hacker News has reached out to Nozomi Networks for additional details about Tengu’s observed scale, infrastructure status, and sample linkage, and will update the story with any response.
Neither Nozomi nor URLhaus establishes whether the C2 service on port 9931 or the IPFS gateway on port 8080 was reachable. URLhaus’s status applies only to its listed download URLs. Nozomi also does not say whether the configured C2 server at 64[.]89.163.8:9931 issued any commands.
