# Tengu: New Mirai-Variant Botnet Targeting Linux IoT and Android TV Devices via Telnet Brute-Force

> Nozomi Networks Labs discovered Tengu, a modernized Mirai-derived botnet that compromises Linux-based IoT devices and Android TV boxes via Telnet credential brute-force, then installs an encrypted SOCKS5-proxy/DDoS bot with 25 attack methods, multi-vector persistence, and hardware-watchdog-based anti-forensic reboot capability.

- **Published:** 2026-07-29T00:00:00Z
- **Last reviewed:** 2026-07-29T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-1758
- **ID:** TL-2026-1758
- **Severity:** HIGH
- **Category:** MALWARE
- **Status:** ACTIVE
- **Detections:** 9 · **IOCs:** 24 (full data via the Threadlinqs MCP server — Purple tier)

## Description

Tengu is a newly catalogued Mirai-family botnet observed by Nozomi Networks Labs — flagged by an internal ML-based clustering system as not matching any known malware signature — after its dropper repeatedly hit the vendor's honeypots via classic Telnet credential brute-force against default/weak factory credentials on internet-exposed embedded Linux devices (routers, IP cameras, DVRs, and similar consumer IoT). After gaining a shell, the dropper fetches an architecture-specific ELF bot binary (samples recovered for i386, amd64, MIPS, ARM, PowerPC, and m68k) from the same host that operates as the botnet's C2 server, 64.89.163.8:9931. That server also runs an IPFS gateway on TCP/8080 used to distribute both ELF payloads and Android APKs, indicating the operators are extending the traditional Mirai targeting envelope to poorly secured Android TV boxes and similar Android-based embedded devices — the bot validates and side-loads APKs with `aapt dump badging` and launches them via `am start -n '%s/.MainActivity'`.

Operationally, the bot exposes a SOCKS5 proxy (with authentication), arbitrary shell command execution, system/network reconnaissance, and 25 distinct DDoS attack methods spanning volumetric floods (UDP, TCP SYN/ACK/PSH, ICMP), protocol-specific floods (HTTP, DNS, NTP, SNMP, SIP, SSH, SMTP, FTP), and gaming-protocol abuse (Source Engine/TSource query, Minecraft). C2 traffic uses a hybrid model — plaintext registration/heartbeat framing wrapped in an outer XOR (key byte 0x22) obfuscation layer, with command and update traffic protected by a ChaCha20/Poly1305-style AEAD scheme keyed from an embedded 256-bit key (`c2a1b84d9f73512e8a6c15f0b4d9e73b114a66895dc328927e34a5b148ce6103`) that Nozomi recovered from sample 097522a52986982b9eefc29f95efdd9d3b6032e7 (i386). The bot's self-update routine is triggered when a decrypted server message begins with the magic constant `0xDEAFBEEF`. The malware also embeds dormant, time-seeded DGA logic (using the current time plus a table of randomly selected TLDs embedded in the binary) for fallback C2 resolution that has not been observed active in the wild.

Tengu's standout engineering investment is anti-remediation and anti-forensics, not exploitation novelty. A detached guardian process (masquerading in the process table as a kernel worker thread, `[kworker/0:0]`) polls the main bot process roughly every 60 seconds and relaunches it if it stops. Persistence is installed redundantly via a real systemd unit, init.d/procd/rc.local/rc*.d modification, and a (partially broken) cron entry referencing `/proc/self/exe`, using decoy service names (`chud-daemon`, `chud-watchdog`, `chud-scheduler`). Most notably, the bot disables then re-arms the device's hardware watchdog (`/dev/watchdog0`) with a ~30-second timeout: if an incident responder kills the malware's process without disabling the watchdog, the device force-reboots before the watchdog is fed again, destroying the volatile memory state that would otherwise evidence the compromise, while the multiply-redundant persistence mechanisms simply relaunch the bot after boot. The malware additionally overwrites the device's reboot/shutdown utility binaries with corrupted ELF headers carrying an "ELFOOD" marker ("binary bricking"), further hindering clean remediation, and runs a competitor-killing loop (polling `/proc` every ~500ms, using netlink connector events and inotify) that SIGKILLs rival bot/miner processes to protect its foothold.

Anti-analysis tradecraft includes runtime string decryption via a custom XOR stream cipher keyed from two linear congruential generators, `memfd_create`-based fileless re-execution (falling back to `/dev/shm/.journal` when `memfd_create` is unavailable), argv[0] spoofing as `/usr/lib/systemd/systemd-journald`, `TracerPid` checks in `/proc/self/status` for debugger detection, inspection of `LD_PRELOAD`/`LD_LIBRARY_PATH` in `/proc/self/environ` for hooking tools, back-to-back `rdtsc` timing checks (self-terminating if execution delta exceeds ~500,000 cycles, indicating emulation/sandboxing), a periodically recomputed SHA-256 code-integrity baseline to detect tampering/patching, and hardening via `SIG_IGN` on termination signals, `prctl(PR_SET_DUMPABLE, 0)`, and an OOM-killer score of -1000. No CVE applies — the vulnerability is architectural (default/weak Telnet credentials on embedded devices), not a specific software flaw, and no threat-actor attribution or victim telemetry has been disclosed. Independent of Nozomi's analysis, URLhaus had already logged 17 malicious URLs (a shell-script dropper, multiple Mirai-tagged ELF files, and one APK) hosted on 64.89.163.8 beginning 2026-06-17, with the newest entry recorded 2026-07-07; as of 2026-07-28 all 17 URLhaus-tracked URLs were offline, and none of the SHA-256 hashes on URLhaus's host record matched the sample hashes Nozomi published, so the URLhaus-tracked payload set is corroborating-but-not-identical evidence of the same C2 host rather than a confirmed match to the exact Tengu samples. The botnet's redundant persistence and the presence of dormant DGA logic mean re-activation via a new C2 host remains plausible.

## MITRE ATT&CK

- T1078.001 Default Accounts
- T1110.001 Password Guessing
- T1059.004 Unix Shell
- T1106 Native API
- T1543.002 Systemd Service
- T1037.004 RC Scripts
- T1053.003 Cron
- T1546.004 Unix Shell Configuration Modification
- T1036.005 Match Legitimate Resource Name or Location
- T1036.004 Masquerade Task or Service
- T1497.001 System Checks
- T1622 Debugger Evasion
- T1027 Obfuscated Files or Information
- T1685 Disable or Modify Tools
- T1070 Indicator Removal
- T1082 System Information Discovery
- T1016 System Network Configuration Discovery
- T1057 Process Discovery
- T1573.001 Symmetric Cryptography
- T1568.002 Domain Generation Algorithms
- T1090.002 External Proxy
- T1105 Ingress Tool Transfer
- T1498.001 Direct Network Flood
- T1529 System Shutdown/Reboot

## Sources

- [New Tengu malware infects Linux IoT devices, Android TV boxes](https://www.helpnetsecurity.com/2026/07/29/tengu-mirai-iot-botnet-linux/)
- [Tengu: A Modernized Mirai That Doesn't Want to Leave](https://www.nozominetworks.com/blog/tengu-a-modernized-mirai-that-doesnt-want-to-leave)
- [Tengu Botnet Reboots Compromised Linux Devices When Defenders Kill Its Process](https://thehackernews.com/2026/07/tengu-botnet-reboots-compromised-linux.html)
- [Tengu Mirai Botnet Uses Watchdog Reboots and Binary Bricking to Resist Removal](https://gbhackers.com/tengu-mirai-botnet-uses-watchdog/)
- [Tengu Botnet Uses Hardware Watchdog to Erase Forensic Evidence on Reboot](https://www.techtimes.com/articles/321800/20260728/tengu-botnet-uses-hardware-watchdog-erase-forensic-evidence-reboot.htm)
- [New Tengu botnet uses hardware watchdog for advanced persistence](https://www.scworld.com/brief/new-tengu-botnet-uses-hardware-watchdog-for-advanced-persistence)
- [New Tengu Mirai Botnet Reboots Your IoT Device When You Try to Kill It](https://cybersecuritynews.com/new-tengu-mirai-botnet/)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-1758