New KATARU IoT Malware Packs Linux Privilege Escalation Exploits and Mirai-Style DDoS Attacks

KATARU is a newly observed IoT malware strain that can turn poorly secured devices into DDoS attack nodes. The sample was captured after an attacker used repeated Telnet password guesses against a honeypot, then downloaded an ARM payload.

It shows how old entry points still give attackers a foothold. The malware resembles the Mirai botnet family in its ability to flood targets with traffic, but carries wider tools.

It can attempt to gain root access, stay active through reboots, hide command traffic, and run commands supplied by its operators. A compromised device can therefore be harder to remove and more useful in attacks.

Analysts at Nozomi Networks identified the sample in August and named the family KATARU after a ChaCha20 nonce used to decrypt its configuration.

Nozomi Networks said in a report shared with Cyber Security News (CSN) that its code appears assembled from public examples and possibly AI-assisted material, yet its working features remain concerning.

For network owners, the immediate problem is exposure. Devices with Telnet enabled, weak credentials, old firmware give operators a path in. As Mirai botnets and proxy abuse have shown, IoT infections can scale quickly when basic device security is neglected.

New KATARU IoT Malware

KATARU begins with Telnet credential brute forcing, then uses BusyBox commands to retrieve and execute a payload. Once running, it checks whether /etc/passwd is writable and tries to remove the root password placeholder.

It then attempts public code for CVE-2026-46300, Fragnesia; CVE-2026-43284, DirtyFrag; and CVE-2026-31431, Copy Fail. The code also attempts a cgroup v1 release_agent escape that can relaunch the malware with higher privileges.

In the analyzed ARM build, however, embedded exploit shellcode targeted x86 systems. It suggests code was copied without full testing, but remains dangerous.

Root access would give the malware greater control and make cleanup harder. KATARU tries to persist through systemd services, cron tasks, rc scripts, OpenWrt hooks, package-management hooks, and Android boot locations.

It may mark copies immutable or append-only when permissions allow, requiring close incident-response review. Its persistence logic spans Linux, routers, desktops, and Android.

Administrators should patch supported firmware and kernels, remove unnecessary Telnet access, and replace default or weak passwords. Actively exploited Linux kernel flaws show why escalation bugs demand attention after a breach.

Encrypted C2 enables DDoS attacks

KATARU does not use the plain-text control traffic associated with older Mirai variants. Each device creates an X25519 key pair and uses a shared secret to protect commands with ChaCha20-Poly1305 encryption.

It hinders casual inspection and server impersonation, although its pinned public key matches an RFC test value. The malware supports TCP, UDP, ICMP, HTTP, QUIC, and DNS floods, including attacks aimed at Minecraft, FiveM, OpenVPN, and WireGuard.

It can brute-force SSH, download additional binaries through wget, execute shell commands, stop active floods, and remove its files. SSH attacks are command-server tasks, not autonomous spreading.

A decoy component further muddies analysis with fake web requests and IRC-style chatter. It includes strings resembling Mirai or Katana labels although code does not use them.

Teams should validate telemetry before blocking infrastructure, as decoys mix documentation addresses with legitimate services. Defenders should isolate IoT and operational technology devices, allowing only required management and business traffic.

Monitor unfamiliar outbound encrypted connections, packet spikes, Telnet or SSH attempts, and startup-file changes. Network teams should also retain logs long enough to compare a device’s current behavior with its normal traffic patterns.

Coverage of TuxBot LLM-generated botnet code also shows why basic hardening matters. These controls cannot ensure every device is safe where vendors no longer issue updates.

Where updates cannot be installed, organizations should consider retiring devices or placing them behind tightly controlled access paths, because unsupported equipment leaves known weaknesses exposed for years on the internet.

They reduce the chance that one device becomes a durable foothold or joins a flood. Inventory connected equipment, restrict remote administration, and investigate unusual outbound activity before it becomes a wider service disruption.

Indicators of compromise (IoCs):-

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.