GoldBrute: analisi dell'aggiornamento del malware rilasciato a Giugno

In questo articolo analizziamo una nuova versione del malware “GoldBrute”, apparso in rete per la prima volta a Giugno 2019.

Come funziona:

Il malware scansiona e sfrutta server che espongono il servizio RDP (Remote Desktop Protocol) e che utilizzano credenziali deboli o rubate. La lista di macchine censite e potenzialmente controllate dalla botnet era di circa 1.5 milioni a Giugno 2019 (Fonte) ma, pensate, in questo momento, il numero delle “vittime” ha superato i 4 milioni.

GoldBrute sfrutta la vulnerabilità BlueKeep (CVE-2019-0708) che può affliggere un sistema operativo Windows con l’RDP abilitato e non aggiornato.

GoldBrute si nasconde dietro un processo apparentemente lecito - javaw.exe - che viene scaricato sulla macchina compromessa insieme al Java Runtime, varie dll e anche un archivio zip che risulta essere protetto da password (XHr4jBYf5BV2Cd7zpzR9pEGn).

L’archivio – hash.zip - contiene due file di testo: 1. Il primo file contiene circa 4 milioni di coppie <indirizzo IP>:<porta>; 2. Il secondo contiene circa 14 mila coppie <username>:<password> che vengono utilizzate per l’attività di brute force.

A questo punto, viene lanciato il comando per l’esecuzione del malware:

C:\Users\\\<username>\AppData\Local\bitcoins\bin\javaw.exe -server -d64 -Xms64m -jar C:\Users\\\<username>\AppData\Local\bitcoins\bin\btclibrary.dll

Il file btclibrary.dll è, in realtà, un file Java Archive Data (JAR) che abbiamo decompilato e analizzato. Il JAR si presenta con circa 12000 classi: solo 84 sono quelle create ex novo e appartenenti al malware, le restanti sono classi di libreria.
L’entry point principale è situato all’interno della classe SocketMain. Dal codice si nota come all’interno della classe venga istanziato un oggetto di tipo Console su cui viene inizializzato l’intero flusso tramite il metodo run.

All’interno del metodo run vengono assegnati alcuni parametri iniziali di configurazione (definiti all’interno della classe Config) e, nella parte finale, viene istanziato un oggetto di tipo GoldBrute, che fa partire l’esecuzione malevola. Le configurazioni standard inizializzate dal malware definiscono l’indirizzo IP e la porta del botmaster - 172.94.15.22:8333 - con sede in Germania.

La classe GoldBrute può essere definita come la classe core in cui vengono effettuate e controllate, nell’ordine: - le attività di scansione tramite l’utilizzo della classe ScanThread - le attività di brute force servendosi della classe BruteThread.

Per gestire queste due attività vengono creati ed eseguiti due tipologie di Thread:

ScanThread

Il Thread avvia una scansione di indirizzi IP per cercare eventuali host con RDP esposto e vulnerabile. Solo quando il numero di risultati prodotti supera la soglia definita nella variabile CHECKER_EXPECT_IP_FOR_ENABLE_BRUTE (di default impostata a 80) viene eseguita l’attività di brute force.

Questa scansione viene delegata alla classe ScanThread che, a differenza della versione distribuita a giugno, è stata aggiornata con la possibilità di supportare altri due protocolli SSH e Telnet.

A questo punto, ogni volta che viene trovato un nuovo host vulnerabile, questo viene aggiunto ad una coda di tipo ConcurrenteLinkedQueue che, successivamente, viene restituita al botmaster.
Per effettuare le scansioni e per individuare host con RDP esposto e vulnerabile viene generato un pacchetto ad hoc il cui formato è descritto all’interno del metodo processPacket.

La conversione dal formato byte a UTF-8 è la seguente:

BruteThread

BruteThread è la classe designata all’attività di brute force che sfrutta le credenziali statiche caricate precedentemente.
In particolare, la classe BruteThread riutilizza per i propri pacchetti un formato simile a quello utilizzato per la fase di scansione. Tutta la comunicazione tra i bot e il botmaster avviene attraverso connessioni di tipo WebSocket e utilizza una cifratura AES/CBC/PKCS5Padding.

La cifratura/decifratura viene effettuata sfruttando chiavi inserite staticamente all’interno del file di configurazione (classe Config).

I pacchetti di comunicazione tra i bot e il botmaster sono definiti come classi: BruteProjectPacket, BruteInfoPackage e BruteResultsPackage; vengono utilizzati per ottenere statistiche sulle scansioni, per ricevere aggiornamenti circa lo stato della scansione e per ottenere i risultati finali.

Risulta interessante notare come, nella nuova versione del malware, siano presenti alcune parti di codice non ancora completamente operative: - il supporto a protocolli differenti dall’RDP per quanto riguarda il brute force (SSH e Telnet) - l’utilizzo di un database SQL persistente in sostituzione delle liste volatili utilizzate per tenere memoria dello stato dell’esecuzione - diversi entry point per permettere l’esecuzione di differenti parti del codice, indipendentemente dall’esecuzione del malware stesso

Per individuare le comunicazioni tra i bot e il botmaster, abbiamo creato una nuova regola Suricata/SNORT:

alert tcp any any -> [104.156.249.231,172.94.15.22] 8333 (msg:"CYBERGON CNC GoldBrute Reported CnC connection"; classtype:trojan-activity; sid:8000001; rev:1; metadata: affected_product Windows, attack_target Any, tag GoldBrute, tag RDP Bruteforce, signature_severity Critical, created_at 2019_12_11, updated_at 2019_12_11;)

Il nostro obiettivo è di approfondire il comportamento conseguente all’attività preliminare del malware, per individuare eventuali attività post-infezione.

Potete consultare la collection delle nostre rules qui