Profilo dell'autore su una botnet inaspettatamente prevalente

L'affascinante storia della botnet Dark Frost ci presenta un criminale sconcertante il cui tasso di successo e livello di originalità non sono allineati. La botnet basata su una combinazione disordinata è stata creata utilizzando il codice rubato da diverse famiglie di malware comuni (Mirai, Gafgyt e Qbot), il che ha consentito a questo criminale di sferrare attacchi contro il settore del gaming . 

In tutto ciò, il criminale si è vantato dei propri exploit sui social media, sfruttando la botnet per impegnarsi in banali faide online e persino lasciare firme digitali sui propri file binari (Figura 1). 

Questo profilo di criminale è più diffuso di quanto si possa pensare. Con sufficiente determinazione e una conoscenza rudimentale del codice, quasi tutti possono diventare una vera minaccia. Ciò è particolarmente vero quando si parla di individui più giovani che possono o meno comprendere le potenziali conseguenze di queste azioni. La fiducia nella propria capacità di vivere al di sopra della legge tende a eclissare i parametri legali stabiliti, rendendoli più pericolosi del previsto.

Il nostro primo campione binario di Dark Frost è stato raccolto il 28 febbraio 2023 in alcuni honeypot HTTP del SIRT (Security Intelligence Response Team) di di Akamai. L'autore di attacchi mirava a configurazioni errate nei server Hadoop YARN (nessuna CVE assegnato) che consentono l'esecuzione di codice in modalità remota (RCE). Anche se il campione doveva essere chiamato "Darkness Botnet," questo titolo era già stato assegnato a una campagna DDoS lanciata nel 2010. Di conseguenza, tenendo conto del nome originale e di altri riferimenti binari, abbiamo deciso di chiamare il campione "Dark Frost Botnet".

Lo sfruttamento di questa errata configurazione YARN sta diventando di recente sempre più popolare poiché non gli è stata assegnata una CVE e consente a un criminale di indurre il server a scaricare ed eseguire il proprio binario dannoso. Tuttavia, va notato che questa vulnerabilità esiste dal 2014, pertanto è tutt'altro che una nuova tecnica. Considerando il suo livello di successo, tuttavia, continuerà probabilmente a essere un fattore nelle future botnet, nonostante la sua età. 

Il criminale ha iniziato inviando un test per verificare se l'applicazione fosse vulnerabile a questo tipo di attacco (Figura 2).

Dopo aver ricevuto una risposta da un'istanza nota vulnerabile che abbiamo fornito, il criminale ha ritenuto l'obiettivo adatto e ha proceduto a distribuire il payload dannoso (Figura 3).

Osserviamo anche un'altra richiesta HTTP inviata, ma al momento non sappiamo per cosa potrebbe essere utilizzata (Figura 4).

Quando è stato esaminato originariamente, il file binario era denominato "roof" e, sebbene l'hash non avesse alcuna reputazione tramite vari strumenti di terze parti, la nostra automazione interna lo riteneva simile a Gafgyt (Figura 5). Ciò potrebbe essere dovuto al fatto che gli IP dell'autore di attacchi sono stati osservati distribuire una variante specifica di Gafgyt nei mesi precedenti alla distribuzione dei binari di Dark Frost, ma più probabilmente corrispondeva a varie stringhe comuni in molti malware in quei giorni. 

Dopo aver fatto perno sull'indirizzo IP per cercare binari aggiuntivi, ne abbiamo trovati altri denominati "roof", ciascuno attribuito allo stesso autore dall'ottobre 2022. Questo ci ha dato un nuovo IP con cui lavorare, che a sua volta ci ha dato la prova di ulteriori tentativi di distribuire payload (Figura 6; censurato per sensibilità razziale).

Questo particolare autore di attacchi si è preso il merito di parecchi sforzi, con diversi livelli di evidenza. A volte ha semplicemente pubblicato un post sui social media, affermando di essere la causa di vari problemi, che in realtà non avrebbero molto peso. Tuttavia, occasionalmente fanno seguire questi dichiarazioni da screenshot che documentano i risultati dei propri loro attacchi. 

Un esempio di ciò è il tweet su un attacco ai server Plutonium (Figura 7), una piattaforma di hosting di giochi open source con server dedicati e supporto mod.

Tweet come questi sono solo l'inizio. Il criminale arriva persino a pubblicare video completi degli attacchi, come questo attacco sferrato contro un server AmongUs (Figura 8).

Come potete osservare negli screenshot, questo criminale è attivo da qualche tempo, da maggio 2022, quando ha sferrato un attacco contro i server di Rogue Company (Figura 9).

Abbiamo anche scoperto che l'autore si prendeva gioco di alcune delle sue vittime e rivelava informazioni sui suoi acquirenti (Figura 12).

Alcune delle domande più difficili a cui rispondere durante l'analisi del malware sono chi ne è responsabile, quali sono gli obiettivi e quanto è grande la botnet. Questo criminale informatico ha risposto alle prime due domande per noi, quindi abbiamo iniziato a verificare se avrebbe risposto anche alla terza domanda e, come previsto, l'ha fatto.

Secondo la Figura 13, uno screenshot acquisito dall'autore del malware nel febbraio 2023, nella botnet sono presenti 414 dispositivi, la maggior parte dei quali sono architetture ARMv4 e i successivi due più comuni sono MIPSEL e x86. La presenza di ARMv4 è particolarmente interessante, in quanto questa architettura è abbastanza obsoleta. Questo metodo di compilazione specifico per ARMv4 e ARMv7 è comune perché ARMv4 è compatibile con ARMv5 e ARMv6. La compilazione sia per ARMv4 che per ARMv7 garantisce che il malware possa prendere di mira anche dispositivi più moderni che eseguono l'architettura ARMv7. 

Questo approccio basato su un doppio obiettivo consente al malware di lanciare una rete più ampia, aumentando le sue possibilità di riuscire a infettare i dispositivi.

Mettere le mani sul binario sarebbe stato difficile se non fosse stato per il nostro sistema di raccolta automatizzata dei binari (Figura 14), perché al momento dell'indagine l'IP della distribuzione era inattivo. 

Dopo aver recuperato il campione, abbiamo appreso che avevamo a che fare con una versione x86-64 (Figura 15), che è stata rimossa, aggiungendo qualche piccolo inconveniente durante la decompilazione.

C'erano, tuttavia, molti altri indicatori come la gestione degli errori e i messaggi di utilizzo per orientarsi all'interno del codice (Figura 16).

Ci sono stati otto attacchi totali, alcuni molto comuni, come UDP e TCP, ma altri un po' più curiosi, come zgoflood (figura 17).

Grazie ai nostri sforzi per decompilare il campione, siamo stati in grado di rinominare alcune delle funzioni rimosse in base a ciò per cui abbiamo dedotto che fossero utilizzate (Figura 18).

Abbiamo quindi applicato la patch al file binario (Figura 19) in modo che il nostro IP fosse il server di comando e controllo (C2). Potete vedere che il nome della variabile stringa ora è diverso dal suo valore effettivo. È interessante notare che C2 era anche l'IP di distribuzione del malware prima di questa modifica.

Utilizzando un altro terminale per l'ascolto sulla porta C2 specificata (TCP/420), siamo stati in grado di superare i controlli della connessione C2, ma il programma continuava a generare un errore (Figura 21).

Il malware tenta di segnalare il tipo di sistema operativo e l'architettura del campione di malware che ha infettato il dispositivo (figura 22). In questo caso, stiamo usando Arch Linux per far diffondere ed esaminare un campione x86.

Dopo aver superato con successo i passaggi di connessione e registrazione, il programma ha continuato a uscire nonostante i nostri migliori sforzi. Alcuni utili messaggi di errore indicavano che la causa era la mancanza di un driver watchdog installato nel nostro laboratorio di malware. Abbiamo tentato molte volte di aggirare o soddisfare questo controllo finché non ci siamo resi conto che sebbene il processo avesse apparentemente interrotto l'esecuzione sulla riga di comando, aveva avviato un processo figlio in background che era in attesa di comandi. 

Per verificarlo, abbiamo inviato l'heartbeat per una tipica variante BASHLITE utilizzando le chat di inoltro Internet per le comunicazioni C2 (Figura 23).

Gli attacchi socketflood e junkflood sembravano anch'essi molto simili, entrambi inviavano una piccola quantità di contenuto con codifica esadecimale su TCP (Figura 25). Un'altra cosa da notare è che socketflood in realtà viene stampato come flood HOLD . 

Dopo aver testato il comando C2 che avevano elencato come @c2, abbiamo riscontrato un errore di utilizzo. Abbiamo deciso che probabilmente intendevano !c2, quindi lo abbiamo provato (Figura 26) ed è stato inviato un singolo pacchetto.

Gli attacchi onepacket, std, randfloode zgoflood sono stati anch'essi lanciati con successo, ma in realtà non hanno inviato alcun dato (Figura 27). Ciò potrebbe significare che queste funzionalità sono ancora in fase di sviluppo o semplicemente non funzionanti.

Abbiamo iniziato a confrontare gli attacchi e abbiamo scoperto che l'UDP flood era il più affidabile e produceva il maggior output. Abbiamo utilizzato varie dimensioni di pacchetto, a partire da 1.024 per vedere come la dimensione ha influenzato la quantità totale di dati inviati.

Come potete osservare nella Figura 28, l'abbiamo eseguito su una porta specifica per 10 secondi, quindi abbiamo proceduto alla raccolta di questi dati in tcpdump per analizzare i risultati (Figura 29).

Il risultato alla dimensione del pacchetto 1.024 per 10 secondi è stato di 1,4 milioni di pacchetti acquisiti, per un totale di 1,5 GB di dati. Questo arriva a 1,2 Gbps. Facendo questo stesso esperimento, abbiamo osservato i seguenti risultati per varie dimensioni di pacchetti (Tabella 1).

Eseguendo il test in questo modo, molto probabilmente vedremmo un autore di attacchi usare con questo pacchetto una dimensione vicina a 1.024. Se raddoppiata, l'output del pacchetto diminuisce, a causa della frammentazione del pacchetto, il che significa che osserviamo solo i pacchetti che arrivano tramite la porta specificata e non i relativi frammenti. Per continuare correttamente l'analisi comparativa, abbiamo dovuto iniziare a lanciare questi attacchi al loopback per evitare la frammentazione e ascoltare l'interfaccia di loopback per rimisurare (Tabella 2). 

Sebbene la botnet Dark Frost sferri attacchi abbastanza potenti da disattivare molti servizi online, quelli protetti da Akamai sono abbastanza sicuri. Il SIRT continuerà a monitorare minacce come queste e allerterà la comunità su ciò che osserviamo. Per ulteriori ricerche in tempo reale da parte di Akamai, seguiteci su Twitter.