Il ransomware Maze chiude. Era davvero in grado di esfiltrare dati?
Maze
Lo scorso 1 novembre 2020 gli sviluppatori del ransomware Maze hanno annunciato sulla home page del loro sito, accessibile via rete TOR, la chiusura ufficiale del progetto.
Anche se di recente non è stata osservata alcuna campagna Maze veicolata in Italia tramite malspam, i criminali dietro al ransomware hanno pubblicato sul loro sito i dati esfiltrati ad illustri vittime italiane.
Ma andiamo con ordine e proviamo a conoscere meglio il malware per capire come si comporta e se realmente ha le capacità di esfiltrare i dati.
Cosa è Maze e chi c’è dietro?
Il nome “Maze” è stato probabilmente scelto dagli autori per dare enfasi al fatto che analizzare questo ransowmare è un po’ come doversi districare all’interno di un labirinto. Maze mira soprattutto ad estorcere denaro ad importanti organizzazioni e, in alcuni casi particolari, l’omonimo malware viene utilizzato in una fase successiva alla compromissione, per garantire ai criminali di tenere sotto scacco le vittime, con la minaccia di pubblicare i loro dati qualora non provvedano a versare la cifra richiesta.
Gli autori del ransomware Maze sono noti (secondo Proofpoint) come gruppo TA2101. Le prime versioni del ransowmare sono state rilasciate esattamente un anno fa mediante campagne rivolte all’Italia e alla Germania. Le prime evidenze ufficiali risalgono al mese di ottobre 2019, anche se sembra sia stato avvistato su qualche forum di settore già nel mese di maggio 2019.
Nel corso di un anno è stato realizzato anche un sito internet su dominio .top per il supporto alle (loro) vittime.
In Italia è stato visto operare sia attrraverso file DLL che come file EXE. Le email solitamente scritte in lingua italiana riportano in allegato un documento MS Office con macro malevola.
Analisi di Maze
Il sample oggetto di analisi è stato scritto in C++ e, come previsto, fa largo uso di tecniche di offuscamento del codice e di soluzioni anti debug.
Nel nostro caso il malware è stato protetto con una versione del software commerciale VMProtect.
A conferma di ciò vi è la presenza di due nomi sezione .vmp0 e .vmp1 di cui la prima vuota e la seconda popolata con caratteri incomprensibili ed un valore di entropia pari a 7.94
Non essendo in possesso di un decryptor funzionante per questa versione di VMProtect l’analisi diventa più complessa .
Tecniche di anti debug e anti analisi
Maze controlla in più occasioni se il valore di IsDebuggerPresent sia True o False. Questa verifica è facile da eludere sia manualmente sia utilizzando appositi plugin disponibili per i debugger.
Inoltre, prima di enumerare i processi, invoca la funzione DbgUIRemoteBreakin per impedire che il sample venga agganciato ad un debugger in runtime.
Tramite GetProcAddress viene richiamata prima la funzione EncodePointer che ha il compito di offuscare il valore del puntatore in modo da non essere intercettato dall’esterno e poi rivelare l’indirizzo corretto tramite una chiamata alla funzione DecodePointer.
Per complicare ulteriormente l’analisi, durante il debug gli autori di Maze hanno pensato di introdurre un po’ ovunque una serie di salti condizionali je e jne consecutivi. Seguendo le istruzioni passo passo si viene dirottati a cicli senza alcun senso.
Maze enumera i nomi dei processi attivi e ne confronta l’hash con una lista interna: se rileva un nome di processo corrispondente viene richiamata la funzione TerminateProcess impedendo al debug di proseguire.
Nel nostro caso, l’analisi è terminata non appena è stato individuato il nome del processo x32dbg.exe, ma la soluzione a questo scenario può essere banale: è sufficiente rinominare il tool con un nome fittizio e per far procede Maze con la verifica del processo successivo.
Di seguito la lista dei nomi di debug monitorata da Maze.
Comandi per l’avvio
Terminati i controlli preliminari, il malware verifica se è stato lanciato seguito da uno di questi comandi:
- –nomutex, consente l’esecuzione di istanze multiple;
- –logging, probabilmente per motivi di debug per visualizzare in console le fasi completate dal malware;
- –path, specifica il ramo da cui avrà origine la cifratura ricorsiva;
- –noshare, non cifra le cartelle condivise.
Dato che il ransomware viene normalmente avviato senza questi parametri, si presume che gli autori abbiano introdotto questi comandi per testare il malware in fase di sviluppo. Questo serve per tenere traccia degli step compiuti, eseguire più istanze contemporaneamente, cifrare una cartella specifica ed escludere quelle condivise: per avere insomma la configurazione perfetta per un ambiente di test.
Mappatura dei device
Lo step successivo richiama la funzione che si occupa di mappare tutte le unità presenti nel sistema, comprese cartelle condivise visto che il nostro sample è stato lanciato senza il comando --noshare
Il ransomware esegue quindi wmic.exe tramite il seguente comando:
Come è possibile osservare, la riga di comando per lanciare wmic.exe è la seguente:
C:\j\..\Windows\gbr\occa\vflaw\..\..\..\system32\rfh\v\x\..\..\..\wbem\yr\..\wmic.exe
Questa istruzione è equivalente a:
C:\Windows\System32\wbem\wmic.exe
wmic.exe viene lanciato seguito dal comando shadowcopy delete per eliminare le copie shadow del sistema prima che abbia inizio il processo di cifratura. Lo scopo è chiaro: impedirne il ripristino.
Di seguito, le stringhe di Maze deoffuscate in memoria:
Lista di server localizzati in Russia
Durante l’esecuzione vengono decifrate in memoria una serie di informazioni, tra le quali una lunga lista di indirizzi IP riguardanti i server da contattare. Tutti gli IP risultano localizzati in Russia.
Successivamente vengono decifrate una serie di stringhe che verranno in seguito utilizzate per comporre la query per contattare il server C2.
| Estensioni | Cartelle remote |
| “.php” | “news” |
| “.asp” | “login” |
| “.aspx” | “register” |
| “.cgi” | “logout” |
| “.jsp” | “edit” |
| “.jspx” | “content” |
| “.do” | “private” |
| “.action” | “messages” |
| “.html” | “account” |
| “.phtml” | “view” |
| “.shtml” | “webauth” |
| “webaccess” | |
| “archive” | |
| “forum” | |
| “post” | |
| “signin” | |
| “signout” | |
| “update” | |
| “support” | |
| “ticket” | |
| “task” | |
| “tracker” | |
| “analytics” | |
| “check” | |
| “checkout” | |
| “payout” | |
| “withdrawal” | |
| “sepa” | |
| “create” | |
| “transfer” | |
| “wire” |
Di seguito, un esempio di preparazione della query per contattare il C2 ancora prima di avviare la cifratura dei dati:
Altri comportamenti di Maze
Oltre a mappare i supporti e a preparare le richieste da effettuare a seguito della cifratura, Maze acquisisce ulteriori informazioni sul sistema compromesso: il nome della macchina e dell’utente, la versione esatta del sistema operativo compreso il codice della lingua utilizzata tramite una chiamata a GetUserDefaultLangID.
Il codice del paese, che nel caso dell’Italia restituisce il valore ax=410, viene confrontato con una lista interna: se non rientra nella lista Maze procede con la cifratura, in caso contrario termina il processo.
Altro controllo viene effettuato sulle cartelle da non cifrare:
Maze mantiene una lista di cartelle “protette” per le quali non viene effettuata la cifratura:
- Windows
- Games
- Tor Browser
- ProgramData
- cache2\entries
- Low\Content.IE5
- User Data\Default\Cache
- All Users
- Local Settings
- AppData\Local
- Program Files
Generazione delle chiavi e cifratura
Maze utilizza le seguenti funzioni in runtime per gestire le chiavi:
CryptGenKeyCryptImportKeyCryptGenRandom
Le chiavi generate vengono salvate dentro il file data1.tmp all’interno di C:\ProgramData\data1.tmp
Una volta definite le chiavi, una combinazione RSA + Salsa20 che in questa analisi non è stata affrontata nel dettaglio, e verificata la possibilità di procedere, Maze cifrata le cartelle presenti sul disco e rilascia dentro un file di testo DECRYPT-FILES.txt con le istruzioni per pagare il riscatto e liberare i dati.
C’è anche un “Easter Egg”
Come osservato con altri sample, anche gli autori di Maze hanno inserito delle stringhe di nomi noti all’interno del codice. In questo caso figura l’indirizzo email di uno degli autori di Bleepingcomputer.
Nel corso dell’analisi sono state riscontrate altre stringhe come ad esempio “nicolas-hoffmann” oppure “reserved for a future trolling“. Una analisi più accurata delle stringhe probabilmente farà emergere altri nomi.
Conclusioni
La macchina compromessa da Maze è stata lasciata attiva per 3 giorni consecutivi e l’unico traffico rilevato ha riguardato le richieste HTTP POST effettuate verso la lista di macchine localizzate in Russia.
I pacchetti inviati al c2 sono cifrati e utilizzano pochi byte: sono le informazioni raccolte sul sistema compromesso. Sembrerebbe quindi da escludere la possibilità di esfiltrazione di copiose quantità di dati da parte del ransomware stesso ma di attribuire l’opera dei databreach all’utilizzo di strumenti ad-hoc (del tipo Mimikatz per intenderci) per la compromissione dei sistemi utilizzati prima che il ransomware stesso venga inoculato all’interno dei server vittima dall’organizzazione criminale.