DIEGO CECATO / NOTE DAL CAMPO

XCPE: il firmware tradisce prima ancora che tu accenda il dispositivo

diego cecato//
XCPE e sicurezza del firmware Android: cover editoriale Diego Cecato

Quando compri un dispositivo con Android, la domanda più comoda è se sia certificato, aggiornato e compatibile. La domanda scomoda è un’altra: chi controlla davvero il software che parte prima delle applicazioni? Il caso XCPE, raccontato il 2 novembre 2026 dal Google Threat Intelligence Group, mostra perché questa distinzione non è un esercizio accademico. Secondo Google, una backdoor integrata nel firmware ha trasformato oltre 1,3 milioni di set-top box in nodi di una botnet. Non si tratta di utenti che hanno installato l’APK sbagliato. Il problema era già dentro il prodotto.

La certificazione fotografa un momento. Il firmware vive nel tempo.

Google sostiene che il produttore Videostrong Technology abbia sviluppato e gestito intenzionalmente XCPE per monetizzare l’accesso ai dispositivi. È una valutazione attribuita all’investigatore, non una responsabilità accertata in sede giudiziaria. La parte tecnica è particolarmente interessante: secondo il rapporto, il codice usava tecniche di offuscamento per superare i controlli di compatibilità e sicurezza, caricando componenti malevoli dopo il primo avvio. Google dichiara di aver modificato i processi di revisione e di aver escluso il produttore dalla filiera dei dispositivi Android certificati.

Qui sta il confine di fiducia: un test prima della distribuzione non può garantire da solo che tutto ciò che verrà caricato dopo il boot sia legittimo. Se un componente privilegiato può recuperare configurazioni e payload da remoto, la superficie reale non coincide con il pacchetto osservato in laboratorio. Certificazione, provenienza del firmware, aggiornamenti e comportamento runtime sono controlli diversi, non sinonimi.

Una backdoor di sistema non è una normale app sospetta

Nel rapporto tecnico Google descrive XCPE come componente preinstallato con privilegi android.uid.system, in alcune versioni identificato come com.oemservice. Il software poteva ripristinarsi dalla partizione /oem/ dopo la rimozione e il riavvio. Questo cambia completamente la prospettiva rispetto alla classica pulizia di un’app: l’utente non ha necessariamente il controllo della radice da cui il codice viene reinstallato.

La catena di comando combinava una fase HTTP per ottenere configurazioni con una connessione MQTT persistente. Secondo l’analisi, i comandi comprendevano installazione silenziosa di applicazioni, esecuzione di shell, raccolta di informazioni, screenshot e ricognizione di rete. MQTT, naturalmente, non è il problema: è un protocollo legittimo. Diventa parte dell’attacco quando un componente privilegiato lo usa per ricevere istruzioni senza consenso e senza una catena di fiducia verificabile.

Il modello economico: vendere la connessione che paga qualcun altro

Una volta ottenuto il controllo del dispositivo, la monetizzazione può essere distribuita su più moduli. Il rapporto di Google cita frodi pubblicitarie, ulteriori payload e reti di proxy residenziali. Quest’ultimo dettaglio merita attenzione: il traffico di terzi esce dalla connessione domestica o aziendale della vittima. L’indirizzo IP sembra quello di un normale abbonato, mentre chi controlla il proxy può sfruttarlo per attività non autorizzate.

Non è soltanto una questione di CPU consumata o di pubblicità fasulla. Cambia il perimetro reputazionale della rete: un apparato apparentemente innocuo può diventare il punto da cui parte traffico che il proprietario non ha mai autorizzato. Plume, partner dell’operazione, conferma che il software era presente prima della vendita e che le connessioni degli utenti venivano sfruttate senza consenso.

Smantellare il comando non equivale a bonificare il dispositivo

Google e i partner dichiarano di aver interrotto infrastrutture di comando e controllo e domini utilizzati dagli affiliati. È un risultato importante, ma non significa che 1,3 milioni di firmware siano stati riscritti o resi affidabili. Se la backdoor rimane in una partizione privilegiata, l’interruzione della comunicazione corrente non dimostra che sia sparita la possibilità tecnica di una nuova attivazione. È la differenza fra interrompere un servizio criminale e rimuovere la capacità di compromissione.

Anche il numero di almeno 10 milioni di altri dispositivi va letto correttamente: è una stima di Google sull’impatto della disattivazione dei domini usati da moduli distribuiti anche attraverso altri canali. Non sono altri 10 milioni di set-top box XCPE e non è un conteggio di dispositivi bonificati. Confondere queste tre grandezze produce titoli impressionanti, non comprensione tecnica.

Che cosa dovrebbe cambiare in un acquisto IoT

Per chi gestisce reti e dispositivi, il criterio non può essere soltanto il prezzo o il logo sulla confezione. Prima di introdurre apparati poco documentati in una rete di lavoro servono una provenienza verificabile del firmware, un canale di aggiornamento affidabile, informazioni sulla durata del supporto e una procedura di sostituzione quando il produttore perde credibilità. Sono verifiche di processo, non una promessa di sicurezza assoluta.

Sul piano operativo, separare i dispositivi IoT dalla rete che ospita workstation e servizi sensibili riduce l’esposizione laterale. Monitorare DNS, destinazioni e traffico in uscita può aiutare a rilevare anomalie; non garantisce però di riconoscere ogni C2, soprattutto quando l’attività è mimetizzata nel traffico ordinario. Se un apparato è sospetto e non esiste un firmware verificato, il reset di fabbrica non deve essere considerato automaticamente una bonifica: può ripristinare proprio il software vulnerabile o malevolo.

Il punto non è diffidare di Android. È sapere dove finisce la verifica.

Sarebbe comodo ridurre XCPE all’ennesima notizia su una botnet smantellata. Ma la lezione più utile riguarda la progettazione dei sistemi: non puoi delegare tutta la fiducia a un certificato, a un marchio o a un controllo eseguito una volta sola. Devi sapere chi può cambiare il codice, con quali privilegi, da quali canali e con quali possibilità di audit. La sicurezza non è una fotografia del prodotto quando esce dalla fabbrica; è una proprietà da difendere lungo l’intero ciclo di vita.

Domande frequenti

Che cos'è la botnet XCPE?

È una rete di dispositivi Android compromessi tramite una backdoor integrata nel firmware, secondo l’analisi pubblicata da Google il 2 novembre 2026.

Un dispositivo Android certificato è necessariamente al sicuro?

No. La certificazione riduce alcuni rischi ma non garantisce che un componente privilegiato non carichi codice malevolo dopo il primo avvio.

Il takedown di XCPE ha ripulito tutti i dispositivi?

No. L’interruzione dei server di comando non equivale alla rimozione del software preinstallato nei dispositivi.

Un reset di fabbrica elimina XCPE?

Non necessariamente: se il componente malevolo persiste nella partizione firmware o OEM, un reset potrebbe non rimuoverlo.