AI wrote most of this IoT botnet, badly. That helps defenders.

Criminals now have a coding assistant, and the first botnet it helped build is broken. Palo Alto Networks' Unit 42 pulled apart a modular device botnet called TuxBot v3 Evolution and found something more useful than alarming: an author who asked a large language model to write malware, shipped what it produced with little review, and left the model's mistakes baked into the binary.

The reflex reaction to any "AI wrote malware" story is dread. This one earns the opposite read. The parts that work are the oldest tricks in the device-botnet playbook, and the parts the model invented mostly do not run. For anyone defending internet-facing servers or embedded gear, the practical picture barely changed. What changed is how quickly the next version arrives.

What Unit 42 found in the TuxBot samples

TuxBot v3 Evolution is a cross-compiled bot agent paired with a command-and-control server, a DDoS-for-hire panel, and an automated build system. Unit 42 reported that it builds for 17 processor architectures, from ARM and MIPS to PowerPC, RISC-V, and x86_64, which is what lets one device botnet spread across routers, cameras, and other embedded hardware. The framework descends from the Mirai line and borrows from the open-source MHDDoS toolkit. Unit 42 places the operator within the Keksec crew and notes infrastructure overlap with two other botnet projects, Kaitori and AISURU.

The tell that a model wrote much of it is hard to miss. According to Unit 42, 61 of the C source files carry an identical header calling the code "for authorized security research only," the kind of disclaimer a chatbot appends and a careful author strips. Source comments preserve the model talking to itself, with lines like // Wait, where is the command? left in place. And the code does not hold together: the researchers rate the recovered build at roughly 70% functional.

The gap between the two states in that table is the whole story. Scanning, credential brute-forcing, persistence, the primary C2 channel, and DDoS execution all work. The model's flourishes do not, as Security Affairs detailed. It implemented password hashing with PBKDF2 but formatted the output to look like Argon2id, producing hashes that begin with $argon2id$ and contain no Argon2 at all. An XOR key mismatch breaks the IRC backup channel. The custom exploit engine ships with the wrong file signature and cannot load its own payloads. Seventy-eight named attack methods silently fall through to a plain TCP SYN flood.

The AI changed the author, not the attack surface

Strip away the novelty and look at what infects a device. TuxBot brute-forces Telnet with 1,496 username and password pairs, tries known exploits against more than 30 families of embedded devices, and keeps itself alive with systemd services, cron entries, and a watchdog process. That is the Mirai recipe from 2016, unchanged. The model did not invent a new way in. It rewrote an old one.

This matters for how you weigh the threat. Your exposure to TuxBot is identical to your exposure to any Mirai variant: an internet-reachable Telnet or SSH port, a device running default or reused credentials, or an unpatched router or camera at the edge of your network. If those doors were closed last month, they are closed to TuxBot too. The detections that flag credential brute-forcing and repeated call-backs to a hardcoded C2 do not need to know a chatbot was involved. We made a similar point when a decade-old router turned into a scanning node: the forgotten device on the edge is the whole game, whoever wrote the payload.

The leftover AI fingerprints are a gift to defenders

The disclaimers and self-narrating comments are more than an embarrassment for the author. They are a triage signal. A sample carrying a boilerplate "authorized research only" header and chain-of-thought remarks is a fair bet to be model-generated, which tells an analyst two things before they finish reading it: the author probably did not review the code closely, and the exotic-looking parts are the likeliest to be broken.

The fake Argon2id label is the clean example. An analyst who trusts the string would model the C2 as using a memory-hard hash and plan around it. In reality it is PBKDF2, a weaker choice, and the mislabeling is itself evidence of a copy-paste author. The same logic applies to the sixteen dead-code exploit functions and the four payloads that never fire: time spent reversing them is wasted, because they were never going to run. When we looked at an AI-run ransomware build that lost its own decryption key, the lesson was the same. Machine-generated attack code fails in machine-generated ways, and those failure modes are predictable enough to plan around.

The real risk is how fast the operator can iterate

Here is the part that should hold your attention. Unit 42 did not just catalog the bugs, they fixed several, rebuilding the broken IRC channel and correcting the mangled tables "with a few targeted LLM prompts." If the researchers can repair the build that way in an afternoon, so can the operator, and Unit 42 assumes corrected variants are already in the wild. The 70%-functional sample is a pre-release that leaked, not the finished weapon.

The framework also shipped with an automated build pipeline and, per Unit 42, 254 automated benchmark reports generated in early January before the first sample reached VirusTotal on January 20. That is a development shop, not a hobbyist. The story is not that an AI wrote one buggy botnet. It is that the barrier to producing and tuning a multi-architecture botnet just dropped, and the same tool that leaves fingerprints today will leave fewer as the author learns to prompt it. The same acceleration is showing up on the research side, where models reopen old code and surface bugs faster than anyone can patch them. The capability is symmetric. The advantage goes to whoever iterates faster.

Lock down Telnet, SSH, and your edge devices first

Because the working core is conventional, the defense is conventional and well understood. If you run internet-facing servers or manage embedded devices, treat this as a prompt to check the basics rather than a new fire to fight.

• Close exposed Telnet and unauthenticated SSH. TuxBot's primary spread is a 1,496-pair credential guess against Telnet. A device that does not answer on those ports from the internet is not in the brute-force pool.
• Kill default and reused credentials on edge hardware. Routers, cameras, and other appliances shipped with vendor defaults are the target list. Change them, and disable remote management you do not use.
• Patch or segment the devices you cannot harden. The exploit set targets known bugs in more than 30 device families. Where a firmware update exists, apply it; where it does not, put the device behind segmentation so a compromise cannot reach the rest of the network.
• Watch for the persistence and the call-back. New systemd units or cron entries on an appliance, and outbound connections to a fixed C2 host, are the signals that survive whatever the malware is written in. Alert on the behavior, not the byline.
• Hunt captured samples for the model's tells. If you triage binaries, treat boilerplate "research only" headers and chain-of-thought comments as a flag for likely AI-assisted code, and deprioritize its exotic crypto and exploit paths as probable dead ends.

TuxBot is a preview of a genre, not a one-off. More malware will be written this way, and the early builds will keep failing in obvious, catchable ways. Read each one for what it teaches about the author's toolchain, patch the same old doors it walks through, and do not let the word "AI" talk you into treating a Mirai clone as something it is not.