ToxicPanda 2.0 prepara nuovi attacchi Android con ADB Wireless e 167 comandi

🛡️ Executive Summary

• ToxicPanda 2.0 dispone ora di 167 comandi remoti e amplia gli overlay di phishing a 349 applicazioni finanziarie distribuite in 16 Paesi.
• Il malware automatizza l’attivazione di ADB Wireless, recupera il PIN di pairing e ottiene privilegi shell senza ricorrere al root del dispositivo.
• Nuove funzioni rubano PIN e credenziali dello screen lock, simulano aggiornamenti di sistema e aggirano le restrizioni energetiche dei principali produttori Android.

ToxicPanda sta preparando una nuova fase delle proprie campagne contro Android e la versione 2.0 mostra un salto significativo nelle capacità di controllo del dispositivo. I ricercatori di Zimperium zLabs hanno individuato una variante aggiornata del banking trojan dotata di 167 comandi remoti, contro un insieme molto più limitato nelle precedenti analisi, e capace di distribuire overlay di phishing contro 349 applicazioni bancarie, finanziarie, wallet e servizi crypto in 16 Paesi. Il malware introduce inoltre un sistema dedicato al furto dei PIN utilizzati da oltre 140 applicazioni, automatizza l’attivazione del Wireless Debugging Android e può arrivare a ottenere privilegi shell attraverso ADB senza bisogno di root. ToxicPanda non si limita quindi più al furto delle credenziali: cerca di trasformare lo smartphone in un endpoint controllabile quasi completamente dall’operatore.

ToxicPanda 2.0 porta il framework a 167 comandi remoti

La nuova analisi tecnica pubblicata da Zimperium zLabs mostra un malware molto più maturo rispetto alle versioni precedentemente documentate. Diverse funzioni che nelle analisi passate risultavano ancora presenti nel codice ma non implementate sono diventate operative, portando il pannello di comando e controllo a gestire 167 comandi. ToxicPanda continua a utilizzare Accessibility Service come principale leva per osservare e manipolare l’interfaccia, ma costruisce intorno a questo permesso un ambiente sempre più vicino a un framework di Device Takeover. La traiettoria è la stessa già osservata con TrickMo Variant C, capace di trasformare Android in un dispositivo completamente controllabile a distanza, dove overlay, intercettazione delle notifiche, tunnel di rete e controllo remoto avevano ormai superato il tradizionale modello del trojan bancario. ToxicPanda 2.0 amplia ulteriormente questo paradigma attraverso automazione delle impostazioni di sistema, privilegi ADB e capacità di persistenza specifiche per i differenti produttori Android.

Il dropper chiede una VPN per isolare Google Play prima di installare il payload

La catena d’infezione utilizza inizialmente un dropper che mostra alla vittima una falsa procedura d’installazione attraverso una WebView. Prima di estrarre il payload reale, l’applicazione chiede di diventare servizio VPN, permesso utilizzato per interferire con le comunicazioni di Google Play e Google Play Services sul dispositivo compromesso.

Dopo avere preparato questo ambiente, il dropper decifra il malware presente all’interno della propria directory assets e procede con l’installazione, chiedendo successivamente l’attivazione del servizio di accessibilità. La scelta mostra come gli operatori non abbiano bisogno di vulnerabilità kernel per ottenere un punto d’appoggio efficace: convincono invece l’utente a concedere funzioni legittime molto potenti e le concatenano.

La documentazione Android sull’Accessibility Service chiarisce che questi servizi possono esaminare il contenuto dello schermo e interagire con le applicazioni per conto dell’utente, capacità nate per finalità assistive ma continuamente abusate dai malware bancari. È lo stesso punto debole sfruttato da Crocodilus per acquisire OTP, credenziali e controllo remoto del telefono.

Gli overlay passano da 16 a 349 applicazioni finanziarie

L’espansione del targeting è probabilmente il dato commerciale più importante della nuova variante. ToxicPanda 2.0 enumera le applicazioni installate, invia package name e icone al C2 e permette all’operatore di identificare quali servizi finanziari siano presenti sul telefono. Quando viene aperta un’applicazione configurata come obiettivo, il server restituisce un overlay HTML costruito per replicarne la schermata di login o di autorizzazione delle transazioni.

Zimperium ha identificato template per 349 applicazioni bancarie, e-wallet, piattaforme finanziarie e servizi crypto distribuiti in 16 Paesi, contro appena 16 app bancarie attribuite alle prime versioni note della famiglia. L’espansione indica che ToxicPanda non è più progettato intorno a una singola regione europea ma sta preparando una piattaforma molto più adattabile geograficamente. Gli overlay sottraggono username, password, PIN e altri dati sensibili, combinandosi con le capacità di controllo dell’interfaccia per permettere agli operatori di proseguire successivamente la frode sul vero servizio finanziario.

Il PIN delle app bancarie viene catturato attraverso un overlay trasparente

Oltre alle pagine di phishing tradizionali, la nuova versione implementa un meccanismo specifico per il PIN harvesting. Quando Accessibility rileva in primo piano una delle oltre 140 applicazioni configurate, ToxicPanda abilita un overlay trasparente sopra lo schermo e registra i punti toccati dall’utente durante l’inserimento del codice. Il malware può quindi ricostruire il PIN senza dover riprodurre necessariamente l’intera interfaccia bancaria. L’elenco degli obiettivi non è statico: il comando replacePinTargets consente al C2 di sostituire dinamicamente package e keyword, permettendo agli operatori di adattarsi a nuove applicazioni senza distribuire un altro APK. È la stessa evoluzione che sta trasformando il banking malware Android da raccolta statica di credenziali a manipolazione in tempo reale del comportamento dell’app, fenomeno evidente anche nelle recenti campagne WindRelay e SpyNote dedicate alle frodi bancarie NFC.

ADB Wireless viene attivato automaticamente attraverso Accessibility

La funzione tecnicamente più aggressiva riguarda l’abuso di Android Wireless Debugging, disponibile a partire da Android 11. In condizioni normali, come spiega la documentazione ufficiale di Android Debug Bridge, l’utente deve abilitare il debug wireless e completare l’associazione con una workstation utilizzando un codice di pairing. ToxicPanda automatizza l’intera procedura attraverso Accessibility. Prima apre la pagina “Informazioni sul telefono”, individua il Build number e simula i sette tap necessari per attivare Developer Options. Successivamente raggiunge le impostazioni sviluppatore, abilita Wireless Debugging e apre la finestra “Pair device with pairing code”. A questo punto legge dalla gerarchia UI il PIN di sei cifre e la porta dinamica esposti dal sistema. Non viene quindi sfruttata una falla di Android: il malware riproduce automaticamente le azioni che un utente autorizzato potrebbe compiere manualmente.

SPAKE2 e ADB portano ToxicPanda ai privilegi shell

Una volta recuperato il codice di pairing, ToxicPanda istanzia localmente un handler SPAKE2, genera le proprie chiavi e completa l’associazione con il demone ADB disponibile sul loopback 127.0.0.1. Il canale viene autenticato e protetto tramite TLS, esattamente come previsto dall’architettura legittima di Android. Al termine, però, il malware dispone dei privilegi dell’utente shell, molto superiori a quelli concessi normalmente a un’applicazione.

Da quella posizione può impartire comandi al demone ADB, concedersi permessi più ampi, modificare restrizioni di background, attivare componenti e rafforzare la persistenza. L’approccio è particolarmente interessante perché conferma una tendenza già visibile nel RAT RedHook, che utilizza Wireless ADB e Shizuku per ottenere privilegi avanzati senza root. Gli autori di malware stanno quindi spostando l’escalation dall’exploit di vulnerabilità alla concatenazione abusiva di funzionalità ufficiali per sviluppatori.

Anche il PIN di sblocco del telefono diventa un bersaglio

La variante aggiunge inoltre il furto delle credenziali di blocco del dispositivo, comprese password, PIN e pattern. ToxicPanda mostra una falsa schermata sovrapposta a quella originale di Android e cattura ciò che la vittima inserisce credendo di sbloccare normalmente il telefono. Ottenere lo screen-lock secret modifica profondamente le possibilità operative dell’attaccante, perché il codice di sblocco può essere necessario per confermare impostazioni sensibili, accedere fisicamente al dispositivo o completare determinate operazioni quando l’interfaccia richiede autenticazione locale.

A questa funzione si aggiungono i comandi admSet e admPwd: il primo cerca di convincere la vittima a concedere privilegi Device Administrator, mentre il secondo utilizza le capacità offerte da DevicePolicyManager per modificare la password del terminale nelle configurazioni in cui l’API risulta applicabile. L’obiettivo non è quindi soltanto leggere dati bancari, ma acquisire il controllo dell’identità locale con cui Android protegge l’intero dispositivo.

I falsi aggiornamenti nascondono ciò che l’operatore fa in background

Durante alcune operazioni ToxicPanda 2.0 può mostrare una falsa schermata a tutto schermo che simula un aggiornamento di sistema. Le interfacce vengono caricate da template HTML presenti localmente nel pacchetto e servono a coprire ciò che il malware sta compiendo in background. In altre parole, mentre la vittima osserva un messaggio apparentemente legittimo che suggerisce di attendere la conclusione di una procedura Android, l’operatore può utilizzare i comandi remoti o modificare configurazioni senza rendere visibili le interazioni sottostanti.

La tecnica non è nuova nella criminalità mobile, ma diventa più efficace quando viene combinata con i privilegi shell e con una manipolazione automatizzata dell’interfaccia. I banking trojan moderni stanno infatti utilizzando sempre più spesso black screen, fake update e overlay a pieno schermo per nascondere vere sessioni remote, come già osservato nell’evoluzione di Crocodilus e degli altri framework Android orientati al Device Takeover.

Il malware conosce le differenze tra Samsung, Xiaomi, OPPO, Vivo e Huawei

Uno dei problemi degli sviluppatori di malware Android è la frammentazione introdotta dai produttori. Samsung, Xiaomi, OPPO, Vivo, Huawei e altri OEM implementano sistemi proprietari per limitare l’avvio automatico, terminare processi in background o imporre politiche aggressive di risparmio energetico. ToxicPanda 2.0 affronta direttamente questa difficoltà attraverso il comando autoBoot, che legge Build.MANUFACTURER, identifica il produttore e apre la specifica schermata interna necessaria per modificare le impostazioni di auto-start o batteria. Accessibility individua quindi pulsanti come “Allow” o “Don’t Optimize” anche attraverso stringhe localizzate e li seleziona automaticamente. Il comando catAllViewSwitch estende lo stesso principio a dialoghi di autorizzazione, ottimizzazione energetica e configurazioni OEM differenti. Non è un dettaglio secondario: una piattaforma criminale che vuole operare su scala globale deve sopravvivere tanto alle difese Android standard quanto alle modifiche dei singoli costruttori.

WebSocket e AES mantengono il controllo remoto in tempo reale

L’infrastruttura C2 mantiene l’impostazione delle precedenti versioni. Il malware effettua inizialmente una richiesta HTTPS verso il server e passa successivamente a una connessione WebSocket persistente, utile per ricevere comandi ed esfiltrare informazioni con bassa latenza. Il contenuto viene protetto con AES in modalità ECB, utilizzando una chiave derivata da un array statico incorporato nel codice. Sul piano crittografico non è una scelta particolarmente raffinata, ma per l’operatore la priorità è garantire un canale bidirezionale persistente piuttosto che costruire un protocollo innovativo. Il pannello individuato da Zimperium mostra esplicitamente l’indicazione “v2”, coerente con una fase di sviluppo successiva. L’ampiezza delle capacità ricorda altri RAT Android diventati piattaforme multifunzione, come Flying Eagle, capace di combinare sorveglianza, controllo remoto e frode bancaria, anche se le due famiglie non risultano collegate.

AWS entra nella catena di distribuzione del malware

Cambia anche la distribuzione. Zimperium ha osservato sample di ToxicPanda 2.0 ospitati in bucket Amazon AWS, segnale che gli operatori stanno utilizzando infrastrutture cloud legittime per consegnare gli APK. L’impiego di servizi molto diffusi riduce l’efficacia delle difese che si basano soltanto sulla reputazione del dominio e rende più complesso applicare blocchi generalizzati senza danneggiare servizi legittimi.

La presenza su AWS non implica naturalmente alcun coinvolgimento di Amazon nella campagna: è un abuso della piattaforma di hosting da parte degli attaccanti. La strategia segue una tendenza ormai consolidata, nella quale repository GitHub, object storage cloud, CDN e servizi di messaggistica vengono trasformati in infrastruttura temporanea per distribuire payload Android e Windows.

ToxicPanda non dorme perché il banking trojan sta diventando un sistema operativo criminale

Il dato più importante di ToxicPanda 2.0 non è quindi una singola funzione. Overlay contro 349 servizi, furto PIN, screen-lock harvesting, 167 comandi, ADB Wireless, privilegi shell, Device Administrator, false schermate di aggiornamento e automazione specifica per OEM appartengono tutti alla stessa trasformazione. Il banking trojan moderno non vuole più soltanto sapere la password della banca: vuole controllare l’ambiente nel quale la banca viene utilizzata. Questo permette di intervenire dopo l’autenticazione, modificare il comportamento del telefono, intercettare conferme e nascondere le operazioni all’utente. La crescita già osservata con Anatsa, capace di entrare attraverso applicazioni apparentemente legittime e trasformarle successivamente in malware bancario trova in ToxicPanda 2.0 un’evoluzione ancora più spinta. Il malware non ha bisogno di bucare Android se riesce a convincere l’utente a concedergli Accessibility e poi utilizza la stessa interfaccia del sistema per procurarsi autonomamente il resto. È qui che il confine tra social engineering, abuso delle API e privilege escalation diventa sempre più sottile, e dove la protezione del mobile banking non può più limitarsi alla sicurezza della singola applicazione.