A fine anno scorso è stata rilevata e studiata dagli analisti di CybergON, business unit di Elmec Informatica una nuova versione del malware GoldBrute, apparso in rete per la prima volta a Giugno 2019. Tale 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 main 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. Il primo file contiene circa 4 milioni di coppie <indirizzo IP>:<porta>; 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.
Il file btclibrary.dll è, in realtà, un file Java Archive Data (JAR) che 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.
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. Nello specifico, 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 a 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.
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 ossia: il supporto a protocolli differenti dall’RDP per quanto riguarda il brute force (SSH e Telnet) e 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.
