New TuxBot v3 IoT Botnet Uses LLM-Generated Code to Hijack Devices and Launch DDoS Attacks

A newly identified IoT botnet framework, TuxBot v3 Evolution, is targeting internet-connected devices and turning compromised systems into tools for distributed denial-of-service attacks.

The malware can run across a wide range of device architectures, creating a broad risk for routers, cameras, and other exposed Linux-based equipment.

TuxBot uses several paths to gain access, including Telnet password guessing, SSH scanning, HTTP-based probing, Android Debug Bridge scanning, and attempts to exploit vulnerable devices.

Its Telnet module alone carries 1,496 username and password combinations, many of them default or vendor-specific credentials that remain common on poorly secured devices.

Analysts at Unit 42 said in a report shared with Cyber Security News (CSN) that they identified the malware as a previously undocumented, modular botnet framework with an encrypted command channel, a custom exploit system, and infrastructure intended to support DDoS-for-hire operations.

The discovery is notable because the developers appear to have used a large language model to build substantial parts of the framework.

The recovered source code includes unremoved AI safety comments and internal-style reasoning, showing that generated code was incorporated with limited manual review.

New TuxBot v3 IoT Botnet Uses LLM-Generated Code

The framework combines a C-based bot client with a Go-based command-and-control server that can build payloads for at least 17 processor architectures.

This allows operators to prepare malware for devices running ARM, MIPS, PowerPC, RISC-V, x86-64, and other platforms from a single development environment.

Once installed, the bot attempts to remain on a device through a disguised system service, cron jobs, shell-profile changes, hidden backup copies, watchdog activity, and repeated relocation of its binary.

It can also disguise its process name and search for rival malware, removing competing botnet infections from the same device.

The authors borrowed code and design elements from several known botnet families and the open-source MHDDoS toolkit.

That reuse follows a familiar pattern in the IoT threat landscape, where Mirai-derived DDoS botnets continue to give attackers a quick foundation for building new attack tools. However, the use of AI-generated code also left serious flaws in the recovered version.

Researchers found an encryption-key mismatch that broke multiple functions, a custom exploit virtual machine that could not load its own packages, and an authentication component labelled as Argon2id that did not actually implement Argon2id password hashing.

These defects do not remove the danger. TuxBot’s core functions, including credential attacks, encrypted primary communications, persistence, scanning, and UDP, TCP, and DNS flooding, were operational in the analyzed samples.

Researchers also warned that the operator could correct the defects quickly because the complete source code is already available to them.

DDoS Infrastructure and Defense

TuxBot connects to its main server using encrypted TCP communications and can fall back on domain-generation and peer-to-peer mechanisms if the primary server becomes unavailable.

The operator’s server included an SSH-accessible panel where users could view connected bots and issue attack commands, pointing to a service designed for managed DDoS activity.

The malware’s developers tested attack performance through a Docker-based environment and generated 254 automated benchmark reports before samples began appearing publicly.

While the framework advertises dozens of attack options, many web-focused methods in the analyzed build were incorrectly routed to simpler TCP SYN floods, leaving some advertised capabilities inactive.

Still, defenders should treat the active features as a practical threat. Organizations should remove default passwords, restrict Telnet and remote administration access, apply firmware updates, and segment IoT devices from critical systems.

Monitoring repeated authentication attempts and unusual outbound traffic can also expose devices being recruited into a botnet, as seen in other IoT botnet attacks.

The researchers linked TuxBot infrastructure to broader Keksec, Kaitori, and AISURU-related activity through shared hosting and certificate artifacts. The connection does not mean the tool is identical to those families, but it shows how operators can reuse infrastructure while maintaining separate malware codebases and campaigns.

TuxBot also illustrates a wider shift in criminal development practices. AI assistance can speed up code writing and porting across platforms, even when the output is unreliable, echoing concerns raised by earlier reporting on LLM-enabled malware.

Indicators of Compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.