At a glance
| Malware family | Tengu (Mirai-derived IoT botnet) |
| Threat actor | Unattributed; no operator named |
| Target | Internet-facing embedded Linux devices, such as routers, cameras, and DVRs |
| Delivery vector | Telnet brute force, then a shell-script dropper over HTTP |
| Key capabilities | 25 DDoS methods, SOCKS5 proxy, recon, payload updates, persistence, self-defense |
| Source | Nozomi Networks Labs |
TL;DR
Nozomi Networks Labs disclosed a new IoT botnet named Tengu on July 27, 2026. The Tengu botnet builds on Mirai but adds encrypted C2, proxy features, anti-analysis, and strong self-defense. It resists removal by rebooting devices and corrupting recovery tools.
Delivery
The Tengu botnet spreads the classic Mirai way. It brute-forces Telnet credentials on exposed devices. A short shell script then downloads architecture-specific binaries over HTTP. Nozomi found builds for i386, amd64, MIPS, ARM, PowerPC, and m68k.
The same host serves both the samples and the C2. As Nozomi notes, “exposed and poorly maintained IoT and embedded Linux systems remain attractive footholds for attackers.” The report names no specific device model, operator, or victim count.
Infection chain
Once running, Tengu tries to hide in memory. It uses memfd_create to run from a RAM-backed file that never touches disk. If that call fails, it copies itself into shared memory and unlinks the file. It also renames its process to mimic a systemd journal daemon.
The malware then hardens itself. It ignores common kill signals and disables core dumps. It also tells the kernel to avoid ending it under memory pressure. On top of that, it checks for debuggers, timing anomalies, and tampering with its own code.
Persistence
Tengu plants several footholds at once. It can add a fake systemd service, init.d entries, and shell startup hooks. A separate guardian process watches the main binary and relaunches it within about a minute. One cron routine looks unfinished, which hints at active development.
Command-and-control and exfiltration
Tengu decodes a hardcoded C2 address at runtime with a simple XOR step. Registration and heartbeat messages travel in plaintext. Server commands, however, use an authenticated, encrypted scheme similar to ChaCha20/Poly1305. The key sits inside the sample.
The controller offers a wide toolset. It can start a SOCKS5 proxy, run shell commands, and stage more payloads. It exfiltrates system and network details, including interfaces, addresses, and DNS settings. A separate update path swaps the running binary for a fresh one.
Payload delivery also moves toward decentralized infrastructure. The bot can fetch files from an IPFS gateway and run ELF or APK samples. That APK path likely targets Android TV boxes. The Tengu botnet’s DDoS toolkit is broad, too. Nozomi counted 25 attack methods, from UDP and TCP floods to probes against HTTP, DNS, and game servers. A dormant DGA also hides inside, so blocking one C2 address is not a full fix.
Self-defense and defense guidance
Self-defense is what sets Tengu apart. Nozomi writes that “most Mirai variants implement few, if any, of these self-defense capabilities.” The standout is a watchdog trick. If defenders kill the main process, the device reboots. That reboot wipes volatile evidence and gives persistence another chance.
The malware pushes further still. It bricks reboot and shutdown binaries by corrupting their headers. It also runs a fast loop that hunts and kills rival botnets to keep sole control.

What defenders should do
- Remove internet exposure for Telnet and other admin services.
- Replace default credentials and disable unused remote access.
- Update firmware and segment IoT networks from critical systems.
- Watch for proxy-like traffic and processes posing as system daemons.
- Check systemd services, init scripts, shell files, and cron paths before restoring a device.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.