Il 17 agosto 2017 svariate reti per la distribuzione dei contenuti (CDN) e numerosi provider di contenuti sono stati oggetto di attacchi importanti da parte della botnet WireX, così battezzata dall’anagramma di una delle stringhe di delimitazione presenti nel relativo protocollo Command and Control. Composta principalmente da dispositivi Android che eseguono applicazioni dannose, la botnet WireX genera traffico DDoS ed è spesso accompagnata da messaggi di richiesta di riscatto.

Avvisata alcuni giorni fa della presenza di questo malware nel suo Play Store, Google ha subito bloccato centinaia di applicazioni interessate e avviato il processo per rimuovere tali applicazioni da tutti i dispositivi infettati.

I ricercatori di Akamai, Cloudflare, Flashpoint, Google, Oracle Dyn, RiskIQ, Team Cymru e di altre organizzazioni hanno unito le forze per contrastare questa botnet. I riscontri indicano che WireX potrebbe essere attiva dal 2 agosto, ma sono stati gli attacchi del 17 agosto ad avere attirato l’attenzione di queste organizzazioni. Questo post è il frutto delle conoscenze e degli sforzi combinati dei ricercatori che collaborano per condividere informazioni su questa botnet nell’interesse di tutta la comunità Internet. Il post del blog è stato redatto congiuntamente dai ricercatori di numerose organizzazioni e pubblicato contemporaneamente da Akamai, Cloudflare, Flashpoint e RiskIQ.

Dettagli degli attacchi

I primi segnali disponibili della presenza della botnet WireX risalgono al 2 agosto. Si tratta di piccoli attacchi passati inosservati in un primo momento e che non sono stati scoperti fino a quando i ricercatori non hanno iniziato a cercare la stringa User-Agent di 26 caratteri nei log. La portata estremamente contenuta di questi primi attacchi suggerisce che il malware fosse ancora in fase di sviluppo o comunque nelle prime fasi dell’implementazione. Attacchi più prolungati sono stati identificati a partire dal 15 agosto, con alcuni eventi che hanno avuto origine da un minimo di 70 mila indirizzi IP simultaneamente, come illustrato nella figura s1.

La botnet WireX genera attacchi DDoS volumetrici a livello di applicazioni. Il traffico generato dai nodi di attacco è principalmente composto da richieste HTTP GET, sebbene stiano facendo la loro comparsa alcune varianti in grado di generare richieste POST. In altre parole, la botnet produce traffico che assomiglia alle richieste valide provenienti da browser web e client HTTP generici.

Figura 1: Crescita prevista della botnet in base al numero di indirizzi IP univoci all’ora che prendono parte agli attacchi.

Nel corso dell’osservazione iniziale, la maggior parte del traffico proveniente da questa botnet si distingueva per l’impiego di una stringa User-Agent della richiesta HTTP contenente caratteri alfabetici minuscoli in ordine casuale.

Alcuni valori User-Agent osservati:

User-Agent: jigpuzbcomkenhvladtwysqfxr User-Agent: yudjmikcvzoqwsbflghtxpanre User-Agent: mckvhaflwzbderiysoguxnqtpj User-Agent: deogjvtynmcxzwfsbahirukqpl User-Agent: fdmjczoeyarnuqkbgtlivsxhwp User-Agent: yczfxlrenuqtwmavhojpigkdsb User-Agent: dnlseufokcgvmajqzpbtrwyxih

Sono state osservante anche varianti del malware che utilizzano stringhe User-Agent di lunghezze e set di caratteri estesi diversi e talvolta includono addirittura i valori User-Agent dei comuni browser. Alcuni esempi di altri valori User-Agent osservati:

User-Agent: xlw2ibhqg0i

User-Agent: bg5pdrxhka2sjr1g

User-Agent: 5z5z39iit9damit5czrxf655ok060d544ytvx25g19hcg18jpo8vk3q User-Agent: fge26sd5e1vnyp3bdmc6ie0

User-Agent: m8al87qi9z5cqlwc8mb7ug85g47u

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3 (.NET CLR 3.5.30729)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.7) Gecko/20071018 BonEcho/2.0.0.7

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_5_7; en-us) AppleWebKit/530.19.2 (KHTML, like Gecko) Version/4.0.2

Risalire ai nodi

Dall’analisi dei dati relativi all’attacco del 17 agosto è emerso che avevano preso parte all’attacco oltre 100 paesi diversi, un aspetto del tutto atipico delle botnet attuali. Guidati da questa anomala distribuzione degli IP di attacco e dalla presenza della stringa User-Agent distintiva della botnet, i ricercatori hanno avviato l’indagine iniziale nella convinzione che anche altre organizzazioni fossero state, o avrebbero potuto essere, prese di mira da attacchi simili. I ricercatori di altre organizzazioni sono stati così contattati al fine di verificare quanto si stava osservando.

Una volta dato vita a una più ampia iniziativa congiunta, l’indagine ha iniziato rapidamente a evolversi con l’analisi delle informazioni storiche dei log, che ha rivelato l’esistenza di un collegamento tra gli indirizzi IP di attacco e qualcosa di dannoso eseguito probabilmente al di sopra del sistema operativo Android.

Sulla scia degli attacchi Mirai si è registrato un ritorno ai gruppi di condivisione di informazioni, in cui i ricercatori condividono rapporti, e quando necessario collaborano attivamente, per risolvere problemi che interessano l’intera rete Internet. Il valore di questo tipo di collaborazione è stato ulteriormente rafforzato dalla comparsa di WannaCry, Petya e altri eventi di portata globale. Molti di questi gruppi di condivisione di informazioni, come quello creato in questa occasione, hanno lo scopo di favorire lo scambio di comunicazioni totalmente informali tra esperti dello stesso settore.

Individuare il software

L’analisi dei log relativi agli attacchi del 17 agosto ha rivelato che alcuni attacchi precedenti, caratterizzati dalla stessa firma, avevano coinvolto la prima applicazione Android, “twdlphqg_v1.3.5_apkpure.com.apk“. Alla luce di questa scoperta i ricercatori hanno subito analizzato esempi dell’applicazione per capirne il funzionamento e verificare l’esistenza di eventuali applicazioni correlate.

Le ricerche condotte sulla base di possibili varianti del nome e dei parametri dell’applicazione hanno rivelato l’esistenza di una serie di altre applicazioni dello stesso autore o di autori con nomi simili e con descrizioni analoghe, come illustrato nella figura 2. Mentre venivano individuate nuove applicazioni, alcuni membri del team hanno iniziato a studiare i file binari per capirne il funzionamento.

Figura 2: Schermata di una ricerca di malware simile.

In alcuni casi queste applicazioni erano presenti anche in app store noti e preconfigurati per dispositivi mobili. Per quanto possibile, si è provveduto a segnalare l’abuso ai team dei vari app store, come Google, e a fornire collaborazione per rimuovere rapidamente il contenuto dannoso. Google ha così commentato il lavoro di ricerca svolto:

Abbiamo identificato circa 300 app coinvolte, che abbiamo provveduto a bloccare su Play Store e ora stiamo rimuovendo da tutti i dispositivi interessati. Le scoperte dei ricercatori combinate con le nostre analisi ci hanno permesso di fornire una migliore protezione agli utenti Android, ovunque si trovino.

Panoramica del malware

Molte delle applicazioni identificate appartengono alle categorie dei lettori video o multimediali, delle suonerie o di strumenti come storage manager e app store, dotati di funzionalità nascoste aggiuntive non prontamente evidenti agli utenti dei dispositivi infettati. All’avvio di queste applicazioni, i componenti dannosi avviano il servizio di polling Command and Control che invia query al server C&C, solitamente g.axclick.store, per ottenere comandi di attacco. Una volta ricevuti i comandi di attacco, il servizio di analisi ispeziona il comando di attacco non elaborato, lo analizza e avvalendosi dei parametri estratti richiama il servizio che lancia l’attacco.

Le applicazioni che ospitavano queste funzioni di attacco, per quanto dannose, apparivano del tutto innocue agli occhi degli utenti che le avevano installate. Esse sfruttavano inoltre le funzionalità dell’architettura di servizi Android, che consente alle applicazioni di utilizzare risorse di sistema persino quando sono eseguite in background. In questo modo erano in grado di lanciare gli attacchi anche quando l’applicazione non era in uso. Attualmente gli scanner antivirus riconoscono questo malware come trojan “Android Clicker”, sebbene lo scopo di questa campagna non abbia niente a che vedere con il Click Fraud. È probabile che questo malware fosse in qualche modo associato al Click Fraud, ma è stato in seguito riqualificato per lanciare attacchi DDoS.

Una panoramica più approfondita dei meccanismi interni dei componenti dannosi delle applicazioni è disponibile nell’Appendice 1.

Conclusione

Queste scoperte sono state possibili solo grazie alla collaborazione tra obiettivi degli attacchi DDoS, società che si occupano di mitigare gli attacchi DDoS e società di ricerca. Ciascuno di loro ha infatti apportato un pezzo diverso del puzzle e senza il contributo di tutti, questa botnet sarebbe rimasta un mistero.

La cosa migliore che le organizzazioni possono fare quando sono vittime di un attacco DDoS è condividere informazioni dettagliate sull’attacco. Sono proprio queste informazioni che consentono a quanti di noi sono impegnati nella lotta al crimine informatico di compiere importanti passi avanti, ben più di quanto sarebbe altrimenti possibile.

I parametri da condividere riguardano intercettazioni di pacchetti, elenchi di indirizzi IP di attacco, richieste di riscatto, intestazioni di richieste e qualsiasi altro pattern che possa interessare. Questi dati non dovrebbero contenere invece alcun traffico legittimo, in modo da limitare al massimo le implicazioni per la privacy e anche perché il traffico legittimo può inquinare e rallentare il lavoro di analisi. Infine, cosa più importante, è necessario altresì fornire l’autorizzazione a condividere questi dati, non solo con i vostri vendor, ma anche con i rispettivi contatti attendibili all’interno della più ampia comunità di sicurezza, all’interno della quale potrebbero essere presenti terze parti in possesso di competenze o visibilità non disponibili nella vostra più ristretta cerchia di vendor.

Non bisogna vergognarsi di chiedere aiuto. Non solo non bisogna vergognarsi, ma nella maggior parte dei casi, è impossibile nascondere il fatto di essere vittima di un attacco DDoS. Numerosi servizi di ricerca sono infatti in grado di individuare l’esistenza di attacchi DDoS in corso a livello globale ai danni di terze parti, indipendentemente da quanti sforzi questi ultimi possano fare per tenere nascosto l’attacco. La reticenza porta con sé pochi vantaggi. Ben più vantaggi porta l’essere collaborativi.

Condividere metriche dettagliate sugli attacchi di cui si è vittima consente inoltre ai vari gruppi di condivisione di informazioni formali o meno di comunicare tra loro al fine di comprendere meglio le dinamiche degli attacchi in corso su scala globale, anziché solo degli attacchi individuati sulle singole piattaforme. Questo rapporto è un esempio di come la condivisione informale può produrre vantaggi assolutamente positivi non solo per le vittime ma per l’intera rete Internet. La cooperazione tra le varie organizzazioni è essenziale per contrastare le minacce in atto su Internet e senza di essa i crimini informatici prolifererebbero indisturbati.

Vogliamo esprimere i nostri ringraziamenti ai ricercatori di Akamai, Cloudflare, Flashpoint, Google, RiskIQ, Team Cymru e di altre organizzazioni non quotate in borsa. Un ringraziamento anche all’FBI per l’assistenza fornita.

Autori e ricercatori

• Tim April: Senior Security Architect, Akamai
• Chris Baker: Principal of Threat Intelligence, Oracle Dyn
• Matt Carothers
• Jaime Cochran: Security Analyst, Cloudflare
• Marek Majkowski: Enthusiastic Geek, Cloudflare
• Jared Mauch: Internetworking Research and Architecture, Akamai
• Allison Nixon: Director of Security Research, Flashpoint
• Justin Paine: Head Of Trust & Safety, Cloudflare
• Chad Seaman: Sen. Security Intelligence Response Team Engineer, Akamai SIRT
• Darren Spruell: Threat Researcher, RiskIQ
• Zach Wikholm: Research Developer, Flashpoint
• e altri