TuxBot ships with 1,496 username/password pairs for Telnet brute-forcing and a cross-compiled bot that targets 17 CPU architectures — but the version recovered is only about 70% functional, with several critical modules broken by errors introduced during LLM-assisted development.
TuxBot v3 Evolution: a modular IoT botnet framework
The recovered archive contains the full framework: a C-based bot agent (cross-compiled for ARM, MIPS, x86_64, PowerPC, RISC‑V and more), a Go-based command-and-control (C2) server with a DDoS-for-hire panel, a custom exploit virtual machine, Docker-based test infrastructure and an automated build system. The build system automates dependency installation, initializes a MariaDB schema, generates configuration and cross-compiles the bot for 17 target architectures. Compiled binaries for multiple architectures and 254 automated DDoS benchmark reports were included in the repository.
LLM-assisted development — faster integration, subtle failures
The developer relied heavily on a large language model (LLM) to generate and port C modules, exploits and C2 code. Multiple source files contain raw LLM chain-of-thought comments and self-narration left verbatim. The LLM produced useful code but also hallucinated implementations (for example, a function that formats output to look like Argon2id while actually using a SHA256 loop), and inserted safety disclaimers that were shipped unchanged: "WARNING: This code is for educational and authorized security research only. Unauthorized use is strictly prohibited and may be illegal." These artifacts, plus a handful of simple mismatches, produced several broken subsystems that a manual code review would have caught.
Command-and-control design and active infrastructure
The Go C2 uses three TCP listeners: the bot protocol on TCP port 1999 (or 31337 in some builds), an SSH admin panel on TCP port 2222 that presents an SSH banner of SSH-2.0-CNC-Control-Server and a machine API on TCP port 9999 (JSON). Fall-back mechanisms include a SHA512-based DGA (20 candidate domains per day using a date-seeded string), peer-to-peer gossip with Ed25519-signed commands, IRC, DNS TXT queries and HTTP polling. Unit 42 linked active infrastructure to the framework: a primary C2 server at 209.182.237[.]133 (Singapore) and a dropper at 185.10.68[.]127 hosted on FlokiNET (Iceland). Those two hosts share a Let's Encrypt certificate for jetross[.]com, tying them to the same operator. The dropper IP had multiple malicious detections on VirusTotal in May 2026 and has historically hosted Kaitori and other DDoS tool payloads.
What actually works — scanners, exploits, and attack methods
The core infection flow is functional: scanning, Telnet credential brute-forcing (1,496 credential pairs), persistence and primary encrypted C2 communication operate as designed. Telnet, SSH, HTTP and Android Debug Bridge (ADB) scanners run correctly. But broader exploitation is limited. Four categories of exploit code exist in the tree; only the RCE scanner (whose dropper is now dead code) and the ADB scanner succeed at runtime. Other exploit capabilities fail for distinct technical reasons: a custom .expl package uses the wrong magic value (Go emits "TUXE" while the C VM expects "EXPL"), an XOR-encrypted string table contains nine entries encrypted with an outdated key (0x54) while the runtime uses 0xB4, and 16 native C exploit functions are compiled but never invoked because exploit_engine_init() has no callers. The attack dispatcher registers 78 vectors but funnels 47 HTTP/application-layer vectors into a TCP SYN handler, so a command like !get target 60 will produce a TCP SYN flood instead of an HTTP GET flood unless the operator modifies the build.
What this means for technologists, incident responders, and operators
- Technologists and security teams: Review IoT edge device logs for telltale indicators — console banner "Infected By Akiru", User-Agent "TuxBot", C2 handshake magic (0xDEADBE01) and the encrypted packet format (0xDEADBEEF + 12-byte nonce + Poly1305 tag) — and block known infrastructure (185.10.68[.]127 and 209.182.237[.]133) where appropriate.
- Incident responders and Palo Alto Networks customers: Unit 42 provided indicators and has shared protections with the Cyber Threat Alliance; Unit 42 also offers incident response contacts listed in the source material for urgent cases.
- Operators and adversaries: The repository is a near-complete development snapshot. Unit 42 repaired several failures with a few targeted LLM prompts — demonstrating that an adversary with access to the same source could produce a more polished and fully functional release with modest effort.
The recovered TuxBot v3 Evolution snapshot is an instructive blend of capability and fragility: a modular, multi-architecture botnet with encrypted C2, a DGA and a DDoS-for-hire panel — and a short list of reproducible bugs that currently limit its exploitation breadth. The facts in the archive and the active infrastructure tied to Kaitori/AISURU tooling mean this is not an academic threat; it is an operational botnet family that could become materially more dangerous if the remaining defects are corrected. Read the full analysis at Palo Alto Networks Unit 42: https://unit42.paloaltonetworks.com/tuxbot-v3-evolution-iot-botnet/
