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.
TuxBot interactive setup wizard screens (Source – Unit42)
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.
TuxBot C2 botmaster panel command reference (Source – Unit42)
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.
C2 protocols and the client – server relationships (Source – Unit42)
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):-
TypeIndicatorDescriptionIPv4 address209.182.237.133TuxBot command-and-control serverIPv4 address185.10.68.127TuxBot payload dropperIPv4 address154.6.197.43Scan-server address in bot source codeIPv4 address45.145.185.229Keksec dropper, not directly attributed to TuxBotIPv4 address107.174.133.119Keksec dropper, Huawei exploit payloadIPv4 address194.46.59.169AISURU-related infrastructureIPv4 address188.166.2.226Tsunami dropper in inactive RCE codeIPv4 address37.32.24.195IP address resolving for digikalas.onlineDomainbinsbot.archTuxBot payload hosting domain/pathDomainc2.tuxbot.localHard-coded DNS fallback C2 domainDomaindigikalas.onlineDeveloper-associated domainDomainnewtuxdev.sevielw.digikalas.onlineDeveloper hostname leaked in Git dataDomainjetross.comTLS certificate artifact linking C2 and dropperDomaincfcybernews.euTest domain leaked by CF bypass moduleDomaincaptcha.kanfetka.siteTest domain leaked by CAPTCHA bypass moduleDomainvrunabo.suHistorical domain associated with dropper infrastructureDomainrezy1337.ted.geHistorical domain associated with dropper infrastructureDomainhigh.cpu.co.uaHistorical domain associated with dropper infrastructureFilenametuxbot.alphaTuxBot compiled binary for Alpha architectureFilenametuxbot.armTuxBot compiled binary for ARMFilenametuxbot.arm64TuxBot compiled binary for ARM64Filenametuxbot.arm7TuxBot compiled binary for ARM7Filenametuxbot.hppaTuxBot compiled binary for PA-RISCFilenametuxbot.m68kTuxBot compiled binary for Motorola m68kFilenametuxbot.mipsTuxBot compiled binary for MIPSFilenametuxbot.mips64TuxBot compiled binary for MIPS64Filenametuxbot.mips64elTuxBot compiled binary for MIPS64 little-endianFilenametuxbot.mipselTuxBot compiled binary for MIPS little-endianFilenametuxbot.ppcTuxBot compiled binary for PowerPCFilenametuxbot.ppc64leTuxBot compiled binary for PowerPC 64 little-endianFilenametuxbot.riscv64TuxBot compiled binary for RISC-VFilenametuxbot.s390xTuxBot compiled binary for IBM S390xFilenametuxbot.sh4TuxBot compiled binary for Renesas SHFilenametuxbot.sparc64TuxBot compiled binary for SPARC64Filenametuxbot.x8664TuxBot compiled binary for x86-64Filename.botx8664Debug TuxBot x86-64 buildSHA-2566b7a8e0c96c2318e747f074f9a99d26738700769ac01bba692d19fc884847737tuxbot.alphaSHA-256146f6010f6ee082aab13e0148d39baefa77eaba4ff65817b511b08c2092bdfd2tuxbot.armSHA-256bd6431fb06e4689142ef597cf00382e38ae20a5393a4d9277e45a3f5b3cbcff9tuxbot.arm64SHA-256a03b0d41f5ef03328150331ffa0ed970998883f7e0343d79b2d3b95330d8e7c1tuxbot.arm7SHA-256eb2fa179fde2f097c18d5d700ad87d660fc238ee14cbe5477032e60856859621tuxbot.hppaSHA-256a8d70d16509e227d8306be361bc37a3dc9fe34bf476f51e361e55e6d293c2b3ftuxbot.m68kSHA-2560f8bcca3ed65e980da2a1f90a767b7d543be32eeea3e9338d09d4d635a497988tuxbot.mipsSHA-25696b1f96efca3b9df2dea85678d60da27e3265b4a00e39e20e64b27bb985e1561tuxbot.mips64SHA-256c7a36d6b8128c41f93a32413675401a10a2b5769b221bbaa8c5c309585b73cebtuxbot.mips64elSHA-256246c97957651de568e61eba1abe572f0b0f960456209995d43d53a0d7cc494a1tuxbot.mipselSHA-2563ec016d637e4c9cd331edd2580a229621ad638e924a4aa29ac0342e9144ace19tuxbot.ppcSHA-2562f2c3551762c03da126e45dca6fc2f997c63f0f1bfc21fd0ceed680ac6f083cetuxbot.ppc64leSHA-2569cd5e7e3c8bad321ef6c3d47fe25b3b56e9487f703a7eeee52db4067e6bafe61tuxbot.riscv64SHA-256e3a5296e762e9ee16010399666441d663beeea956382e97cca032a6a5ad06811tuxbot.s390xSHA-256f1efb78887bb8783d7781c07cd13b53c9c79ebe5baa81f335838d0a6e73dec7etuxbot.sh4SHA-256f324a45fcd2a9db4e542c09486c21b08bc42d6bf76fbd5f17871090361b10815tuxbot.sparc64SHA-25615c17dce89deccd5172285b2650de957918aa1157cde8e4633ae15dfe31f2711tuxbot.x8664SHA-25671dfbb171eca4ef9d02ff630b56e5283bbef7b375d4dbe9e8c9531bef312fa8d.botx8664 debug buildSHA-256511d3ffb4091cbcc94571d9fb3102e8cb424c6e187d01d53ff12078d54929bdaConfirmed external TuxBot sampleSHA-2566aa4034dc7a2858094ff4dc59af07d6fe31119591e41599bcc0f3d0b516ee734Confirmed internal TuxBot sampleHost artifactInfected By AkiruConsole output after successful executionHost artifactsd-pam.serviceDisguised systemd persistence serviceHost artifacttmp.08x.lockLock-file format for single-instance controlUser-AgentTuxBotHTTP requests generated by botUser-Agentr00ts3c-owned-youInactive RCE payload inherited from MHDDoSSSH bannerSSH-2.0-CNC-Control-ServerC2 SSH service fingerprintNetwork port209.182.237.133:1999Encrypted bot protocolNetwork port209.182.237.133:31337Alternate encrypted bot protocolNetwork port209.182.237.133:2222C2 SSH administration panelNetwork port209.182.237.133:9999JSON machine API
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.
Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.
The post New TuxBot v3 IoT Botnet Uses LLM-Generated Code to Hijack Devices and Launch DDoS Attacks appeared first on Cyber Security News.
