Come cambia la diffusione del malware: gli script con Nietzsche

Autori:

• Jozsef Gegeny, Senior Security Researcher
• Norbert Biro, Senior Security Researcher
• Robert Neumann, Responsabile, Acronis TRU Labs

Negli ultimi dieci anni il ruolo delle catene di diffusione dei malware ha assunto un ruolo di grande rilevanza. Dalla semplice distribuzione tramite un allegato e-mail dannoso o un download inconsapevole di file malevoli, i criminali sono arrivati all'ideazione di una serie di passaggi intermedi prima di diffondere il payload finale. Questi passaggi aggiuntivi sono progettati per aggirare le soluzioni di sicurezza installate e garantire una consegna del payload ininterrotta; tuttavia, poiché sono spesso inutilmente complessi, comportano anche rischi aggiuntivi. Come accade con le catene convenzionali, se vengono interrotte in un punto qualsiasi, la loro continuità si perde definitivamente.

Di recente, ci siamo imbattuti in una catena di distribuzione complessa che utilizza più linguaggi di script e ha l'obiettivo di diffondere famiglie di malware di alto profilo, come il codice open source DCRat o l'infostealer Rhadamanthys.

La nostra indagine ha preso avvio con la ricezione di un'e-mail con un allegato in formato RAR. Come prevedibile, il file compresso non contiene contenuti legittimi, ma un file script di Visual Basic (VBS) denominato "Citación por embargo de cuenta". Il nome del file, chiaramente indirizzato a un pubblico di lingua spagnola, suona in italiano come "Citazione per pignoramento del conto corrente". Si tratta di un avviso legale relativo al sequestro o al blocco di un conto bancario a causa di un debito o di altri obblighi finanziari. L'intenzione è chiara: chi riceve l'e-mail non deve avere alcuna esitazione nello scaricare l'allegato; così facendo avvierà l'esecuzione di una catena di diffusione molto pericolosa.

Il file VBS dannoso utilizza dropper nidificati che avviano un processo di distribuzione in più fasi. La nostra analisi è stata suddivisa in quattro fasi distinte, come mostra la figura seguente.

Lo script di Visual Basic ha una dimensione di circa 200 KB; è il segnale che non ci troviamo di fronte a un semplice script di automazione sviluppato internamente. Osservandolo in dettaglio, diventa evidente che siamo in presenza di un codice offuscato. La dimensione piuttosto inusuale è dovuta solo in parte all'offuscamento, come dimostrerà l'analisi successiva: il file contiene infatti anche un payload codificato, che verrà estratto solo nella fase tre.

Esistono diversi modi per gestire l'offuscamento. È possibile deoffuscare il codice manualmente, utilizzare il supporto AMSI di Microsoft o ignorarlo, nella speranza di riuscire a intercettare il payload finale quando l'esecuzione raggiunge l'ultima fase. Noi di Acronis siamo fermamente convinti che per individuare le minacce sia necessario un approccio multilivello. Per questo, ogni volta che è possibile, preferiamo neutralizzare i contenuti pericolosi prima della loro esecuzione. Oltre al supporto per l'interfaccia AMSI, utilizziamo anche un emulatore di script generico sviluppato internamente e basato sul concetto di AST (albero di sintassi astratta), per automatizzare il deoffuscamento in scenari simili.

Dopo il deoffuscamento, lo script appare molto più leggibile all'occhio umano. La funzione principale dello script VBS iniziale è quella di generare un file batch di Windows (BAT) in cui viene trasferito il comando di esecuzione. Il file BAT dannoso viene quindi collocato nella directory del profilo utente:

Inoltre, lo script VBS crea una copia di sé stesso nella stessa directory:

Non sorprende che, come nel livello precedente, anche lo script batch della seconda fase sia offuscato.

Se viene eseguito, il file batch costruisce una stringa codificata in Base64 partendo da numerose variabili di ambiente, con l'aiuto del comando "set". Questa stringa Base64 rappresenta uno script PowerShell compresso, che verrà eseguito utilizzando l'argomento "-command" come se fosse stato digitato al prompt dei comandi di Windows PowerShell:

In sostanza, i dati Base64 decodificati che rappresentano uno script di PowerShell vengono scaricati nella directory del profilo utente come:

ed eseguiti con il comando seguente:

È interessante notare come gli autori del malware non si siano affatto adoperati per oscurare questo livello, perché il testo è in chiaro e facilmente leggibile:

Il codice, tuttavia, contiene alcune curiose citazioni come questa:

Quasi tutte le citazioni appartengono a Friedrich Nietzsche, il filosofo tedesco; sono state aggiunte come commenti nello script di PowerShell ma non hanno alcuna funzione pratica. Chissà, forse gli autori del malware sono anch'essi filosofi.

La funzione principale di questo script è quella di individuare il file aguwDl.bat delle fasi precedenti nella directory del profilo dell'utente, leggerne l'ultima riga (molto lunga), rimuovere i byte del marcatore, infine decodificare e caricare il payload risultante nella memoria:

Il payload caricato in memoria è un eseguibile Windows .NET e appartiene a una famiglia di trojan di accesso remoto molto diffusa, chiamata DCRat.

Il payload è stato compresso con un packer .NET personalizzato ed è offuscato. L'analisi ci ha permesso di identificarne il contenuto: due blob di dati crittografati all'interno della struttura delle risorse.

Questi blob di dati utilizzano solo una crittografia di base e possono essere facilmente decrittografati con un'operazione XOR byte per byte con la chiave 0x78. La decodifica di queste risorse svela due ulteriori file eseguibili:

Uno è l'eseguibile principale di DCRat, l'altro è una libreria che supporta il modulo packer durante il caricamento e l'esecuzione dell'esemplare di DCRat direttamente in memoria, senza scriverlo su disco. La tecnica utilizzata per ottenere questo risultato è chiamata RunPE ed è implementata nella libreria dell'helper. Oggi il file binario principale di DCRat è piuttosto datato, ma con l'aiuto di metodi di distribuzione simili a quello esaminato è ancora possibile diffondere l'infezione.

Le catene di distribuzione utilizzate nelle campagne più pericolose sono in continua evoluzione e diventano sempre più complesse. Gli autori delle minacce sono continuamente in cerca di metodi per nascondere i payload finali, anche se si tratta solo di un'ulteriore variante di una famiglia di malware che circola da anni. Se i loro tentativi vanno a buon fine, potrebbero eseguire anche i file binari dei malware più datati senza alcun intervento fisico, a condizione che la soluzione di sicurezza installata non ne rilevi la presenza in memoria.

Va detto che con la maggiore complessità delle catene di distribuzione, aumentano anche il rischio e la possibilità di interromperle ad ogni passaggio aggiunto, impedendo il caricamento del payload previsto dagli autori.

Durante l'analisi di questa campagna, abbiamo individuato un paio di esempi simili, in cui la catena di infezione era identica, come descritto sopra, ma con un diverso payload finale. Invece di distribuire DCRat, gli attaccanti hanno utilizzato l'infostealer Rhadamanthys e un altro trojan di accesso remoto molto conosciuto, Remcos.

Acronis Advanced Security + Extended Detection and Response (XDR) rileva i componenti utilizzati nella catena di attacco.