TuxBot : quand un malware assisté par LLM laisse ses empreintes dans le code

De quoi s’agit-il ?

Le 15 juillet 2026, l’Unit 42 de Palo Alto Networks a publié l’analyse de TuxBot v3 Evolution, un framework de botnet IoT jusqu’ici non documenté dont le code source porte des marques nettes d’une écriture assistée par un grand modèle de langage. Les chercheurs Chris Navarrete, Asher Davila et Doel Santos rattachent le framework à l’écosystème Keksec, aux côtés de familles connues comme Mirai et AISURU, avec au moins un échantillon déposé sur VirusTotal le 20 janvier 2026.

Ce qui intéresse les défenseurs, ce ne sont pas les capacités du botnet — une boîte à outils assez classique de la lignée Mirai — mais ce que l’auteur a laissé traîner par inadvertance. Le développeur a livré les notes de travail brutes du modèle, un avertissement de sûreté généré par l’IA qu’il a oublié de supprimer, et du code cryptographique que le modèle semble avoir halluciné. Plusieurs fonctions des échantillons analysés ne marchent tout simplement pas. Le résultat est un aperçu rare et bien documenté des résidus forensiques que peut laisser un développement de malware assisté par LLM.

Comment ça marche

TuxBot est modulaire : un agent bot en C qui se compile pour ARM, MIPS, x86_64, PowerPC et RISC-V, un serveur de commande et contrôle (C2) en Go avec un panneau de DDoS-as-a-service, une VM d’exploitation dédiée et un système de build automatisé. L’agent brute-force le Telnet avec une liste d’identifiants et embarque des exploits pour plus de trente familles de dispositifs IoT, avec repli sur plusieurs canaux C2 (un algorithme de génération de domaines, un protocole de gossip pair-à-pair signé, IRC, requêtes DNS TXT et polling HTTP). Rien de tout cela n’est nouveau.

Les artefacts révélateurs, eux, le sont. L’Unit 42 rapporte que plusieurs fichiers contiennent du raisonnement (chain-of-thought) brut laissé tel quel dans les commentaires — les notes pas à pas du modèle pendant qu’il traitait les tâches de portage, avec ses auto-interruptions, ses décisions et des références à « l’utilisateur », c’est-à-dire le développeur qui l’a sollicité. Par ailleurs, l’avertissement de sûreté du modèle a survécu jusque dans le code livré, un artefact qui n’apparaît que lorsqu’un texte généré est collé sans relecture. Enfin, l’auteur a livré des implémentations cryptographiques hallucinées sans les vérifier, ce qui explique en grande partie pourquoi plusieurs fonctionnalités sont cassées.

Ensemble, ce sont les empreintes comportementales d’un flux « générer-coller » sans relecture manuelle — exactement le genre de pipeline peu coûteux qui permet à un opérateur seul d’assembler rapidement un botnet multi-canaux.

Pourquoi c’est important

Deux conséquences en découlent, qui tirent en sens opposés.

Pour les défenseurs, le malware assisté par LLM offre aujourd’hui une surface de détection et d’attribution que le malware écrit à la main n’a pas. Commentaires de raisonnement verbatim, avertissements d’assistant oubliés, styles d’identifiants et de commentaires caractéristiques, et grappes de code non fonctionnel mais plausible sont autant de signaux de chasse. Ils divulguent aussi du renseignement sur le processus : quels composants ont été portés, dans quel ordre, et où la compétence de l’auteur a lâché. C’est la même leçon que les analyses antérieures sur les empreintes du code écrit par IA — les artefacts générés par machine ont un grain reconnaissable.

Le revers gênant est que ces artefacts sont des signes transitoires d’inexpérience, pas de faiblesse. L’Unit 42 note que quelques prompts ciblés ont suffi à réparer plusieurs des fonctions cassées : un adversaire disposant du même code pourrait livrer une version plus complète avec un effort minimal. La barrière qui a produit cet échantillon bâclé est une étape de relecture manquante, pas une limite du modèle. À mesure que les opérateurs apprendront à retirer les commentaires de raisonnement et à tester le code généré, cette empreinte particulière s’effacera — sa valeur pour les défenseurs est donc réelle mais limitée dans le temps.

Défenses

• Chassez les artefacts de génération dans les échantillons récupérés. Ajoutez des règles YARA et des recherches grep pour les avertissements de style assistant, les commentaires de raisonnement à la première personne, les références à « l’utilisateur » et autres marques de sortie de modèle collée. C’est peu coûteux à rechercher et, à ce jour, fréquent dans les malwares peu élaborés.
• Traitez le code non fonctionnel mais plausible comme un signal, pas comme du bruit. Des grappes de fonctions cassées mais bien structurées (surtout de la crypto approximative) trahissent une génération non vérifiée et aident à regrouper des échantillons par auteur ou par chaîne d’outils.
• Ne minimisez pas une menace parce que son build actuel est bogué. Le même code, plus une passe de relecture, donne un outil fonctionnel. Priorisez sur la capacité et la lignée (ici Keksec / Mirai / AISURU), pas sur le fait que cet échantillon précis tourne.
• Durcissez les fondamentaux IoT. Le vecteur d’entrée réel de l’agent est le brute-force Telnet et les exploits de dispositifs connus. Désactivez Telnet, changez les identifiants par défaut, segmentez et corrigez les équipements IoT/OT, et limitez le trafic sortant de type C2. L’assistance par LLM change qui peut construire un botnet, pas la façon dont il entre.
• Alimentez le renseignement sur la menace dès maintenant. Comme la fenêtre des artefacts se referme à mesure que les opérateurs se professionnalisent, capturez et partagez ces indicateurs tant qu’ils sont abondants.

Statut

Élément	Valeur
Quoi	TuxBot v3 Evolution — botnet IoT/DDoS modulaire à développement assisté par LLM
Divulgation	15 juillet 2026 (Unit 42, Palo Alto Networks)
Première observation	Dépôt VirusTotal le 20 janvier 2026 ; travaux ~1 an plus tôt
Attribution	Écosystème Keksec ; lignée Mirai, AISURU, Wuhan ; portage de MHDDoS
Artefacts clés	Raisonnement LLM verbatim en commentaires, avertissement de sûreté oublié, crypto hallucinée
État	En développement ; plusieurs fonctions non fonctionnelles dans l’échantillon
Périmètre	Découverte de threat intel ; pas de CVE, pas de correctif (malware, pas une faille produit)

Dates clés : 20 janvier 2026 — premier échantillon connu sur VirusTotal ; 15 juillet 2026 — publication Unit 42 et couverture presse. Les deux sources citées ont été publiées le 15 juillet 2026.