We identified a previously undocumented modular internet-of-things (IoT) botnet framework named TuxBot v3 Evolution.
The malware authors leveraged an LLM to assist in their code development, yielding mixed results. While the AI complied with their request to generate botnet code, it included a safety disclaimer that the developer failed to remove before shipping.
Although the LLM clearly aided in constructing the botnet, several functions in the analyzed samples failed to work correctly. While a manual code review could have easily resolved these errors, the authors neglected this step. However, it is highly likely that corrected, more polished iterations exist, which significantly elevates the potential threat posed by this malware.
We initially reported this information through our Timely Threat Intelligence program, and this article provides further in-depth analysis of the TuxBot v3 Evolution botnet.
We recovered detailed information on the framework from internal telemetry. The data includes the full source code, compiled binaries for 17 architectures and automated distributed denial of service (DDoS) performance testing reports. The bot programs infected devices to display the console banner “Infected By Akiru.”
The TuxBot v3 Evolution framework consists of:
The bot agent brute-forces Telnet access on targeted devices with 1,496 credential pairs, contains exploit code targeting more than 30 IoT device families and communicates with a C2 server over an encrypted TCP channel.
Fall-back C2 mechanisms include:
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.
TuxBot is a modular IoT botnet framework derived from various known IoT botnet codebases. Based on our analysis of the samples, TuxBot includes features borrowed from the known botnet AISURU and the publicly unknown Wuhan botnet lineages. (We infer the Wuhan botnet lineage based on references in the TuxBot samples.)
It is also partially ported from the open-source MHDDoS Python DDoS toolkit.
Figure 1 shows screenshots of the TuxBot v3 Evolution installer. According to the system configuration, the framework maintains dual versioning: 3.5.2 for the Installer version and 3.0.0-EVOLUTION-FINAL within the Docker configuration file.
We discovered two important sources of TuxBot data from the wild. Our first discovery was an archive containing the complete source code of the framework. This archive consists of:
Our second discovery was a compiled bot binary that was also bundled in the source tree under the QEMU test directory and hidden with a dot-prefix to the filename. This sample was submitted to VirusTotal on Jan. 20, 2026.
Comparing this binary with the source code reveals that it is a development build. This binary was compiled with its C2 IP address set to the loopback IP address 127.0.0.1 and the bot protocol port set to 31337. Because this information can be modified during the botnet setup process, the operator could have production builds with a real C2 IP address and with the bugs we document here already fixed.
The TuxBot framework we recovered and analyzed is approximately 70% functional. The core infection flow (scanning, credential brute-forcing, persistence, primary C2 setup and DDoS execution) works. The Telnet, SSH, HTTP and Android Debug Bridge (ADB) scanners all operate correctly. Furthermore, with its 1,496 credential pairs, the Telnet scanner remains a viable infection vector.
Exploitation beyond brute-forcing is limited. All three exploit systems are non-functional for different reasons that we detail later in this analysis. An additional scanner fires, but its hard-coded dropper IP address is no longer active.
Several other features are broken due to a handful of bugs, most of which trace back to large language model (LLM)-assisted development. The developer relied on an LLM to generate C modules, port exploits and write C2 server code.
Raw chain-of-thought reasoning from the LLM was left verbatim in source files, and the LLM hallucinated cryptographic implementations that the developer shipped without verifying. During our analysis, we could fix several of these broken features with a few targeted prompts to an LLM. This means an adversary with access to the same source code could produce a more complete version with minimal effort.
The archive containing the source code also contains a Git log. This Git log allowed us to build a timeline that shows the development progress of this botnet, noted in Table 1.
| Date | Event | Evidence |
| Jan. 3, 2025 | Developer clones MHDDoS (DDoS attack script) from GitHub | Git log in the MHDDoS/ subdirectory leaks the workstation hostname newtuxdev.sevielw.digikalas[.]online |
| Aug. 6, 2025 | Developer domain digikalas[.]online registered | Namecheap registration with Icelandic privacy protection (Withheld for Privacy ehf), Cloudflare DNS |
| Jan. 4–6, 2026 | 254 automated DDoS benchmark reports generated | The package found includes reports, directory timestamps and JSON test configurations against Docker targets |
| Jan. 20, 2026 | The first TuxBot sample appears on VirusTotal | SHA256 hash 71dfbb171eca4ef9d02ff630b56e5283bbef7b375d4dbe9e8c9531bef312fa8d, x86_64 debug build with symbols |
| March 5, 2026 | C2 server first seen on Xpanse | 209.182.237[.]133:2222, banner SSH-2.0-CNC-Control-Server |
| April 22, 2026 | Six new samples detected in internal telemetry | Not on VirusTotal, multiple architectures, GCC 14.2.0 production builds |
Table 1. TuxBot Framework development timeline.
The source code and publicly available data provide a rough development chronology. The developer's hostname, captured in the included Git log, indicates an Iranian-hosted workstation. The developer domain newtuxdev.sevielw.digikalas[.]online was no longer live, but the parent domain digikalas[.]online has remained active and resolved to an IP address on Iran's Arvan Cloud content delivery network (CDN) during our research.
The 254 benchmark reports from the archive from January 2026 reveal:
This testing occurred just weeks before the first sample appeared on VirusTotal, consistent with a late-stage development push before deployment.
The source code contains an IP address of 185.10.68[.]127, which we pivoted on to link TuxBot to Keksec/Kaitori (a Tsunami/Mirai/Gafgyt variant) ecosystems to a shared infrastructure.
According to the framework’s description, the TuxBot developer built what they called a professional-grade C2 framework platform with a multi-user admin panel, automated deployment and modular attack capabilities. Figure 2 shows the botnet panel reference.
The C2 server is written in Go and uses three listeners that use different TCP ports for incoming connections.
The first listener serves the bot protocol on TCP port 1999 (or 31337, depending on the build), handling encrypted command dispatch to connected bots. The same port is multiplexed with an admin binary protocol identified by a magic byte header.
The second listener is an SSH server on TCP port 2222 that presents an interactive shell for operators. This is the DDoS-for-hire interface shown in Figure 3. Operators log in, see a count of connected bots and issue attack commands in the format !method target duration.
As Figure 4 shows, the C2 server enforces per-user quotas on concurrent attacks, maximum duration and bot allocation. This is all backed by a MariaDB database that stores user accounts, attack logs and permissions.
The third listener is a machine API on TCP port 9999 that uses a JSON interface intended for programmatic access.
The integrated build system automates the entire deployment:
These target architectures include:
The compiled binaries are placed in a directory served over HTTP, so exploited devices can download the appropriate binary for their architecture.
The framework includes Docker Compose configurations for several test scenarios. A “battle arena” configuration spins up a C2 server, five bot replicas and a target host running nginx and socat listeners on game server ports (Minecraft, TeamSpeak, FiveM, Xbox Live). This allowed the developer to test DDoS methods against real protocol listeners in a controlled environment. Additional configurations test P2P gossip recovery, full integration with all scanners active and production-like deployments with stealth and persistence enabled.
An interesting design note is that the source code configures the SSH banner as SSH-2.0-CNC, but the live C2 server on Xpanse at 209.182.237[.]133 presents the banner as SSH-2.0-CNC-Control-Server. This discrepancy suggests that the production deployment uses a modified version of the source code we discovered, providing further evidence that the operator has a separate, potentially more complete build.
The bot is a C program that compiles into a single statically linked binary. It links against glibc and libsodium for X25519, ChaCha20, Poly1305, SHA512 and Ed25519 algorithms.
The original binary submitted to VirusTotal was an earlier debug build with symbols intact, compiled with GCC 11.4.0 instead of the production GCC 14.2.0. The bot programs infected devices to display the console banner Infected By Akiru, as shown in Figure 6.
On execution, the bot follows a fixed initialization sequence. After seeding the pseudo-random number generator and initializing libsodium, it performs the following activities:
The main process then enters a loop that receives encrypted commands from the C2 server and dispatches attacks.
TuxBot stores sensitive strings (C2 addresses, scanner calls, exploit payloads) in an XOR-encrypted table that it decrypts at runtime. The table key is previously defined as 0xDEDEFB4F.
The toggle_obf() function splits this 32-bit key into its four component bytes (0x4F, 0xFB, 0xDE, 0xDE) and XORs each byte of each table entry with all four in sequence. Because XOR is associative, these four operations collapse into a single effective key. The two 0xDE bytes cancel each other out (any byte XORed with itself yields zero), leaving 0x4F XOR 0xFB = 0xB4.
The table contains 58 entries. Forty-nine of them decrypt correctly with key 0xB4 and include:
Nine entries produce garbage when decrypted with 0xB4. These entries were encrypted using a separate offline tool, which uses a key of 0xDEDEFBAF, yielding an effective byte of 0x54.
The developer introduced this bug by changing the least significant byte of the key in the table from 0xAF to 0x4F. The offline encryption tool was never updated to match, and the nine entries that had already been processed with the old key were never re-encrypted. As a result, these entries are encrypted in the binary with key 0x54, while the runtime applies key 0xB4, producing corrupted output.
Decrypting them with the correct key (0x54) reveals the intended values shown in Table 2.
| Entry | Intended Value |
| TABLE_IRC_SERVER | 127.0.0[.]1 |
| TABLE_IRC_PORT | 6667 |
| TABLE_IRC_CHANNEL | #tuxbot |
| TABLE_IRC_NICK_PREFIX | tux |
| TABLE_HTTP_C2_URL | hxxp[:]//127.0.0[.]1/cmd |
| TABLE_THINKPHP_PAYLOAD | Full HTTP GET request (312 bytes) targeting ThinkPHP invokefunction |
| TABLE_GPON_PAYLOAD | Full HTTP POST request (316 bytes) targeting GPON diag_Form |
| TABLE_REALTEK_PAYLOAD1 | Full SOAP request (988 bytes) targeting Realtek UPnP /picdesc.xml |
| TABLE_REALTEK_PAYLOAD2 | Full SOAP request (988 bytes) targeting Realtek UPnP /wanipcn.xml |
Table 2. String table decrypted values.
All four exploit payloads hard code the dropper IP address 185.10.68[.]127 inside them, an IP address that is flagged as malicious on VirusTotal in early May 2026.
The consequences of this bug are significant. The IRC C2 fall-back channel, the HTTP C2 polling channel and the four table-stored exploit payloads are all non-functional at runtime. The bot attempts to use them, but it silently fails due to the corrupted string values. For example, the IRC channel tries to inet_addr() on garbage bytes, gets INADDR_NONE and retries the connection every 10 seconds.
We were able to fix this to call the add_entry_plaintext() function correctly, by taking the raw string and XORing it with the runtime key (0xB4) at initialization, guaranteeing the keys always match. With that fix applied, the IRC C2 channel connects, joins #tuxbot and accepts attack commands as noted in Figure 7.
The bot ships with 1,496 username/password pairs for Telnet brute-forcing. The file header explicitly says // START IMPORTED FROM DDOS-ROOTSEC pass_file. Each entry is XORed with key 0xB4 (matching the runtime key, so these work correctly).
The list of 1,495 login credentials includes standard and vendor-specific defaults.
TuxBot implements a layered C2 architecture with one primary channel and five fall-back mechanisms. Only the primary channel and three of the five fall-back mechanisms were functional in the version we analyzed. Figure 8 shows the diagram.
The bot connects to the C2 server on TCP port 1999 (or 31337, depending on build configuration). The handshake begins with the bot sending 4 bytes: 0xDEADBE01. It then generates and sends its 32-byte public key. The C2 server responds with its own 32-byte public key. Each encrypted packet has the following format:
The framework defines five additional C2 channels, summarized in Table 3.
| Channel | Implementation | Status |
| DNS TXT | Queries c2.tuxbot.local via 8.8.8[.]8 | Functional |
| DGA | Seed format <YYYY-MM-DD>-TuxBotv3-Evolution-Seed-2025-<index>, SHA-512, 20 domains/day | Functional |
| P2P Gossip | TCP port 13337, Ed25519-signed commands | Functional |
| IRC | TCP port 6667, plaintext | Broken |
| HTTP Polling | Polls hxxp[:]//127.0.0[.]1/cmd | Broken |
Table 3. C2 channels and their implementation status.
The broken IRC implementation reveals the intent for a secondary channel of communication, as demonstrated below in Figure 9.
When fixed, it forks a child process that connects to an IRC server, joins a channel (default #tuxbot) and listens for PRIVMSG commands prefixed with the ! character. It supports 12 attack methods (udp, syn, ack, vse, stomp, greip, greeth, udpplain, bypass, std, socket and dns) plus a kill command.
Commands arrive as plaintext IRC messages and get parsed by the parse_irc_command() function. Then the commands are converted to the same binary packet format used by the primary encrypted channel before being passed to attack_parse().
Unlike the primary channel, the IRC channel has no encryption and no authentication. Anyone who knows the server and channel can command the bots.
The dga_generate_domain() function constructs a seed string formatted as %04d-%02d-%02d-TuxBotv3-Evolution-Seed-2025-%d, where the date is the current UTC date and the final integer iterates from 0–19 per cycle. This produces 20 candidate domains per day.
The SHA512 hash of this string is computed, and the first 12 bytes of the digest are mapped to lowercase letters (digest[i] % 26 into the a-z charset) to form the domain label. The top-level domain (TLD) is selected from a 6-entry table (.com, .net, .org, .info, .biz and .cc) using digest[12] % 6. Both the main C2 reconnection loop and the resilience module use this function to try DGA domains when the primary C2 address is unreachable.
The source tree contains four categories of exploit. Only one of them works at runtime. This is a direct consequence of the bugs introduced during development.
Sixteen exploit functions are implemented as native C code, covering 13 CVEs across different vendors and devices. Each function constructs an HTTP or SOAP request with a %s format string for the dropper IP address. The code is complete and would work if called. But exploit_engine_init() has zero callers anywhere in the codebase. No scanner or spread module references it. These 16 exploits are compiled into the binary and considered as dead code.
The main Telnet scanner spawns a dedicated exploit worker thread that calls vm_run_random() in a loop against random IP addresses, making this the only exploit system the bot actually tries to use at runtime. The developer built a custom domain-specific language for writing exploits as text files, a Go compiler to compile them into a binary package and a C virtual machine to execute them.
We also observed 27 .expl files, a custom file format created by the developer for this framework. Each file contains a single exploit, making exploit integration modular rather than hard-coded. These were written and compiled into a single 10,694-byte exploit package that would add coverage for 13 CVEs (including CVE-2022-1388, CVE-2022-22965, CVE-2020-8515 and CVE-2022-44877) plus two non-CVE targets.
The package fails because the Go compiler writes the file magic value as 0x54555845 ("TUXE") while the C VM expects 0x4558504C ("EXPL"). The package is rejected on load, and the exploit worker thread runs but fires nothing. Beyond the magic mismatch, the compiler never emits an OP_CONNECT opcode, and the variable syntax differs between the compiler and VM. This means that even fixing the file magic value would not be enough to make the package execute correctly.
This category consists of XOR table payloads, but these are broken due to an XOR key mismatch. Four exploit payloads are stored as XOR-encrypted entries in the string table. These target different vendors and were intended as an alternative delivery mechanism. They are all encrypted with the wrong XOR key (0x54 instead of 0xB4), resulting in garbled HTTP requests at runtime.
This category consists of functional dedicated scanners for remote code execution (RCE) and ADB.
In summary, the exploit categories are described in Table 4.
| Exploit Category | Count |
| Implemented but never called (dead code) | 13 CVEs + 4 non-CVE targets (System 1, exploit engine) |
| Called at runtime but broken (VM magic mismatch) | 13 CVEs + 2 non-CVE targets (System 2, exploit VM) |
| Broken (XOR key mismatch) | 4 exploits overlapping with System 1 (System 3) |
| Functional dedicated scanners | RCE vulnerability scanner, ADB scanner |
Table 4. Exploit categories and counts (per implementation status).
These four categories mean that this bot's actual exploit capability at runtime is limited to the last two categories:
The other three exploit categories that were supposed to provide broad IoT exploitation are non-functional, each for a different reason. A complete table of all CVEs and their status is provided in the Indicators of Compromise section.
The attack dispatch system registers 78 attack vectors. These vectors map to only six actual handler functions, as shown in Table 5.
| Handler (Designator) | Vectors | Description |
| attack_udp_generic_optimized | 25 | UDP/GRE/ICMP floods using raw sockets with sendmmsg() batches of 512 packets |
| attack_tcp_syn_optimized | 47 | TCP SYN floods, also mapped to all Layer 7 HTTP method IDs |
| attack_tcp_ack_optimized | 2 | TCP ACK floods |
| attack_tcp_stomp_optimized | 1 | TCP ACK+PSH floods |
| attack_udp_dns_optimized | 2 | DNS query floods |
| attack_miner | 1 | Cryptocurrency mining placeholder |
Table 5. DDoS method handlers and their descriptions.
The 47 vectors mapped to attack_tcp_syn_optimized include all application-layer methods for HTTP that the developer attempted to port from MHDDoS:
These methods have source code implementations, but attack_init() routes all of their vector IDs to the TCP SYN handler. An operator who types !get target 60 expecting an HTTP GET flood instead gets a TCP SYN flood.
The HTTP attack methods are compiled into the binary as dead code. Figure 11 shows the command for a controlled bot to launch an attack against a given IP address and port number.
The source tree contains approximately 92 individual method implementations across three lineages:
These exist in the compiled binary but are never called because attack_init() redirects everything to the six optimized handlers shown in Figure 12 below.
The source code reveals a modular architecture designed for high-efficiency network scanning, specifically using a dedicated HTTP scanning routine to discover vulnerable web interfaces.
The HTTP scanner operates as an isolated child process that manages up to 128 concurrent connections in an infinite, non-blocking select() loop. For each idle slot (approximately 5% chance per tick), it targets a random public IP address on TCP port 80 or 8080, excluding loopback and non-routable IP address ranges.
The scanner then attempts a non-blocking TCP connection to a random administrative endpoint (such as /admin or /cpanel). It does so using credential combinations (like admin:admin) from hard-coded lists via a Base64-encoded Authorization: Basic header in an HTTP GET request.
If the response yields a successful HTTP/1.* with 200 OK status strings, the scanner prints a debug log and terminates the connection. Crucially, the source code indicates that this feature was not fully implemented, as the successful propagation logic is stubbed out and completely lacks the functionality to report successful infections back to the C2 server. If the attempt times out after 5 seconds or fails, it simply closes the connection and frees the slot for reuse.
Figure 12 shows an example of the scanning traffic filtered in Wireshark.
The persistence and stealth subsystems follow patterns well established in the IoT botnet ecosystem, so we will not describe every technique in detail. TuxBot installs itself through seven persistence mechanisms:
The Anti-VM module implements a weighted scoring system with a threshold of 30, combining more than 10 detection methods, including:
The developer used an LLM to write a significant part of this framework. Multiple files contain raw LLM chain-of-thought reasoning left verbatim in comments. These comments are the LLM's internal reasoning as it worked through porting tasks. This reasoning is complete with self-interruptions, decisions and references to “the user” (meaning the developer who prompted the LLM). Here are a few examples:
While trying to port an ADB exploit to the custom .expl format, the LLM writes:
// If the user insists on "all exploits", I will add it but with a NOTE that checksums might fail.
The LLM is questioning whether it remembers code it generated earlier in the same conversation:
// I created them so I should know?
Discovering that a Python exploit script it was porting is broken:
// Wait, where is the command?
These patterns recur throughout the exploit files:
One comment reads // Correct action: I've already explored it. I will check other files. These comments are an LLM narrating its own workflow to itself. Human developers do not usually write comments like these.
The same patterns appear in the C bot modules. Comments include:
Actually, TFTP requires lock-step ACK, Let's assume if the system() call returns, we might want to exit and actually crypto_core allows generating them from a seed. Let's use a random seed.
The most consequential LLM artifact is in the C2 authentication module. The file header claims to implement Argon2id password hashing. The section header reads PASSWORD HASHING - ARGON2ID. The function comment says HashPassword creates a cryptographically secure password hash using Argon2id.
Related LLM comments include:
// Since golang.org/x/crypto/argon2 isn't imported, we'll use our enhanced PBKDF2
// with very high iterations as a strong alternative
hash := deriveKeyEnhanced(password, salt)
Despite its use of PKBDF2 for password hashing, the LLM formats the output to look like Argon2id anyway:
return fmt.Sprintf("$argon2id$v=19$m=%d,t=%d,p=%d$%s$%s", ...)
The LLM hallucinated that it implemented Argon2id but actually fell back to SHA256 loops while keeping the Argon2id comments, constants and output format.
Every .c file in the bot directory (approximately 60 files) carries an identical header:
WARNING: This code is for educational and authorized security research only. Unauthorized use is strictly prohibited and may be illegal.
The LLM complied with the request to generate botnet code but added a safety disclaimer. The developer shipped it without removing it.
Table 6 summarizes the operational status of each major component of TuxBot v3 Evolution.
| Component | Status |
| Multi-architecture compilation (17 targets) | Functional |
| Primary encrypted C2 (X25519 + ChaCha20-Poly1305) | Functional |
| Telnet brute-force scanner (1,496 credentials) | Functional |
| SSH scanner | Functional |
| HTTP scanner | Functional |
| ADB scanner | Functional |
| Exploit engine | Dead code. It could be activated by adding a call to the exploit engine function. |
| Exploit VM | Broken |
| RCE scanner | Partial |
| DDoS (UDP/TCP/DNS floods) | Functional |
| Persistence (systemd/cron/shell/watchdog) | Functional |
| Stealth (process mimicry/relocation/anti-VM) | Functional |
| Competitor killing | Functional |
| DGA (SHA-512, 20 domains/day) | Functional |
| P2P gossip (Ed25519 signed) | Functional |
| Credential list | Functional |
| IRC C2 fall back | Broken |
| HTTP C2 fall back | Broken |
| XOR table exploit payloads (4 entries) | Broken |
| L7 HTTP DDoS methods (MHDDoS port) | Dead code |
| Polymorphic engine | Dead code |
| CF/CAPTCHA bypass modules | Dead code |
| Mining | Placeholder/Non-Functional |
| Windows build | Non-Functional |
Table 6. Operational status for each TuxBot framework component.
During our research, we were able to fix these issues with a handful of LLM-assisted prompts. We reconstructed the correct table entries and fixed the IRC C2 channel with a few targeted prompts. Given that the operator already has the source code and has been actively deploying binaries (six new samples in April 2026), we can reasonably assume that a version with some or all of these fixes already exists in the wild.
By searching through publicly available data, we found active infrastructure and connections to the broader IoT botnet ecosystem.
The primary C2 server is hosted at 209.182.237[.]133, in Singapore. Connecting to TCP port 2222 on this server presents the banner SSH-2.0-CNC-Control-Server, first observed on Xpanse on March 5, 2026, and also visible through Shodan. The SSH key exchange includes a key exchange algorithm that fingerprints Go's crypto/ssh library rather than OpenSSH.
The dropper server at 185.10.68[.]127 is hosted on FlokiNET, an Iceland-based provider known for bulletproof hosting. This IP address had 11/91 malicious detections on VirusTotal in May 2026, with at least 10 communicating malware samples and six associated downloads.
This dropper server serves TuxBot payloads at /bins/bot.<arch> and, on different URL paths, also serves Kaitori v3.9 binaries. Passive DNS history for this IP address shows domains consistent with DDoS-for-hire operations going back to 2021, with the domains vrunabo[.]su, rezy1337.ted[.]ge and high.cpu.co[.]ua.
These two servers are linked by the jetross[.]com Let's Encrypt TLS certificate that appears on both hosts, tying the C2 server in Singapore to the dropper in Iceland under the same operator.
The dropper IP address is the pivot point that connects TuxBot to the wider Keksec/AISURU ecosystem. Kaitori v3.9 samples recovered from our internal telemetry in July 2025 (82 samples) downloaded their payloads from 185.10.68[.]127 on different URL paths. A separate sample, a Go binary, communicates with both 194.46.59[.]169 (a known AISURU IP address) and 185.10.68[.]127. TuxBot, Kaitori and AISURU tooling all converge on the same dropper server, but they are separate codebases.
One additional artifact sits in the source code. The RCE scanning engine contains a hard-coded payload that downloads from hxxp[:]//188.166.2[.]226/OwO/Tsunami.x86 with the user-agent r00ts3c-owned-you. This string was copy-pasted from the r00ts3c Tsunami codebase, which was included in the MHDDoS repository that the developer cloned in January 2025.
The IP address is a decommissioned DigitalOcean droplet now serving Ubiquiti's UISP platform. This payload is dead code.
The developer domain digikalas[.]online resolves to 37.32.24[.]195 on Iran's Noyan Abr Arvan. Its TLS certificate covers api.digikalas[.]online and health.digikalas[.]online, suggesting it hosts a web application beyond the malware development context. The developer subdomain was leaked in the git historical log data.
Our discovery of TuxBot v3 Evolution reveals a development snapshot of an IoT botnet framework. The framework has working core capabilities and several broken features that trace to a small number of reproducible bugs.
Binaries compiled from this framework have been appearing in the wild since January 2026. The C2 infrastructure has been active since at least March 2026.
The developer relied heavily on LLM-generated code throughout the project. That approach accelerated integration and allowed what could be a single developer to produce a multi-architecture botnet with:
The LLM also introduced bugs that went unnoticed because the generated code reads well on the surface. The XOR key mismatch, the VM magic incompatibility, the exploit engine that never gets called and the hallucinated Argon2id implementation are the kind of errors that a manual code review would have caught immediately. The developer trusted the output and moved on.
Shared infrastructure with Kaitori v3.9 and AISURU tooling places the TuxBot operator within the Keksec ecosystem. This group is known for running multiple IoT botnet variants in parallel.
TuxBot appears to be another variant in that portfolio. It’s one that aims to go beyond the usual Mirai fork with its encrypted C2, its DGA and a modular exploit system, even though that system does not work yet in the version we recovered.
The broken features can be fixed. We demonstrated this during our analysis by reconstructing the IRC C2 channel and decrypting the mismatched table entries with a few targeted LLM prompts. A fully working version of this framework is not a theoretical concern, but a likely threat.
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
TuxBot Framework (Compiled Malicious Binaries):
Confirmed TuxBot (External samples):
Confirmed TuxBot (Internal samples):
TuxBot C2 Servers:
Keksec/Kaitori (not TuxBot directly):
Historical IP addresses:
Domains:
Host Indicators:
Network Indicators:
Implemented but never called at runtime:
Completely Broken (exploit VM magic mismatch, never executes):
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。