RatHat trasforma gli strumenti di debug di Android e l’IA generativa in un canale di controllo persistente

Una nuova famiglia di malware Android, denominata RatHat, combina l’abuso di Accessibility, l’associazione autonoma tramite ADB, overlay per il furto di credenziali, servizi nativi in background e la navigazione dell’interfaccia guidata dall’IA. I ricercatori hanno segnalato il malware il 17 settembre 2026, attribuendone le attività a criminali informatici con base in Cina.

RatHat raggiunge le vittime tramite annunci malevoli, phishing via SMS, pagine di download ingannevoli, portali di terze parti e forum. Queste campagne inducono gli utenti a installare pacchetti APK ospitati al di fuori di Google Play.

Una volta installato e dopo aver ottenuto i permessi di Accessibility, RatHat può attivare Wireless Debugging, associarsi al servizio Android Debug Bridge locale del dispositivo e ottenere l’esecuzione a livello di shell. I suoi componenti possono quindi mantenere l’accesso anche se la vittima rimuove l’applicazione Android visibile.

Gli APK installati tramite sideloading aprono la strada all’abuso di Accessibility

L’APK iniziale funge da dropper per il payload principale di RatHat. Include inoltre protezioni progettate per ostacolare l’analisi automatizzata, il debugging e il reverse engineering.

L’infezione dipende in larga misura dall’ingegneria sociale. Gli utenti Android devono installare il pacchetto al di fuori di Google Play e concedere poi permessi che attribuiscono all’applicazione un controllo significativo sull’interfaccia.

I servizi di Accessibility sono centrali per l’attacco. Sebbene siano stati progettati per aiutare gli utenti a interagire con i dispositivi, se utilizzati impropriamente possono consentire a un’applicazione di osservare gli elementi dell’interfaccia ed eseguire azioni sintetiche.

Dopo aver ottenuto questo accesso, RatHat può navigare nelle impostazioni di Android, attivare le Opzioni sviluppatore, abilitare Wireless Debugging e recuperare il codice a sei cifre utilizzato per l’associazione ADB. Può così stabilire una connessione di debugging locale senza che sia necessario collegare fisicamente un computer controllato dall’attaccante.

Questa tecnica di autoassociazione consente a RatHat di accedere a una shell ADB e a funzionalità che vanno oltre quelle implementate direttamente nell’applicazione malevola. Meccanismi simili sono già comparsi nelle famiglie di malware Android ToxicPanda e RedHook.

Le versioni di Android interessate non sono state rese note. Al momento non sono disponibili nomi di pacchetti malevoli, hash, domini, indirizzi IP o altri indicatori specifici della campagna.

Tre componenti creano una persistenza ridondante

RatHat utilizza tre livelli cooperanti, invece di affidarsi a un unico pacchetto Android.

Il primo è la stessa applicazione malevola. Gestisce l’accesso ad Accessibility, abilita le funzioni di debugging, distribuisce gli altri componenti, mostra overlay di phishing, intercetta le comunicazioni, registra lo schermo e ostacola la rimozione.

Il secondo componente è un agente locale basato su Go, camuffato o impacchettato come liblocal-service.so. Grazie all’accesso ottenuto tramite il demone ADB locale, l’agente può eseguire comandi forniti dall’attaccante, richiedere esenzioni dalle restrizioni per la gestione della batteria, mantenere la persistenza e raccogliere pressioni dei tasti o tocchi sullo schermo.

L’agente verifica inoltre se il malware Android è ancora installato. Se l’applicazione è stata rimossa, può reinstallarla.

Il terzo livello è un client proxy inverso FRP. Un’analisi dell’architettura di RatHat identifica la sua libreria come libmedia_codec.so. Il componente riceve la configurazione del tunnel tramite l’agente Go e crea una connessione inversa persistente verso l’infrastruttura di comando e controllo.

Il tunnel offre agli operatori un canale generico verso il demone ADB del dispositivo, indipendente dai comandi integrati in RatHat. Può mantenere l’accesso anche quando singole funzioni del malware vengono interrotte.

La persistenza funziona in entrambe le direzioni. L’applicazione Android può ripristinare l’agente locale se quest’ultimo si arresta o scompare, mentre l’agente può reinstallare l’applicazione. Rimuovere soltanto l’icona dell’app o il pacchetto visibile può quindi lasciare il dispositivo compromesso.

RatHat ostacola attivamente anche la disinstallazione. Annulla il flusso di conferma di Android e mostra una schermata di errore contraffatta nello stile di Google Play, inducendo la vittima a credere che la rimozione non sia riuscita per una ragione legittima legata al sistema.

L’IA generativa interpreta le schermate Android in tempo reale

La caratteristica distintiva di RatHat è un meccanismo di controllo assistito dall’IA che interpreta l’interfaccia utente corrente, invece di dipendere interamente da coordinate fisse e script predefiniti.

Il malware serializza in XML la gerarchia Accessibility di Android in tempo reale. Invia quindi questa rappresentazione a un assistente di IA generativa molto diffuso, ma non identificato.

Secondo le informazioni disponibili, il sistema di IA viene utilizzato per tre attività:

• Individuare un elemento dell’interfaccia specificato per nome e restituirne le coordinate centrali in formato JSON.
• Estrarre il testo attualmente visualizzato da un elemento selezionato.
• Produrre istruzioni di navigazione come SCROLL_DOWN.

Si crea così un ciclo decisionale dinamico. Se un pulsante cambia posizione, un’applicazione visualizza un testo diverso o una schermata richiede lo scorrimento, l’IA può interpretare l’albero Accessibility aggiornato e suggerire l’azione successiva.

Le automazioni rigide spesso si interrompono quando le applicazioni modificano layout, lingue o stati dell’interfaccia. L’approccio di RatHat consente invece agli operatori di descrivere un elemento obiettivo e delegare al servizio di IA parte del processo di navigazione.

L’identità dell’assistente è sconosciuta. I ricercatori non hanno reso noto quale modello o provider siano coinvolti, né il protocollo di comunicazione, la configurazione dell’account o se il servizio venga utilizzato direttamente oppure tramite infrastrutture controllate dall’attaccante.

Questa funzionalità non rende il malware completamente autonomo. RatHat dipende ancora da un’architettura di controllo articolata, da istruzioni di comando e controllo, dall’accesso ad Accessibility e dall’esecuzione locale tramite ADB. Tuttavia, l’IA riduce la necessità per gli operatori di navigare manualmente ogni schermata o mantenere script per ciascuna variante dell’interfaccia.

Il furto ai danni delle banche è solo una parte della minaccia

RatHat può sovrapporre finestre HTML alle applicazioni bancarie e di criptovalute per acquisire le credenziali degli account. Può inoltre intercettare SMS e notifiche, esponendo potenzialmente le password monouso utilizzate durante l’autenticazione.

Le sue capacità di sorveglianza si estendono all’intero dispositivo. Includono:

• Acquisizione di PIN, password e sequenze di sblocco della schermata di blocco.
• Registrazione delle credenziali inserite nelle applicazioni.
• Monitoraggio degli eventi di modifica del testo e delle pressioni dei tasti.
• Raccolta degli URL inseriti nelle barre degli indirizzi dei browser.
• Registrazione dei tocchi sullo schermo tramite l’agente Go.
• Creazione di screenshot e registrazioni tramite l’API MediaProjection di Android.
• Raccolta dei file e dell’inventario delle applicazioni installate.
• Navigazione remota nelle applicazioni e nelle impostazioni di sistema.
• Esecuzione di comandi arbitrari tramite la shell ADB.

Il tunnel inverso aumenta l’impatto della minaccia perché offre un accesso continuativo che va oltre l’insieme predefinito di funzionalità del malware. Un operatore che riesca a raggiungere il demone ADB può utilizzare le funzioni a livello di shell esposte dal dispositivo compromesso.

RatHat rappresenta quindi un rischio per conti bancari, servizi di criptovaluta, messaggi privati, file archiviati, codici di autenticazione e segreti utilizzati per sbloccare il dispositivo. La registrazione dello schermo e il monitoraggio dei tocchi possono inoltre rivelare informazioni che non verrebbero acquisite tramite i tradizionali overlay per il furto di credenziali.

La campagna segue una tendenza più ampia delle minacce Android che utilizzano pacchetti installati tramite sideloading per attività di sorveglianza invasiva. Un altro esempio recente, il malware Mantax Otax, è stato distribuito anch’esso tramite APK esterni a Google Play, sebbene capacità e architettura differiscano da quelle di RatHat.

Strutture APK malformate complicano l’analisi

Gli sviluppatori di RatHat utilizzano diverse tecniche anti-analisi per ottenere comportamenti differenti nei parser integrati in Android e nei più comuni strumenti di reverse engineering.

Alcuni file sono dichiarati come directory oppure contrassegnati con il flag di crittografia per uso generico degli archivi ZIP. libziparchive di Android può ignorare queste voci, mentre utility come unzip e apktool le elaborano in modo diverso.

AndroidManifest.xml contiene intestazioni di chunk non documentate 0x9999. Il runtime nativo di Android ignora queste strutture, ma i sistemi di analisi automatizzata possono andare in crash, esaurire il tempo disponibile o non riuscire a elaborare il pacchetto. È stato inoltre segnalato che il manifest raggiunge 61 MB, una dimensione anomala che sottopone a ulteriore pressione le pipeline di scansione.

RatHat inserisce anche pseudo-istruzioni DEX non valide con un attributo element_width errato, con il rischio di compromettere i disassembler. Un meccanismo di protezione a doppio livello delle stringhe, identificato come StringCrypto: Base64, rende più difficile l’analisi statica.

Queste difese non forniscono direttamente il controllo del dispositivo. Servono a ritardare la classificazione, produrre risultati incoerenti tra gli strumenti e ridurre l’affidabilità dei flussi automatizzati di analisi dei malware.

I ricercatori ritengono che RatHat sia gestito da criminali informatici con base in Cina. I prompt in lingua cinese inviati al sottosistema di IA sostengono questa valutazione, ma non è stato confermato alcun gruppo di minacce specifico. L’attribuzione resta provvisoria.

Il rilevamento deve andare oltre l’applicazione visibile

Gli utenti dovrebbero evitare gli APK promossi tramite messaggi di testo non richiesti, annunci, forum, pagine di phishing o portali di download sconosciuti. Non si dovrebbe concedere l’accesso ad Accessibility alle applicazioni, a meno che la loro funzione legittima non lo richieda chiaramente.

L’attivazione inattesa delle Opzioni sviluppatore o di Wireless Debugging è un segnale d’allarme significativo. Gli utenti dovrebbero inoltre verificare la presenza di richieste di associazione ADB inspiegabili, richieste di esenzione dalla gestione della batteria, permessi sospetti per la registrazione dello schermo e applicazioni che mostrano errori con il tema di Google Play durante la rimozione.

Le scansioni di Google Play Protect possono aiutare a individuare le applicazioni dannose, ma i servizi indipendenti di RatHat rendono la risposta più complessa della semplice eliminazione di un APK.

I team aziendali e di sicurezza mobile dovrebbero cercare:

• Servizi Accessibility non autorizzati.
• Attivazioni inattese di Wireless Debugging.
• Eventi di associazione ADB locale non riconosciuti.
• Librerie native denominate liblocal-service.so o libmedia_codec.so.
• Traffico insolito del proxy inverso FRP.
• Processi persistenti che sopravvivono alla rimozione dell’applicazione.
• Reinstallazioni ripetute di un pacchetto precedentemente eliminato.
• Schermate contraffatte di errore durante la disinstallazione, nello stile di Google Play.

I soli nomi delle librerie non costituiscono una prova sufficiente dell’infezione e dovrebbero essere valutati insieme alle attività relative a processi, pacchetti, rete e ADB.

Non è stata pubblicata alcuna procedura completa di bonifica da parte dei vendor. Poiché l’agente Go di RatHat può sopravvivere alla rimozione dell’applicazione principale e reinstallarla successivamente, chi interviene sull’incidente deve verificare che siano stati eliminati anche il servizio accessibile tramite ADB e il tunnel inverso. In caso contrario, la rimozione apparente potrebbe eliminare soltanto la parte più visibile della compromissione.