Tengu evolve Mirai con proxy, IPFS e persistenza aggressiva

🛡️ Executive Summary

• Tengu combina il codice DDoS di Mirai con un protocollo C2 cifrato, proxy SOCKS5, aggiornamenti remoti e raccolta di dati di sistema.
• Il malware tenta di sopravvivere attraverso servizi systemd e init.d, esecuzione fileless, processi guardian e abuso del watchdog hardware.
• I payload vengono distribuiti tramite Telnet e IPFS verso più architetture Linux, con un supporto sperimentale per dispositivi Android.

Tengu è una nuova famiglia malware per dispositivi IoT e sistemi Linux embedded derivata da Mirai, ma progettata per svolgere funzioni molto più ampie rispetto ai tradizionali attacchi DDoS. Il malware integra comunicazioni cifrate, proxy SOCKS5, aggiornamenti remoti, raccolta delle informazioni di rete e download di ulteriori payload attraverso IPFS. Nozomi Networks ha inoltre individuato diversi meccanismi di persistenza e autodifesa, tra cui esecuzione fileless, servizi systemd contraffatti, processi guardian e manipolazione del watchdog hardware. L’obiettivo non è soltanto utilizzare router e dispositivi vulnerabili per generare traffico, ma trasformarli in nodi persistenti per proxy, ricognizione e distribuzione di nuovo codice.

Tengu conserva Mirai ma amplia il controllo dei dispositivi

I campioni analizzati da Nozomi Networks Labs mantengono diversi elementi riconducibili a Mirai, tra cui la registrazione iniziale dei bot, la cifratura runtime delle stringhe e parte del codice impiegato per gli attacchi denial of service. Tengu aggiunge però un livello operativo più moderno, perché il sistema infetto può raccogliere informazioni sul kernel, sulla memoria, sui processi, sulle interfacce di rete, sul gateway e sui server DNS, eseguire comandi arbitrari e restituirne l’output al server di controllo. Il malware può inoltre avviare un proxy SOCKS5 configurabile, trasformando il dispositivo in un punto di uscita utilizzabile per nascondere scansioni, frodi o accessi verso altre infrastrutture. Questa evoluzione segue il percorso già osservato con TuxBot v3 Evolution e la sua botnet IoT multi-architettura, dove il valore di una rete compromessa non dipende più esclusivamente dalla potenza DDoS, ma dalla capacità di offrire accesso persistente e funzioni modulari.

Il dropper entra attraverso Telnet e sceglie l’architettura

Il campione intercettato dagli honeypot veniva consegnato dopo tentativi di brute force contro il servizio Telnet. Una volta ottenuto l’accesso, un semplice script shell scaricava via HTTP il binario compatibile con l’architettura del dispositivo e lo eseguiva. La ricerca ha identificato versioni per x86, AMD64, ARM, MIPS, PowerPC e m68k, confermando l’obiettivo di colpire una gamma molto ampia di router, gateway, telecamere e sistemi embedded. Il server usato per distribuire i file coincideva con l’infrastruttura di comando e controllo, mentre l’indirizzo C2 veniva deoffuscato a runtime tramite XOR. Il malware contiene anche una logica simile a un domain generation algorithm basata sull’orario e su più domini di primo livello, anche se Nozomi non ne ha osservato l’utilizzo operativo. La propagazione attraverso credenziali deboli resta quindi rudimentale, ma conduce a un impianto molto più complesso rispetto alle prime varianti Mirai. Lo stesso divario tra accesso iniziale elementare e capacità successive sofisticate caratterizzava C0xMo, botnet che trasformava router DD-WRT in nodi DDoS multi-architettura.

Il comando e controllo usa cifratura autenticata

Tengu invia in chiaro il pacchetto iniziale di registrazione, gli heartbeat e parte dell’output prodotto dai comandi, ma protegge le istruzioni dirette ai bot e i messaggi di aggiornamento attraverso uno schema simile a ChaCha20-Poly1305. La chiave è incorporata nel binario e può essere ricostruita combinando due valori da 32 byte, scelta che impedisce a un osservatore passivo di interpretare immediatamente i comandi ma non offre una protezione reale quando il campione viene analizzato. Dopo aver estratto la chiave e studiato le differenze rispetto all’implementazione standard, i ricercatori sono riusciti a redirigere il bot verso un C2 controllato e a interagire con il malware in laboratorio. L’adozione di cifratura autenticata distingue Tengu da molte varianti Mirai che utilizzano protocolli semplici e facilmente decodificabili, rendendo più difficile costruire firme basate sul contenuto dei pacchetti. Il server può ordinare al bot di avviare o fermare proxy e attacchi, eseguire comandi, raccogliere dati e installare meccanismi di persistenza.

Venticinque modalità DDoS colpiscono reti e server di gioco

Il malware registra 25 metodi di attacco, comprendenti flood UDP con sorgenti contraffatte, pacchetti TCP SYN, ACK e PSH, ICMP echo e modalità miste. Accanto agli attacchi volumetrici generici compaiono funzioni rivolte a HTTP, DNS, NTP, SNMP, SIP, SSH, SMTP e FTP, oltre a protocolli utilizzati da server Source Engine, Quake e Minecraft. Questa combinazione permette agli operatori di colpire sia infrastrutture di rete sia servizi applicativi specifici, con una particolare attenzione verso il settore gaming. Tengu non introduce necessariamente tecniche DDoS inedite, ma le concentra in un singolo agente che può essere aggiornato e riconfigurato a distanza. La disponibilità di un proxy e dell’esecuzione remota dei comandi consente inoltre di utilizzare gli stessi dispositivi per attività differenti tra una campagna e l’altra. Il modello si avvicina alle botnet più recenti, come Masjesu e i suoi attacchi DDoS stealth contro router e gateway, nelle quali il traffico offensivo rappresenta soltanto una parte dell’infrastruttura criminale.

IPFS distribuisce nuovi payload Linux e Android

Tra i comandi più insoliti compare il download di payload attraverso un gateway IPFS codificato direttamente nel malware. Il C2 invia un content identifier e Tengu recupera il file, lo salva temporaneamente in un percorso nascosto e controlla se il contenuto sia un eseguibile ELF oppure un pacchetto APK. Nel primo caso avvia il binario sul sistema Linux; nel secondo tenta di installare e aprire l’applicazione Android. Questa seconda funzione potrebbe essere destinata a TV box o altri dispositivi Android scarsamente protetti, anche se Nozomi non ha confermato l’uso del meccanismo durante le campagne osservate. Un canale separato permette inoltre di aggiornare direttamente il bot: un messaggio cifrato contenente il valore 0xDEAFBEEF induce il malware a scrivere il nuovo eseguibile in /tmp/.up e sostituire il processo corrente. IPFS offre agli operatori un sistema di distribuzione meno dipendente da un singolo server web e può rendere più difficile rimuovere rapidamente i payload, strategia già sfruttata in altre campagne come DeadVax, che utilizzava IPFS per portare AsyncRAT in memoria.

Il malware usa più livelli di persistenza

Tengu tenta di installarsi attraverso falsi servizi systemd, script init.d, file rc.local, configurazioni procd e modifiche ai profili shell. Una funzione dedicata prova anche ad aggiungere una voce cron, ma l’implementazione appare incompleta perché richiama /proc/self/exe dal contesto del processo che dovrebbe eseguire il comando, senza garantire il riferimento al binario installato. Il malware può applicare l’attributo immutabile al proprio file, rendendone più difficile la cancellazione, e avviare un processo guardian separato che controlla ogni sessanta secondi la presenza dell’istanza principale. Quando il processo viene terminato, il guardian tenta di riavviarlo. La persistenza ridondante è significativa perché molti dispositivi IoT vengono considerati ripuliti dopo un semplice riavvio; Tengu prova invece a trasformare il reboot in un’opportunità per ripristinare il malware attraverso i servizi registrati nel sistema.

Il watchdog hardware viene trasformato in un’arma

Una delle funzioni più aggressive riguarda la gestione del watchdog. Tengu disabilita temporaneamente i meccanismi esistenti, avvia un processo in background mascherato come kworker/0:0 e riapre il dispositivo watchdog con un timeout di circa trenta secondi. Il processo invia segnali di keepalive soltanto mentre il malware principale rimane attivo. Se un amministratore termina l’impianto, il worker smette di alimentare il watchdog e lascia che il dispositivo si riavvii automaticamente, consentendo ai meccanismi di persistenza di rilanciare l’infezione. Il malware contiene inoltre una lista di binari collegati a reboot e shutdown e può sovrascriverne l’intestazione ELF con la stringa ELFOOD, danneggiando gli strumenti che il difensore potrebbe usare per spegnere o riavviare correttamente il sistema. Tengu trasforma così una funzione progettata per aumentare l’affidabilità dell’hardware in un sistema anti-remediation capace di ostacolare la risposta all’incidente.

L’esecuzione fileless imita systemd-journald

Quando viene avviato da disco, Tengu tenta di copiare il proprio eseguibile in una regione anonima creata con memfd_create. Se la funzione non è disponibile, utilizza un file nella memoria condivisa /dev/shm, lo apre e lo elimina mantenendo il descrittore attivo. Il malware viene quindi rieseguito dalla memoria con il nome /usr/lib/systemd/systemd-journald, inducendo strumenti basati sulla command line a mostrarlo come un processo legittimo. L’impianto ignora diversi segnali di terminazione, disabilita i core dump e assegna a sé stesso un valore oom_score_adj pari a -1000 per evitare che il kernel lo selezioni quando la memoria è insufficiente. Controlla inoltre TracerPid, variabili come LD_PRELOAD, ritardi anomali rilevati tramite rdtsc e modifiche alle proprie aree eseguibili. Questi controlli non rendono impossibile l’analisi, ma mostrano una cura insolita per una famiglia Mirai e spiegano perché Nozomi abbia deciso di classificarla come una nuova linea evolutiva.

Tengu elimina i malware concorrenti

I dispositivi IoT esposti vengono spesso contesi da più botnet e Tengu cerca di mantenere il controllo attraverso un ciclo continuo di eliminazione dei processi rivali. Il malware scandaglia /proc, confronta percorso, nome e command line con una lista interna e termina con SIGKILL i programmi riconducibili a famiglie concorrenti. Il controllo non si limita a una scansione periodica: Tengu osserva la creazione dei processi attraverso il connector Linux e un monitoraggio inotify della directory /proc, reagendo ogni mezzo secondo circa. Le applicazioni legittime presenti in una allowlist vengono ignorate, mentre i processi sospetti e i relativi discendenti vengono eliminati. Questo comportamento protegge le risorse della macchina, impedisce che un’altra botnet sostituisca l’infezione e riduce la possibilità che tool di remediation poco specifici rimangano attivi abbastanza a lungo da rimuovere il malware.

I dispositivi infetti richiedono una bonifica completa

La ricerca tecnica di Nozomi Networks su Tengu mostra che il semplice riavvio non può essere considerato una bonifica affidabile. Gli amministratori devono disabilitare Telnet, sostituire tutte le credenziali predefinite, aggiornare il firmware e isolare i dispositivi embedded dalle reti aziendali più sensibili. In presenza di un’infezione occorre verificare servizi systemd, script init.d, file di avvio, profili shell, processi mascherati e attributi immutabili, controllando anche eventuali modifiche ai binari di shutdown e reboot. Connessioni inattese verso il C2, attività SOCKS5, download IPFS e processi mostrati come systemd-journald su apparati che non dovrebbero eseguirlo costituiscono indicatori rilevanti. Quando non è possibile ristabilire con certezza l’integrità del firmware e del filesystem, la scelta più sicura resta il ripristino completo o la sostituzione del dispositivo. Tengu dimostra che Mirai non è più soltanto una base per generare DDoS: può diventare un impianto persistente, aggiornabile e capace di trasformare ogni dispositivo compromesso in proxy, downloader e punto d’appoggio resistente alla rimozione.