Nel corso del 2026, ho assistito a un’escalation preoccupante di attacchi alla catena di approvvigionamento Android. Non si tratta più solo di malware generici: gli attaccanti stanno compromettendo le fondamenta stesse dell’ecosistema, inserendo malware direttamente nella firmware dei dispositivi e nei moduli di sistema come Play Services. In questa guida, condivido le tecniche di rilevamento che applico quotidianamente e le strategie di hardening che hanno dimostrato di funzionare in ambienti enterprise.
Il Panorama dei Supply Chain Attack Android nel 2026
Nel febbraio 2026, Kaspersky ha scoperto Keenadu, un malware integrato nella firmware Android come risultato di un supply chain attack. Quello che mi ha colpito di più è la sofisticatezza: una fase della catena di approvvigionamento della firmware è stata compromessa, introducendo una dipendenza malevola che utilizza il processo Zygote di Android, il che significa che il malware viene automaticamente copiato in ogni applicazione in esecuzione.
Secondo Kaspersky, circa 13.000 dispositivi Android sono stati infettati da Keenadu, con il numero più alto di utenti colpiti in Russia, seguito da Giappone, Germania, Brasile e Paesi Bassi. Ma c’è di più: le applicazioni si affidano sempre più a SDK di terze parti, creando dipendenze di supply chain grandi e spesso opache. Man mano che diventano più comuni portafogli mobili e altre app di alto valore, anche piccoli difetti nelle librerie upstream possono impattare milioni di dispositivi.
Come Funzionano gli Attacchi: La Compromissione a Livello di Modulo
Nella mia esperienza, gli attacchi più sofisticati sfruttano tre vettori:
- Firmware compromessa durante il build: Kaspersky ha concluso che Keenadu è stato “integrato nella firmware durante la fase di build” in una compromissione della supply chain, piuttosto che essere successivamente installato attraverso un server OTA compromesso.
- Moduli Play Services modificati: Il malware può essere distribuito non solo via firmware armata, ma anche nascosto in app di sistema, inclusi servizi di riconoscimento facciale e app launcher, oltre a versioni modificate di applicazioni popolari su store ufficiali come Google Play.
- Vulnerabilità negli SDK di terze parti: Nel 2026, Microsoft ha identificato una grave vulnerabilità di reindirizzamento intent in un SDK Android ampiamente utilizzato (EngageSDK), che consente alle app sullo stesso dispositivo di bypassare la sandbox Android e accedere senza autorizzazione ai dati privati. Con oltre 30 milioni di installazioni di applicazioni di wallet di terze parti da sole, l’esposizione di PII, credenziali utente e dati finanziari era a rischio.
Nel mio lavoro di System Administrator, ho notato che questo file infetto viene utilizzato dal processo master Zygote di Android, il che significa che il malware viene automaticamente copiato in ogni applicazione che gira su un dispositivo compromesso, rendendo estremamente difficile il rilevamento per l’utente finale.
Rilevamento dei Moduli Compromessi: La Mia Procedura Pratica
1. Verificare l’Autenticità dei Moduli Play Services
A partire dal 1° maggio 2026, le applicazioni Android di produzione di Google avranno una voce crittografica corrispondente che ne conferma l’autenticità. L’iniziativa include sia Google Play Services che app Google standalone, nonché i moduli Mainline che fanno parte del sistema operativo e possono essere aggiornati dinamicamente al di fuori del normale ciclo di rilascio.
Come implementarlo nella tua infrastruttura:
#!/bin/bash
# Script per verificare l'integrità di Play Services su dispositivi Android
# Utilizzo: ./verify_play_services.sh <device_serial>
DEVICE=$1
GMS_PACKAGE="com.google.android.gms"
GMS_VERSION=$(adb -s $DEVICE shell dumpsys package $GMS_PACKAGE | grep versionName)
echo "[*] Play Services Version: $GMS_VERSION"
# Verificare il certificato di firma
adb -s $DEVICE shell pm dump $GMS_PACKAGE | grep -A 5 "signingCertificates"
# Confrontare con la lista ufficiale di Google
echo "[!] Verificare il certificato contro il registro pubblico di Binary Transparency"
echo "[!] URL: https://transparency.googlesource.com/android/+/refs/heads/main"
2. Analizzare le Dipendenze degli SDK di Terze Parti
Le applicazioni si affidano sempre più a SDK di terze parti, creando grandi e spesso opache dipendenze della supply chain. Man mano che i portafogli mobili e altre app di alto valore diventano più comuni, anche piccoli difetti nelle librerie upstream possono impattare milioni di dispositivi. Questi rischi aumentano quando le integrazioni espongono componenti esportati o si affidano a ipotesi di fiducia che non vengono validate oltre i confini dell’app.
La procedura che uso quotidianamente:
- Generare un SBOM (Software Bill of Materials) per ogni APK/AAB distribuito
- Verificare le versioni degli SDK contro i bollettini di sicurezza ufficiali
- Analizzare le attività esportate in AndroidManifest.xml
- Testare le intent redirection vulnerabilities usando strumenti come Frida
3. Scansionare le Attività Esportate e Componenti Nascosti
Nella mia esperienza, le vulnerabilità più pericolose si nascondono nei componenti esportati impliciti:
# Estrai AndroidManifest.xml dal file APK
apktool d app.apk
# Cerca attività esportate senza protective permissions
grep -n "exported="true"" AndroidManifest.xml
# Identifica servizi, content provider e broadcast receiver senza protezioni
grep -E "<(service|provider|receiver)" AndroidManifest.xml | grep -v "android:permission"
Hardening della Catena di Approvvigionamento APK: La Mia Strategia Enterprise
Implementazione di Binary Transparency per Google Apps
Questo fornisce un “Source of Truth” trasparente che consente a chiunque di verificare che il software Google sul proprio dispositivo Android è una versione di produzione autorizzata da Google e non è stato modificato da un attaccante. Se il software non è nel registro, Google non lo ha rilasciato come software di produzione. Qualsiasi tentativo di distribuire una versione “one-off” sarà rilevabile. Come parte di questo sforzo, il gigante tecnologico sta anche mettendo a disposizione strumenti di verifica che utenti e ricercatori possono sfruttare.
Come integro questo nella mia infrastruttura Plesk:
- Utilizzo Google Binary Transparency API per fare il log di tutte le app Google rilasciate dopo il 1° maggio 2026
- Mantengo una copia locale dei registri di trasparenza per audit offline
- Implemento verifiche automatizzate che bloccano app non presenti nel registro
Blocco dei Componenti Non Autorizzati
In un ambiente enterprise, implemento un whitelist di componenti conosciuti:
# Script di verifica per environment enterprise
adb shell pm list packages -3 > /tmp/third_party_apps.txt
# Per ogni app, verificare che non contenga componenti non autorizzati
for app in $(cat /tmp/third_party_apps.txt); do
adb shell dumpsys package "${app#package:}" | grep -E "Service|Activity|Provider" |
while read -r component; do
# Confrontare contro whitelist autorizzato
if ! grep -q "$component" /etc/android_whitelist.conf; then
echo "[ALERT] Componente non autorizzato: $component in $app"
fi
done
done
Implementazione di SafetyNet/Play Integrity API
Live Threat Detection, il sistema AI on-device di Android per contrassegnare il comportamento sospetto delle app, guadagna nuovi avvisi per l’inoltro SMS e l’abuso di overlay di accessibilità. Una capacità chiamata dynamic signal monitoring osserverà le interazioni applicazione-sistema in tempo reale e distribuirà regole di rilevamento aggiornate per affrontare nuove minacce. Arriva sui dispositivi Android 17, con protezioni spedite nella seconda metà del 2026.
Integro questa verifica nel mio workflow di deployment:
// Verificare l'integrità del dispositivo prima dell'installazione di app sensibili
final SafetyNetClient client = SafetyNet.getClient(context);
client.attest(nonce, apiKey).addOnSuccessListener(result -> {
SafetyNetData data = result.getResult();
if (data != null && data.isValidSignature()) {
// Dispositivo autorizzato, procedere con l'installazione
installSecureApp();
} else {
// Dispositivo compromesso o modificato
blockInstallation("Dispositivo non supera il controllo di integrità");
}
});
Protezione Contro le Compromissioni di Firmware: Zero-Trust su Android
Nel corso del 2026, la ricerca di Kaspersky e Sophos ha evidenziato un fatto spaventoso: Keenadu è un’infezione firmware incorporata in libandroid_runtime.so che si inietta nel processo Zygote. Poiché Zygote è il processo padre di tutte le app Android, un attaccante guadagna effettivamente il controllo totale di un dispositivo infetto. Keenadu funge da downloader per moduli malware di secondo stadio.
Implementazione di Verified Boot Hardening
Prima che qualsiasi app si esegua, prima che qualsiasi utente acceda, prima che accada qualcosa di visibile sullo schermo, il secure boot su Android è già in funzione. Verified Boot è l’implementazione di secure boot di Android, ed è uno dei meccanismi di sicurezza più importanti dell’intero sistema. Il processo funziona in una catena di fiducia: il bootloader verifica l’integrità del recovery, che verifica la partizione di sistema, che verifica il resto del sistema operativo. Se qualsiasi collegamento in quella catena è stato manomesso, il dispositivo lo rileva e rifiuta di avviarsi o avverte chiaramente l’utente.
Auditing Continuo della Firmware
Implemento uno script di auditing mensile nei miei ambienti:
#!/bin/bash
# Verifica mensile dell'integrità della firmware
for device in $(adb devices | grep -v devices); do
if [ -z "$device" ]; then continue; fi
# Estrarre info della build
adb -s $device shell getprop ro.build.fingerprint > /tmp/fingerprint_$device.txt
adb -s $device shell getprop ro.build.version.security_patch > /tmp/patch_level_$device.txt
# Verificare contro database storico
if ! grep -q "$(cat /tmp/fingerprint_$device.txt)" /var/lib/android_firmware_whitelist.db; then
echo "[CRITICAL] Nuova fingerprint rilevata su $device - Verificare manualmente"
# Inviare alert ai security team
mail -s "Anomalia firmware su $device" security@company.com
fi
done
Protezione degli SDK e Validazione delle Dipendenze
La maggior parte delle app mobile integra dipendenze esterne, incluse open-source e proprietarie, a volte come SDK solo binari o moduli offuscati. I problemi di sicurezza, come vulnerabilità, errori di configurazione o logica malevola, sono difficili da rilevare tramite sole scansioni a livello di codice sorgente o fuzzing superficiale. In poche parole, ogni app ha una catena di approvvigionamento, e i dispositivi mobili ereditano dozzine, se non centinaia, di queste catene.
Verifica dell’Integrità degli SDK Integrate
// Verificare il certificato di firma dell'SDK all'avvio dell'app
public class SDKIntegrityChecker {
public static boolean verifySDKSignature(Context context, String sdkPackageName) {
try {
PackageInfo pkgInfo = context.getPackageManager()
.getPackageInfo(sdkPackageName, PackageManager.GET_SIGNATURES);
Signature[] signatures = pkgInfo.signatures;
for (Signature signature : signatures) {
byte[] signatureBytes = signature.toByteArray();
MessageDigest md = MessageDigest.getInstance("SHA-256");
byte[] hash = md.digest(signatureBytes);
// Confrontare con hash conosciuto
String hashHex = bytesToHex(hash);
if (!isKnownSignature(hashHex)) {
Log.e("SDKCheck", "Firma SDK non autorizzata: " + sdkPackageName);
return false;
}
}
return true;
} catch (Exception e) {
Log.e("SDKCheck", "Errore nella verifica SDK", e);
return false;
}
}
}
Developer Verification e Accountability
Nel 2026, a partire da settembre, Google richiederà che tutte le app Android installate su dispositivi certificati in Brasile, Indonesia, Singapore e Tailandia siano registrate da sviluppatori verificati. Per altre regioni, questo requisito verrà implementato gradualmente dal 2027 in poi.
Il mandato di Google richiede che ogni sviluppatore che vuole che la sua app sia installabile su un dispositivo Android certificato provi la propria identità. Google sta confermando chi è lo sviluppatore, il che introduce un nuovo livello di responsabilità nell’ecosistema. Se uno sviluppatore verificato distribuisce malware, Google può rimuoverli più efficacemente e impedire loro di semplicemente creare un nuovo account anonimo per continuare le loro attività.
Link Interni Pertinenti
Se sei interessato ad approfondire le strategie di sicurezza multi-layer, consiglio di leggere i miei articoli correlati:
- Come Implementare Android 17 Security Hardening: Verifica APK Avanzata, Chromium Security Updates e Privacy Dashboard per Dispositivi Enterprise
- Cyber Resilience Act 2026: Implementazione SBOM, Vulnerability Disclosure e Compliance per Provider Hosting
- Plugin WordPress Abbandonati 2026: Come Identificare e Migrare Dipendenze Critiche – Le stesse tecniche di audit si applicano agli SDK Android
FAQ
Come faccio a sapere se il mio dispositivo Android è stato compromesso da Keenadu?
I segnali di compromissione includono: drenaggio della batteria anomalo, consumo dati inaspettato, app che crashano frequentemente, e latenza di sistema. Tuttavia, Keenadu è sofisticato nel rimanere nascosto. L’unico modo definitivo è installare una soluzione antimalware affidabile (Kaspersky, Sophos) e abilitare Google Play Protect. Se possiedi un Pixel, verifica il registro di Binary Transparency contro le app installate.
Qual è la differenza tra Binary Transparency e firme digitali?
Una firma digitale non può garantire che questo particolare binario fosse quello previsto per essere rilasciato al pubblico dal suo autore. Le firme digitali sono un certificato di origine, ma binary transparency è un certificato di intento. In altre parole, una firma prova chi ha creato il binario; la binary transparency prova che Google voleva che quel binario fosse distribuito.
Come implemento SBOM (Software Bill of Materials) per gli SDK?
Utilizzo strumenti come Gradle Module Graph, CYCLONEDX, o Syft per generare SBOM in formato JSON/XML. Nel mio workflow Plesk, ho creato un hook di build che blocca qualsiasi APK che contiene dipendenze non catalogate. Questo è obbligatorio dal Cyber Resilience Act per i provider hosting europei.
Can third-party app stores come F-Droid sopravvivere alla verifica obbligatoria degli sviluppatori?
Sì, ma con limitazioni. Store come Aptoide, F-Droid e Aurora Store esistono perché gli sviluppatori potevano pubblicare liberamente. Una volta che la verifica diventa obbligatoria, molti sviluppatori indipendenti non si registreranno (per motivi di privacy, attrito burocratico, o semplicemente non sapendo). F-Droid sta implementando il proprio framework di verifica per mantenere la compatibilità.
Quale versione di Android ha il miglior supporto per Binary Transparency?
Android 17 e Pixel 9+ hanno supporto completo. Per versioni precedenti (Android 16, 15), il supporto è limitato a Google Play Services e Mainline modules. La lista completa degli APK verificati è disponibile nel registro pubblico su transparency.googlesource.com.
Conclusione
Nel 2026, la sicurezza della catena di approvvigionamento Android non è più un “nice to have” – è una necessità critica. Gli attacchi sono evoluti da semplici malware APK a compromissioni a livello di firmware. Le strategie che ho condiviso – dalla verifica di Binary Transparency alla validazione degli SDK, dal Verified Boot Hardening alla Developer Verification – rappresentano un defense-in-depth robusto.
Se gestisci un’infrastruttura enterprise o distribuisci app Android, implementa subito almeno tre di queste misure: (1) verifica delle dipendenze dell’SDK, (2) scansione mensile della firmware, (3) abilitazione di Play Integrity API su tutte le app sensibili. La finestra per prevenire gli attacchi è stretta, ma con le giuste misure, è ancora chiudibile.
Hai domande sulla rilevazione di supply chain attack o sulla strategia di hardening APK? Lascia un commento qui sotto o contattami direttamente – ho implementato queste tecniche su migliaia di dispositivi enterprise nel 2026, e sono felice di condividere gli insegnamenti raccolti sul campo.