Mit LLM-Hilfe erstelltes IoT-Botnetz enthält noch die Sicherheits-Haftungsausschlüsse der KI

Cybersicherheitsforscher von Palo Alto Networks ↗ 5.00% haben ein bisher nicht dokumentiertes IoT-Botnetz-Framework namens TuxBot v3 Evolution offengelegt, das mit massiver Unterstützung eines großen Sprachmodells (LLM) erstellt wurde – und bei dem der Sicherheits-Haftungsausschluss des LLM in jeder Quelldatei eingebettet blieb.

Ein KI-erstelltes Botnetz mit KI-induzierten Fehlern

Unit 42, das Threat-Intelligence-Team von Palo Alto Networks, veröffentlichte am Montag seine Ergebnisse und enthüllte ein modulares Botnetz-Framework, das für 17 CPU-Architekturen, von ARM und MIPS bis hin zu PowerPC und RISC-V, cross-kompiliert werden kann. Das Framework umfasst einen C-basierten Bot-Agenten, einen Go-basierten Befehls- und Kontrollserver mit einem DDoS-for-Hire-Panel, eine benutzerdefinierte Exploit-VM und eine Docker-basierte Testinfrastruktur.unit42.paloaltonetworks

Die Forscher stellten den vollständigen Quellcode, kompilierte Binärdateien und 254 automatisierte DDoS-Benchmark-Berichte sicher, die eine aktive Entwicklung und Tests bis Anfang 2026 belegen. Der Bot führt Brute-Force-Angriffe auf den Telnet-Zugang unter Verwendung von 1.496 Anmeldedatenpaaren durch und enthält Exploit-Code, der auf mehr als 30 IoT-Gerätefamilien abzielt.mallory+1

Unit 42 bewertete das Framework als „zu etwa 70 % funktionsfähig“, wobei die Kernfunktionen – Scannen, Brute-Force-Angriffe auf Anmeldedaten, Persistenz, verschlüsselte C2-Kommunikation und DDoS-Ausführung – alle funktionieren. Die fehlerhaften Teile lassen sich fast vollständig auf LLM-generierten Code zurückführen, den der Entwickler nie überprüft hat.securityaffairs+1

Das LLM hinterließ überall seine Fingerabdrücke

Die Beweise für die Beteiligung eines LLM sind umfangreich. Rohe Chain-of-Thought-Überlegungen wurden wortwörtlich in den Kommentaren der Quelldateien im gesamten Code hinterlassen, einschließlich Zeilen wie „// I created them so I should know?“ und „// Wait, where is the command?“ – ein LLM, das seine eigene Verwirrung kommentiert und in einem funktionierenden Botnetz konserviert wurde. Jede der etwa 60 C-Quelldateien trägt einen identischen Header-Hinweis, dass „dieser Code nur für Bildungszwecke und autorisierte Sicherheitsforschung bestimmt ist“.unit42.paloaltonetworks+1

Der folgenschwerste Fehler des LLM befindet sich im C2-Authentifizierungsmodul. Der Entwickler bat um Argon2id-Passwort-Hashing. Das LLM konnte die korrekte Bibliothek nicht importieren, griff auf SHA-256-Schleifen zurück, die PBKDF2 ähneln, behielt aber die Argon2id-Kommentare, Konstanten und das Ausgabeformat bei – eine Halluzination, die als Produktionscode ausgeliefert wurde.securityaffairs+1

Ein während der Entwicklung eingeführter XOR-Schlüssel-Fehler unterbricht den IRC-Fallback-C2-Kanal, vier Exploit-Payloads und das HTTP-Polling. Eine benutzerdefinierte Exploit-VM startet nie, weil der Go-Compiler einen Datei-Magic-Wert schreibt, während die C-Laufzeitumgebung einen anderen erwartet.unit42.paloaltonetworks

Eine behebbare Bedrohung, die mit einem bekannten Ökosystem verknüpft ist

Unit 42 warnte, dass die Fehler leicht zu korrigieren seien. „Wir konnten diese Probleme mit einer Handvoll LLM-gestützter Prompts beheben“, schrieben die Forscher und fügten hinzu, dass im April 2026 sechs neue produktionskompilierte Samples auftauchten, was darauf hindeutet, dass wahrscheinlich bereits eine ausgefeiltere Version existiert.securityaffairs+1

Gemeinsame Infrastruktur verbindet TuxBot mit dem Keksec-Ökosystem, einer Gruppe, die dafür bekannt ist, mehrere IoT-Botnetz-Varianten parallel zu betreiben. Ein Dropper-Server auf FlokiNET, einem in Island ansässigen Bulletproof-Hosting-Anbieter, bedient sowohl TuxBot-Payloads als auch Kaitori v3.9-Binärdateien, während das Git-Log des Entwicklers einen Hostnamen enthüllte, der mit einer im Iran gehosteten Maschine verknüpft ist.unit42.paloaltonetworks+1

Der Entwicklungszeitplan reicht bis Januar 2025 zurück, als der Entwickler das Open-Source-Toolkit MHDDoS von GitHub klonte. „Eine voll funktionsfähige Version dieses Frameworks ist keine theoretische Sorge, sondern eine wahrscheinliche Bedrohung“, schloss Unit 42.unit42.paloaltonetworks