Ricevi DeafLetter
Una selezione settimanale di segnali, vulnerabilità e guide. Gli avvisi critici restano facoltativi.
Puoi cancellarti in ogni momento. Privacy policy.
Kaspersky ha rivelato il primo malware con infection chain dedicata alle head unit automobilistiche Android, scoperto il 21 agosto su dispositivi aftermarket del vendor cinese DoFun. Il codice sfrutta l'app di sistema privilegiata TWCore — progettata per aggiornamenti firmware — per infiltrare veicoli in una botnet proxy monetizzata dal MoYu Group. Il veicolo non manifesta anomalie di guida: diventa silenziosamente un nodo di relay traffico, sfruttando la connettività cellulare e WiFi onboard.
- Il malware è il primo documentato con infection chain specifica per head unit auto, non adattamento di codice IoT generico.
- L'ingresso avviene tramite TWCore, app di sistema legittima che riceve comandi da broker MQTT su cardoor[.]cn, abusando il flag installNotExists per installare APK arbitrari.
- La catena multi-stadio (JarService → loader → payload finale) si conclude con il modulo proxy "zhima" che converte il veicolo in relay di traffico.
- Kaspersky attribuisce l'attività con alta confidenza al MoYu Group, identificato da Human Security come sviluppatore della backdoor BADBOX 2.0.
Come TWCore diventa il canale d'ingresso nel veicolo
La superficie di attacco non è una vulnerabilità di Android AOSP bensì un'app di sistema del vendor: TWCore, distribuita su head unit DoFun con privilegi elevati per gestire aggiornamenti firmware. Secondo l'analisi tecnica di Kaspersky SecureList, l'app si registra come servizio persistente e stabilisce una connessione a un broker MQTT ospitato su cardoor[.]cn.
Il meccanismo di compromissione si articola in due passaggi documentati. TWCore riceve messaggi con flag installNotExists, normalmente destinato a installare componenti firmware mancanti. Il malware abusa questo flag per far installare silenziosamente un APK dropper, JarService, privo di interfaccia utente. Il dropper impiega una decrittografia XOR a byte singolo con chiave sequenziale — schema rudimentale ma efficace contro analisi statiche automatizzate — per estrarre il payload successivo.
Da qui la catena multi-stadio documentata: JarService contatta un server C2 per scaricare il loader (stadio 2), che a sua volta recupera il payload finale (stadio 3). Kaspersky ha osservato 7 varianti distinte del payload stadio 3, ottenute modificando il numero di versione nell'URL di download, con configurazione più recente alla versione 3.82.
Il modulo "zhima" e la monetizzazione del veicolo come proxy
Il payload finale stabilisce una comunicazione periodica con il C2 con intervalli di circa 90 minuti, trasmettendo informazioni sul dispositivo e ricevendo comandi in formato JSON. Kaspersky ha identificato 9 comandi supportati dal malware, tra cui funzionalità per display di annunci pubblicitari e ad fraud. Tuttavia, nei campioni analizzati i ricercatori hanno osservato esclusivamente l'esecuzione del comando loadlib2.
Questo comando scarica il modulo denominato "zhima" — classe com.miyc.transfer.Client — che configura il veicolo come relay proxy con parametri IP e porta specificati dal server. Il traffico cellulare o WiFi della head unit viene così monetizzato come infrastruttura proxy residenziale, indistinguibile da quella di qualsiasi dispositivo IoT compromesso. La novità non è il modello di business — consolidato nelle botnet residenziali — bensì il target: un sistema embedded automotive con connettività permanente e spesso trascurato nei programmi di patch management.
"This is the first documented case of malware found on a car head unit with an infection chain specific to that type of device" — Kaspersky SecureList
Attribuzione al MoYu Group e collegamento BADBOX 2.0
L'attribuzione opera su due livelli convergenti. Kaspersky collega il campione analizzato "with high confidence" al MoYu Group, operatore già associato all'ecosistema BADBOX. Human Security, attraverso il team Satori, identifica il MoYu Group come entità che ha "developed the backdoor for BADBOX 2.0, coordinated the variants of that backdoor and operated a botnet composed of a subset of BADBOX 2.0-infected devices". Il gruppo prende nome dai servizi di proxy residenziale offerti agli affiliati.
La convergenza tra le due fonti primarie è significativa: Kaspersky documenta il meccanismo tecnico su head unit DoFun, Human Security conferma che BADBOX 2.0 include esplicitamente "vehicle infotainment units" tra i dispositivi compromessi, con riferimento a una Public Service Announcement dell'FBI datata giugno 2025. BADBOX 2.0 nel suo complesso — principalmente TV box Android compromesse in supply chain — avrebbe coinvolto oltre 10 milioni di dispositivi secondo una causa legale citata da SecurityWeek, con traffico osservato in 222 paesi e territori e impatto su oltre 1 milione di dispositivi consumer secondo Human Security. La scala specifica su head unit automotive non è quantificata nelle fonti disponibili.
Cosa fare adesso
- Verificare la provenienza delle head unit aftermarket: i dispositivi DoFun sono diffusi in Cina e APAC; in flotte o veicoli importati occorre identificarne la presenza.
- Ispezionare il traffico MQTT verso domini sospetti: il broker cardoor[.]cn è indicato da Kaspersky come infrastruttura di comando; la sua risoluzione in reti veicolari segnala compromissione.
- Controllare la presenza di app TWCore o servizi JarService: l'assenza di interfaccia utente rende il dropper invisibile all'utente, rilevabile solo tramite audit dei processi di sistema.
- Richiedere conferma del fix al vendor: SecurityWeek riporta che DoFun è stata notificata e avrebbe corretto il problema, senza che le fonti primarie indichino dettagli sul rilascio o sulla verifica indipendente.
Perché la supply chain automotive è il prossimo confine dell'IoT compromesso
La scoperta segnala un punto di svolta nel targeting botnet: il passaggio da dispositivi domestici statici — TV box, router, telecamere — a sistemi veicolari mobili con connettività persistente. Le head unit aftermarket rappresentano un segmento particolarmente vulnerabile: combinano Android AOSP con privilegi di sistema elevati, meccanismi di aggiornamento spesso non firmati o verificati debolmente, e assenza di oversight tipico del settore automotive OEM.
Per i consumatori l'effetto è asimmetrico: nessun malfunzionamento evidente, nessun warning sul cruscotto, mentre il veicolo trasporta traffico di terzi attraverso la propria connessione dati. Per il settore, il caso evidenzia come la convergenza tra infotainment e sistemi di bordo — già complessa per sicurezza funzionale — si arricchisca di un vettore supply chain finora proprio dell'IoT consumer. Il confine tra "dispositivo Android" e "sistema veicolo" si è rivelato più permeabile di quanto la tassonomia dei risk model automotive presupponga.
Fonti
- https://www.securityweek.com/first-malware-built-specifically-for-car-head-units-fuels-botnet/
- https://securelist.com/android-head-unit-malware/121106/
- https://www.scworld.com/brief/new-malware-targets-android-car-head-units-for-ad-fraud-and-botnet-creation
- https://gbhackers.com/android-malware-campaign/
- https://www.humansecurity.com/learn/blog/satori-threat-intelligence-disruption-badbox-2-0/
- https://podcast.securityweek.com/
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
Ricevi DeafLetter
Una selezione settimanale di segnali, vulnerabilità e guide. Gli avvisi critici restano facoltativi.
Puoi cancellarti in ogni momento. Privacy policy.