RatHat fa paura: il malware Android che usa l’AI e può rubare PIN e codici OTP

RatHat è un nuovo trojan per Android documentato da Zimperium zLabs il 16 settembre 2026: non si limita a mostrare schermate di phishing, ma combina abuso dei servizi di accessibilità, auto-abbinamento ad Android Debug Bridge e controllo dell’interfaccia assistito da AI per sottrarre credenziali bancarie, PIN, codici OTP e dati di pagamento. La ricerca originale di Zimperium lo descrive come una minaccia mobile “AI-powered” orientata ai conti bancari e attribuita, con formulazione prudente, ad attori che sembrano operare dalla Cina; la società non ha però pubblicato un conteggio globale delle vittime né un elenco di banche colpite.

La notizia è stata ripresa in Italia da Punto Informatico, che sottolinea il punto centrale dell’analisi: una volta ottenuti i permessi necessari, RatHat può leggere la struttura della schermata, riconoscere pulsanti, menu e campi da compilare, quindi decidere quali tocchi o scorrimenti eseguire. In altre parole, l’AI non “buca” Android da sola: rende più flessibile l’automazione dell’attacco, mentre i privilegi arrivano dall’abuso di funzioni legittime del sistema operativo, in particolare Accessibilità e ADB.

Come arriva sul telefono: niente exploit magico, ma APK e inganno

La catena di infezione descritta dalle fonti finora disponibili parte da metodi molto tradizionali: SMS di phishing, pubblicità malevole, forum e pagine di download che imitano applicazioni note. L’obiettivo è convincere la vittima a installare manualmente un APK esterno agli store ufficiali, spesso presentato come browser, app di streaming o servizio finanziario. Cybernews riferisce che i ricercatori hanno individuato 162 app malevole associate a RatHat; il dato indica una campagna già articolata, ma non equivale a dire che tutte abbiano avuto la stessa diffusione o lo stesso numero di installazioni secondo la ricostruzione pubblicata il 18 settembre 2026.

Questo aspetto è decisivo per valutare il rischio. RatHat non è stato presentato come una vulnerabilità zero-day capace di infettare automaticamente qualsiasi smartphone Android. L’attacco richiede una fase iniziale di social engineering: l’utente deve scaricare il pacchetto, installarlo e poi concedere almeno un permesso critico. Matrice Digitale, analizzando la ricerca di Zimperium, evidenzia che il dropper usa payload cifrati e API native di installazione per rendere più difficile il blocco del sideloading, ma il primo varco resta l’installazione volontaria dell’app malevola da una fonte non affidabile.

Il passaggio chiave: Accessibilità diventa il telecomando dell’attacco

Il primo obiettivo di RatHat è ottenere l’autorizzazione ai servizi di accessibilità. Su Android questi servizi sono nati per aiutare persone con disabilità a interagire con il dispositivo e, proprio per questo, possono osservare elementi dell’interfaccia e compiere azioni al posto dell’utente; la documentazione ufficiale Android li descrive come componenti in grado di ricevere eventi dall’interfaccia e assistere l’interazione con le app. Nelle mani di un’app malevola, però, lo stesso canale diventa un sistema per premere pulsanti, aprire impostazioni e guidare la vittima verso ulteriori concessioni.

Dopo il permesso di accessibilità, RatHat automatizza l’apertura delle Opzioni sviluppatore e del Debug wireless, legge dalla schermata il codice di abbinamento e la porta dinamica, poi si collega al servizio ADB locale del dispositivo. Android Debug Bridge è uno strumento legittimo usato dagli sviluppatori per comunicare con telefoni e tablet durante test, debug e installazione di app; Google lo definisce un tool da riga di comando per interagire con un dispositivo Android. RatHat sfrutta questa superficie in modo anomalo: invece di collegare un computer allo smartphone, induce il telefono a stabilire una sessione ADB con sé stesso e poi verso l’infrastruttura dell’attaccante.

Il risultato è più grave di un normale abuso di permessi. Con l’auto-pairing ADB, il malware esce dai limiti della singola app e ottiene capacità di livello shell, senza richiedere il root. Security Affairs descrive la procedura come un modo per trasformare il debugging, normalmente controllato dallo sviluppatore o dall’utente esperto, in una scorciatoia per il controllo remoto: RatHat legge il codice di pairing mostrato sullo schermo e completa l’associazione senza un computer esterno o un’approvazione consapevole della vittima.

I componenti nascosti che sopravvivono all’app principale

Una volta ottenuto l’accesso tramite ADB, RatHat installa componenti nativi mascherati da librerie Android. Secondo Cyberpress, uno dei file analizzati, indicato come liblocal-service.so, agisce come agente locale privilegiato ed è eseguito da /data/local/tmp; un secondo componente, libmedia_codec.so, funziona come client Fast Reverse Proxy per mantenere un tunnel persistente verso il server di comando e controllo. Questa architettura separa l’app visibile dalla parte più pericolosa dell’impianto, rendendo la rimozione molto più complessa rispetto a un trojan bancario basato solo su overlay.

Cyber Security News aggiunge un dettaglio operativo importante: anche quando l’utente prova a disinstallare l’app, RatHat può mostrare una falsa schermata di errore sopra il prompt di rimozione. Se la disinstallazione riesce comunque, l’agente nascosto può verificare l’assenza del pacchetto, reinstallarlo e ripristinare i permessi senza chiedere nuovamente consenso. È questa persistenza, più ancora del marchio “AI”, a rendere l’incidente difficile da gestire per un utente normale: eliminare l’icona sospetta non garantisce che il controllo del dispositivo sia cessato secondo la ricostruzione tecnica pubblicata il 17 settembre.

Che cosa fa davvero l’AI dentro RatHat

La parte AI di RatHat serve a superare uno dei limiti storici dei malware Android: la fragilità degli script. I vecchi trojan bancari automatizzano tocchi e inserimenti seguendo coordinate, testi o percorsi prefissati; basta che una banca cambi layout, che un produttore modifichi la skin di Android o che l’utente abbia una lingua diversa per far fallire parte dell’attacco. RatHat, invece, serializza l’albero di accessibilità della schermata, ne invia porzioni a un assistente generativo e riceve indicazioni su cosa premere, leggere o far comparire con uno scorrimento in base allo stato reale del dispositivo.

Malwarebytes interpreta questa caratteristica come un salto pratico per i criminali: il percorso di attacco diventa variabile, quindi più difficile da bloccare con firme rigide o regole basate su sequenze prevedibili. La logica non è quella di un malware completamente autonomo che prende decisioni finanziarie da solo; è piuttosto un operatore remoto assistito da un modello capace di leggere l’interfaccia, proporre azioni e adattarsi alle differenze tra app e versioni del sistema senza dover mantenere script separati per ogni bersaglio.

Questo dettaglio ridimensiona anche alcune letture allarmistiche. RatHat non dimostra che l’AI generativa renda obsoleta la sicurezza mobile da un giorno all’altro; dimostra però che l’AI può abbassare il costo operativo di campagne già note, rendendo più conveniente attaccare dispositivi con interfacce, lingue e app differenti. SourceSecurity cita il chief scientist di Zimperium, Nico Chiaraviglio, secondo cui RatHat combina social engineering, escalation dei privilegi e controllo assistito da AI in un’unica catena di attacco più adattabile rispetto all’automazione statica.

Ti potrebbe interessareUn solo hacker e centinaia di agenti IA: 11 organizzazioni violate in 26 secondi

Credenziali bancarie, OTP e PIN: la parte finanziaria dell’attacco

Il furto dei dati avviene su più livelli. RatHat può mostrare overlay web che imitano app bancarie, wallet crypto, servizi di pagamento e messaggistica, raccogliendo username, password, numeri di carta e PIN. Può intercettare SMS e notifiche per ottenere codici OTP e 2FA, ma anche leggere eventi di modifica del testo generati dall’accessibilità, inclusi campi mascherati. Cyberpress segnala inoltre la capacità di raccogliere URL da browser come Chrome, Brave, Opera, Edge, DuckDuckGo e Samsung Internet, un indizio che la raccolta dati non si ferma alle sole app bancarie ma segue l’attività complessiva del dispositivo.

La funzione più invasiva riguarda gli input fisici. Zimperium sostiene che RatHat possa monitorare gli eventi tattili grezzi e ricostruire PIN, password o sequenze di sblocco confrontando le coordinate del dito con layout noti di tastierini e griglie. Punto Informatico spiega il meccanismo con un esempio intuitivo: se il tocco cade nella zona corrispondente a un determinato tasto numerico, il malware può dedurre quale cifra sia stata digitata. È un metodo che aggira molte difese pensate contro screenshot e lettura diretta dei campi, perché osserva l’interazione a un livello più basso rispetto al contenuto visibile sullo schermo.

Per una banca, questo scenario è più insidioso del classico phishing via pagina web. Se il telefono è compromesso, l’attaccante può trovarsi nello stesso ambiente in cui arrivano notifiche, SMS, app di autenticazione e sessioni già aperte. L’eventuale furto delle credenziali non è quindi un evento isolato: può essere accompagnato dalla lettura dei codici temporanei, dall’approvazione remota di passaggi sullo schermo e dalla raccolta di informazioni utili a superare controlli antifrode basati sul dispositivo.

Il confronto con i trojan bancari precedenti

Overlay, keylogging e abuso dell’accessibilità non nascono con RatHat. Le famiglie di malware bancario Android usano da anni finte schermate sopra le app legittime e tentano di intercettare SMS di conferma. Le fonti citano precedenti come ToxicPanda, per la distribuzione tramite pagine ingannevoli e permessi di accessibilità, e il caso RedHook, per l’abuso di ADB. La differenza è l’integrazione: RatHat unisce in un’unica catena l’automazione assistita da AI, l’auto-pairing del Debug wireless, componenti nativi persistenti e furto di input a basso livello secondo il confronto tecnico riportato da Cyber Security News.

Questo cambia anche il lavoro dei difensori. Un controllo basato soltanto sul nome del pacchetto, sull’icona o su una schermata di phishing rischia di arrivare tardi. Se l’app cambia etichetta, maschera la propria presenza e sposta parte delle funzioni in binari separati, la protezione deve osservare comportamenti: richiesta improvvisa di accessibilità da parte di un’app appena installata, attivazione del Debug wireless, processo che mantiene tunnel in uscita, reinstallazione anomala di pacchetti e uso sospetto di comandi shell.

Cosa significa per utenti, banche e aziende italiane

Per gli utenti italiani la prima conseguenza è concreta: evitare APK ricevuti via SMS, pubblicità o siti non ufficiali non è più una raccomandazione generica, ma una barriera essenziale contro una catena che parte quasi sempre dal sideloading. Google Play Protect controlla le app e avvisa su comportamenti potenzialmente dannosi, ma la protezione non sostituisce la cautela sulle installazioni manuali, soprattutto quando una pagina esterna chiede di ignorare avvisi di sicurezza o concedere permessi di accessibilità a un’app che non ha un motivo legittimo per usarli.

Se compare una richiesta di Accessibilità per un’app appena scaricata, o se lo smartphone mostra schermate relative a Opzioni sviluppatore e Debug wireless senza che l’utente le abbia cercate, il comportamento va trattato come un segnale di compromissione. In caso di sospetto, la risposta prudente è disconnettere il dispositivo dalle reti, cambiare password e credenziali bancarie da un dispositivo sicuro, contattare la banca, revocare sessioni attive e token, quindi valutare un ripristino completo o assistenza tecnica qualificata. Con RatHat, la semplice disinstallazione dell’app sospetta può non bastare, perché la persistenza è progettata proprio per sopravvivere alla rimozione visibile.

Per le aziende il problema entra nei programmi BYOD, nella posta aziendale su smartphone personali e nelle app interne distribuite fuori dagli store. Le policy MDM o EMM dovrebbero bloccare o limitare il sideloading dove non necessario, impedire l’attivazione del Debug wireless sui dispositivi gestiti, generare allarmi sulle nuove concessioni di Accessibilità e verificare la presenza di tunnel di rete anomali. Nei settori finanziari, assicurativi e retail, un telefono compromesso può diventare il punto di ingresso per frodi sui conti personali, ma anche per furto di identità, email aziendale e accessi SaaS già autenticati.

Per le banche, RatHat conferma un principio ormai inevitabile: l’OTP via SMS o notifica non può essere l’unica barriera quando il dispositivo che riceve il codice è lo stesso su cui opera il malware. Servono controlli di rischio lato server, conferma delle transazioni con importo e beneficiario chiaramente vincolati, analisi comportamentale, verifica dell’integrità del dispositivo e canali di autenticazione che riducano il valore di un codice intercettato. Non è un invito ad abbandonare l’autenticazione multifattore, ma a progettarla assumendo che lo smartphone del cliente possa essere sotto controllo remoto.

I punti ancora aperti

Le informazioni pubbliche su RatHat sono solide sul piano tecnico, ma incomplete sul perimetro dell’operazione. Al momento non risultano pubblicati da Zimperium numeri verificabili su utenti infettati, Paesi più colpiti, istituti bancari bersaglio o perdite economiche attribuibili alla campagna. L’attribuzione geografica resta formulata come collegamento ad attori che “sembrano” operare dalla Cina, non come identificazione definitiva di un gruppo noto o di uno sponsor statale. Anche la presenza nelle piattaforme ufficiali non è stata confermata: le fonti descrivono soprattutto APK distribuiti tramite canali esterni e pagine ingannevoli.

Il prossimo passaggio da seguire sarà la pubblicazione di indicatori tecnici più completi, aggiornamenti di rilevamento da parte dei vendor mobile e possibili interventi di Google sulle restrizioni relative a Accessibilità e Debug wireless. Nel frattempo, il messaggio operativo è chiaro: RatHat non rende Android indifendibile, ma mostra che le funzioni nate per sviluppo, assistenza e inclusione possono diventare una catena di attacco se un’app malevola riesce a combinarle con social engineering, persistenza nativa e automazione assistita da AI.

Vedo RatHat come un campanello d’allarme utile, non come una condanna del mobile banking o dell’AI. La parte più interessante non è l’etichetta “malware con intelligenza artificiale”, che rischia di diventare uno slogan, ma il modo in cui tecniche già note vengono orchestrate meglio. Questo ci dice dove investire: meno fiducia cieca nel dispositivo, più controlli comportamentali, più telemetria mobile nelle aziende e interfacce Android che rendano davvero difficile concedere permessi critici a un’app appena scaricata.

Per il mercato italiano c’è anche un’opportunità. Banche, assicurazioni e imprese possono usare casi come RatHat per migliorare l’educazione degli utenti senza terrorismo, spostando l’attenzione da “non cliccare mai” a segnali concreti: non installare APK arrivati da link, non concedere Accessibilità a servizi non necessari, non attivare Debug wireless se non si è sviluppatori. Se la sicurezza diventa comprensibile, la tecnologia resta usabile. E se l’AI viene usata dagli attaccanti per adattarsi, può e deve essere usata dai difensori per riconoscere prima gli abusi reali.