New Linux Bot Hides as Kernel Process and Launches DDoS Attacks

A new Linux bot called Tengu is built to stay hidden and turn compromised systems into tools for disruption. The 32-bit malware poses as a routine kernel worker, persists across several Linux setups, and can generate traffic floods against selected targets.

Its broad feature set puts servers, embedded systems, and IoT-adjacent devices at risk. Unlike a simple denial-of-service tool, Tengu combines raw UDP and standard datagram floods with SSH handshake activity, web-request generation, and proxy features.

This gives operators several ways to consume bandwidth or application resources, while infected hosts can also be used to relay traffic. The analysis does not establish how victims are initially compromised, so its delivery route remains unconfirmed.

Reverser.space said in a report shared with Cyber Security News (CSN) that its sample was a stripped, statically linked 32-bit Linux ELF designed for servers, embedded systems, and IoT-adjacent environments.

Researchers found a hidden control endpoint and several persistence options, but cautioned that the evidence supports a Mirai-style label rather than proving direct code lineage.

This matters because an infected device may look normal during a quick check and then become part of a larger attack network on command. No victim count, attack volume, or confirmed campaign impact was provided in the published analysis.

Still, the combination of concealment, durable startup methods, and multiple flooding routines raises the risk of difficult-to-remove Linux and IoT infections.

Kernel Process Masquerading

To avoid drawing attention, Tengu replaces its visible process name with a randomized kernel-worker-style label, making it resemble a Linux kernel worker in ordinary process listings.

It also writes a protective value to the operating system’s out-of-memory control, reducing the chance that memory pressure will terminate the task. It then silences normal standard streams and continues quietly in the background.

The bot retrieves its own executable path even if the original file has been deleted, then attempts to survive reboots through systemd services, SysV and OpenWrt startup scripts, scheduled tasks, and local startup files.

That cross-platform approach is notable beside a Tengu Mirai botnet report that described another Tengu operation targeting internet-facing embedded Linux equipment.

The implant’s design reaches beyond persistence. It can gather basic host and network details, build authenticated HTTP CONNECT and SOCKS5 proxy functions, and issue HTTP GET, POST, and HEAD requests with randomized forwarding headers.

Those web flood features resemble tactics discussed in coverage of an LLM generated IoT botnet, although the Reverser.space analysis does not link the two threats.

DDoS Attack Capabilities

The DDoS component has two UDP modes. One creates raw IPv4 packets with attacker-controlled header fields and checksums, which can support spoofing where the environment allows it.

The other sends traffic through ordinary datagram sockets, offering a fallback when raw sockets are unavailable. The malware also performs SSH banner and key-exchange handshakes, but the review found no evidence of an authentication exploit or credential attack in that function.

When directed at a target, these modules can exhaust network capacity or make web services harder to reach. The mix of UDP, application-layer HTTP, and SSH-related activity reinforces why defenders should look for behavior rather than rely on one signature.

For context, an Evooo1Bot Linux botnet investigation also showed how Linux edge-device malware can combine flooding with proxy and access functions.

Teams should inspect a suspicious kernel-worker-style process against its executable and parent process, watch for unexpected changes to out-of-memory settings, and review new service units, startup scripts, and reboot-triggered tasks.

Network monitoring should flag connections to the observed endpoint and bursts of raw UDP, unusual SSH handshakes, or HTTP requests carrying randomized forwarding headers.

This Mirai botnet evolution report provides further background on the wider danger posed by exposed IoT systems. Administrators should isolate suspected hosts, preserve executable and network evidence, rotate exposed remote-access credentials, and remove unapproved persistence only after confirming the process is malicious.

Patching internet-facing devices, disabling unnecessary remote administration, and watching for repeated access attempts can reduce the opportunities botnet operators use to build new nodes over time across the internet.

Indicators of compromise (IoCs):-

Type	Indicator	Description
File name	tengu_sample	Name assigned to the analyzed Linux ELF sample
IPv4 address	64[.]89[.]163[.]8	Decoded command-and-control endpoint address
TCP port	9931	Port paired with the recovered command-and-control address
Process name	[kworker/%d:%d]	Kernel-worker-style process-name format used for masquerading
Init path	/etc/init.d/tengu	Tengu-linked startup artifact
PID file	/tmp/.proxy.pid	File associated with the malware’s proxy capability
Systemd description	System Helper Service	Description used in the created systemd service template
MD5	3a1069cd649e22b87cbccf0c36b69f4b	MD5 hash of the analyzed sample
SHA-1	097522a52986982b9eefc29f95efdd9d3b6032e7	SHA-1 hash of the analyzed sample
SHA-256	897226af37990fa60f25fea00b0509faa0e78d8bee10875c23b9b6ab0b8faed9	SHA-256 hash of the analyzed sample

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Keep your SOC up to date on active malware & phishing within 24h of their emergence. Try ANYRUN to prevent incidents with early detection.