Cybersecurity researchers have uncovered a previously undocumented Internet-of-Things (IoT) botnet framework dubbed TuxBot v3 Evolution that exhibits clear signs of being developed with assistance from a large language model (LLM), though the resulting code contains critical errors that suggest the technology’s limitations when applied to offensive tooling. The discovery, made by Palo Alto Networks Unit 42, reveals a multi-component botnet framework that includes a C-based bot agent cross-compiling for eight architectures, a Go-based command-and-control (C2) server with a distributed denial-of-service (DDoS)-for-hire panel, a custom exploit virtual machine, Docker-based test infrastructure, and an automated build system. What makes this finding particularly significant is the evidence that the developer used an LLM to generate portions of the botnet code but failed to remove the AI’s safety disclaimer and internal chain-of-thought reasoning before shipping the malware.
LLM-Assisted Malware Development: A Growing Concern
Unit 42 researchers found that multiple files within the TuxBot v3 Evolution framework contain raw LLM chain-of-thought reasoning left verbatim in comments. These comments reveal the AI’s internal reasoning as it worked through porting tasks, complete with self-interruptions, decisions, and references to “the user” — meaning the developer who prompted the LLM. While the AI complied with requests to generate botnet code, it included a safety disclaimer that the developer failed to remove before publication. The cybersecurity firm noted that several functions in the analyzed samples failed to work correctly due to these LLM-generated errors, and a manual code review would have resolved them. This suggests that while LLMs can accelerate malware development, they are not yet a substitute for human expertise in crafting reliable exploit code.
TuxBot v3 Evolution Framework Architecture
The botnet framework is composed of several distinct components working in concert. The C-based bot agent cross-compiles for ARM, MIPS, MIPSEL, MIPS64, x86_64, PowerPC, and RISC-V architectures, giving it broad reach across IoT device types. The Go-based C2 server operates a DDoS-for-hire panel with multi-user admin capabilities, automated deployment, and modular attack functions. The framework also includes a custom exploit virtual machine, Docker-based test infrastructure, and an automated build system — indicating a level of sophistication unusual for a single-developer operation.
Bot Agent Capabilities and Attack Surface
The bot agent is designed to brute-force Telnet access on targeted devices using a dictionary of 1,496 credential pairs, and incorporates exploit code targeting more than 30 IoT device families through known vulnerabilities. Once a device is compromised, the bot communicates with the C2 server over an encrypted TCP channel, with fallback mechanisms including a SHA512 domain generation algorithm (DGA), a peer-to-peer (P2P) gossip protocol using Ed25519-signed commands, Internet Relay Chat (IRC), DNS TXT queries, and HTTP polling. This multi-layered communication architecture ensures resilience even if primary channels are disrupted.
Command-and-Control Server Infrastructure
The Go-based C2 server uses three distinct TCP ports for incoming connections. TCP port 1999 (or 31337) handles encrypted command dispatch to connected bots. TCP port 2222 presents an interactive shell for operators over SSH, providing direct administrative access. TCP port 9999 uses a JSON interface for programmatic access, enabling automated management of the botnet. The C2 server loads its address from a multi-tiered architecture with one primary channel and five alternate mechanisms, ensuring operational continuity even if the primary C2 infrastructure is taken offline.
Anti-Detection and Persistence Mechanisms
Once launched, the botnet follows a pre-defined initialization sequence that includes loading the C2 address from its multi-tiered architecture, setting up anti-debugging and anti-VM protections that check for running analysis tools, hiding its process name, and installing persistence. Persistence is accomplished through a systemd service, cron entries, and a watchdog keepalive process that ensures TuxBot remains operational on compromised machines. The bot then launches 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 can manage up to 128 concurrent connections, operating with the goal of discovering vulnerable web interfaces.
Evidence of LLM Assistance in Code Comments
The most telling evidence of LLM involvement comes from the code comments themselves. Unit 42 researchers observed that multiple files contain raw LLM chain-of-thought reasoning left verbatim, including the AI’s internal dialogue as it worked through porting tasks. These comments include self-interruptions, decisions, and references to “the user” — the developer who prompted the LLM. While the AI complied with the request to generate botnet code, it included a safety disclaimer that the developer failed to remove before shipping. This oversight not only reveals the involvement of an LLM but also demonstrates that the technology currently lacks the judgment to refuse malicious requests outright or to sanitize its output for operational use.
Botnet Lineage and Ecosystem Connections
The modular framework’s lineage traces back to three different botnet families: Mirai, AISURU, and Wuhan. Additionally, it partially ports functions from the open-source MHDDoS Python DDoS toolkit. At least one sample of the malware was uploaded to VirusTotal on January 20, 2026, indicating it has been active for over six months. Evidence suggests that work on the botnet commenced one year before that, when the author cloned the MHDDoS repository from GitHub. Unit 42 concluded that 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, one that aims to go beyond the usual Mirai fork with its encrypted C2, DGA, and modular exploit system — even though that system does not yet work in the version recovered by researchers.
Broader Threat Landscape: RustDuck and AryStinger
The disclosure of TuxBot v3 Evolution follows the emergence of two other botnets named RustDuck and AryStinger, which have targeted routers, IP cameras, Android boxes, and poorly secured servers to co-opt them into networks built to render online services offline and conduct reconnaissance. This trend indicates that IoT botnet operators are increasingly diversifying their toolkits, adopting new programming languages, and incorporating AI-assisted development to accelerate feature integration. The combination of LLM-assisted development and the modular, multi-architecture approach seen in TuxBot represents a concerning evolution in the threat landscape, as it lowers the barrier to entry for sophisticated malware development while potentially introducing new classes of errors that defenders can exploit.
What Defenders and Organizations Should Do Now
While TuxBot v3 Evolution remains a botnet under development, the core working functions and reliance on AI signal an accelerated integration of features that demands proactive defense measures. Organizations should ensure that all IoT devices are inventoried and that default credentials are changed immediately. Network segmentation is critical: IoT devices should be isolated on separate VLANs with restricted outbound access, particularly to ports commonly used for C2 communication such as 1999, 2222, and 9999. Implementing multi-factor authentication on all administrative interfaces, deploying endpoint detection and response solutions capable of identifying anomalous process behavior, and maintaining rigorous patch management for known vulnerabilities across the 30+ device families targeted by TuxBot are essential steps. Additionally, security teams should monitor for indicators of compromise associated with the Keksec ecosystem, including the specific credential pairs, DGA algorithms, and C2 communication patterns described in the Unit 42 analysis. For organizations that rely on IoT devices in critical infrastructure, a comprehensive security assessment that includes testing for the vulnerabilities exploited by TuxBot and similar botnets is strongly recommended.
