RedHook RAT: malware Android ottiene shell senza root né PC

Il trojan RedHook aggiorna il proprio arsenal: abusa di Wireless ADB, Shizuku e Accessibility Service per ottenere privilegi shell su dispositivi non-rooted

Il 9 luglio 2026 Group-IB ha pubblicato l'analisi di una nuova versione di RedHook, Android RAT già noto da un anno. Il trojan abusa funzionalità legittime di sviluppo Android — Wireless Debugging, Accessibility Service, il framework open source Shizuku — per ottenere privilegi shell (uid 2000) senza richiedere un computer collegato, vulnerabilità zero-day o accesso root. La rilevazione non amplifica un nuovo exploit: documenta un cambiamento nel threat model del malware mobile, dove le porte aperte per comodità degli sviluppatori diventano vettori di privilege escalation più affidabili delle catene di bug.

Punti chiave

RedHook automatizza via Accessibility Service l'attivazione di Developer Options e Wireless ADB, poi si auto-paira via loopback 127.0.0.1 come client autorizzato del dispositivo stesso.
Integra codice dal framework Shizuku legittimo per eseguire un server privilegiato (libmx.so) con identità uid 2000, ottenendo permessi runtime, comandi shell arbitrari e cattura touch event a basso livello.
La campagna si è espansa dal Vietnam all'Indonesia: distribuzione via social engineering con impersonificazione di agenzie governative e istituzioni finanziarie, APK ospitati su AWS S3 e GitHub.
Il kit di persistenza include attività 1×1 pixel, audio silenzioso, WakeLock, oom_score_adj a -1000, resurrezione incrociata tra due servizi e allarme ogni 5 minuti.

Come il dispositivo diventa "host di se stesso"

Il meccanismo centrale è l'abuso di Android Wireless Debugging, introdotto in Android 11 per eliminare il cavo USB nello sviluppo. RedHook non sfrutta un difetto di implementazione: ne strumentalizza il design. Secondo Group-IB, il malware usa i permessi Accessibility Service per automatizzare interazioni UI non osservabili dall'utente: sette tap sul numero di build per sbloccare Developer Options, attivazione di Wireless Debugging, recupero del codice di pairing. Incorpora poi un client ADB proprio e si connette al daemon ADB del dispositivo via interfaccia di loopback 127.0.0.1. Il flusso ADB completo — pairing, autorizzazione, sessione — resta confinato sul dispositivo.

"The malware embeds its own ADB client and connects to the device's own daemon over the loopback interface (127.0.0.1), so that the whole ADB flow runs on-device, neither needing a PC nor USB cable" — Group-IB researchers

Questa architettura bypassa due assunti classici della sicurezza Android: che ADB richieda un host esterno fidato, e che l'abilitazione manuale di Developer Options costituisca barriera sufficiente. Il dispositivo è contemporaneamente target e host di attacco.

Da uid 1000 a 2000: la scelta di Shizuku al posto del root

Con la sessione ADB stabilita, RedHook integra codice dal framework Shizuku — strumento legittimo usato da sviluppatori per eseguire API di sistema protette su dispositivi non-rooted. Group-IB documenta che il malware avvia un server "libmx.so" con identità uid 2000 (shell), non root (uid 0). A uid 2000, RedHook concede a sé stesso permessi runtime, esegue comandi shell arbitrari, installa e rimuove applicazioni silenziosamente, cattura touch event a basso livello e ottiene WRITE_SECURE_SETTINGS. La versione attuale supporta 53 comandi distinti dal server C2. La scelta di fermarsi a uid 2000 anziché puntare al root è funzionale: evita la fragilità delle catene di exploit e l'instabilità tipica dei dispositivi modificati. Shell-level privileges sono sufficienti per le operazioni RAT (screen streaming via RTMP bypassando MediaProjection, keylogging, esfiltrazione dati via WebSocket e REST API) e generano meno attrito rilevabile.

Il motore di persistenza: undici meccanismi sovrapposti

Group-IB descrive un sistema di persistenza multi-layer che opera su più assi contemporaneamente. L'attività in foreground è una finestra 1×1 pixel, invisibile all'utente ma sufficiente a evitare la terminazione per inattività. Un flusso audio silenzio via MediaSession mantiene aperta la sessione multimediale. WakeLock blocca la sospensione del processo. Il valore oom_score_adj è forzato a -1000, massima resistenza al low-memory killer di Android. Due servizi implementano resurrezione incrociata con bindService() e flag BIND_AUTO_CREATE: la morte di uno innesca il riavvio dell'altro. Un allarme ogni 5 minuti funge da watchdog. Su BOOT_COMPLETED, il malware riattiva la catena Wireless ADB-Accessibility-Developer Options da zero. Non si affida a un singolo punto di fallimento.

Targeting e distribuzione: il perimetro finanziario del Sud-Est asiatico

La prima campagna, documentata da Cyble nel luglio 2025, era concentrata sul Vietnam. Group-IB rileva ora espansione all'Indonesia, con un repertorio di social engineering mirato: chiamate e messaggi che impersonano agenzie governative o istituzioni finanziarie, siti clone del Google Play Store, APK ospitati su infrastrutture cloud legittime (AWS S3, GitHub). I domini C2 identificati — skt.3n7wj[.]com, sktv.3n7wj[.]com per WebSocket, api.3n7wj[.]com per REST — sono attivi nella catena di esfiltrazione. L'hash SHA-256 del payload è 453333bffdd1850ea2e0647f7c805530b578919978a01b1e2be52d6eb2add946, secondo CyberSecurityNews. Nel codice sono presenti routine OEM-specific per abilitare Wireless ADB su Google, Huawei, Meizu, Oppo, Samsung, Vivo, Xiaomi. Group-IB non le documenta come attivamente invocate: rimangono capacità future, non evidenza di campagne in corso.

Cosa fare adesso

Trattare ogni richiesta di Accessibility Service con diffidenza massima: è il prerequisito che abilita l'intera catena di auto-privileging, non una funzionalità innocua.
Impedire l'installazione di APK da fonti esterne al Google Play Store: la catena di distribuzione documentata passa esclusivamente per sideloading social-engineered.
Verificare che Developer Options e Wireless Debugging siano disabilitati sui dispositivi aziendali e personali non utilizzati per sviluppo: l'abuso richiede entrambi attivi.
Monitorare connessioni WebSocket verso domini sospetti e sessioni RTMP non autorizzate: lo screen streaming di RedHook bypassa il consenso utente tipico di MediaProjection.

L'insegnamento: quando le funzioni sviluppatore diventano armi

La novità di RedHook non è tecnica nel senso di vulnerabilità scoperta: è architetturale. Il malware dimostra che il perimetro di attacco si è spostato dalle falle di sicurezza alle funzionalità di comodità. Wireless ADB esiste per eliminare attrito agli sviluppatori; Shizuku per democratizzare l'accesso a API di sistema; Accessibility Service per l'inclusione. Il loro incrocio programmato produce privilege escalation senza exploit. Per le istituzioni finanziarie nel mirino, l'implicazione è di digital risk protection: i siti clone e le campagne di impersonificazione richiedono rilevamento precoce del brand abuse. Per il settore mobile security, la domanda è se il threat model dei dispositivi non-rooted debba ancora presumere che "nessun PC collegato" equivalga a "nessun vettore ADB". Per Google e gli OEM, la presenza di routine specifiche per sette brand nel codice del malware suggerisce che gli attori della minaccia studiano la frammentazione dell'interfaccia di sviluppo come vettore scalabile.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti