Il trojan bancario Android ToxicPanda è tornato, e la versione che i ricercatori hanno battezzato ToxicPanda 2.0 non somiglia più al malware da frode bancaria del 2024. Secondo l'analisi pubblicata da Zimperium zLabs e ripresa il 24 agosto 2026 da Dark Reading, la nuova variante aggiunge 167 comandi remoti, allarga il bersaglio da 16 istituti finanziari a 349 fra applicazioni bancarie, e-wallet e piattaforme di criptovalute distribuite in 16 Paesi, e introduce tecniche che puntano al controllo completo del dispositivo, non solo al saldo del conto.

Il dettaglio che rende questa notizia diversa dalle decine di segnalazioni su malware Android che escono ogni mese: l'Italia non è un bersaglio marginale di questa famiglia. Quando Cleafy individuò ToxicPanda per la prima volta, a novembre 2024, la botnet contava circa 1.500 dispositivi infetti e la quota più consistente era italiana, seguita da Portogallo, Hong Kong, Spagna e Perù. L'Europa meridionale, e l'Italia in particolare, è il terreno su cui gli operatori hanno costruito e collaudato la campagna. È ragionevole aspettarsi che la versione 2.0 riparta da lì.

Cosa fa concretamente la nuova variante

Le capacità documentate da Zimperium sono queste, e vale la pena leggerle in sequenza perché descrivono una catena, non un elenco di funzioni scollegate:

  • Distribuzione da infrastruttura legittima. I campioni osservati sono stati serviti da bucket AWS, una scelta che rende inefficace il blocco per reputazione del dominio e complica il filtraggio a livello di rete.
  • Falsa schermata di installazione per ottenere i permessi VPN. Ottenuto il consenso, il malware usa il canale VPN locale per bloccare le comunicazioni di Google Play e Google Play Services: in pratica taglia fuori Play Protect prima di installare il payload vero e proprio.
  • Overlay sulla schermata di blocco. Non è la solita finta pagina di login della banca: l'overlay cattura il PIN o la sequenza di sblocco del telefono. Chi ruba il PIN del dispositivo non ruba solo l'accesso a un'app, ruba la chiave che protegge tutto il resto.
  • Abuso dei Servizi di accessibilità. Il malware li usa per leggere il contenuto dello schermo, automatizzare i tocchi e mostrare overlay di phishing sopra le 349 app finanziarie in elenco.
  • Escalation via Wireless Debugging e ADB. È la novità più significativa. ToxicPanda automatizza, tramite accessibilità, l'attivazione delle Opzioni sviluppatore e del debug wireless introdotto con Android 11, estrae il codice temporaneo di accoppiamento ADB e completa il pairing con il servizio ADB del dispositivo stesso. Il risultato è l'accesso a livello di shell: da lì il malware può concedersi permessi aggiuntivi, indebolire le restrizioni del sistema operativo e installare la propria persistenza.

Il salto qualitativo, quindi, non sta nel numero di banche colpite ma nel fatto che l'attaccante smette di dipendere dall'inganno dell'utente e ottiene privilegi che di norma appartengono a chi ha il telefono in mano.

Cosa significa per le aziende italiane

Il primo istinto, leggendo "trojan bancario", è archiviare la notizia come un problema del consumatore e della sua banca. È l'errore da evitare, per una ragione strutturale: in gran parte delle organizzazioni italiane lo smartphone che esegue l'home banking è lo stesso che approva le richieste MFA push, custodisce le passkey, ospita l'app aziendale di posta e talvolta il token software per la VPN. La diffusione del BYOD nelle PMI italiane, dove un MDM aziendale è ancora l'eccezione più che la regola, rende questa sovrapposizione la norma.

Se il malware ottiene il PIN di sblocco e la shell, l'attaccante non ha compromesso "il conto del dipendente": ha compromesso l'ancora di identità dietro cui stanno tutti gli account aziendali di quella persona. Un secondo fattore basato su OTP via SMS o su push notification perde gran parte del suo valore quando l'endpoint che lo genera o lo approva è sotto controllo altrui. Le passkey, che si appoggiano al blocco schermo del dispositivo, non fanno eccezione se il blocco schermo è quello che l'overlay ha catturato.

C'è poi un secondo profilo di rischio, meno evidente e più insidioso per chi gestisce la sicurezza: la visibilità. Un attacco che vive interamente sul telefono personale di un dipendente non produce alert nel SIEM aziendale, non passa dal proxy, non lascia tracce sull'EDR degli endpoint gestiti. Il primo segnale può arrivare settimane dopo, sotto forma di un accesso legittimo con credenziali valide da un contesto anomalo.

Per le realtà del settore finanziario il tema è ancora più diretto: sotto DORA la gestione del rischio ICT include i canali di interazione con la clientela, e una campagna che colpisce in modo mirato le app di 349 istituti si traduce in scenari di frode da valutare nei test di resilienza operativa, non solo in comunicazioni di sicurezza ai correntisti. Sul fronte GDPR, la compromissione del telefono di un dipendente che dà accesso a dati personali trattati dall'azienda è a tutti gli effetti una violazione ai sensi dell'articolo 33, con l'orologio delle 72 ore per la notifica al Garante che parte dal momento in cui l'organizzazione ne viene a conoscenza. E l'articolo 32, sulle misure tecniche e organizzative adeguate, oggi non si può ritenere soddisfatto ignorando la superficie mobile.

Cosa fare subito

Le misure che seguono sono ordinate per rapporto fra efficacia e sforzo, e quasi tutte sono già disponibili in un MDM o in un Intune di fascia standard:

  • Bloccare il sideloading e l'installazione da origini sconosciute su tutti i dispositivi iscritti al sistema di identità aziendale. È la misura che spezza la catena all'inizio.
  • Trattare la concessione di un Servizio di accessibilità come un evento di accesso privilegiato: registrarla, generare un alert e verificarla, esattamente come si farebbe con l'aggiunta di un utente a un gruppo di amministratori.
  • Allertare sull'attivazione delle Opzioni sviluppatore e del Wireless Debugging sui dispositivi gestiti. È un segnale che quasi nessuno monitora e che l'MDM già vede: è probabilmente il singolo controllo di rilevamento con il miglior rapporto costo/beneficio contro questa specifica catena.
  • Verificare la presenza di profili VPN non autorizzati sui dispositivi e allertare quando un'app di terze parti registra un servizio VPN locale.
  • Spostare l'MFA verso fattori che non dipendono dal solo telefono: chiavi di sicurezza FIDO2 in hardware per gli account ad alto privilegio, o quantomeno number matching sulle push, che alza il costo dell'approvazione automatica.
  • Separare i profili: dove il BYOD è inevitabile, imporre un work profile Android gestito, in modo che il compromesso del profilo personale non tocchi direttamente credenziali e dati aziendali.
  • Aggiornare la procedura di risposta: se un dipendente segnala una richiesta anomala di permessi VPN o accessibilità, il dispositivo va considerato compromesso, non "da controllare". Reset di fabbrica e rotazione delle credenziali e delle sessioni, non rimozione dell'app.

Vale infine una raccomandazione da girare alle persone, non ai sistemi: nessuna app legittima chiede il PIN di sblocco del telefono, e nessuna banca chiede di attivare le Opzioni sviluppatore. Sono due domande che, da sole, identificano l'inganno prima che diventi un incidente.