RedHook controlla Android senza root: tutto parte da una chiamata

Un’app Android apparentemente innocua può trasformare lo smartphone in una postazione controllata a distanza, capace di eseguire comandi privilegiati, registrare ciò che appare sullo schermo e installare altri pacchetti senza mostrare le normali finestre di conferma. È il salto tecnico compiuto da RedHook, un trojan di accesso remoto che combina ingegneria sociale, servizi di accessibilità e debug wireless per superare buona parte delle limitazioni imposte alle applicazioni comuni.

I primi campioni pubblicamente documentati risalgono al luglio 2025 e presentavano già le caratteristiche tipiche dei trojan bancari Android: controllo dell’interfaccia, furto delle credenziali, acquisizione dei messaggi e sovrapposizione di finestre contraffatte. La variante analizzata da Group-IB a luglio 2026 introduce però un meccanismo più insidioso: sfrutta una funzione legittima disponibile da Android 11 per ottenere i privilegi della shell di sistema, identificata dal sistema operativo con UID 2000.

Non si tratta di accesso root e non emerge lo sfruttamento di una vulnerabilità non corretta nel kernel o nei componenti Android. Il punto è che RedHook induce la vittima ad autorizzare una sequenza di operazioni lecite, poi usa tali autorizzazioni in modo ostile. L’attacco dipende quindi da un errore umano iniziale, ma una volta completata la procedura concede ai criminali un livello di controllo ben superiore a quello normalmente associato a un’app installata tramite file APK.

RedHook parte da una telefonata, non da una falla software

La catena d’infezione inizia di solito con una comunicazione costruita per creare urgenza. Il truffatore si presenta come un dipendente della banca, un operatore dell’assistenza o un rappresentante di un ente pubblico; sostiene che il conto, l’identità digitale o un servizio essenziale richiedano una verifica immediata. Poco dopo invia un collegamento a un sito che imita una pagina istituzionale oppure il Google Play Store. La vittima scarica in realtà un file APK ospitato fuori dal negozio ufficiale.

Group-IB ha rilevato campagne nelle quali i pacchetti dannosi risiedevano su infrastrutture affidabili, tra cui repository GitHub e bucket Amazon S3. La scelta non rende il file legittimo, naturalmente, ma offre agli aggressori una distribuzione stabile, connessioni HTTPS valide e domini che possono suscitare meno sospetti rispetto a un server sconosciuto.

Android non installa automaticamente l’app: l’utente deve consentire al browser, al file manager o all’app di messaggistica di “installare app sconosciute”. A quel punto RedHook accompagna la vittima attraverso altre richieste, spesso presentate come passaggi necessari per completare una verifica di sicurezza.

La richiesta decisiva riguarda i Servizi di accessibilità. Android li ha progettati per aiutare chi incontra difficoltà nell’uso dello schermo, della tastiera virtuale o dei controlli tattili. Un’app autorizzata può leggere gli elementi dell’interfaccia, rilevare cambiamenti sul display e compiere azioni al posto della persona: sono capacità essenziali per screen reader e strumenti assistivi; nelle mani di un malware, però, equivalgono a dita e occhi digitali.

Come il malware attiva le Opzioni sviluppatore

Dopo aver ottenuto l’accesso ai servizi assistivi, RedHook non si limita a intercettare ciò che compare sul display. Simula tocchi, scorrimenti e pressioni prolungate; apre le impostazioni di Android, raggiunge le informazioni sul dispositivo e può ripetere i tocchi sul numero di build necessari ad attivare le Opzioni sviluppatore.

La procedura è nota a chi sviluppa applicazioni Android: in genere bisogna toccare sette volte la voce relativa al numero di build e, su alcuni dispositivi, confermare il PIN di sblocco. Proprio qui entra in gioco la capacità di RedHook di osservare lo schermo e guidare l’utente: alcune operazioni possono richiedere una conferma esplicita, ma la truffa telefonica mantiene la vittima sotto pressione e la induce a seguire istruzioni che, fuori da quella situazione, apparirebbero anomale.

Una volta aperto il menu per sviluppatori, il malware abilita Debug wireless. Google ha introdotto questa modalità con Android 11, API level 30, per consentire ad Android Studio e agli strumenti ADB di comunicare con lo smartphone tramite WiFi, senza cavo USB. È una comodità reale per programmatori e tecnici: permette di installare build di prova, leggere i log, trasferire file ed eseguire comandi dalla workstation.

Per impedire collegamenti casuali, Android richiede l’abbinamento tra telefono e computer mediante codice numerico oppure QR code. RedHook aggira la logica prevista non violando il protocollo, ma trasformando il telefono sia nel dispositivo controllato sia nel client che effettua l’abbinamento.

Il telefono si collega al proprio servizio ADB

Quando Android mostra il codice di pairing, il malware lo legge attraverso l’accessibilità. Recupera anche la porta assegnata al servizio e avvia una connessione verso 127.0.0.1, l’indirizzo di loopback che identifica lo stesso dispositivo. In pratica, RedHook ordina allo smartphone di collegarsi alla propria interfaccia ADB.

Una normale applicazione Android opera all’interno di una sandbox, con un UID dedicato e permessi limitati dal file manifest, dalle autorizzazioni a runtime e dalle regole SELinux. La shell ADB, invece, usa UID 2000 e può accedere a comandi, servizi Binder e impostazioni che restano fuori portata per le app comuni.

L’account root usa UID 0 e può controllare l’intero sistema, salvo ulteriori restrizioni imposte da SELinux e dal boot verificato. La shell ADB dispone di privilegi elevati ma non assoluti: non può modificare liberamente ogni partizione, leggere qualsiasi area privata o disattivare tutte le protezioni.

Definire RedHook come malware “root-level” risulta quindi impreciso: la portata delle autorizzazioni acquisite resta comunque molto seria, soprattutto perché avviene senza computer, exploit o bootloader sbloccato.

Perché RedHook integra componenti ispirati a Shizuku

Ottenuta la sessione ADB, RedHook utilizza codice derivato da Shizuku, progetto open source legittimo molto conosciuto tra sviluppatori e utenti esperti. Shizuku avvia un servizio con privilegi ADB o root e permette alle applicazioni autorizzate di accedere a determinate API di sistema attraverso Binder, evitando di eseguire per ogni operazione lunghi comandi shell.

Lo strumento non è malevolo. Serve, per esempio, ad app avanzate che gestiscono pacchetti, permessi e impostazioni normalmente inaccessibili, senza richiedere il rooting permanente del dispositivo. RedHook riprende parti di tale architettura per uno scopo opposto: creare un ponte privilegiato tra il proprio processo e i servizi interni di Android.

Secondo l’analisi tecnica, il malware impiega una libreria denominata libmx.so come server privilegiato: da quella posizione può invocare API protette con l’identità della shell, assegnarsi ulteriori autorizzazioni, modificare impostazioni riservate e interagire con il Package Manager. Il vantaggio, dal punto di vista dell’attaccante, consiste nella maggiore stabilità rispetto a una sequenza di tocchi simulati: una chiamata diretta ai servizi di sistema è più rapida, meno visibile e meno dipendente dalla disposizione grafica dei menu.

Le 53 istruzioni inviate dal server di comando

Group-IB ha contato 53 comandi C2 nella variante esaminata: non tutti risultano necessariamente completi o attivi in ogni campagna, ma il numero descrive un RAT (Remote Access Trojan) ormai vicino a una piattaforma modulare per la frode mobile.

Gli operatori possono trasmettere in diretta ciò che appare sul display, acquisire schermate, registrare le digitazioni e simulare tocchi, trascinamenti, scorrimenti o pressioni prolungate. Possono inoltre raccogliere contatti, SMS, informazioni sul dispositivo e l’elenco delle app installate.

Sono dati utili non soltanto per il furto immediato: permettono di capire quale banca usa la vittima, quali strumenti di autenticazione possiede e quali persone potrebbero diventare bersagli successivi.

RedHook può catturare credenziali di accesso e codici temporanei, osservare l’inserimento del PIN e ricostruire alcuni gesti di sblocco.

La combinazione tra keylogging, registrazione dello schermo e controllo remoto riduce l’efficacia di molte forme di autenticazione a due fattori basate sul medesimo telefono. Se la password e il secondo fattore transitano entrambi sul dispositivo compromesso, l’attaccante può osservarli nella stessa sessione.

Il malware supporta anche l’utilizzo di finestre sovrapposte, schermate nere e falsi messaggi di verifica: tutti trucchi che aiutano a nascondere le operazioni eseguite in primo piano, mentre il criminale apre un’app bancaria o modifica le impostazioni. Un modulo può attivare la fotocamera durante una falsa procedura di identificazione: la vittima crede di completare un controllo legittimo, ma consegna immagini e riprese all’infrastruttura criminale.

L’accesso della shell consente inoltre di installare o rimuovere pacchetti con pochissime interazioni: RedHook potrebbe eliminare un’app di sicurezza, aggiungere un secondo payload o sostituire un componente usato nella frode.

Come difendersi da RedHook: la telefonata è il primo segnale d’allarme

La protezione più efficace contro RedHook non parte dall’antivirus, dagli aggiornamenti o dalla ricerca di impostazioni nascoste: consiste nel non dare credito a chi telefona o scrive chiedendo di installare immediatamente un’app.

Banche, enti pubblici, corrieri e servizi di assistenza non invitano i clienti a scaricare un pacchetto APK da un collegamento ricevuto tramite SMS, WhatsApp o email; tanto meno possono chiedergli di attivare i Servizi di accessibilità, aprire le Opzioni sviluppatore o abilitare il Debug wireless.

Il tono urgente rappresenta una parte essenziale dell’attacco: il criminale segnala un pagamento sospetto, un conto bloccato o una verifica obbligatoria e interpreta ogni avviso mostrato da Android come un semplice ostacolo da superare.

Proprio le truffe nelle quali un falso operatore guida la vittima durante l’installazione hanno spinto Google a progettare Android Developer Verifier, un componente distribuito attraverso gli aggiornamenti di sistema Google Play. Il servizio non stabilisce se un’app sia sicura e non sostituisce Play Protect: controlla piuttosto che il pacchetto e la relativa chiave di firma risultino associati a uno sviluppatore identificato da Google. Le nuove regole partiranno il 30 settembre 2026 in Brasile, Indonesia, Singapore e Thailandia, mentre l’estensione agli altri Paesi, Italia compresa, è prevista dal 2027.

La soluzione ha suscitato critiche fondate: la verifica riguarda l’identità dello sviluppatore, non la qualità del codice. Al tempo stesso Google assume un ruolo centrale anche per applicazioni distribuite fuori dal Play Store, imponendo una registrazione preventiva. F-Droid, GrapheneOS e la campagna Keep Android Open contestano proprio tale aspetto: una misura nata per limitare le frodi rischia di rendere più difficile l’uso legittimo del sideloading e di trasformare l’identificazione presso Google in un requisito per eseguire software su un dispositivo acquistato dall’utente.