TuxBot v3 Uses LLM-Assisted Code to Build an IoT DDoS Botnet

Security researchers have uncovered TuxBot v3 Evolution, a previously undocumented IoT botnet framework built with help from a large language model. The malware targets exposed Linux-based devices and can use compromised systems to launch distributed denial-of-service attacks.

The framework supports 17 processor architectures, allowing operators to prepare malware for routers, cameras and other connected equipment running ARM, MIPS, PowerPC, RISC-V, x86-64 and several less common platforms.

According to the Unit 42 TuxBot analysis, the recovered version was approximately 70% functional. Its scanners, credential attacks, persistence mechanisms, primary command channel and several DDoS methods worked, while major parts of its exploit system remained broken.

What is TuxBot v3 Evolution?

TuxBot is a modular botnet framework designed to compromise internet-connected devices and manage them through a central command-and-control server. The analyzed package included source code, compiled malware, an automated build system and a Docker-based testing environment.

The bot component is primarily written in C, while its command-and-control server uses Go. An integrated build system installs dependencies, creates the database, generates configurations and compiles malware for each supported architecture.

Unit 42 traced the development process through source files, Git history and infrastructure records. The first recovered sample reached VirusTotal on January 20, 2026, while researchers observed the command server on March 5, 2026. Six additional production builds appeared in internal telemetry in April.

• A C-based malware agent for IoT and Linux devices
• A Go-based command-and-control server
• An SSH-accessible DDoS-for-hire panel
• A custom exploit virtual machine
• Docker and QEMU testing environments
• Automated compilation for 17 architectures

How TuxBot attempts to infect devices

TuxBot searches for exposed devices through Telnet, SSH, HTTP and Android Debug Bridge connections. Its Telnet scanner contains 1,496 username and password combinations, including default and vendor-specific credentials.

The framework also contains exploit code aimed at more than 30 IoT device families. However, researchers found that the three exploit systems in the recovered source did not work correctly. One engine was never called, its exploit virtual machine could not load its own packages, and another scanner referenced an inactive payload server.

The functional credential attacks still make TuxBot dangerous. Routers, cameras and other devices that expose remote administration services with weak or default passwords could join the botnet without relying on a software vulnerability.

Infection component	Status in analyzed version
Telnet scanner with 1,496 credential pairs	Functional
SSH scanner	Functional
HTTP scanner	Functional
Android Debug Bridge scanner	Functional
Main exploit engine	Present but never called
Custom exploit virtual machine	Broken
Additional remote-code execution scanner	Partially functional

TuxBot supports 17 processor architectures

The automated build system compiles TuxBot for a wide range of hardware. This gives an operator the ability to target both modern and older embedded systems from one development environment.

Supported builds include Alpha, ARM, ARM64, PA-RISC, Motorola m68k, MIPS, MIPS64, PowerPC, RISC-V, IBM S390x, Renesas SH, SPARC64 and x86-64. The server places the resulting files in an HTTP directory so an infected device can retrieve the correct binary.

The malware displays the console message “Infected By Akiru” after successful execution. The Akiru name also appears in parts of the framework and connects TuxBot to the developer’s internal naming.

Multiple persistence and stealth techniques

Once active, TuxBot tries to survive restarts and removal attempts. It can install a disguised systemd service, add cron jobs, modify shell profiles and create hidden backup copies of itself.

A watchdog component can restart the malware if it stops running. TuxBot also relocates its binary, changes its process name and uses names that resemble ordinary Linux processes to avoid attracting attention.

The bot includes a competitor-killing function that searches for rival malware and terminates it. This tactic allows TuxBot to preserve device resources and prevent another botnet from taking control of the same system.

• Disguised sd-pam.service systemd service
• Cron-based startup entries
• Modified shell-profile files
• Hidden backup binaries
• Watchdog monitoring
• Process-name imitation
• Binary relocation
• Removal of competing malware

Encrypted command-and-control system

TuxBot communicates with its main server through an encrypted TCP connection using X25519 and ChaCha20-Poly1305. The primary bot protocol listens on port 1999 or 31337, depending on the build.

The command server also exposes an SSH panel on port 2222. Operators can sign in, view the number of connected bots and issue DDoS commands. A MariaDB database stores user accounts, attack logs, permissions and limits on attack duration or bot allocation.

A separate JSON machine interface listens on port 9999. The multi-user panel and account quotas support Unit 42’s assessment that the system was designed for DDoS-for-hire activity rather than use by only one operator.

Port	Purpose
1999 or 31337	Encrypted bot communications and command delivery
2222	SSH administration and DDoS control panel
9999	JSON machine API

Fallback channels could keep the botnet online

TuxBot contains several backup communication methods for use when the main server becomes unavailable. These include a SHA-512 domain generation algorithm, peer-to-peer gossip, IRC, DNS TXT queries and HTTP polling.

Only three of the five fallback mechanisms worked in the recovered version. The domain generation system and Ed25519-signed peer-to-peer commands were functional, while the IRC and HTTP fallback channels contained defects.

The domain generator can produce 20 possible command-server domains per day. This could make a corrected TuxBot deployment harder to disable because infected devices would not depend entirely on one server address.

Developers left LLM artifacts in the source code

Researchers found direct signs that a large language model helped create C modules, port exploits and write parts of the command server. Raw model reasoning remained inside source files, while approximately 60 C files carried the same warning that the code was intended only for authorized security research.

The generated code looked plausible but included several serious mistakes. One encryption table used mismatched keys, the exploit virtual machine expected an incompatible file signature, and the main exploit engine was never connected to the program’s execution flow.

The authentication module claimed to use Argon2id password hashing. In reality, it used repeated SHA-256 operations while formatting its output to resemble an Argon2id hash. A manual code review should have identified the discrepancy.

LLM-related problem	Effect
Mismatched encryption keys	Prevented several encrypted table entries from working
Incompatible exploit package signature	Stopped the custom virtual machine from loading its packages
Disconnected exploit engine	Left the main exploitation component as inactive code
Fake Argon2id implementation	Created misleading password-hash output without implementing Argon2id
Unremoved safety comments	Exposed the use of generated code with little manual cleanup

Core DDoS functions remained operational

The defects did not prevent TuxBot from performing its main botnet functions. UDP floods, TCP floods and DNS-based DDoS attacks worked in the analyzed build.

The developers created 254 automated benchmark reports between January 4 and January 6, 2026. The tests measured packet rates, throughput and errors across 12 attack methods running against three Docker-based bot hosts.

Many advertised web-layer attacks did not work. Some commands incorrectly called simpler TCP SYN floods, while other Layer 7 features inherited from the MHDDoS project remained inactive.

Researchers repaired several broken components with only a few targeted LLM prompts. Because the operator has the complete source code, Unit 42 warned that a more reliable version may already exist or could appear with limited additional work.

Links to the wider IoT botnet ecosystem

TuxBot contains code and design elements taken from AISURU, an unidentified lineage that researchers call Wuhan, and the open-source MHDDoS toolkit.

Its payload server also hosted Kaitori v3.9 malware on separate paths. Certificate and hosting records connected the TuxBot command server in Singapore with a dropper server in Iceland.

The shared infrastructure places the operator within the broader Keksec ecosystem, according to researchers. However, TuxBot, Kaitori and AISURU remain separate codebases. Shared servers alone do not establish that every related campaign has the same operator.

Key TuxBot indicators of compromise

The following indicators come from the Unit 42 investigation. Domains have been defanged to prevent accidental access.

Type	Indicator	Description
IPv4 address	209.182.237[.]133	Primary TuxBot command-and-control server
IPv4 address	185.10.68[.]127	TuxBot and Kaitori payload server
IPv4 address	154.6.197[.]43	Scan-server address found in the source code
Domain	digikalas[.]online	Developer-associated domain
Domain	newtuxdev.sevielw.digikalas[.]online	Developer hostname exposed in Git history
Domain	jetross[.]com	Certificate artifact linking the C2 and dropper servers
Host artifact	sd-pam.service	Disguised persistence service
Host artifact	tmp.08x.lock	Single-instance lock-file format
User-Agent	TuxBot	User-Agent generated by the bot
SSH banner	SSH-2.0-CNC-Control-Server	Fingerprint for the SSH administration service
SHA-256	71dfbb171eca4ef9d02ff630b56e5283bbef7b375d4dbe9e8c9531bef312fa8d	Debug x86-64 TuxBot build
SHA-256	511d3ffb4091cbcc94571d9fb3102e8cb424c6e187d01d53ff12078d54929bda	Confirmed external TuxBot sample

How to protect IoT devices from TuxBot

Organizations should identify internet-facing IoT and edge devices, remove unnecessary exposure and replace every default password. CISA’s IoT security guidance warns that attackers can easily find many factory-set passwords online.

Administrators should disable Telnet and Android Debug Bridge access when those services are not required. SSH and web administration interfaces should remain available only through trusted management networks, VPNs or monitored jump hosts.

Firmware updates can close known vulnerabilities, but organizations should replace equipment that no longer receives security fixes. IoT devices should also sit on segmented networks that cannot directly reach sensitive servers or administrative systems.

• Change default and vendor-supplied passwords.
• Disable unused Telnet, SSH, HTTP and ADB services.
• Restrict administration interfaces to trusted networks.
• Install current firmware and security updates.
• Replace unsupported devices that no longer receive patches.
• Separate IoT equipment from critical business systems.
• Monitor repeated login attempts and scanning activity.
• Investigate unexpected outbound connections and DNS requests.
• Block confirmed TuxBot infrastructure after validating the indicators.

Network monitoring should look for repeated authentication attempts, unusual traffic from embedded devices and outbound connections to unfamiliar servers. Defenders can also hunt for the TuxBot SSH banner, persistence files and known binary hashes.

Following CISA’s recommendations for securing connected devices can reduce the main weakness exploited by TuxBot’s functional scanner: exposed equipment that still uses predictable credentials.

FAQ