"While the AI complied with their request to generate botnet code, it included a safety disclaimer that the developer failed to remove before shipping," Palo Alto Networks Unit 42 said.
TuxBot v3 Evolution's architecture and components
Researchers at Palo Alto Networks Unit 42 describe TuxBot v3 Evolution as a multi-component Internet-of-Things (IoT) botnet framework that combines traditional botnet elements with modern tooling. The framework includes a C-based bot agent that cross-compiles for 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 (VM); Docker-based test infrastructure; and an automated build system. Unit 42 notes the framework was built as "a professional-grade C2 framework platform with a multi-user admin panel, automated deployment, and modular attack capabilities," according to researchers Chris Navarrete, Asher Davila, and Doel Santos.
LLM involvement and embedded chain-of-thought
Unit 42 found direct artifacts of large language model (LLM) use inside the codebase. Multiple files contain raw LLM chain-of-thought reasoning left verbatim in comments, the researchers reported. Those comments include the LLM’s internal reasoning, self-interruptions, decisions, and references to "the user" (the developer who prompted the model). In at least one instance the LLM inserted a safety disclaimer that the developer did not remove before shipping. Unit 42 concluded the LLM "clearly aided in constructing the botnet," but also observed that several functions in the analyzed samples failed to work correctly — errors a manual code review would likely have resolved.
Operational behavior: scanning, persistence, and C2 channels
The recovered sample follows a defined initialization sequence that loads C2 addresses from a multi-tiered architecture (one primary channel and five alternate mechanisms), sets up anti-debugging and anti-VM checks, hides its process name, installs persistence, and launches sub-modules. Those sub-modules mount DDoS attacks, terminate competing processes, establish C2 channels over encrypted TCP, IRC, HTTP, DNS, and a peer-to-peer (P2P) gossip protocol with Ed25519-signed commands; additionally the framework uses a SHA512 domain generation algorithm (DGA) and falls back to DNS TXT queries and HTTP polling.
The bot agent is designed to brute-force Telnet access with a credential list of 1,496 username-password pairs and to incorporate exploit code against more than 30 IoT device families using known vulnerabilities. Dedicated scanners run for Telnet, SSH, HTTP, and Android Debug Bridge (ADB); the HTTP scanner can manage up to 128 concurrent connections. Persistence mechanisms observed include systemd services, cron entries, and a watchdog keepalive process. The Go-based C2 exposes three TCP ports: TCP 1999 (or 31337) for encrypted command dispatch, TCP 2222 for an interactive SSH shell for operators, and TCP 9999 for a JSON interface intended for programmatic access.
Links to Mirai, AISURU, Wuhan, Kaitori v3.9, and the Keksec ecosystem
Unit 42 traced portions of TuxBot’s lineage to three known botnets — Mirai, AISURU, and Wuhan — and found partial ports from the open-source MHDDoS Python DDoS toolkit. The report also identifies shared infrastructure with Kaitori v3.9 and AISURU tooling, which the researchers say places the TuxBot operator within the "Keksec ecosystem." Unit 42 characterized TuxBot as another variant in that portfolio: it aims to go beyond Mirai-like forks by adding encrypted C2, a DGA, and a modular exploit system, even though Unit 42 observed the exploit system did not function in the recovered version.
What this means for technologists, policymakers, and device owners
- Technologists and security teams: Unit 42’s findings point to multiple observable signals — SHA512 DGA activity, Ed25519-signed P2P commands, unusual TCP ports (1999/31337, 2222, 9999), systemd/cron/watchdog persistence artifacts, and the credential brute-force patterns tied to 1,496 pairs — that defenders can hunt for in logs and network telemetry.
- Policymakers and regulators: The presence of a Go-based DDoS-for-hire panel and shared infrastructure linking TuxBot to other known toolsets demonstrates how modular criminal ecosystems can reuse and recombine components, raising enforcement and attribution challenges highlighted by Unit 42’s linkage to the Keksec ecosystem.
- Device owners and operators: The bot’s focus on Telnet brute force and ADB/SSH/HTTP scanning underlines the continuing exposure risk of poorly secured IoT devices. Unit 42’s discovery that at least one sample was uploaded to VirusTotal on January 20, 2026 — and evidence suggesting work began roughly a year prior when the author cloned MHDDoS — suggests this framework has been developing and may not be a one-off experiment.
Unit 42’s assessment frames TuxBot v3 Evolution as a work-in-progress that nevertheless contains core working functions and signature artifacts of LLM-assisted development. The presence of raw chain-of-thought comments and a safety disclaimer left in shipped code yields an unusual forensic breadcrumb trail; at the same time, the framework’s modularity, multiple C2 channels, and ties to existing botnet lineages make clear that more polished iterations could pose materially greater risk. Whether such iterations already exist in the wild is an open question Unit 42 flags as plausible.
