Palo Alto Networks Unit 42 published the first comprehensive technical analysis of TuxBot v3 — a modular IoT botnet framework that cross-compiles attack binaries for 17 CPU architectures and targets more than 30 IoT device families. The botnet’s author used a large language model to generate portions of the Go-based framework code and shipped the AI output without removing the model’s safety disclaimers, leaving them embedded in 61 production source files alongside bugs the LLM introduced. Unit 42 links TuxBot’s infrastructure to the Keksec threat ecosystem and to Arvan Cloud CDN, an Iranian hosting provider.
TuxBot v3 Architecture: 17 CPU Architectures and a DDoS-for-Hire Module
TuxBot v3 is built in Go and designed for wide hardware coverage. Its automated build infrastructure compiles attack binaries for 17 CPU architectures — including ARM, MIPS, PowerPC, RISC-V, and x86_64, among others — allowing a single framework to target cameras, routers, DVRs, and other IoT devices regardless of the hardware platform they run on. Unit 42’s analysis identified the framework targeting over 30 IoT device families through telnet credential brute-forcing using 1,496 credential pairs.
The framework’s capability set extends beyond simple infection. The core components include a Go-based command-and-control server with a DDoS-for-hire module, a custom exploit virtual machine for modular vulnerability exploitation, and the automated cross-architecture binary compilation infrastructure. The DDoS-for-hire capability indicates the operators run TuxBot as a financially motivated service — renting out the botnet’s attack capacity to paying customers to flood target services with multiple flood mechanism types — as well as potentially for direct use against their own targets.
TuxBot v3’s development began in January 2025 with a cloned version of MHDDoS, an existing DDoS attack toolkit. The first submission of a TuxBot sample to VirusTotal occurred on January 20, 2026. Six new samples appeared in April 2026, and Unit 42 identified the C2 infrastructure as active since at least March 2026. The July 16 publication is the first comprehensive public documentation of the full framework’s architecture, capabilities, and attribution indicators.
How AI Code Generation Left Safety Disclaimers in 61 Production Source Files
The TuxBot author’s use of an LLM to generate Go code produced an unusual forensic artifact: the AI model’s safety disclaimers were left in place in 61 of the production codebase’s source files. LLM safety systems insert warnings or disclaimers when generating content that falls into categories the model is trained to flag — including code for attack tools or dual-use security software. Rather than removing these embedded text strings before deploying the production framework, the TuxBot author shipped them as part of the live codebase.
Bugs introduced by the LLM during code generation also remain in the production code. Unit 42’s analysis characterizes this as evidence that the attacker used AI code generation as a rapid development tool — generating functional code at speed — without carefully reviewing or auditing the LLM’s output before deployment.
This operational pattern carries implications beyond TuxBot. It demonstrates that financially motivated threat actors are integrating LLM-assisted development into their tooling workflows and accepting the trade-off of unreviewed AI output in exchange for faster production. The safety disclaimers embedded in the source code give defenders an unconventional indicator: the presence of LLM-style safety text in malware source code or decompiled output may signal AI-assisted development.
Keksec Ecosystem Connections and Arvan Cloud Infrastructure Attribution
Unit 42 attributes TuxBot to the Keksec threat ecosystem based on infrastructure analysis. Keksec is a financially motivated network of operators associated with multiple IoT botnets and DDoS-for-hire services. The attribution evidence in the TuxBot case includes connections to Arvan Cloud CDN — an Iranian cloud hosting and content delivery provider — a developer workstation hostname pointing to an Iranian-hosted machine, and shared dropper infrastructure with other tooling previously linked to Keksec operations.
The Arvan Cloud connection adds an Iran-adjacent dimension to what has historically been characterized as a primarily financially motivated actor group. The infrastructure overlap with other Keksec-linked tooling indicates TuxBot v3 is not an isolated development but part of the broader Keksec capability portfolio.
From MHDDoS Clone to 17-Architecture Framework: TuxBot’s Development Trajectory
The development arc from cloned MHDDoS toolkit to a cross-architecture framework with a custom exploit virtual machine and DDoS-for-hire infrastructure represents a substantial capability expansion driven partly by AI-assisted code generation. The cloning of an existing open-source attack tool as a starting point is a common approach in financially motivated botnet development; the application of LLM-generated code to extend and customize that starting point represents the newer component of the workflow.
Unit 42’s disclosure does not include a total infection count for TuxBot v3, focusing instead on the framework architecture, capability set, and attribution indicators. The targeting of over 30 IoT device families with 1,496 credential pairs for telnet brute-forcing positions TuxBot for broad initial access across the IoT device landscape — cameras and DVRs are typically numerous in any given corporate or home network and frequently run with default credentials that have not been changed since deployment.
The combination of wide hardware coverage, a built-in DDoS-for-hire commercial module, AI-accelerated development, and Iranian infrastructure connections makes TuxBot v3 a notable addition to the documented IoT botnet ecosystem.
