Do Son 
TuxBot interactive setup wizard screens | Image: Unit 42
At a glance
| Malware family | TuxBot v3 Evolution (also tracked as Akiru) |
| Threat actor | Suspected link to the Keksec ecosystem; no confirmed named actor |
| Target / victims | IoT devices across 30+ device families; DDoS-for-hire customers |
| Delivery vector | Telnet brute-force with 1,496 credential pairs, plus SSH, HTTP and ADB scanners |
| Key capabilities | Encrypted TCP C2, SHA-512 DGA, P2P gossip, 78 registered DDoS vectors, 17-architecture builds |
| Source | Palo Alto Networks Unit 42 |
TL;DR
Unit 42 found a new IoT botnet framework called TuxBot v3 Evolution. The author built much of it with a large language model, and the AI left bugs that keep large parts broken. Even so, the core infection and DDoS features work, so a fixed version is a likely threat.
What Unit 42 found
Unit 42 recovered the full source code of TuxBot v3 Evolution from internal telemetry. The archive held 61 C++ source files, 58 headers, and 254 DDoS benchmark reports. Researchers also found a compiled bot binary hidden with a dot-prefixed filename. Someone uploaded that sample to VirusTotal on January 20, 2026.
The framework targets IoT devices at scale. Its bot agent brute-forces Telnet with 1,496 credential pairs. It also carries exploit code aimed at more than 30 IoT device families. For distribution, the build system cross-compiles the bot for 17 architectures, from ARM and MIPS to RISC-V.
How the infection chain works
The infection flow stays simple at the concept level. First, the bot scans random public addresses for open Telnet, SSH, HTTP, and ADB services. Next, it tries default and vendor credentials until one works. After access, it installs persistence and hides its process name. Then it launches attack, scanning, and C2 subsystems in a cascade.
Persistence runs deep. TuxBot uses seven methods, including a systemd service, cron jobs, and shell profile injection. Meanwhile, stealth code mimics common daemon names and relocates the binary across 21 directories.
Command and control, and DDoS behavior
The bot talks to its server over an encrypted TCP channel. That primary channel pairs X25519 with ChaCha20-Poly1305. For resilience, the malware defines five fallback channels. These include a SHA-512 DGA, P2P gossip with signed commands, IRC, DNS TXT queries, and HTTP polling. However, only the DGA, P2P, and DNS paths work, because a bug broke IRC and HTTP polling.
The attack engine registers 78 DDoS vectors. In practice, those vectors map to only six working handlers. So an operator who asks for an HTTP GET flood gets a TCP SYN flood instead. The panel also runs a DDoS-for-hire interface over SSH. Operators log in, see the bot count, and issue attack commands.
Data theft is not the goal here. TuxBot exists to build a DDoS platform, not to exfiltrate files.
The LLM fingerprints
This case stands out for one reason. The developer used an LLM to write much of the code. The AI then left its own reasoning inside the source files. Comments show self-interruptions, first-person notes, and references to “the user.”
The AI also caused real bugs. For example, it hallucinated an Argon2id password hash but shipped a weaker routine. A key mismatch left nine string-table entries garbled, which broke the IRC and HTTP channels. As Unit 42 put it, the framework is “approximately 70% functional.”
One detail is almost funny. Every bot source file kept a safety disclaimer that the AI added. Unit 42 wrote that the developer “shipped it without removing it.”
Attribution: suspected, not confirmed
Unit 42 did not name a confirmed actor. Instead, it points to suspected links. A leaked hostname in the Git log suggests an Iran-hosted workstation. Shared infrastructure ties the operator to the Keksec ecosystem, home to Kaitori and AISURU tooling. For the full technical breakdown, read the Unit 42 analysis of TuxBot v3 Evolution.
Defense and detection guidance
You can cut most of this risk with basic IoT hygiene. The steps below map directly to how the bot spreads.
- Change default Telnet, SSH, and web credentials on every device.
- Disable Telnet and keep management ports off the public internet.
- Watch for outbound traffic on unusual TCP ports and repeated DGA-style DNS lookups.
- Patch known RCE flaws on cameras, routers, and DVRs quickly.
- Flag processes that mimic system daemons yet run from hidden paths.
Why a broken botnet still matters
TuxBot v3 Evolution looks half-finished today. Yet the operator holds the source code and keeps shipping builds. Unit 42 counted six new samples in April 2026. Because the bugs are small and reproducible, a working version is a likely threat, not a distant one.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
