Il malware Android RatHat usa l'IA, ma la persistenza ADB è la minaccia più grave
Il malware Android RatHat ha introdotto il controllo dello schermo guidato dall'IA, ma la sua minaccia più profonda deriva da un'architettura in tre parti progettata per sopravvivere alla rimozione. I ricercatori di sicurezza hanno reso noto il malware il 16 settembre 2026, dopo averne analizzato la navigazione automatizzata, il furto di credenziali e gli insoliti meccanismi di persistenza. Secondo quanto riportato, RatHat combina l'accesso ad Android Accessibility, il debugging wireless locale e due agenti nativi che operano oltre l'applicazione dannosa principale.
Il componente IA aiuta RatHat a interpretare interfacce in evoluzione invece di affidarsi interamente a istruzioni fisse. Questo offre agli operatori un modo più flessibile per trovare pulsanti, leggere etichette e navigare nei dispositivi compromessi. Tuttavia, l'IA non crea l'accesso iniziale. Le vittime devono comunque installare un pacchetto Android al di fuori di Google Play e concedere le autorizzazioni necessarie per avviare l'attacco.
Il cambiamento più rilevante è il tentativo di RatHat di mantenere il controllo dopo che l'applicazione visibile scompare. Malware precedenti assistiti dall'IA, incluso PromptSpy, hanno mostrato come un modello linguistico possa navigare nelle interfacce specifiche dei produttori. Secondo quanto riportato, RatHat unisce tale adattabilità all'accesso a livello shell, a overlay per il furto di credenziali, keylogging e un tunnel di rete persistente.
Il malware Android RatHat combina l'IA con un controllo persistente
RatHat trasforma un'applicazione Android dannosa nel punto d'accesso a un sistema di controllo più ampio che può sopravvivere all'applicazione stessa.
Il team zLabs di Zimperium ha reso noto RatHat dopo aver esaminato una catena d'infezione multistadio distribuita tramite smishing, malvertising, pagine di phishing e forum di terze parti. Questi canali indirizzano gli utenti verso file APK dannosi, ovvero pacchetti applicativi Android installati al di fuori del normale flusso del Play Store.
L'app dannosa richiede innanzitutto le autorizzazioni Accessibility. I servizi Android Accessibility sono progettati per aiutare le persone a interagire con i dispositivi, ma possono anche esporre il contenuto dell'interfaccia e supportare l'input automatizzato. Gli operatori di malware abusano spesso di tali capacità per leggere gli schermi, premere pulsanti e approvare azioni sensibili.
Secondo quanto riportato, RatHat usa questo accesso per abilitare le Opzioni sviluppatore e il Debugging wireless. Quindi estrae il codice di associazione a sei cifre necessario per una connessione locale Android Debug Bridge. ADB è la legittima interfaccia a riga di comando di Android per lo sviluppo, i test e l'amministrazione dei dispositivi.
Secondo l'analisi dettagliata di RatHat, questo processo consente a un agente Go incorporato di eseguire codice a livello shell senza un computer esterno. L'agente è archiviato con il nome di libreria ingannevole liblocal-service.so.
Questo agente può eseguire comandi, ottenere esenzioni dalla gestione della batteria, raccogliere input e supportare la persistenza. Zimperium afferma che può anche verificare se l'app dannosa rimane installata e ripristinarla quando necessario. Allo stesso modo, l'app può ripristinare l'agente se quel componente scompare.
Un secondo componente nativo, denominato libmedia_codec.so, funge da client Fast Reverse Proxy. Crea un tunnel tra i servizi locali sul telefono e l'infrastruttura dell'attaccante. Questo percorso offre agli operatori un accesso che non dipende esclusivamente dal canale di comando originale dell'app.
RatHat può mostrare overlay HTML che imitano applicazioni bancarie, di pagamento e di criptovalute. Un overlay colloca un'interfaccia fraudolenta sopra un'app legittima, inducendo gli utenti a inserire credenziali in campi controllati dagli attaccanti.
I ricercatori hanno inoltre individuato funzioni per intercettare messaggi SMS, notifiche e password monouso. Il malware può registrare le modifiche al testo, ispezionare le barre degli indirizzi del browser, catturare schermate e raccogliere elenchi delle applicazioni installate.
Secondo quanto riportato, il suo agente nativo monitora anche l'input tattile a basso livello. Questa funzione può aiutare a ricostruire tocchi sullo schermo, PIN, password e schemi di sblocco dai movimenti dell'utente.
Queste capacità rendono il sottosistema IA solo una parte della minaccia. RatHat usa l'IA per rendere la navigazione più adattabile, mentre l'accesso ADB e gli agenti nativi forniscono la base operativa duratura.
Il motore di navigazione IA elimina un costoso passaggio manuale
L'IA di RatHat è rilevante perché trasforma gli schermi Android in evoluzione in decisioni di navigazione strutturate senza richiedere un input costante da parte dell'operatore.
L'automazione mobile tradizionale dipende in larga misura da layout prevedibili, identificatori di risorse o istruzioni redatte con cura. Questo approccio diventa inaffidabile quando i produttori di dispositivi modificano i menu, traducono le etichette o riprogettano le finestre di dialogo di sistema.
Un'istruzione che funziona su un Google Pixel può fallire su un dispositivo Samsung, Oppo o Xiaomi. Anche le normali differenze nella dimensione dello schermo, nella versione del software e nella struttura di accessibilità possono interrompere una sequenza fissa.
RatHat affronta questo problema serializzando l'attuale albero Accessibility in XML. Questo albero descrive elementi visibili dell'interfaccia, etichette di testo, tipi di elemento e posizioni sullo schermo. Il malware invia questa istantanea strutturata a quello che Zimperium definisce un popolare assistente IA generativo.
I ricercatori non hanno identificato il servizio, il modello, l'account o la configurazione di hosting. RatHat non dovrebbe pertanto essere descritto come utilizzatore di uno specifico modello commerciale senza ulteriori prove.
Secondo quanto riportato, il componente IA risponde a domande mirate sull'interfaccia. Può restituire le coordinate centrali di un elemento denominato, determinare il testo visualizzato di un elemento o fornire istruzioni quali SCROLL_DOWN.
Si tratta di un ruolo circoscritto ma utile. Il modello non inventa autonomamente l'attacco né concede nuove autorizzazioni Android. Agisce come interprete dell'interfaccia tra l'obiettivo di un operatore e lo schermo corrente del dispositivo.
Questa distinzione è importante perché le descrizioni sensazionalistiche di malware autonomi possono oscurare i meccanismi sottostanti. RatHat continua a dipendere dall'ingegneria sociale, da autorizzazioni pericolose, dall'accesso al debugging, da codice nativo dannoso e da infrastrutture controllate dagli attaccanti.
Il suo livello IA può comunque ridurre il lavoro necessario. Un operatore non deve osservare ogni schermo infetto né mantenere uno script di automazione separato per ogni variante dell'interfaccia. Il modello può tradurre i dati dell'interfaccia in tempo reale nell'azione successiva.
Il report sulla navigazione IA di BleepingComputer afferma che questa adattabilità distingue RatHat dall'automazione basata interamente su script statici. Offre inoltre agli operatori remoti un altro modo per navigare senza un'interazione manuale continua.
La tecnica ricorda la precedente scoperta di PromptSpy. Quel malware inviava dati sullo stato dello schermo a Google Gemini e riceveva istruzioni per fissarsi nell'interfaccia delle app recenti di un dispositivo. Il comportamento di fissaggio differisce tra i produttori Android, rendendolo un problema adatto alla navigazione guidata dal modello.
ESET non aveva osservato PromptSpy nella propria telemetria quando è emersa la ricerca precedente. La sua diffusione nel mondo reale rimaneva quindi incerta. RatHat estende il concetto a un'architettura più ampia, sebbene anche la sua prevalenza resti sconosciuta.
La progressione è importante. L'IA generativa sta passando da ausilio per lo sviluppo degli attacchi a componente del ciclo di esecuzione di alcuni malware. Il suo vantaggio immediato non è un ragionamento sovrumano. È la tolleranza alle variazioni dell'interfaccia.
La persistenza, non l'IA, crea il problema di sicurezza più complesso
Il conflitto centrale di RatHat è tra adattabilità e contenimento: l'app avvia la compromissione, mentre agenti separati tentano di conservarla.
La sandbox delle applicazioni Android normalmente separa le app dalle funzioni di sistema sensibili e le une dalle altre. Secondo quanto riportato, RatHat usa l'associazione ADB locale per spostare parte della propria operazione in un contesto a livello shell con un accesso ai comandi più ampio.
Questo non significa che il malware riceva privilegi root illimitati. L'accesso shell e l'accesso root sono diversi. Tuttavia, una shell ADB può comunque eseguire azioni non disponibili a un'applicazione convenzionale e supportare l'esecuzione persistente di comandi.
L'agente Go di RatHat espone un servizio HTTP sull'interfaccia loopback del dispositivo. Il componente reverse proxy può quindi rendere quel servizio interno raggiungibile tramite un tunnel controllato dall'attaccante. Questa configurazione separa l'accesso remoto dall'interfaccia visibile dell'app dannosa.
Il design risultante presenta tre elementi cooperanti. L'app Android ottiene autorizzazioni e coordina l'attività. L'agente Go esegue comandi e gestisce la persistenza. Il proxy mantiene una rotta esterna verso i servizi locali.
Se una vittima rimuove soltanto l'applicazione, un altro componente può secondo quanto riportato reinstallarla. Se l'agente nativo si arresta, l'applicazione può ripristinare quell'agente. Questo recupero reciproco è più problematico di un singolo trucco di persistenza.
RatHat interferisce anche con i normali tentativi di rimozione. I ricercatori affermano che monitora la schermata di conferma della disinstallazione di Android, annulla l'azione e mostra un falso errore di Google Play sopra l'interfaccia.
Un comportamento anti-rimozione simile precede RatHat. Il malware Android abusa da tempo dei servizi Accessibility per premere pulsanti di navigazione o coprire i controlli di sicurezza. RatHat combina questa tecnica nota con un canale indipendente di accesso alla shell.
Le difese anti-analisi del malware aggiungono un ulteriore livello. I ricercatori hanno identificato manomissioni dei container, attributi ZIP insoliti, stringhe crittografate, pseudo-istruzioni DEX non valide e controlli runtime per gli strumenti di analisi.
Secondo quanto riportato, il suo manifest Android è di 61MB, con il 99 percento composto da due tipi di chunk non documentati. Il runtime Android ignora questi chunk, mentre alcuni strumenti di analisi possono fallire o esaurire le risorse durante la loro elaborazione.
La bomba nel manifest non ruba direttamente credenziali né controlla un telefono. Il suo scopo è rallentare l'ispezione automatizzata e rendere il pacchetto più difficile da classificare. Questo ritardo può offrire a una campagna più tempo prima che firme e indicatori circolino.
RatHat controlla anche la presenza di debugger, repackaging, emulatori, tracce di root, Frida e Xposed. Questi strumenti sono comuni negli ambienti di analisi del malware. Rilevarli consente al codice dannoso di modificare il proprio comportamento o di interrompere l'esecuzione durante l'ispezione.
L'architettura combinata mette sotto pressione i difensori che si concentrano solo sui file applicativi. Rimuovere un APK, trovare una corrispondenza con un hash noto o bloccare un server di comando potrebbe non eliminare ogni componente attivo.
I segnali comportamentali diventano più importanti. I team di sicurezza possono cercare concessioni sospette di Accessibility, attività inattesa di Debugging wireless, associazioni ADB locali, daemon nativi insoliti e tunnel inversi persistenti.
Questo non rende inutile il rilevamento basato sulle firme. Hash di pacchetti, domini, certificati e indicatori di rete noti restano preziosi. RatHat mostra perché questi segnali necessitano del supporto del monitoraggio runtime e dello stato del dispositivo.
Le app bancarie affrontano un avversario a livello di interfaccia
RatHat attacca l'interazione fidata tra un utente e un'app finanziaria, non soltanto i dati archiviati all'interno di quell'app.
Un'applicazione bancaria può crittografare il proprio database locale e proteggere il traffico verso il server mentre il malware osserva lo schermo dell'utente. Se un servizio Accessibility ostile può leggere il contenuto dell'interfaccia o iniettare tocchi, le protezioni a livello applicativo affrontano un problema diverso.
Secondo quanto riportato, RatHat mostra false interfacce HTML sopra app bancarie e di criptovalute mirate. Una vittima può credere che una richiesta di accesso appartenga al servizio autentico mentre inserisce i propri dati in un overlay dannoso.
Il malware può quindi intercettare messaggi SMS o contenuti delle notifiche contenenti codici di verifica. Può inoltre raccogliere il testo digitato e monitorare gli indirizzi del browser, fornendo agli operatori un contesto attorno alle credenziali acquisite.
Android ha aggiunto difese contro queste tecniche. Android 15 limita l'esposizione di alcune password monouso durante la condivisione dello schermo e ai servizi di ascolto delle notifiche. Android 16 ha introdotto un modo per gli sviluppatori di contrassegnare gli elementi sensibili dell'interfaccia.
L'impostazione accessibilityDataSensitive può impedire ai servizi Accessibility non verificati di leggere o interagire con le visualizzazioni protette. Le linee guida di Android 16 di Google ne raccomandano l'uso per password, informazioni finanziarie e altri campi sensibili.
Gli sviluppatori possono inoltre utilizzare i segnali di ambiente di Play Integrity. Il verdetto di accesso alle app può indicare se un'altra applicazione dispone di autorizzazioni in grado di acquisire lo schermo, visualizzare overlay o controllare il dispositivo.
Queste difese aumentano il costo operativo di RatHat, ma non eliminano il problema. La protezione dipende dalla versione di Android, dalla configurazione del dispositivo, dall'adozione da parte degli sviluppatori e dal fatto che l'app malevola abbia già stabilito un altro canale di controllo.
Accessibility presenta inoltre un difficile compromesso a livello di piattaforma. Android deve supportare software assistivi legittimi che leggono i contenuti dell'interfaccia ed eseguono azioni per gli utenti. Bloccare ogni interazione automatizzata danneggerebbe questi strumenti essenziali.
Google esamina gli strumenti Accessibility distribuiti tramite Play e avverte degli usi ingannevoli. Le sue linee guida su Play Protect affermano che un servizio sospetto può richiedere il controllo completo del dispositivo e accedere a informazioni personali o finanziarie.
Secondo quanto riportato, RatHat entra tramite download di APK al di fuori di Google Play. Ciò limita l'esposizione diretta attraverso lo store ufficiale, ma il sideloading rimane possibile tramite browser, messaggi, forum e marketplace di terze parti.
Google ha riferito nel marzo 2026 che il malware compariva nelle fonti di sideloading con una frequenza oltre 90 volte superiore rispetto a Google Play. L'azienda sta ampliando la verifica degli sviluppatori, con requisiti regionali per l'installazione previsti a partire dal 30 settembre 2026.
La tempistica colloca RatHat accanto a una più ampia risposta della piattaforma alla distribuzione malevola. La verifica degli sviluppatori può aumentare la responsabilizzazione per il software installato oltre Play, anche se resteranno disponibili percorsi di installazione avanzati.
Anche gli istituti finanziari hanno del lavoro da fare. Le azioni ad alto rischio non dovrebbero dipendere interamente da prove visualizzate o inserite su un telefono potenzialmente compromesso.
La conferma delle transazioni può integrare punteggi di rischio lato server, cronologia dei dispositivi attendibili, cambiamenti comportamentali e limiti per nuovi destinatari aggiunti di recente. Le banche possono inoltre sottoporre le sessioni a ulteriori verifiche quando i segnali di integrità del dispositivo o di accesso alle app indicano un rischio elevato.
Per i team aziendali, i dispositivi mobili meritano la stessa profondità di risposta agli incidenti dei laptop. Un telefono che contiene app di autenticazione, messaggi di lavoro, sessioni cloud e accesso bancario può diventare un ponte verso diversi sistemi.
La portata e l'attribuzione di RatHat restano poco chiare
Le capacità del malware sono documentate in dettaglio, ma il numero di vittime, la scala della campagna e l'identità degli operatori restano irrisolti.
Zimperium collega RatHat ad attori che sembrano operare dalla Cina. Le prove pubbliche includono richieste in lingua cinese trovate nel malware e infrastrutture di campagna osservate.
La lingua non costituisce un'attribuzione definitiva. Gli sviluppatori di malware possono riutilizzare codice, inserire indizi fuorvianti, lavorare oltre i confini nazionali o vendere strumenti a operatori non correlati. Le informazioni disponibili non identificano un gruppo nominato né uno sponsor governativo.
La ricerca pubblica non fornisce neppure un numero confermato di infezioni. Non elenca i Paesi colpiti, le banche prese di mira, la durata della campagna o il numero di server di comando attivi.
Queste informazioni mancanti limitano le conclusioni sull'esposizione immediata. RatHat potrebbe sostenere una campagna strettamente mirata, un servizio criminale in sviluppo o un'operazione più ampia che i ricercatori hanno osservato solo in parte.
Il servizio AI non identificato introduce un'altra incertezza. Gli investigatori non hanno spiegato pubblicamente come il malware si autentichi all'assistente, con quale frequenza invii richieste o cosa accada quando la connettività viene meno.
Le richieste AI basate sul cloud possono generare attività di rete rilevabile. I fornitori possono inoltre sospendere account abusivi, filtrare prompt sospetti o collaborare alle indagini. Gli aggressori potrebbero rispondere ruotando gli account, usando servizi proxy o passando a modelli ospitati localmente.
Anche l'affidabilità del modello merita attenzione. L'automazione dell'interfaccia può fallire quando i dati XML sono incompleti, le etichette sono ambigue o le schermate contengono finestre di dialogo inattese. Un tocco errato può esporre il malware, interrompere un attacco o impedire agli operatori di accedere.
Queste limitazioni non neutralizzano la minaccia. Mostrano che il malware assistito dall'AI dipende ancora da infrastruttura, credenziali, connettività e logiche di fallback progettate con cura.
Il precedente caso PromptSpy offre un utile riferimento. La sua funzionalità assistita dal modello affrontava un ristretto compito di persistenza, mentre un modulo VNC separato abilitava il controllo remoto. I ricercatori non hanno potuto confermare se i suoi campioni rappresentassero una campagna attiva o una proof of concept.
RatHat sembra più completo sotto il profilo operativo. I suoi canali di distribuzione, gli overlay per le credenziali, il sistema di comando, i servizi nativi e il componente di tunneling formano una catena d'attacco coerente.
Tuttavia, la completezza tecnica non equivale a un'implementazione su larga scala. I lettori dovrebbero evitare di considerare ogni capacità documentata come prova che abbia colpito una vasta popolazione.
Zimperium vende inoltre prodotti di sicurezza mobile e afferma che i suoi prodotti rilevano RatHat. Questo contesto commerciale non invalida le conclusioni tecniche, ma la replica indipendente resta preziosa.
Un secondo resoconto tecnico di The Hacker News conferma l'architettura sulla base della divulgazione di Zimperium. Non rappresenta un'analisi indipendente del malware con campioni separati.
La conclusione più solida al momento è più circoscritta. I ricercatori hanno analizzato un malware che combina l'interpretazione dell'interfaccia guidata dall'AI con tecniche consolidate di acquisizione del controllo Android e un'architettura basata su ADB insolitamente persistente.
Tre segnali mostreranno se RatHat cambierà il malware mobile
Il prossimo banco di prova è capire se le tecniche di RatHat si diffonderanno oltre una singola famiglia segnalata e imporranno cambiamenti misurabili a difensori, app finanziarie e Android.
Il primo segnale è la presenza di prove indipendenti della campagna. Altri ricercatori dovrebbero cercare campioni corrispondenti, infrastrutture di comando, certificati di firma, pagine di distribuzione e infezioni nella telemetria dei clienti.
La geografia confermata delle vittime chiarirebbe se RatHat prende di mira particolari banche o regioni. Un numero crescente di campioni suggerirebbe sviluppo o distribuzione attivi, anziché un esperimento tecnico isolato.
L'assenza di una telemetria diffusa indebolirebbe le affermazioni secondo cui RatHat rappresenta un'ondata globale immediata. Non cancellerebbe la lezione architetturale, ma cambierebbe il livello di urgenza.
Il secondo segnale è il riuso della catena di persistenza ADB locale. Gli autori di malware copiano frequentemente le tecniche che si dimostrano affidabili, soprattutto quando la ricerca pubblica rivela dettagli di implementazione sufficienti a ispirare imitazioni.
I difensori dovrebbero monitorare nuove famiglie che abilitano Wireless Debugging, recuperano codici di associazione, distribuiscono agenti a livello di shell e mantengono l'accesso dopo la rimozione dell'applicazione. Un'adozione ripetuta renderebbe questo meccanismo più rilevante del marchio RatHat.
Android e i produttori di dispositivi possono rispondere irrigidendo le transizioni tra Accessibility, Developer Options, associazione wireless e processi shell in background. Avvisi migliori per gli utenti potrebbero inoltre rendere visibili combinazioni sospette di queste azioni.
Il terzo segnale è l'espansione dell'AI runtime oltre la consultazione dell'interfaccia. Secondo quanto riportato, RatHat chiede a un modello coordinate, testo visibile e comandi di navigazione. Campioni futuri potrebbero usare modelli per classificare schermate finanziarie, adattare prompt fraudolenti o selezionare azioni in base a obiettivi più ampi.
Questo sviluppo rafforzerebbe l'argomento a favore del monitoraggio del traffico verso servizi AI nelle indagini sul malware. Metterebbe inoltre pressione sui fornitori di modelli affinché identifichino gli abusi automatizzati senza bloccare flussi di lavoro legittimi di accessibilità e test.
Se l'AI resterà limitata a pochi compiti di navigazione fragili, RatHat apparirà come un aggiornamento incrementale dell'automazione. Se più famiglie di malware adotteranno cicli decisionali, i difensori dovranno affrontare un comportamento più variabile tra i dispositivi.
Gli utenti possono ridurre il rischio attuale senza attendere questi segnali. Evitate file APK inviati tramite messaggi non richiesti, pubblicità o pagine di download sconosciute. Considerate le richieste Accessibility inattese come un serio avvertimento, soprattutto da app non correlate a funzioni assistive.
Mantenete Play Protect attivato e consentitegli di analizzare le applicazioni sconosciute. In caso di sospetta compromissione, controllate i servizi Accessibility abilitati, l'accesso alle notifiche, le app con privilegi di amministratore del dispositivo, Developer Options e Wireless Debugging.
Un dispositivo che blocca la disinstallazione o ripristina un'applicazione rimossa richiede più di un altro normale tentativo di rimozione. Disconnettetelo da account e reti sensibili, quindi rivolgetevi a un supporto qualificato per la risposta agli incidenti.
Le organizzazioni dovrebbero revocare le sessioni attive, ruotare le credenziali esposte e rivedere l'attività finanziaria da un dispositivo attendibile separato. Potrebbe rendersi necessario un ripristino ai dati di fabbrica, ma chi risponde all'incidente dovrebbe preservare le prove quando un'indagine è rilevante.
Il malware Android RatHat merita attenzione perché combina una navigazione adattabile con un controllo duraturo del dispositivo. La domanda decisiva è se i difensori possano contenere ogni componente, non se la sua AI possa premere il pulsante successivo.
