Ransomware: FUD DLL via Javascript

Introduzione

Nel corso dell’ultima settimana abbiamo ricevuto 5 mail molto simili e di natura evidentemente sospetta, le quali oltre ad un testo evidentemente fasullo, ma sempre diverso, avevano allegato sempre un file in formato ZIP. Curiosi di scoprire cosa si celasse all’interno di questi archivi abbiamo deciso di iniziare un’analisi sull’ultima mail ricevuta.

Mail ransomware
Mail ransomware

Analisi

Preso lo ZIP e portato in un ambiente di test abbiamo proceduto ad estrarlo e ad eseguire il comando file sul contenuto dell’archivio.

Comando file sugli allegati
Comando file sugli allegati

Grazie all’utility abbiamo potuto notare la presenza di un file in formato HTML con estensione WSF (Windows Script File), il quale abbiamo immediatamente provveduto ad aprire con Atom con lo scopo di mapparne il comportamento.

Anteprima file WSF
Anteprima file WSF

Come visto nell’articolo Analisi Documento Word con Macro malevole il classico iter delle infezioni tramite e-mail passa attraverso l’invio di uno script (Javascript, Macro, …) che se avviato andrà a scaricare il reale Malware e ad eseguirlo. Di conseguenza, quando si effettua l’analisi di un allegato di una e-mail, si cercano i vari link o funzioni di generazione di DGA (Domain Generation Algorithm) così da poter scaricare i file del Malware veri e propri e poter proseguire l’analisi. Tuttavia, come vedremo in questo caso, motivo che ci ha spinti a fare questo articolo, non è stato sufficiente il “classico” percorso.

Come si può vedere nello screenshot precedente lo script prova ad eseguire una eval() su una stringa, così da interpretare questa stringa come codice Javascript ed eseguirlo, tale azione spesso viene fatta per offuscare il codice, infatti dopo aver eseguito tale eval ci siamo trovati un codice leggermente più leggibile.

Console-log(eval(x))
Console-log(eval(x))

Individuata la variabile contente la lista degli URL dove il malware era stato caricato (hxxp://nnptrading[.]com/nigb1es7, hxxp://paraspokeri[.]net/x4d7xxc7, hxxp://theweroup[.]net/xr0jkl62, hxxp://nitercatha[.]com/2vpd9d, hxxp://luxcrone[.]net/32359wo) e abbiamo provveduto a scaricarlo.
(Ndr. In alcuni casi potrebbero essere presenti controlli server-side su user-agent o altri aspetti per limitare le possibilità di download esclusivamente alle potenziali vittime.)

Ottenuto tale file abbiamo subito provveduto ad inserirlo all’interno di Cuckoo Sandbox per mapparne il comportamento, ma dopo qualche minuto Cuckoo ci ha dato un report vuoto facendoci pensare a qualche tipologia di VM detection. Tornati sul malware abbiamo provato ad eseguire il comando file il quale ci ha dato come output “Data”, indicando fondamentalmente che il formato del file non era noto, il che ci è stato confermato aprendo il malware in un Hex editor.

Hex del malware
Hex del malware

A questo punto è stato necessario tornare al codice Javascript con l’obiettivo di capire cosa succedesse dopo il download del malware. Essendo tale codice estremamente offuscato ci siamo dovuti aiutare con un analisi dinamica, ovvero eseguendo porzioni di codice dello script per capire come venissero popolate le variabili e gli oggetti ed andando a sostituire i risultati nel sorgente, ottenendo una struttura decisamente più leggibile.

Snippet di codice de-offuscato
Snippet di codice de-offuscato

Attraverso il codice abbiamo notato che successivamente al download il file viene aperto in modalità testo e il suo contenuto passato a due funzioni IGi2() e Kx1().
La prima funzione ha il compito, attraverso un dizionario, di sostituire il contenuto di ogni carattere che rispetta determinate caratteristiche con un altro carattere mappato in un’array, mentre la seconda funzione effettua un controllo sulla validità del file dopo la fase di decoding.

Snippet funzione IGi2()
Snippet funzione IGi2()

Come ultimo step il file decodato andrà a sostituire quello scaricato attraverso la funzione OMb() dopo una successiva fase di decoding analoga alla precedente effettuata dalla funzione St(). Al termine di questa fase si ottiene un file dll legittimo contenente il file malware vero e proprio.

Tuttavia il lavoro non è ancora finito, infatti provando ad eseguire la dll con rundll32.exe su un ambiente virtuale, salvo la creazione di un file vuoto il malware sembrava fermarsi. A questo punto un ultima analisi delle istruzioni finali del Javascript ci ha nuovamente indicato la via, infatti il malware viene lanciato con il seguente comando C:\Windows\System32\rundll32.exe C:\path\to\TEMP\malware.dll,qwerty 323 

Esecuzione della .dll
Esecuzione della .dll

Ed ecco dopo qualche istante la nostra Virtual Machine infettata dal Ransomware Locky, con tutti i file cifrati e cambiati di estensione in .odin.

Riflessioni finali

Come accennato in precedenza la particolarità nella distribuzione di questo malware risiede nel metodo utilizzato per offuscare il file dll e renderne difficile l’analisi, tutte azioni che comunque possono solo rallentare il processo, ma non bloccarlo, in quanto viene tutto eseguito client-side ed è di conseguenza leggibile e replicabile.

Consigliamo inoltre di seguire Paolo Dal Checco sul suo blog ransomware.it il quale fornisce sia ottimi consigli agli utenti finali per prevenire le infezioni, che analisi di ransomware noti, che consigli su come gestire un’infezione.

Allegati

Chi fosse interessato ai file analizzati può scaricare lo zip protetto da password ransomware allegato.

polict

Conosciuto su twitter come polict, lavoro a Shielder come security researcher e penetration tester. In ufficio sono quello in infradito e cuffiette.