TuxBot v3 Evolution usa gli LLM per costruire una botnet IoT multi-architettura

🛡️ Executive Summary

• TuxBot combina agente C, server C2 in Go, exploit VM e build multi-architettura per infettare dispositivi IoT tramite Telnet, SSH, HTTP e ADB.
• Il codice mostra tracce evidenti di sviluppo assistito da LLM, comprese funzioni crittografiche allucinate, ragionamenti grezzi e disclaimer rimasti nei sorgenti.
• Il nucleo operativo consente scansione, persistenza e DDoS; credenziali predefinite, Telnet esposto e firmware obsoleti restano i principali vettori difensivi.

TuxBot v3 Evolution è un framework botnet per dispositivi IoT costruito con il supporto di un modello linguistico di grandi dimensioni e progettato per trasformare router, gateway, telecamere e sistemi embedded in nodi utilizzabili per attacchi DDoS. Il codice sorgente recuperato comprende un agente scritto in C, un server di comando e controllo in Go, una macchina virtuale dedicata agli exploit e ambienti Docker e QEMU per testare il malware su differenti architetture. Il progetto contiene errori riconducibili alle allucinazioni dell’AI, ma il flusso principale di infezione, persistenza, collegamento al C2 ed esecuzione degli attacchi risulta funzionante.

TuxBot supporta diciassette architetture e un’infrastruttura completa

L’agente bot di TuxBot può essere compilato per ARM, MIPS, x86_64, PowerPC, RISC-V e numerose varianti utilizzate nei dispositivi embedded. Il supporto dichiarato raggiunge diciassette architetture, permettendo agli operatori di produrre rapidamente payload adatti a router domestici, apparati industriali, decoder, telecamere e appliance di rete. Il server C2 scritto in Go utilizza più listener TCP: il canale principale opera sulle porte 1999 o 31337, gestisce il protocollo dei bot e supporta anche un’interfaccia amministrativa binaria riconoscibile attraverso un header dedicato; un secondo listener espone invece una shell SSH sulla porta 2222, dalla quale gli operatori possono controllare il numero di dispositivi connessi e avviare campagne DDoS. L’archivio contiene inoltre 61 file sorgente C++, 58 header, un compilatore personalizzato, configurazioni Docker Compose e ambienti QEMU per verificare automaticamente le build.

Questa struttura colloca TuxBot nella stessa evoluzione osservata con RustDuck, botnet capace di combinare loader Rust e funzioni DDoS e con C0xMo, framework multi-architettura rivolto ai router DD-WRT: il malware IoT moderno non è più un singolo binario derivato da Mirai, ma una piattaforma completa di sviluppo, distribuzione, test e monetizzazione.

L’LLM accelera lo sviluppo ma introduce errori e codice incoerente

I sorgenti mostrano che gli autori hanno utilizzato un LLM per generare moduli C, convertire exploit, costruire parti del server C2 e implementare funzioni crittografiche. Nel codice sono rimasti ragionamenti prodotti dal modello, commenti discorsivi e persino un disclaimer di sicurezza che avrebbe dovuto impedire un utilizzo malevolo. Alcune implementazioni risultano errate o incomplete: primitive crittografiche non conformi, funzioni che richiamano parametri inesistenti e moduli di exploit incapaci di completare correttamente la catena di infezione.

Questi difetti non impediscono però il funzionamento delle componenti centrali, perché scansione, brute force, persistenza, connessione al server primario e attacchi DDoS sono operativi. L’aspetto più preoccupante riguarda la facilità di correzione: prompt più precisi rivolti allo stesso modello possono risolvere molte delle anomalie lasciate nella prima versione. TuxBot conferma quindi quanto già emerso con VoidLink, framework malware AI-driven sviluppato in modo modulare e con le analisi di Google sugli hacker che usano l’intelligenza artificiale per creare malware e accelerare la ricerca di vulnerabilità. L’AI non rende automaticamente sofisticato un attore inesperto, ma riduce il tempo necessario per assemblare codice proveniente da famiglie differenti e produrre iterazioni successive.

Brute force Telnet ed exploit IoT alimentano il processo di infezione

Il vettore principale utilizza il brute force degli accessi Telnet attraverso una lista di 1.496 combinazioni di username e password, molte delle quali corrispondono a credenziali predefinite o ricorrenti nei dispositivi consumer. Il framework integra anche scanner per SSH, HTTP e Android Debug Bridge, ampliando la superficie verso TV box, gateway e sistemi con porte amministrative esposte. Nel codice sono presenti exploit destinati a più di trenta famiglie di dispositivi IoT, anche se i tre motori principali non risultano pienamente funzionanti nella build recuperata.

Uno scanner aggiuntivo tenta di scaricare il payload da un indirizzo hard-coded ormai inattivo, dimostrando che almeno parte dell’infrastruttura era stata predisposta per operazioni reali. Dopo l’accesso iniziale, il malware installa il binario compatibile con l’architettura, configura la persistenza e mostra sulla console la stringa “Infected By Akiru.”. La dipendenza da Telnet resta significativa perché milioni di dispositivi continuano a utilizzare firmware datati, servizi amministrativi esposti e password non modificate. Lo stesso modello è stato osservato in XlabsV1, botnet Mirai che sfrutta ADB per offrire DDoS a noleggio e in Masjesu, botnet stealth capace di colpire router e gateway con attacchi fino a 290 Gbps. La protezione richiede quindi la disattivazione dei servizi inutilizzati, il cambio delle credenziali di fabbrica, l’isolamento delle reti IoT e il blocco delle interfacce amministrative provenienti da Internet.

DGA, peer-to-peer e canali alternativi rendono resiliente il comando e controllo

TuxBot utilizza un canale TCP cifrato per ricevere istruzioni e inviare informazioni al C2 principale, ma integra numerosi sistemi di fallback. Un algoritmo di generazione dei domini basato su SHA-512 produce indirizzi alternativi; un protocollo gossip peer-to-peer distribuisce comandi firmati con Ed25519; IRC, query DNS TXT, polling HTTP, BitTorrent DHT e meccanismi libp2p forniscono ulteriori percorsi di comunicazione. Questa ridondanza riduce l’efficacia del sequestro di un singolo server e permette alla botnet di ricostruire il contatto anche dopo blocchi DNS o rimozioni dell’hosting. Il pannello amministrativo include funzioni di DDoS-for-hire e l’archivio contiene 254 benchmark automatizzati eseguiti contro target Docker, con misurazioni di throughput, pacchetti al secondo ed errori per dodici metodi di attacco. La commercializzazione della capacità DDoS richiama l’evoluzione di Aisuru, botnet TurboMirai capace di generare traffico superiore a 20 Tbps e dei servizi booter colpiti dalle recenti operazioni PowerOFF. Anche se alcune funzioni crittografiche di TuxBot risultano imperfette, la molteplicità dei canali aumenta notevolmente il costo delle attività di takedown.

Le tracce infrastrutturali collegano TuxBot agli ecosistemi Mirai e Keksec

La cronologia Git indica che lo sviluppo è iniziato almeno il 3 gennaio 2025, quando l’autore ha clonato il progetto open source MHDDoS. Il nome della workstation newtuxdev.sevielw.digikalas.online, la registrazione del dominio digikalas.online e la risoluzione verso infrastrutture Arvan Cloud suggeriscono un ambiente di sviluppo localizzato in Iran, pur senza dimostrare automaticamente la nazionalità o l’identità dell’operatore. I test DDoS più intensi risalgono ai primi giorni di gennaio 2026, mentre una build debug x86_64 con simboli e C2 impostato su loopback è stata caricata su VirusTotal il 20 gennaio 2026.

A marzo è comparso un server con banner SSH-2.0-CNC-Control-Server, seguito in aprile da sei campioni compilati per architetture differenti. L’indirizzo 185.10.68.127 presente nei sorgenti collega inoltre il framework a infrastrutture associate agli ecosistemi Keksec o Kaitori. Il codice contiene elementi provenienti da Mirai, Gafgyt, Tsunami, AISURU e da lignaggi Wuhan meno documentati, dimostrando una strategia di assemblaggio più che uno sviluppo completamente originale. Questa continuità conferma quanto osservato con ShadowV2, botnet cloud-native evoluta dai codici Mirai: gli autori combinano moduli pubblici, exploit riutilizzati e componenti generati dall’AI per abbreviare il ciclo tra sviluppo, test e distribuzione.

Difese e indicatori devono concentrarsi sui dispositivi e sul traffico

Gli operatori di rete devono cercare connessioni in uscita verso porte 1999, 31337 e 2222, traffico DNS TXT anomalo, domini generati algoritmicamente, comunicazioni IRC inattese e attività peer-to-peer provenienti da dispositivi che normalmente non utilizzano questi protocolli. Sul dispositivo possono comparire processi sconosciuti, servizi di persistenza, modifiche agli script di avvio e il banner “Infected By Akiru.”, ma l’assenza della stringa non esclude l’infezione. Le misure prioritarie comprendono aggiornamento del firmware, sostituzione delle password predefinite, disabilitazione di Telnet e ADB, segmentazione VLAN, limitazione dell’accesso amministrativo e monitoraggio del traffico laterale. I dispositivi non più supportati dovrebbero essere sostituiti o isolati perché non possono ricevere correzioni per gli exploit incorporati nel framework. TuxBot v3 Evolution dimostra che l’uso di un LLM può produrre codice difettoso ma comunque sufficiente a sostenere una botnet operativa: la barriera d’ingresso si abbassa, mentre la modularità permette agli operatori più esperti di correggere rapidamente le componenti mancanti e distribuire varianti più mature.