Esplorazione approfondita del malware mobile: ecosistemi di trojan per Android e iOS

Famiglie di Trojan Android: Da Anubis ai Moderni Abusi dei Servizi di Accessibilità

Il panorama dei trojan bancari Android ha subito trasformazioni generazionali da quando Anubis è apparso per la prima volta nel 2017. Anubis (AndroidOS_Anubis) ha stabilito il modello fondamentale: attacchi di overlay combinati con keylogging tramite servizi di accessibilità, distribuiti attraverso dropper su siti web compromessi e campagne di phishing via SMS. La sua infrastruttura di comando e controllo (C2) si basava su semplici richieste HTTP a domini hardcoded, rendendo i takedown efficaci ma temporanei.

EventBot, emerso all'inizio del 2020, ha introdotto architettura modulare ed evoluzione crittografica. A differenza della configurazione statica di Anubis, EventBot impiegava comunicazioni C2 crittografate con RC4 con chiavi recuperate dinamicamente da profili Twitter o gist GitHub—infrastruttura legittima abusata per resilienza. Il malware raccoglieva credenziali da oltre 200 applicazioni finanziarie in tutto il mondo, con particolare aggressività nei confronti dei portafogli crittografici. Le tecniche di manipolazione DEX di EventBot includevano offuscamento di stringhe multistrato tramite risoluzione API basata su reflection, richiedendo agli analisti di tracciare le catene Class.forName() e Method.invoke() per ricostruire l'intento originale.

FluBot rappresentò un cambiamento di paradigma nei meccanismi di propagazione. Sfruttando l'esfiltrazione delle liste contatti e le capacità di invio SMS dei dispositivi infetti, FluBot ha ottenuto auto-propagazione simile a un worm attraverso messaggi smishing contenenti esche di consegna pacchi. Tecnicamente, FluBot impiegava evasione aggressiva a livello nativo: la funzionalità core risiedeva in librerie ARM64 .so caricate via JNI, con il codice a livello DEX che serviva meramente come loader. Le librerie native implementavano controlli anti-analisi inclusi:

// Rappresentazione semplificata dell'anti-debug nativo di FluBot
#include <sys/ptrace.h>
#include <unistd.h>

int anti_debug_ptrace() {
    if (ptrace(PTRACE_TRACEME, 0, NULL, NULL) == -1) {
        // Tracciamento in corso: terminare o alterare l'esecuzione
        return 1;
    }
    return 0;
}

void check_frida() {
    // Scansione di /proc/self/maps per gadget o agent Frida
    FILE *maps = fopen("/proc/self/maps", "r");
    char line[512];
    while (fgets(line, sizeof(line), maps)) {
        if (strstr(line, "frida") || strstr(line, "gum-js")) {
            // Frida rilevato: crash o loop
            __builtin_trap();
        }
    }
    fclose(maps);
}

TeaBot e i suoi successori esemplificano la crisi moderna dell'abuso dei servizi di accessibilità. Il motore di overlay di TeaBot genera dinamicamente schermate di phishing basate su WebView da template JSON recuperati dal C2, abilitando il targeting rapido di nuove applicazioni bancarie senza richiedere aggiornamenti APK. Il malware si registra come servizio di accessibilità con il permesso BIND_ACCESSIBILITY_SERVICE, poi abusa della traversata AccessibilityNodeInfo per:

  • Leggere i contenuti dello schermo in tutte le applicazioni
  • Iniettare eventi di click (ACTION_CLICK, ACTION_SET_TEXT) per bypassare l'MFA
  • Intercettare il contenuto delle notifiche per l'esfiltrazione degli OTP SMS
  • Prevenire la disinstallazione intercettando la navigazione delle impostazioni

Le varianti contemporanee sono escalate al "ransomware dei servizi di accessibilità", dove il malware blocca il dispositivo iniettando continuamente pressioni del pulsante home e sovrapponendo finestre opache, richiedendo il pagamento attraverso la stessa infrastruttura.

Deoffuscamento APK e Manipolazione DEX: Approcci Analitici

L'analisi dei trojan Android moderni richiede di navigare offuscamento sofisticato. I packer commerciali come Jiagu, Bangcle e implementazioni custom impiegano crittografia DEX, caricamento dinamico del codice e appiattimento del flusso di controllo. La pipeline di deoffuscamento procede tipicamente attraverso diverse fasi.

Fase 1: Identificazione del Packer ed Estrazione Dinamica

Per campioni con DEX crittografato, l'estrazione runtime via Frida rimane il metodo più affidabile quando l'analisi statica è bloccata:

// Script Frida per estrazione DEX dalla memoria
function hook_dexclassloader() {
    var DexClassLoader = Java.use("dalvik.system.DexClassLoader");
    
    DexClassLoader.$init.implementation = function(dexPath, optimizedDirectory, librarySearchPath, parent) {
        console.log("[+] DexClassLoader caricamento: " + dexPath);
        // Estrai DEX decriptato da optimizedDirectory dopo il caricamento
        this.$init(dexPath, optimizedDirectory, librarySearchPath, parent);
    };
}

function dump_dex_from_maps() {
    var module = Process.findModuleByName("libart.so");
    // Individua strutture file dex in memoria, estrai via /proc/self/mem
    // L'implementazione varia per versione Android e versione ART
}

Fase 2: Contromisure all'Evasione JNI/Livello Nativo

Il malware migra sempre più operazioni sensibili al codice nativo. Il confine JNI diventa sia una tecnica di evasione che un punto di strozzatura analitico. Gli analisti devono:

  • Tracciare le chiamate RegisterNatives per identificare metodi registrati dinamicamente
  • Hookare JNI_OnLoad per intercettare l'inizializzazione delle librerie
  • Usare emulazione basata su QEMU (via Unicorn Engine) quando il comportamento ARM-specifico è rilevante
  • Considerare i trucchi di selezione ABI (crash deliberati su emulatori x86 per rilevare ambienti di analisi)

Le varianti moderne implementano "code splitting nativo", dove i corpi delle funzioni sono crittografati e decriptati per-chiamata usando chiavi derivate da proprietà specifiche del dispositivo (Build.SERIAL, ANDROID_ID), frustrando l'analisi statica e il rilevamento basato su hash.

Vie di Sfruttamento iOS: Oltre il Giardino Murato

Il malware iOS opera sotto vincoli fondamentalmente diversi. La firma del codice, la sandboxing e i processi di review della piattaforma hanno storicamente imposto barriere significative. Tuttavia, avversari determinati hanno sviluppato multipli vettori di infezione con prerequisiti e prevalenza variabili.

Abuso di Certificati Enterprise

L'Apple Developer Enterprise Program (D-U-N-S richiesto, $299/anno) fornisce certificati per la distribuzione interna di app al di fuori dell'App Store. Gli operatori di malware hanno sistematicamente abusato di questo meccanismo: ottenendo registrazioni enterprise fraudolente o compromettendo certificati legittimi, distribuiscono applicazioni trojanizzate. Casi notevoli includono la famiglia AceDeceiver, che ha sfruttato difetti di progettazione nel DRM FairPlay di Apple per installare app malevole senza alcun certificato—puramente manipolando il flusso di authorization code tra iTunes e i dispositivi.

Il malware distribuito via enterprise tipicamente si presenta come app premium "craccate", giochi modificati con "cheat" o contenuto pornografico—applicazioni che Apple rifiuterebbe dall'App Store. Gli utenti devono fidarsi esplicitamente del certificato enterprise nelle Impostazioni, ma l'ingegneria sociale supera efficacemente questo attrito.

Sideloading: Disruzione Normativa

Il Digital Markets Act (DMA) dell'UE, in vigore da marzo 2024, impone ad Apple di permettere marketplace di app alternative e sideloading sui dispositivi iOS in Europa. Questo rappresenta il cambiamento strutturale più significativo per la sicurezza iOS dalla sua nascita. Apple ha implementato l'entitlement con restrizioni caratteristiche: review di notarization per marketplace alternativi, Core Technology Fee per app ad alto numero di installazioni, e gating geografico tramite rilevazione della regione del dispositivo.

Per gli operatori di malware, il sideloading riduce ma non elimina le barriere. I marketplace alternativi devono ancora implementare la notarization, e la scansione malware di Apple persiste. Tuttavia, la superficie di attacco si espande: compromissioni di marketplace, account takeover di sviluppatori e ingegneria sociale degli operatori di marketplace diventano fattibili. La frammentazione geografica (sideloading solo UE) complica le campagne globali ma abilita operazioni mirate.

Attacchi Dipendenti da Jailbreak vs. Non-Jailbreak

Il malware dipendente da jailbreak (Pegasus, trojan iOS precedenti) ottiene compromissione profonda del sistema attraverso exploit del kernel, garantendo accesso root e disabilitando la verifica della firma del codice. Tale malware si impianta a livello kernel o daemon, ottenendo persistenza attraverso i restore a meno che il firmware non sia completamente riscritto. La catena di attacco per Pegasus di NSO Group ha esemplificato questo: Safari WebKit RCE → escalation dei privilegi locali → vulnerabilità kernel → jailbreak → installazione del daemon di persistenza e agent di esfiltrazione dati.

Gli attacchi non-jailbreak operano all'interno della sandbox iOS vincolata, facendo affidamento su:

  • Abuso di dispositivi supervisionati: Enrollment MDM per controllo enterprise, riadattato per controllo malevolo
  • Manipolazione di profili di configurazione: Installazione di certificati root e configurazioni VPN per intercettare il traffico
  • Sfruttamento di estensioni app: Abuso di notification service extensions o keyboard extensions per accesso ai dati
  • Hijacking di URL scheme: Registrazione per URL scheme sensibili (bankapp://, sso://) per intercettare i lanci di app legittime

L'incidente XCodeGhost ha dimostrato la compromissione della supply chain dell'ecosistema non-jailbreak: distribuzioni XCode modificate iniettavano codice malevolo nelle applicazioni compilate, distribuendo attraverso l'App Store legittima a centinaia di milioni di dispositivi.

Architetture di Trojan Bancari: Dall'Overlay all'Evoluzione ATS

I trojan bancari mobile hanno evoluto attraverso distinte generazioni architetturali, ciascuna aumentando l'automazione e riducendo i requisiti di interazione della vittima.

Prima Generazione: Attacchi di Overlay Statici

Il modello di overlay originale hardcodava nomi di pacchetto delle app target e visualizzava WebView di phishing generici quando tali app erano in primo piano. Limitato da asset statici, facilmente identificabile dai prodotti di sicurezza.

Seconda Generazione: Overlay Dinamico con Template Remoti

TeaBot e i trojan Android contemporanei implementano overlay dinamici. Il C2 consegna template JSON che specificano:

{
  "target_package": "com.bank.target",
  "trigger_activity": "com.bank.target.LoginActivity",
  "overlay_layout": "base64_encoded_layout",
  "form_fields": [
    {"id": "username", "type": "text", "hint": "Nome utente"},
    {"id": "password", "type": "password", "hint": "Password"},
    {"id": "submit", "type": "button", "action": "exfil_and_dismiss"}
  ],
  "c2_endpoint": "https://legitimate-service.firebaseio.com/logs.json"
}

L'endpoint Firebase esemplifica l'abuso di infrastruttura legittima—il traffico verso *.firebaseio.com si confonde con innumerevoli applicazioni legittime, complicando il rilevamento basato su rete.

Terza Generazione: ATS (Automated Transfer Systems)

Gli ATS rappresentano l'attuale frontiera, minimizzando la consapevolezza della vittima automatizzando le transazioni fraudolente. Dopo la cattura delle credenziali, il trojan mantiene la persistenza della sessione e inizia trasferimenti in modo autonomo:

  1. La vittima effettua il login legittimamente; il trojan cattura il token di sessione
  2. Il C2 schedula il trasferimento via meccanismo push o polling
  3. I trojan abusano dei servizi di accessibilità o iniettano JavaScript via WebView compromesso per eseguire il trasferimento
  4. Le challenge MFA intercettate dalle notifiche e sottoposte automaticamente
  5. Schermate di conferma della transazione soppresse o rapidamente chiuse

La famiglia di trojan Medusa implementa ATS sofisticati con "live session takeover"—capacità RAT che permettono l'interazione in tempo reale dell'operatore con la sessione bancaria della vittima, mescolando frode automatizzata e manuale.

Bypass MDM e Anti-Analisi Specifici ARM

I sistemi Mobile Device Management presentano ostacoli sia per la sicurezza aziendale che per gli operatori di malware. I trojan Android avanzati implementano tecniche di bypass MDM:

  • Gara di escalation device admin: Registrazione come device owner prima dell'enrollment MDM aziendale, garantendo precedenza superiore delle policy
  • Escalation di privilegi via servizio di accessibilità: Uso di WRITE_SECURE_SETTINGS via accessibilità per disabilitare componenti MDM
  • Fuga dall'isolamento del work profile: Sfruttamento di vulnerabilità cross-profile nell'implementazione multi-user di Android

L'anti-analisi specifico ARM sfrutta caratteristiche architetturali assenti dagli ambienti di analisi x86:

Tecnica Scopo Metodo di Rilevamento
Compilazione condizionale __arm__ Comportamento diverso su ARM vs. x86 emulato Esecuzione differenziale cross-architettura
Fingerprinting NEON/SIMD Sondaggio delle capacità hardware Implementazione NEON incompleta di QEMU
Side-channel di timing della cache Rilevamento di emulatore Analisi statistica dei tempi
Autenticazione puntatore PAC/BTI Mitigazione exploit, anche anti-tampering Strumentazione dinamica PAC-aware

Walkthrough di una Vera Catena di Infezione: Variante TeaBot "Toddler"

Il seguente walkthrough sintetizza comportamenti osservati dalle campagne TeaBot 2023-2024:

Accesso Iniziale: Messaggio di phishing SMS che finge di provenire dal servizio postale nazionale: "La consegna del suo pacco è fallita. Riprogrammare: [URL accorciato]"

Dropper di Fase 1: APK scaricato ("DeliveryApp.apk") richiede permessi SMS e servizi di accessibilità sotto la copertura di "mirroring delle notifiche." Il DEX contiene funzionalità minima; payload primario crittografato in assets/raw.dat con AES-256-GCM, chiave derivata dal fingerprint del dispositivo e salt hardcoded.

Decriptazione Nativa di Fase 2: libnative-lib.so implementa:

  • Rilevamento emulatore tramite query delle proprietà hardware
  • Rilevamento Frida tramite scansione di /proc/self/maps
  • Decriptazione DEX e istanziazione InMemoryClassLoader

Registrazione C2 di Fase 3:

  • Genera coppia di chiavi ECDH; deriva segreto condiviso con chiave pubblica C2 embedded nella libreria nativa
  • Registra il dispositivo con il C2 via webhook Discord (URL webhook ruotato settimanalmente, distribuito tramite canale Telegram)
  • Esfiltra: lista contatti, applicazioni installate, cronologia SMS, app bancarie presenti sul dispositivo

Abuso di Accessibilità di Fase 4:

  • Ottiene BIND_ACCESSIBILITY_SERVICE attraverso prompt persistenti di ingegneria sociale
  • Inizia il monitoraggio AccessibilityEvent per applicazioni bancarie target
  • Al trigger: gonfia overlay WebView da template recuperato dal C2, cattura credenziali
  • Intercetta eventi NotificationListenerService per estrazione OTP

Persistenza di Fase 5:

  • Registra receiver BOOT_COMPLETED
  • Schedula lavoro JobScheduler per riavviare il servizio se terminato
  • Disabilita Google Play Protect via navigazione impostazioni iniettata tramite accessibilità
  • Previene la disinstallazione intercettando intent di rimozione pacchetto e reindirizzando alla schermata home

Il webhook Discord C2 esemplifica l'evoluzione dell'abuso di infrastruttura: i messaggi appaiono come traffico di canale di routine, la cancellazione del webhook da parte di Discord solo disrompe singoli nodi, e il CDN della piattaforma serve come hosting affidabile del payload con distribuzione globale edge.