Arresto anomalo di una botnet
Analisi riassuntiva
I ricercatori di Akamai hanno proseguito la loro ricerca su KmsdBot, una botnet di cryptomining, arrestata accidentalmente in modo anomalo dai suoi autori.
Nel nostro ambiente controllato, siamo stati in grado di inviare comandi al bot per testarne le funzionalità e attaccarne le firme.
Nell'ambito di quest'analisi, un errore di sintassi ha fatto in modo che il bot smettesse di inviare comandi, interrompendo efficacemente la botnet.
Dal momento che questa particolare botnet non mira a persistere nel sistema, può continuare la sua missione solo se reinfetta il sistema.
Introduzione
All'inizio di questo mese, il team Akamai Security Research ha pubblicato un blog su KmsdBot, una botnet di cryptomining che infetta le sue vittime tramite il protocollo SSH e credenziali deboli. Questa botnet, dopo aver infettato i nostri honeypot, è stata prontamente sottoposta ad una nostra analisi, di cui abbiamo poi pubblicato i risultati in un rapporto.
Tuttavia, dopo questa pubblicazione, abbiamo continuato a monitorare la botnet, pertanto desideriamo condividere i nostri aggiornamenti in questo blog, come il fatto di averla resa inutilizzabile. In questo post evidenzieremo i passaggi intrapresi per ispezionare KmsdBot, che ci hanno consentito di eseguire i nostri comandi e, infine, bloccarla.
Come ottenere il comando e il controllo (C2)
L'elemento più letale di qualsiasi entità dannosa è la sua capacità di ottenere il comando e il controllo (C2) delle vittime designate. Dal momento che KmsdBot disponeva di una funzionalità C2, volevamo testare diversi scenari ad essa correlati. Come parte del test, abbiamo modificato un recente campione di KmsdBot per comunicare con un indirizzo IP nello spazio degli indirizzi RFC 1918.
Ciò ci ha consentito di gestire la botnet in un ambiente controllato e, di conseguenza, siamo riusciti a inviare al bot i nostri comandi per testarne le funzionalità e attaccarne le firme. Il dato interessante è che, dopo un unico comando formattato in modo errato, il bot ha smesso di inviare comandi. Naturalmente, abbiamo iniziato ad indagare. Non capita tutti i giorni di imbattersi in una botnet arrestata in modo anomalo dagli stessi suoi autori.
Come l'abbiamo scoperto
Figura 1: disassemblaggio della funzione sys.main.connect()
Come si può vedere, la sezione della stringa è archiviata nella posizione in memoria 0x00632f19. Possiamo saltare all'indirizzo nel file binario e modificarne il contenuto in modo da farlo puntare a un indirizzo di rete presente nello spazio RFC 1918, in particolar modo in un punto nell'indirizzo 192.168.0.0/24, che possiamo controllare.
In questo modo, possiamo agire come nella funzionalità C2 e inviare comandi di attacco di esempio per indirizzare il traffico a una destinazione in cui possiamo registrare il traffico di rete.
Figura 2: scrittura dell'indirizzo in esadecimali .861.291 a ritroso a causa dell'architettura endian
Quindi, la nostra nuova funzionalità C2 è l'indirizzo 192.168.0.31 sulla porta 57388 (Figura 2). Sappiamo che la funzionalità C2 comunica in testo chiaro, pertanto è possibile inviare i comandi del malware tramite Netcat. A questo punto, configuriamo due macchine virtuali: una in cui far esplodere il malware e l'altra in cui usare la nostra funzionalità C2.
Durante il test, abbiamo notato che la botnet smetteva di inviare comandi di attacco dopo aver osservato l'arrivo di un unico comando in formato errato, ossia il comando
!bigdata www.bitcoin.com443 / 30 3 3 100
Un osservatore acuto noterà la mancanza di spazio tra il sito web di destinazione e la porta. Nel codice del bot non è integrata la correzione degli errori per verificare che i comandi siano nel formato corretto.
Pertanto, un comando in formato errato causa l'arresto anomalo del file binario Go con una traccia dello stack che indica un errore di indice fuori intervallo perché è stato fornito il numero errato di argomenti. Abbiamo testato questa teoria con la nostra funzionalità C2 e la configurazione del bot (Figura 3).
Figura 3: emulazione della funzionalità C2 e riproduzione del comando errato da inviare
Figura 4: bot arrestato in modo anomalo perché fornito il numero errato di argomenti
Probabilmente, questo comando errato ha fatto arrestare in modo anomalo tutto il codice della botnet che era in esecuzione sui computer infetti e comunicava con la funzionalità C2, facendo terminare, essenzialmente, la botnet. Dal momento che il bot non dispone di alcuna funzionalità di persistenza sul computer infetto, l'unico modo per recuperare da questa situazione è reinfettare e ricostruire la botnet da zero.
Conclusione
Nel campo della sicurezza, è davvero insolito trovarsi di fronte ad un episodio del genere. Nel nostro mondo fatto di attacchi zero-day e attacchi che mirano ad esaurire le risorse, vedere una minaccia che può essere mitigata con l'equivalente in codice di un refuso è una bella storia. Questa botnet si era intrufolata nei sistemi di alcuni importanti brand di lusso e società di gaming, eppure, per un solo comando non riuscito, non poteva proseguire il suo lavoro. Si tratta di un esempio della natura inflessibile della tecnologia e di come chi tenta di sfruttare possa essere sfruttato a sua volta.
L'obiettivo del team Akamai Security Research è monitorare, rilevare, documentare e pubblicare le nuove scoperte per proteggere la sicurezza e la stabilità di Akamai, dei suoi clienti e di Internet nel complesso. Continueremo a monitorare questi attacchi e ad aggiornare di conseguenza questo blog. Per aggiornamenti in tempo reale della ricerca sulla sicurezza, seguiteci su Twitter.
