Threat reportMalwareTL-2026-1758
Tengu: New Mirai-Variant Botnet Targeting Linux IoT and Android TV Devices via Telnet Brute-Force
Tengu: New Mirai-Variant Botnet Targeting Linux IoT and (TL-2026-1758) is a high-severity malware campaign, first published 2026-07-29. It has no confirmed attribution, affects Multiple (unspecified) Linux-based consumer IoT devices (routers, IP, maps to 24 MITRE ATT&CK techniques (T1016, T1027, T1036.004), and is covered by 9 detection rules and 24 indicators of compromise.
- Severity
- HIGHAssessed severity
- CVEs
- 0None referenced
- Techniques
- 24MITRE ATT&CK
- Actors
- 0Not attributed
- Detection rules
- 9SPL · KQL · Sigma
- IOCs
- 24Indicators of compromise
Key facts for TL-2026-1758
- Threat ID
- TL-2026-1758
- Severity
- HIGH
- Status
- ACTIVE
- Category
- MALWARE
- First published
- Last reviewed
- Attribution confidence
- LOW
- Motivation
- FINANCIAL
- Target sectors
- consumer, smallofficehomeoffice, telecoms, mediaandentertainment
- Target regions
- Global
- Detection rules
- 9
- Indicators of compromise
- 24
Malware and tooling in Tengu: New Mirai-Variant Botnet Targeting Linux IoT and
Malware and tooling: tengu
How Tengu: New Mirai-Variant Botnet Targeting Linux IoT and works
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.
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 techniques used in TL-2026-1758
Discovery
T1016 System Network Configuration Discovery; T1057 Process Discovery; T1082 System Information Discovery
Defense Evasion
T1027 Obfuscated Files or Information; T1036.004 Masquerade Task or Service; T1036.005 Match Legitimate Resource Name or Location; T1070 Indicator Removal; T1497.001 System Checks; T1622 Debugger Evasion
Persistence
T1037.004 RC Scripts; T1053.003 Cron; T1543.002 Systemd Service; T1546.004 Unix Shell Configuration Modification
Execution
T1059.004 Unix Shell; T1106 Native API
Initial Access
Command and Control
T1090.002 External Proxy; T1105 Ingress Tool Transfer; T1568.002 Domain Generation Algorithms; T1573.001 Symmetric Cryptography
Credential Access
Impact
T1498.001 Direct Network Flood; T1529 System Shutdown/Reboot
defense-impairment
Affected products and versions in Tengu: New Mirai-Variant Botnet Targeting Linux IoT and
- Multiple (unspecified) — Linux-based consumer IoT devices (routers, IP cameras, DVRs, embedded Linux appliances)
Vulnerable versions: Any device with Telnet enabled and default/weak administrative credentials
Fixed in: N/A — insecure configuration issue, not a version-specific vulnerability - Multiple (unspecified) — Android TV boxes / Android-based embedded devices
Vulnerable versions: Poorly secured Android TV / set-top devices reachable for APK side-loading via IPFS-delivered payload
Fixed in: N/A
Remediation for Tengu: New Mirai-Variant Botnet Targeting Linux IoT and
Patches
- No vendor patch applies — root cause is default/weak Telnet credentials and exposed management services on embedded Linux/Android devices, not a specific CVE
Immediate actions
- Disable Telnet (TCP/23) and any unnecessary remote-administration services on internet-facing IoT devices, routers, IP cameras, DVRs, and Android TV boxes
- Change all default/factory administrative credentials on embedded Linux and Android TV/set-top devices; enforce strong, unique passwords
- Block C2/IPFS host 64.89.163.8 (TCP/9931 C2, TCP/8080 IPFS gateway) at perimeter firewalls, egress filters, and DNS sinkholes
- Restrict management interfaces (Telnet/SSH/HTTP admin) to a VPN or isolated management network rather than the open internet
Workarounds
- Fully disable Telnet and any unused remote-administration daemons if not operationally required
- Deploy network egress filtering to block outbound connections to the known Tengu C2/IPFS host 64.89.163.8
Longer-term hardening
- Deploy IDS/IPS and EDR-equivalent signatures for Mirai-family C2 beacon patterns and the documented YARA-style detection strings
- Establish firmware update and default-credential-rotation programs for deployed IoT/embedded device fleets
- Segment IoT and embedded devices onto isolated VLANs with default-deny egress filtering
- Monitor for hardware-watchdog-triggered reboots and unexplained device restarts as a forensic-evasion indicator, and preserve volatile memory before killing suspicious processes on embedded devices
Weaknesses (CWE) in Tengu: New Mirai-Variant Botnet Targeting Linux IoT and
Timeline of Tengu: New Mirai-Variant Botnet Targeting Linux IoT and
- URLhaus independently begins logging malicious URLs hosted on 64.89.163.8 — the same IP later identified as the Tengu C2/IPFS server — starting with a shell-script dropper and Mirai-tagged ELF payloads.
- Newest of 17 total malicious URLs (including an APK) recorded by URLhaus on host 64.89.163.8; Nozomi Networks separately dates its Tengu YARA detection rule to the same day.
- Nozomi Networks Labs publishes original technical analysis 'Tengu: A Modernized Mirai That Doesn't Want to Leave', disclosing the C2 IP, 10 SHA-1 sample hashes across six processor architectures, the recovered ChaCha20/Poly1305 key, DGA/encryption details, and the full persistence/anti-analysis TTP set. Nozomi states the sample was first flagged by an internal ML-based clustering system as not matching any known malware family.
- Full IOC set published: C2 IP/port, 10 sample hashes across i386, amd64, MIPS, ARM (4 variants), PowerPC, and m68k architectures, the recovered 256-bit ChaCha20/Poly1305 key, and YARA-style detection strings (service names, file paths, masquerade strings).
- All 17 URLhaus-tracked malicious URLs on host 64.89.163.8 confirmed offline; URLhaus's own SHA-256 hashes for those files do not match Nozomi's published Tengu sample hashes, leaving the two datasets as corroborating-but-unconfirmed matches on the same C2 infrastructure. Redundant persistence and dormant DGA logic leave re-activation via new infrastructure plausible.
- GBHackers, Cybersecurity News, and SC Media publish independent technical summaries corroborating Nozomi's findings on persistence, evasion, and DDoS capability.
- The Hacker News and Tech Times publish initial coverage of Tengu's hardware-watchdog-based anti-forensic reboot mechanism.
- TL-Intel Harness ingests the Tengu disclosure from the Help Net Security RSS feed and opens threat record TL-2026-1758 for research.
- Help Net Security reports on Nozomi Networks Labs' discovery of the Tengu Mirai-variant botnet actively compromising Linux IoT devices and Android TV boxes via Telnet brute-force honeypot captures.
Sources cited for Tengu: New Mirai-Variant Botnet Targeting Linux IoT and
- New Tengu malware infects Linux IoT devices, Android TV boxes
- Tengu: A Modernized Mirai That Doesn't Want to Leave
- Tengu Botnet Reboots Compromised Linux Devices When Defenders Kill Its Process
- Tengu Mirai Botnet Uses Watchdog Reboots and Binary Bricking to Resist Removal
- Tengu Botnet Uses Hardware Watchdog to Erase Forensic Evidence on Reboot
- New Tengu botnet uses hardware watchdog for advanced persistence
- New Tengu Mirai Botnet Reboots Your IoT Device When You Try to Kill It
Detection coverage for TL-2026-1758
As of 2026-07-29, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-1758 across Splunk SPL, Microsoft KQL and Sigma, covering 24 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.
Community OSINT corroboration for TL-2026-1758
1 of this threat's indicators have also been reported by the open-source security community, which observed at least one of them before this report was published. Community sightings are unverified and are kept separate from Threadlinqs' curated indicators. Indicator values, reporters and campaign linkage are available to authenticated Red-tier users.