Un dispositivo Android collegato al televisore, apparentemente innocuo, può trasformarsi in uno strumento nelle mani dei criminali informatici senza che il proprietario se ne accorga. È quanto emerge dall’operazione internazionale che ha portato allo smantellamento di XCPE (x.cpe), una botnet composta da oltre 1,3 milioni di dispositivi Android, principalmente TV Box e set-top box, distribuiti in più di 200 Paesi. La particolarità dell’attacco è inquietante: il codice malevolo non arrivava attraverso applicazioni scaricate dagli utenti, ma era già presente nel firmware dei dispositivi al momento della vendita.
L’operazione ha coinvolto Google, Lumen, HUMAN Security, Plume, Synthient e TrendAI, in collaborazione con la National Police Agency giapponese. Le indagini hanno individuato il presunto responsabile in Videostrong Technology, produttore cinese con sede a Shenzhen specializzato nella realizzazione di dispositivi Android per diversi marchi commerciali. Secondo Google, l’azienda avrebbe integrato deliberatamente una backdoor nei propri prodotti, commercializzando successivamente l’accesso ai dispositivi compromessi.
La vicenda richiama le operazioni poste in essere contro BADBOX 2.0, rete criminale che nel 2025 aveva coinvolto milioni di dispositivi Android economici. XCPE presenta però una caratteristica particolarmente grave: il produttore accusato aveva in essere una collaborazione con Google e il codice malevolo era riuscito ad aggirare i controlli previsti per la certificazione dei dispositivi.
Come funzionava XCPE: il malware nascosto nel firmware Android
Le analisi pubblicate dal Google Threat Intelligence Group descrivono un’infrastruttura criminale sviluppata e perfezionata almeno dalla fine del 2024. Il malware sfruttava un’architettura modulare, progettata per separare il controllo remoto del dispositivo dalle attività illegali vere e proprie.
Il componente principale, identificato come com.oemservice in alcune versioni, operava con i privilegi associati ad android.uid.system. Una piccola applicazione integrata nel firmware verificava all’avvio la presenza del pacchetto x.cpe e poteva reinstallarlo dalla partizione /oem/ nella directory /data/app/.
La persistenza non dipendeva da una comune applicazione installata dall’utente: il dispositivo disponeva già delle istruzioni necessarie per ripristinare il componente malevolo. Cancellare semplicemente l’applicazione, quindi, non eliminava la compromissione.
Una volta attivo, x.cpe recuperava le impostazioni operative da un server remoto mediante richieste HTTP POST. Le informazioni trasmesse comprendevano identificativi hardware, indirizzo MAC, modello e versione del firmware; il server, a sua volta, restituiva i parametri necessari per stabilire una connessione permanente tramite MQTT (Message Queuing Telemetry Transport), protocollo leggero comunemente utilizzato nelle applicazioni IoT.
Il dispositivo restava in ascolto dei comandi degli operatori. Attraverso il canale MQTT, questi ultimi potevano installare APK senza interazione dell’utente, modificare impostazioni, eseguire comandi shell, acquisire schermate e raccogliere informazioni sulla rete locale.
Google ha documentato anche la sottrazione di dati relativi agli account, ai registri di sistema e alle applicazioni installate.
Il secondo livello dell’attacco: com.abc.nexus e i moduli criminali
Per rendere meno evidente la propria attività, gli sviluppatori avevano progressivamente separato le funzionalità malevole. Il componente x.cpe gestiva prevalentemente le comunicazioni, mentre com.abc.nexus funzionava da motore per caricare ed eseguire altri moduli. Le istruzioni passavano tra i processi attraverso meccanismi IPC (Inter-Process Communication) di Android.
Il secondo componente poteva caricare librerie native ELF, integrare SDK direttamente nel bytecode DEX oppure scaricare ulteriori APK dai server controllati dagli operatori. Alcuni file arrivavano persino da repository e release GitHub amministrati dagli stessi soggetti.
Una delle tecniche più significative riguardava la disattivazione delle verifiche di sicurezza: Google ha individuato una routine che modificava il parametro Android package_verifier_user_consent, impostandolo a -1 tramite Settings.Global.putInt(), con l’obiettivo di aggirare i controlli di Google Play Protect sulle installazioni.
Una libreria denominata libseccomp_guard.so limitava inoltre determinate chiamate di sistema per ostacolare gli strumenti di ispezione e interferire con le attività di debugging.
Da agosto 2026 gli operatori avevano iniziato a sostituire com.abc.nexus con componenti più specializzati, alcuni dei quali tentavano di ottenere privilegi root tramite ADB (Android Debug Bridge) e di collocarsi nella directory /system/priv-app/. Un’evoluzione che indica quanto il progetto fosse tutt’altro che improvvisato.
Perché i criminali volevano controllare le connessioni Internet domestiche
Il vero valore economico della botnet non risiedeva soltanto nella possibilità di eseguire comandi sui dispositivi altrui: gli operatori potevano trasformare ciascun TV Box in un proxy residenziale, utilizzando la connessione Internet domestica del proprietario per instradare traffico generato da terzi.
Le connessioni provenienti da data center e hosting commerciali possono suscitare sospetti; quelle originate da normali operatori telefonici residenziali appaiono invece più simili al traffico di utenti legittimi. Affittando l’accesso a uno dei dispositivi compromessi, un soggetto malevolo poteva quindi utilizzare un indirizzo IP domestico per tentare accessi fraudolenti, aggirare controlli geografici o nascondere l’origine delle proprie comunicazioni. Il traffico risultava così associato alla connessione della vittima, non a quella dell’effettivo utilizzatore.
I ricercatori hanno identificato numerosi componenti destinati a monetizzare la banda disponibile, tra cui Linkfog, GaGaNode, NetNut, AppSalt e Traffmonetizer.
Accanto ai proxy operavano moduli per la frode pubblicitaria. HiddenView, per esempio, utilizzava WebView nascoste per caricare contenuti, simulare interazioni e generare visualizzazioni pubblicitarie artificiali. Altri componenti producevano richieste verso sistemi di tracciamento delle impression senza mostrare realmente gli annunci.
Un singolo TV Box poteva eseguire contemporaneamente più moduli, generando ricavi attraverso differenti attività. Il tutto mentre l’utente continuava tranquillamente a guardare film e programmi televisivi.
Oltre 3,8 milioni di indirizzi IP: i numeri della botnet XCPE
Le rilevazioni di TrendAI Research, effettuate dal 3 giugno al 1° ottobre 2026, restituiscono un quadro ancora più dettagliato rispetto alla cifra generale di 1,3 milioni di dispositivi.
Gli analisti hanno osservato 1.472.554 dispositivi compromessi, appartenenti a 206 modelli e distribuiti in oltre 170 Paesi; circa 1,33 milioni risultavano destinati all’esecuzione di moduli per proxy e frodi pubblicitarie.
Le differenze rispetto ai dati dell’operazione congiunta dipendono dai diversi periodi di osservazione e dalle informazioni accessibili ai singoli ricercatori.
La diffusione non riguardava esclusivamente i TV Box: Google ha identificato componenti malevoli anche in dispositivi Android destinati alla telemedicina, sistemi per karaoke e schermi utilizzati per la segnaletica digitale.
La certificazione Google non è bastata a fermare il malware
L’aspetto forse più delicato dell’intera vicenda riguarda i controlli effettuati prima della commercializzazione.
Google richiede ai produttori una serie di test di compatibilità e sicurezza; Videostrong, secondo le conclusioni dell’indagine, avrebbe sfruttato una lacuna nelle verifiche, nascondendo il codice e attivando i componenti malevoli dopo il primo avvio.
La differenza rispetto alle precedenti campagne BADBOX è rilevante: non siamo davanti soltanto a prodotti economici privi di aggiornamenti o provenienti da canali poco affidabili. Le accuse riguardano direttamente un produttore che aveva accesso al processo di distribuzione di dispositivi certificati.
Google ha interrotto i rapporti con Videostrong e ha vietato all’azienda, comprese eventuali società affiliate o controllate future, di produrre e commercializzare dispositivi Android certificati o fornire software ad altri produttori certificati. Mountain View ha inoltre annunciato modifiche alle verifiche sull’integrità dei firmware Android TV.
Come è stata smantellata la botnet e perché il problema non è risolto
L’intervento coordinato ha colpito i domini e i server utilizzati per controllare XCPE e distribuire i moduli aggiuntivi; Google ha intrapreso azioni legali per interrompere anche le infrastrutture di comando e controllo utilizzate da oltre una dozzina di famiglie malware collegate.
Secondo le stime dell’azienda, l’interruzione di tali infrastrutture potrebbe privare gli operatori criminali dell’accesso ad almeno altri 10 milioni di dispositivi compromessi, raggiunti attraverso canali di distribuzione differenti da XCPE. La disattivazione dei server riduce la capacità di controllo degli aggressori, ma non equivale alla cancellazione del malware presente nei firmware.
Per chi possiede un TV Box Android, soprattutto se acquistato attraverso marchi poco conosciuti, il primo passo consiste nell’identificare produttore, modello e versione del firmware, verificando eventuali comunicazioni ufficiali di sicurezza. La sola presenza di Android TV o delle applicazioni Google non costituisce una garanzia assoluta. Un controllo del traffico attraverso router, firewall o strumenti di analisi DNS può aiutare a individuare connessioni anomale.