Threat reportMalwareTL-2026-1745
Tengu Botnet Reboots Compromised Linux Devices When Defenders Kill Its Process
Tengu Botnet Reboots Compromised Linux Devices When (TL-2026-1745) is a high-severity malware campaign, first published 2026-07-28. It has no confirmed attribution, affects Multiple / unspecified OEM embedded-Linux device manufacturers, maps to 25 MITRE ATT&CK techniques (T1016, T1027, T1036), and is covered by 9 detection rules and 20 indicators of compromise.
- Severity
- HIGHAssessed severity
- CVEs
- 0None referenced
- Techniques
- 25MITRE ATT&CK
- Actors
- 0Not attributed
- Detection rules
- 9SPL · KQL · Sigma
- IOCs
- 20Indicators of compromise
Key facts for TL-2026-1745
- Threat ID
- TL-2026-1745
- Severity
- HIGH
- Status
- ACTIVE
- Category
- MALWARE
- First published
- Last reviewed
- Attribution confidence
- LOW
- Motivation
- UNKNOWN
- Target sectors
- iotconsumerdevices, smallofficehomeoffice, embeddedsystems, generalenterpriseiot
- Target regions
- Global
- Detection rules
- 9
- Indicators of compromise
- 20
Malware and tooling in Tengu Botnet Reboots Compromised Linux Devices When
Malware and tooling: Mirai, tengu, Custom ChaCha20/Poly1305-like encrypted C2 protocol, SOCKS5 proxy module
How Tengu Botnet Reboots Compromised Linux Devices When works
Tengu is a Mirai-derived Linux/IoT botnet, documented by Nozomi Networks Labs, that compromises internet-exposed embedded devices across six CPU architectures via Telnet credential brute force. It survives takedown attempts through a 60-second guardian-process respawn, fake systemd/init/RC/shell-startup persistence, binary immutability marking, and hardware-watchdog abuse that force-reboots the device if its process is killed, while offering 25 DDoS methods, SOCKS5 proxying, remote shell execution, and a custom ChaCha20/Poly1305-like encrypted C2 channel.
Tengu is a newly documented Mirai-lineage botnet targeting internet-facing embedded Linux systems — routers, cameras, DVRs, and other low-maintenance devices — that expose Telnet or similar remote administration services. Nozomi Networks Labs published the first technical analysis on 2026-07-27, and the finding was corroborated the following day by The Hacker News, Cyber Security News, Cyberpress, and Cryptika Cybersecurity.
Initial access is achieved through Telnet credential brute force against honeypot and internet-exposed devices. A shell-script dropper subsequently pulls an architecture-specific binary over HTTP, with samples confirmed for i386, amd64, MIPS, ARM, PowerPC, and m68k — giving Tengu one of the broadest hardware footprints observed in a current Mirai derivative.
What separates Tengu from generic Mirai clones is its anti-remediation depth. The primary malware process forks a detached guardian that checks the main process every 60 seconds and relaunches the installed binary if it is stopped. In parallel, a background worker masquerading as the kernel thread "[kworker/0:0]" reopens the hardware watchdog device where available, arms it with an approximately 30-second timeout, and issues keepalive signals only while the main malware process remains alive — meaning that if a defender kills the process without disabling the watchdog, the device is forced into a hardware reboot, destroying volatile forensic evidence and undoing in-memory remediation. Tengu additionally marks its installed binary immutable, installs fake systemd service units, alters init/RC scripts and shell startup files (cron-based persistence is present but described as unfinished/broken), and overwrites the ELF headers of a hardcoded list of reboot/shutdown utility binaries with the string "ELFOOD" — corrupting the very tools an administrator would use to cleanly power-cycle the device.
The malware also runs largely fileless: it uses memfd_create() to build an in-memory file named "systemd-journal" (falling back to /dev/shm/.journal if memfd is unavailable), deletes the filesystem-visible entry while keeping the file descriptor open, and re-executes itself via execve — leaving little on-disk footprint. The main process additionally rewrites its displayed command-line name to /usr/lib/systemd/systemd-journald to blend into normal process listings, and performs self-integrity checks by reading /proc memory-mapping information, computing a baseline SHA-256 value over part of its own code, and repeatedly comparing it (alongside monitoring for unexpectedly writable memory mappings) to detect tampering, patching, or analysis.
Command and control runs to 64.89.163.8 over TCP/9931. Registration, heartbeat, and command-output traffic are sent in plaintext, but server-issued commands and binary updates are protected with a custom ChaCha20/Poly1305-like authenticated encryption scheme. The C2 IP is XOR-obfuscated inside the binary, and dormant domain-generation-algorithm (DGA) logic is present but not observed in active use, suggesting a fallback capability the operator has not yet activated. The same host also serves an IPFS gateway (port 8080) used to retrieve additional ELF or APK payloads, including an Android APK whose delivery path suggests targeting of poorly secured Android TV boxes, though no confirmed Android infections have been documented.
Operational capabilities include 25 distinct DDoS methods, built-in SOCKS5 proxying (enabling proxy resale/relay abuse), arbitrary remote shell command execution, system and network reconnaissance data collection, self-updating, and the ability to detect and remove competing malware from a compromised device — a common Mirai-family trait aimed at monopolizing device resources.
URLhaus has tracked 17 malware URLs at 64.89.163.8 since 2026-06-17 (most recently 2026-07-07), comprising shell-script droppers, multiple ELF binaries tagged as Mirai, and one APK — corroborating that the C2 host doubles as an active malware distribution point. No CVE applies: this is a configuration/credential-exposure threat (exposed Telnet plus default or weak credentials) rather than a specific software vulnerability, so remediation is centered on reducing exposure and hardening credentials rather than patching.
MITRE ATT&CK techniques used in TL-2026-1745
Discovery
T1016 System Network Configuration Discovery; T1082 System Information Discovery
Defense Evasion
T1027 Obfuscated Files or Information; T1036 Masquerading; T1070 Indicator Removal; T1497 Virtualization/Sandbox Evasion; T1620 Reflective Code Loading
Persistence
T1037 Boot or Logon Initialization Scripts; T1053 Scheduled Task/Job; T1543 Create or Modify System Process; T1546 Event Triggered Execution
Execution
T1059 Command and Scripting Interpreter
Command and Control
T1071 Application Layer Protocol; T1090 Proxy; T1102 Web Service; T1105 Ingress Tool Transfer; T1568 Dynamic Resolution; T1573 Encrypted Channel
credential-access
Initial Access
T1133 External Remote Services
defense-impairment
T1222 File and Directory Permissions Modification; T1685 Disable or Modify Tools
Impact
T1489 Service Stop; T1498 Network Denial of Service; T1529 System Shutdown/Reboot
Affected products and versions in Tengu Botnet Reboots Compromised Linux Devices When
- Multiple / unspecified OEM embedded-Linux device manufacturers — Internet-exposed embedded Linux IoT devices (routers, IP cameras, DVRs, and Android TV boxes) running with Telnet or similar remote administration enabled
Vulnerable versions: i386 builds; amd64 builds; MIPS builds; ARM builds; PowerPC builds; m68k builds
Fixed in: Not applicable — mitigated via configuration (disable Telnet, enforce strong credentials), not a vendor patch
Remediation for Tengu Botnet Reboots Compromised Linux Devices When
Patches
- No vendor patch applies — Tengu propagates via exposed Telnet and weak/default credentials rather than a specific software vulnerability; remediation is configuration-based
Immediate actions
- Disable Telnet and any other unauthenticated or default-credential remote administration service on internet-facing IoT/embedded Linux devices
- Block inbound and outbound traffic to 64.89.163.8 on TCP/9931 (C2) and TCP/8080 (IPFS gateway) at the network perimeter
- Replace all default/factory-set device credentials with strong, unique passwords
- Flag and forensically preserve (before rebooting) any device running a process masquerading as systemd-journald with anomalous behavior, or a [kworker/0:0]-named process holding active network sockets
Workarounds
- Before returning a cleaned device to service, inspect systemd service units, init/RC scripts, shell startup files, and cron entries for Tengu-installed persistence artifacts
- Because killing the malware process can trigger a hardware-watchdog-forced reboot, plan remediation as a full firmware re-flash or factory reset rather than in-place process termination
Longer-term hardening
- Segment IoT and embedded devices onto isolated network zones separate from critical enterprise infrastructure
- Deploy network-based monitoring for anomalous outbound connections, DDoS-pattern traffic, and SOCKS5-proxy-style relay traffic originating from IoT device subnets
- Maintain an active firmware/patch update program for internet-facing embedded devices
- Where feasible, deploy Linux-capable EDR/behavioral monitoring able to flag memfd_create-based fileless execution and process-name masquerading
Weaknesses (CWE) in Tengu Botnet Reboots Compromised Linux Devices When
Timeline of Tengu Botnet Reboots Compromised Linux Devices When
- URLhaus records the first malicious activity at the Tengu C2 host 64.89.163.8, marking the earliest documented infrastructure activity tied to this campaign.
- Most recent URLhaus submission tied to 64.89.163.8, bringing the tracked total to 17 malware URLs (shell-script droppers, Mirai-tagged ELF binaries, and one APK) hosted at the address.
- Nozomi Networks Labs completes technical analysis of the Tengu botnet, documenting its guardian-process respawn, fake-systemd persistence, and hardware-watchdog-driven forced-reboot anti-remediation behavior.
- Nozomi Networks Labs publishes a SHA-256 hash for its analyzed Tengu sample; as of this date no URLhaus-submitted binary at 64.89.163.8 matches the published hash, suggesting active binary rotation or a build distinct from the URLhaus-captured samples.
- All 17 URLhaus-tracked malware URLs previously hosted at 64.89.163.8 are confirmed offline as of publication, though the underlying C2 IP itself is not confirmed decommissioned and may resume serving payloads.
- Cryptika Cybersecurity publishes defensive guidance recommending Telnet exposure reduction, credential hardening, and inspection of persistence locations before returning affected devices to service.
- Cyberpress publishes a deep-dive on Tengu's memfd_create-based fileless execution and its systemd-journald/kworker process masquerading.
- Cyber Security News corroborates the Nozomi findings, emphasizing the SHA-256 self-integrity check and the reboot-on-kill defense mechanism.
- The Hacker News publishes the first public report on Tengu, detailing its six-architecture reach (i386, amd64, MIPS, ARM, PowerPC, m68k), 25 DDoS methods, SOCKS5 proxying, and ChaCha20/Poly1305-like C2 encryption.
Sources cited for Tengu Botnet Reboots Compromised Linux Devices When
- Tengu Botnet Reboots Compromised Linux Devices When Defenders Kill Its Process
- Tengu Runs From Memory and Masquerades as systemd-journald to Hide on Linux Devices
- New Tengu Mirai Botnet Reboots Your IoT Device When You Try to Kill It
- New Tengu Mirai Botnet Reboots Your IoT Device When You Try to Kill It
- URLhaus host record: 64.89.163.8
- Nozomi Networks Labs (primary research source cited by all secondary reporting)
Detection coverage for TL-2026-1745
As of 2026-07-28, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-1745 across Splunk SPL, Microsoft KQL and Sigma, covering 20 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-1745
2 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.