Kimwolf v7 usa HTTP/2, Ethereum e Tor per rafforzare la botnet Android

🛡️ Executive Summary

• Kimwolf v7 aggiunge flood HTTP/2 capaci di imitare fingerprint Chrome completi, rendendo il traffico DDoS applicativo più simile alla navigazione legittima.
• Il C2 usa cinque endpoint Ethereum RPC, domini ENS, un hidden service Tor e un proxy locale per resistere alla rimozione dell’infrastruttura.
• La propagazione viene separata dal bot: loader esterni sfruttano soprattutto istanze ADB non autenticate su Android TV box e set-top box.

Kimwolf v7 trasforma una botnet già estesa in una piattaforma DDoS più specializzata, resiliente e difficile da distinguere dal traffico reale. Unit 42 ha individuato la nuova variante il 3 febbraio 2026 durante attività di threat hunting successive alle disclosure che avevano documentato la crescita della famiglia tra Android TV box e dispositivi IoT. La versione 7 introduce un flood HTTP/2 con fingerprint del browser, rafforza il comando e controllo attraverso Ethereum Name Service, endpoint RPC pubblici, Tor e proxy locali e rimuove dal payload principale scanner, exploit e brute force. La scelta indica una separazione più netta dei ruoli: strumenti esterni gestiscono l’infezione, mentre Kimwolf si concentra su DDoS e relay di rete.

Kimwolf nasce da AISURU e passa dagli IoT ad Android

La famiglia è attiva almeno dall’agosto 2024. Unit 42 distingue due codebase sotto gli stessi operatori: AISURU per le precedenti varianti Linux IoT e Kimwolf per il ramo Android, diventato predominante intorno all’agosto 2025. Il vettore più importante contro Android TV box e set-top box consiste nell’abuso di servizi proxy residenziali per raggiungere istanze Android Debug Bridge esposte nelle reti locali. Alcuni dispositivi vengono distribuiti con ADB attivo sulla porta TCP 5555 senza autenticazione; attraversando un nodo proxy già presente nella rete, gli operatori possono quindi installare il malware senza conoscere credenziali. La ricerca originale di Unit 42 su Kimwolf v7 descrive il campione principale come un ELF ARM staticamente linkato, compilato con Android NDK e dotato di BoringSSL e nghttp2. Il modello si inserisce nella crescente esposizione dei dispositivi embedded già osservata con Tengu, evoluzione Mirai dotata di proxy, IPFS e persistenza aggressiva.

Il flood HTTP/2 imita il comportamento di Chrome

La novità offensiva più evidente è il metodo attack_case17_http2_flood, costruito sulla libreria nghttp2. A differenza dei flood applicativi più semplici, Kimwolf v7 genera richieste dotate di fingerprint completi del browser, riproducendo header e caratteristiche coerenti con client Chrome e altri browser reali. Lo scopo è ridurre la distanza tra traffico DDoS e navigazione legittima, complicando mitigazioni basate su pattern troppo rigidi o su richieste HTTP palesemente anomale. Unit 42 attribuisce proprio a questa capacità uno dei maggiori miglioramenti della variante v7, perché l’attacco avviene al livello applicativo e può quindi costringere CDN, reverse proxy e sistemi anti-DDoS a distinguere connessioni malevole che formalmente assomigliano a sessioni browser corrette. È un’evoluzione coerente con la crescita delle botnet IoT commerciali già osservata con Masjesu, capace di combinare diversi vettori DDoS e picchi fino a 290 Gbps.

Quindici metodi DDoS coprono dal livello 3 al livello 7

Kimwolf v7 dispone complessivamente di 15 modalità di attacco, distribuite tra livelli rete, trasporto e applicazione. Sono presenti TCP socket flood, più varianti UDP, query flood DNS, SYN, ACK, SYN-ACK e RST flood, ICMP, connessioni TCP asincrone, TLS/HTTPS e infine HTTP/2. Una funzione UDP dedicata è stata ottimizzata specificamente per i processori ARM dei TV box: utilizza un PRNG Xorshift256 alimentato da /dev/urandom e sfrutta istruzioni ARM NEON SIMD per velocizzare il calcolo dei checksum IP e UDP.

L’obiettivo è diminuire l’overhead per pacchetto e aumentare il throughput ottenibile su hardware consumer relativamente economico. Rispetto alle varianti precedenti, che esponevano decine di metodi nominati, gli sviluppatori hanno quindi consolidato la superficie offensiva attorno a un numero minore di funzioni più specializzate.

Ethereum ENS rende il C2 più difficile da bloccare

Il secondo grande cambiamento riguarda il command and control. Il binario contiene cinque endpoint Ethereum RPC pubblici e legittimi, utilizzati per interrogare record Ethereum Name Service e recuperare gli indirizzi del C2. Gli endpoint vengono randomizzati prima di ogni tentativo, creando ridondanza: bloccarne uno non impedisce al malware di provare gli altri quattro. Unit 42 raccomanda per questo di non bloccare indiscriminatamente i servizi Ethereum pubblici, che possono essere utilizzati anche da applicazioni legittime, ma di cercare invece traffico RPC Ethereum anomalo proveniente da Android TV box e dispositivi IoT che normalmente non interagiscono con blockchain. Una strategia analoga di infrastruttura distribuita era già emersa con Dysphoria, botnet che utilizza domini ENS e SNS per rendere dinamica la risoluzione dei propri C2.

Un endpoint RPC potrebbe essere controllato direttamente dagli operatori

Durante l’analisi infrastrutturale Unit 42 ha individuato anche eth.rpcuniverse[.]com, endpoint differente dai cinque servizi pubblici presenti nel campione di riferimento. I ricercatori valutano con moderata confidenza che possa trattarsi di una facade RPC controllata dagli operatori. L’attribuzione non è definitiva, ma diversi elementi la rendono plausibile: il dominio non presenta il profilo dei grandi provider RPC, risolve verso un singolo VPS economico, l’host appare single-tenant e il dominio compare direttamente in alcuni binari Kimwolf sia ELF sia APK. Unit 42 precisa esplicitamente di non poter confermare la proprietà dell’infrastruttura, evitando quindi di trasformare il clustering tecnico in un’attribuzione certa.

Tor entra in funzione quando Ethereum non basta

Se la risoluzione ENS fallisce, Kimwolf v7 dispone di un secondo livello di continuità operativa: un hidden service Tor v3 hardcoded. Il malware implementa una state machine SOCKS per collegarsi al servizio .onion, effettuare il tunnel e avviare successivamente una sessione TLS. Tutto il traffico C2, sia verso clearnet sia verso Tor, viene inoltre instradato attraverso un proxy locale sulla porta 23075 di localhost. Questa architettura rende il componente proxy separabile dal bot principale e quindi aggiornabile indipendentemente. Unit 42 interpreta il design come una risposta diretta ai takedown che avevano colpito l’infrastruttura Kimwolf due volte nel dicembre 2025. Il principio è simile a quello osservato nelle botnet più mature: non affidarsi a un singolo dominio o IP, ma distribuire la risoluzione su servizi difficili da rimuovere simultaneamente.

Ventidue server condividono la stessa chiave SSH

L’analisi dei server ha permesso a Unit 42 di identificare un ulteriore cluster infrastrutturale. Diversi indirizzi utilizzati dal C2 presentavano la stessa chiave host SSH. Il pivot su quell’impronta ha portato a 22 indirizzi IP nello stesso range, comparsi tra il 18 dicembre 2025 e il 3 febbraio 2026. Tutti appartenevano ad AS202799 ed erano geolocalizzati a San Pietroburgo, in Russia. Il primo host osservato con la chiave condivisa risale al 18 dicembre e gli altri sono comparsi progressivamente nelle sei settimane successive. Il dato collega tecnicamente i server tra loro, ma non dimostra da solo né la nazionalità né la localizzazione degli operatori: indica semplicemente che l’infrastruttura C2 utilizzata in quella fase era concentrata nello stesso autonomous system.

Scanner ed exploit spariscono dal payload principale

Una delle modifiche più indicative rispetto alle precedenti versioni è ciò che Kimwolf v7 non contiene più. Unit 42 non trova nel nuovo bot le funzioni di scanning, exploitation e brute force presenti nelle generazioni precedenti. Il payload sembra quindi destinato esclusivamente a DDoS e proxy relay, lasciando a loader e infrastrutture separate il compito di compromettere nuovi dispositivi. È una scelta di specializzazione che può rendere più semplice l’aggiornamento della botnet: se cambia il vettore iniziale, gli operatori possono sostituire soltanto il loader senza modificare l’intero modulo DDoS. Lo stesso processo di industrializzazione si osserva in botnet come SSHStalker, dove scanning, accesso, persistenza e controllo vengono affidati a componenti distinti.

Le varianti APK mascherano il malware da servizio Android

Accanto ai binari ELF standalone, gli operatori distribuiscono APK Android che incorporano il payload ELF all’interno di un wrapper Java. Unit 42 ha identificato otto campioni tra ottobre e dicembre 2025. Le applicazioni si presentano come SystemService, verificano la disponibilità dei privilegi root e successivamente avviano l’ELF incluso nel pacchetto. Nel corso dei mesi cambiano nomi dei package, certificati di firma e nomi del payload, compreso libdevice.so, che in una fase rinomina il processo in TVHelper per confondersi con un servizio apparentemente plausibile su un televisore Android. I campioni più antichi raccontano anche l’evoluzione della famiglia: un ELF x86 osservato nel settembre 2025 richiama Dirty COW, CVE-2016-5195, indicando che il progetto era inizialmente più vicino alla compromissione Linux tradizionale prima di spostarsi sull’ecosistema ARM e Android.

Il processo netd_service cerca di confondersi nel sistema

La variante v7 analizzata da Unit 42 si presenta in memoria con il nome netd_service, scelto per ricordare componenti Android legittimi legati alla rete. Il binario crea inoltre un Unix domain socket dedicato per assicurarsi che sul dispositivo venga eseguita una sola istanza. Questi elementi non rappresentano tecniche di evasione particolarmente sofisticate se considerati isolatamente, ma sono efficaci su dispositivi IoT e TV box nei quali il monitoraggio dei processi è spesso minimo o inesistente. È questo uno dei vantaggi strutturali delle botnet embedded: molti apparati restano accesi continuamente, ricevono pochi controlli di sicurezza e possono mantenere una compromissione per lunghi periodi senza produrre sintomi immediatamente visibili all’utente.

ADB aperto resta il punto da chiudere per primo

La mitigazione prioritaria indicata da Unit 42 consiste nel disabilitare ADB quando non è necessario oppure limitarlo all’accesso USB, eliminando così il principale vettore di propagazione osservato per Kimwolf. Le organizzazioni dovrebbero inoltre trattare Android TV box e set-top box come dispositivi non attendibili e segmentarli dalle reti enterprise. Sul piano della detection, diventano rilevanti connessioni HTTPS da dispositivi IoT verso endpoint Ethereum RPC, traffico Tor o SOCKS5 inatteso, comunicazioni verso 127.0.0.1:23075 e la presenza anomala di un processo netd_service. Questo approccio è particolarmente importante negli ambienti dove apparati consumer e sistemi aziendali convivono sulla stessa LAN, scenario che permette a un proxy residenziale compromesso di trasformare una superficie apparentemente interna in un percorso raggiungibile dall’esterno.

Kimwolf v7 separa infezione, C2 e potenza DDoS

L’evoluzione più importante di Kimwolf v7 non è quindi il semplice aumento del numero di pacchetti che può generare. Gli operatori stanno separando il ciclo operativo in livelli indipendenti: loader esterni gestiscono l’accesso iniziale, il bot ARM si concentra sugli attacchi DDoS, Ethereum ENS risolve l’infrastruttura, Tor fornisce un fallback e il proxy locale astrae il percorso di comunicazione. Il flood HTTP/2 completa il modello cercando di rendere il traffico applicativo più simile a quello prodotto da browser reali.

Unit 42 descrive quindi una botnet che ha reagito ai takedown non ricostruendo semplicemente altri server, ma ridisegnando la resilienza del C2. Nel panorama già popolato da botnet IoT che integrano proxy, DDoS e tecniche di persistenza sempre più complesse, Kimwolf mostra un passaggio ulteriore: il dispositivo infetto non è più soltanto un nodo che genera traffico, ma una componente intercambiabile di un’infrastruttura distribuita progettata per continuare a funzionare anche quando una parte viene rimossa.