TuxBot v3 Evolution Shows Signs of LLM-Assisted IoT Botnet Development

Researchers at Palo Alto Networks Unit 42 have disclosed details of TuxBot v3 Evolution, a developing Internet-of-Things (IoT) botnet framework that shows signs of being built with assistance from a large language model (LLM). Despite the AI's contribution, the developer failed to remove a safety disclaimer included in the code, leading to functional errors that required manual correction. The framework’s development began approximately one year prior to the discovery of the malware.

At its core, TuxBot v3 Evolution consists of several components: a C-based bot agent that cross-compiles for various architectures (e.g., ARM, MIPS, MIPSEL, MIPS64, x86_64, PowerPC, and RISC-V), a Go-based command-and-control (C2) server with a DDoS-for-hire panel, a custom exploit virtual machine, and an automated build system. The bot agent is designed to brute-force Telnet access on targeted devices, utilizing 1,496 credential pairs, and incorporates exploit code targeting over 30 IoT device families using known vulnerabilities. It communicates with the C2 server over an encrypted TCP channel, utilizing a SHA512 domain generation algorithm (DGA), peer-to-peer (P2P) gossip protocol with Ed25519-signed commands, Internet Relay Chat (IRC), DNS TXT queries, and HTTP polling as a fallback mechanism.

The Go-based C2 server component uses three different TCP ports for incoming connections: TCP port 1999 (or 31337), which handles encrypted command dispatch to connected bots; TCP port 2222, which provides an interactive shell for operators over SSH; and TCP port 9999, which uses a JSON interface for programmatic access. Once launched, the botnet follows a pre-defined initialization sequence to perform a series of actions, including loading the C2 address from a multi-tiered architecture with one primary channel and five alternate mechanisms, setting up anti-debugging and anti-VM protections, hiding its process name, installing persistence through systemd service, cron entries, and a watchdog keepalive process, and launching various sub-modules to mount DDoS attacks, terminate competing processes, establish C2 channels over IRC, HTTP, DNS, and P2P, run scanners for Telnet, SSH, HTTP, and Android Debug Bridge (ADB), spawn a SOCKS5 proxy, and execute a cryptocurrency mining placeholder. The dedicated HTTP scanner, in particular, can manage up to 128 concurrent connections at any given point in time, operating with the goal of discovering vulnerable web interfaces. Persistence is accomplished by means of a systemd service, cron entries, and a watchdog keepalive process to ensure TuxBot remains operational on the compromised machine.

Multiple files contain raw LLM chain-of-thought reasoning left verbatim in comments. These comments are the LLM’s internal reasoning as it worked through porting tasks, including self-interruptions, decisions, and references to ‘the user’ (meaning the developer who prompted the LLM). The framework’s lineage has been traced back to three different botnets, like Mirai, AISURU, and Wuhan, in addition to partially porting some of its functions from the open-source MHDDoS Python DDoS toolkit. Shared infrastructure with Kaitori v3.9 and AISURU tooling places the TuxBot operator within the Keksec ecosystem, a group known for running multiple IoT botnet variants in parallel. TuxBot appears to be another variant in that portfolio, aiming to go beyond the usual Mirai fork with its encrypted C2, its DGA, and a modular exploit system, even though that system does not work yet in the version we recovered.