LLM-Assisted TuxBot Botnet Targets IoT Devices Across 17 Processor Architectures

TuxBot v3 Evolution, a modular IoT botnet framework capable of infecting devices running architectures ranging from ARM and MIPS to x86_64, PowerPC and RISC-V.

The platform appears designed for mass compromise, persistence and distributed denial-of-service operations, with a C-based bot agent and a Go-based command-and-control server.

Palo Alto Networks Unit 42 said it recovered the framework’s complete source code, compiled binaries, Docker testing environments and 254 automated DDoS benchmark reports from internal telemetry.

The bot displays the console message “Infected By Akiru” after compromise, a likely nod to the broader IoT botnet ecosystem from which it borrows code and operational concepts.

Its Telnet component includes 1,496 credential pairs, including common default and vendor-specific logins, enabling brute-force attacks against poorly secured routers, cameras, DVRs and other embedded systems.

The malware also contains exploit code covering more than 303030 IoT device families, although much of that functionality was broken in the analyzed build.

The botnet’s primary C2 channel uses encrypted TCP communications, based on X25519 key exchange and ChaCha20-Poly1305 encryption.

It can also fall back to a SHA-512-based domain generation algorithm, DNS TXT lookups, peer-to-peer gossip using Ed25519-signed commands, IRC and HTTP polling.

Unit 42 found that the DNS, DGA and P2P channels functioned, while IRC and HTTP mechanisms failed due to a string-encryption bug.

A notable element of the case is the developer’s apparent reliance on an LLM to generate modules, port exploits, and develop C2 components.

Unit42 Researchers said that, TuxBot’s agent supports 17 target architectures and uses Telnet, SSH, HTTP and Android Debug Bridge scanners to locate exposed devices.

LLM-Assisted TuxBot Botnet

Researchers found raw model-style reasoning comments embedded in source files, including self-corrections and references to “the user.”

Every C source file also retained an AI-generated disclaimer warning that the code was only for authorized research, suggesting the operator shipped LLM-produced content without review.

That lack of validation introduced major flaws. TuxBot’s custom exploit virtual machine rejected its exploit package because of an incompatible file magic value, while multiple payloads were rendered unusable by an XOR key mismatch.

Several HTTP-layer DDoS methods were also misrouted to a TCP SYN flood handler. Despite these errors, Unit 42 assessed the recovered version as roughly 70% functional, with core scanning, brute-forcing, persistence, primary C2 communications and DDoS execution operating correctly.

The framework includes a Go-based administrative panel accessible over SSH on TCP port 2222, where operators can view bot counts and launch attacks with commands such as !method target duration.

A MariaDB backend tracks user accounts, quotas, permissions and attack logs, indicating that TuxBot was built to support a multi-user DDoS-for-hire operation.

Researchers linked an embedded dropper address, 185.10.68[.]127, to infrastructure associated with Keksec/Kaitori-related Tsunami, Mirai and Gafgyt ecosystems.

A live C2 server was observed at 209.182.237[.]133:2222, exposing the SSH banner SSH-2.0-CNC-Control-Server. The first known development sample appeared on VirusTotal on January 20, 2026, while additional multi-architecture production binaries emerged in telemetry in April.

The central risk is not the botnet’s current defects, but how easily they can be repaired. Unit 42 noted that several issues could be corrected through limited code changes or even targeted LLM prompts.

Organizations should eliminate default credentials, disable unnecessary Telnet and ADB services, patch exposed IoT devices, and monitor for suspicious outbound connections over TCP ports 1999, 2222, 9999 and 1333.

𝗔𝗜 𝗦𝗢𝗖 𝘃𝘀 𝗠𝗗𝗥 𝘃𝘀 𝗠𝗦𝗦𝗣 Which is Best in 2026? Compare costs, Automation, and response: Download Free Guide