RatHat usa l’AI per guidare Android e ottiene shell via ADB senza root

🛡️ Executive Summary

• RatHat usa un assistente AI generativo per interpretare in tempo reale l’interfaccia Android e guidare automaticamente click, testo e navigazione.
• Accessibility abilita Developer Options e Wireless Debugging, permettendo al malware di auto-associarsi ad ADB e ottenere privilegi shell senza root.
• Un agente Go e un tunnel FRP sopravvivono all’app principale, rubano PIN e OTP e possono reinstallare RatHat dopo la rimozione.

RatHat porta l’automazione AI dentro una catena di compromissione Android già capace di superare il sandbox applicativo senza utilizzare il root. Il nuovo malware individuato da Zimperium zLabs combina phishing, abuso dei servizi di Accessibility, auto-pairing con Android Debug Bridge Wireless, agenti nativi indipendenti e un motore generativo che interpreta l’interfaccia del dispositivo. Il risultato non è un malware “creato dall’AI”, ma qualcosa di più concreto: l’intelligenza artificiale viene utilizzata durante l’operazione per rendere adattabile il controllo dell’interfaccia, mentre ADB fornisce i privilegi shell necessari alle funzioni più invasive.

RatHat arriva da APK esterni e conquista Accessibility

La ricerca tecnica originale pubblicata da Zimperium zLabs descrive una distribuzione attraverso smishing, malvertising, forum e portali di download fraudolenti che inducono la vittima a installare manualmente APK apparentemente legittimi. Un dropper trasporta il payload all’interno di asset cifrati e utilizza le API native SessionInstaller per aggirare alcune restrizioni introdotte da Android sul sideloading e sull’accesso ai servizi di accessibilità. Non emerge quindi una vulnerabilità zero-day capace di infettare automaticamente lo smartphone: l’attacco continua ad avere bisogno di una fase iniziale di social engineering.

Dopo l’installazione, Accessibility Service diventa il vero punto di rottura del modello di sicurezza. RatHat utilizza interazioni sintetiche per premere sette volte sul numero di build, attivare Developer Options, raggiungere Wireless Debugging e leggere dalla stessa interfaccia il codice di pairing ADB e la porta dinamica. È la stessa superficie operativa che ricorre sempre più spesso nel malware mobile: StreamRat combina Accessibility, controllo remoto e overlay dopo essere stato distribuito attraverso Meta Ads, confermando che il problema non è il singolo permesso ma ciò che un’app malevola riesce ad automatizzare dopo averlo ottenuto.

L’AI non viola Android: interpreta l’interfaccia per RatHat

La caratteristica nuova è il Generative AI UI-Automation Engine. RatHat serializza l’albero Accessibility visualizzato sul dispositivo in formato XML e lo invia a uno dei principali assistenti di AI generativa, che Zimperium non identifica pubblicamente. Il modello deve risolvere compiti molto specifici: individuare il centro di un elemento dell’interfaccia e restituirne le coordinate in JSON, determinare il testo realmente visualizzato e produrre istruzioni operative come SCROLL_DOWN. In altre parole, l’LLM viene usato come interprete dinamico della UI, sostituendo parte della logica rigida normalmente codificata negli script di automazione.

Questo dettaglio ridimensiona e contemporaneamente rende più interessante il riferimento all’AI. Non è il modello generativo a ottenere i privilegi né a compromettere Android: la catena dipende da Accessibility e ADB. L’AI serve invece a rendere l’automazione meno fragile quando cambiano posizione, testo o struttura degli elementi grafici. È un’evoluzione diversa da quella osservata nel malware AI utilizzato per automatizzare rapidamente la costruzione di infrastrutture C2: con RatHat il modello entra direttamente nel loop operativo sul dispositivo compromesso.

Leggi anche: RedHook ottiene privilegi shell su Android attraverso ADB Wireless senza bisogno del root

ADB trasforma un’app Android in un operatore con privilegi shell

Ottenuto il codice di pairing, RatHat utilizza una libreria ADB incorporata per collegarsi al daemon locale e conquistare un contesto shell UID 2000. La documentazione ufficiale Android su ADB Wireless conferma che il debugging Wi-Fi richiede normalmente Developer Options, Wireless Debugging e un codice di associazione: RatHat automatizza precisamente questa procedura dall’interno del dispositivo invece di utilizzare una workstation esterna.

La tecnica assume ancora maggiore rilevanza dopo l’arrivo di ADB Wi-Fi 2.0 su Android 17, che Google ha appena riprogettato anche nella gestione delle reti fidate. Una volta ottenuta la shell, RatHat deposita in /data/local/tmp liblocal-service.so, un agente scritto in Go che può modificare le restrizioni energetiche, mantenere attivo il malware e disabilitare o disinstallare altri pacchetti. Un secondo binario, libmedia_codec.so, è in realtà un client FRP che crea un reverse tunnel persistente verso l’infrastruttura degli aggressori. L’app Android diventa così soltanto uno dei componenti della compromissione.

PIN e password vengono ricostruiti dai tocchi sullo schermo

Il passaggio alla shell permette una funzione particolarmente invasiva. Il Go Agent esegue getevent per leggere gli eventi grezzi provenienti da /dev/input, normalmente inaccessibili alle comuni applicazioni Android. RatHat registra coordinate e timestamp dei tocchi e li confronta con layout delle tastiere e dei keypad presenti nel proprio database. Un punto toccato sullo schermo può così essere trasformato nel numero corrispondente di un PIN, mentre una sequenza di coordinate sulla griglia 3×3 consente di ricostruire un pattern di sblocco. Secondo Zimperium, questa tecnica continua a funzionare anche quando FLAG_SECURE impedisce screenshot o letture tradizionali tramite Accessibility.

A questa raccolta si aggiungono overlay HTML contro applicazioni bancarie e crypto, intercettazione di SMS e OTP, keylogging tramite eventi Accessibility, lettura degli URL dai browser e streaming dello schermo. È una convergenza già visibile nel recente Mantax Otax, che combina spyware, furto di PIN e controllo remoto su Android, ma RatHat sposta più in basso il livello di controllo sfruttando direttamente il contesto shell.

Continua con:

• ToxicPanda 2.0 automatizza ADB Wireless e porta il controllo remoto a 167 comandi
• RokaRolla ruba il PIN, disattiva Play Protect e punta al takeover completo di Android

La persistenza è il vero salto operativo di RatHat

La parte più pericolosa di RatHat non è quindi l’etichetta “AI-powered”, ma l’architettura costruita fuori dal normale ciclo di vita dell’app Android. Se la vittima prova a disinstallarla, il malware può intercettare la schermata di conferma e mostrare un falso errore Google Play. Anche qualora la rimozione riesca, liblocal-service.so continua a operare nel contesto shell, verifica l’assenza del pacchetto e può reinstallarlo concedendogli nuovamente permessi e Accessibility. L’app, a sua volta, mantiene un heartbeat capace di ridistribuire l’agente se questo viene terminato.

Zimperium associa RatHat ad attori che sembrano operare dalla Cina, soprattutto sulla base dei prompt in lingua cinese osservati nel sottosistema AI. È un indicatore tecnico, non un’attribuzione definitiva. Più solida è invece la conclusione sul modello operativo: Accessibility viene utilizzata per conquistare ADB, ADB porta alla shell, i daemon nativi mantengono persistenza e tunnel, mentre l’AI rende adattabile la navigazione dell’interfaccia. Il modello generativo non sostituisce le tecniche tradizionali del malware Android: le rende più automatiche proprio nel punto in cui l’interfaccia dell’utente costituiva ancora un ostacolo.