[BatLoader]| [NatsoLoader]| dropper| multistage| Delphi| Remcos| Discord| Morphine | cloud storage| email| phishing| spoofing| ISO| BoB/BobSoft| .Gif| URL| Twetdrv.exe| tewT.url - Nel presente report si descrive l’analisi di ModiLoader, un dropper multi-stage che viene solitamente sfruttato per eseguire un RAT sulla macchina vittima, ad esempio Remcos. Il file sospetto si presenta come un eseguibile Windows a 32 bit, la sua analisi avanzata si ritiene significativa a causa della sua abilità di evadere le sandbox più note e dell’inefficacia delle analisi statiche o dinamiche di base. Di seguito si elencano i punti chiave: - il malware usa tre stage per la consegna del payload; - i primi due stage sono scritti in Delphi; - nel primo stage viene utilizzato un timer per eseguire, dopo 17 secondi, la callback che effettua l’unpacking di una dll. La routine di decifratura della dll sfrutta tecniche di steganografia su una immagine di tipo GIF presente nelle risorse dell’eseguibile; - nel secondo stage carica ed esegue la dll estratta, la quale si rivela essere un downloader che scarica un PE cifrato da un canale Discord; - nel terzo stage, il PE risulta essere una nuova dll, la quale setta la persistenza e successivamente, tramite la tecnica del process hollowing su un processo di Internet Explorer lecito, estrae, decifra ed avvia un eseguibile; - l’eseguibile contiene un packer Morphine che, dopo essersi auto estratto, esegue il RAT Remcos. La diffusione del sample sembrerebbe avvenire tramite vettori tradizionali, come email di phishing, più o meno mirate. In particolare, l’indirizzo email del mittente sembrerebbe essere stato oggetto di tecniche di spoofing al fine di celare il vero mittente che, dagli esempi analizzati, impiega web-mail general purpose di vario genere. L’oggetto e la tematica trattata nella comunicazione sembrerebbero essere legati principalmente all’invio o ricezione di merci, allegando quello che viene spacciato come un documento relativo a quest’ultime (preventivi, procedimenti legali, bonifici, ecc.). Focalizzando la propria attenzione sul sample, questo si presenta tipicamente compresso all’interno di archivi senza password, ma sono stati anche individuati alcuni sample contenuti all’interno di immagini ISO. Di seguito si elencano alcune informazioni sul file analizzato: - File metadata Nome “Files 224643, 4565577.exe” - Dimensione 636 568 byte MD5 D19AC81E5A2B0797649878CB25A05912 - SHA1 9327C927F456BEB49F279EC306064C1D4555BD0A - SHA256 509CC1160A4457F7919BB870D59F8E16C311757780172B72B29D506FDD54EEDA - Tipo Eseguibile .EXE a 32 bit Il malware si presenta dunque come un eseguibile Windows a 32 bit, il quale, una volta eseguito in Sandbox, non fornisce molte informazioni utili all’analista. Vengono infatti utilizzate tecniche di evasion, descritte in seguito, che riescono a eludere i controlli delle sandbox standard. A valle di controlli automatici di tale tipo, un’informazione utile che emerge è relativa a connessioni verso il sito ufficiale di Discord, la nota piattaforma di messaggistica istantanea per i videogiocatori. Si procede dunque ad effettuare un’analisi avanzata del sample in oggetto. Analisi Packer Delphi – Stage 1 Si inizia con un’analisi statica di base. Si nota, anzitutto, che si tratta dell’ormai diffuso packer scritto in linguaggio Delphi, individuato con firma “BoB / BobSoft”, e che la data di compilazione è Timestomped (Figura 2). Successivamente si osserva che l’eseguibile presenta una sezione risorse (.rsrc), tra le quali, in RCDATA, spicca una GIF nominata T__6541957882 (Figura 3). La presenza di una risorsa di questo tipo in un sample sospetto fa solitamente presupporre l’utilizzo di steganografia per l’unpacking del codice. Un’analisi dinamica di base con simulazione della connessione Internet non porta ad alcuna informazione aggiuntiva. Si utilizzeranno dunque un disassembler e un debugger per approfondire le analisi. Utilizzando tali strumenti, si osserva che l’entry point del packer corrisponde a quello del PE e che quest’ultimo corrisponde alle routine di avvio di Delphi, le quali sono sempre pressoché simili in tutti gli eseguibili scritti in questo linguaggio. In linea generale, le funzioni interessanti negli eseguibili Delphi sono spesso quelle con prefisso _TForm_main, tra le quali, dopo una breve analisi di ciascuna, emerge _TForm_main_xvvTimer. La funzione è significativa perché viene richiamata dal packer alla ricezione di un messaggio con codice 0x113 (corrispondente alla costante WM_TIMER) nel ciclo di “message pump” di Win32. Questa tipologia di messaggi viene inviata nel loop alla scadenza di un timer. Infatti, andando a ricercare nel codice tutti i riferimenti statici alla funzione nativa SetTimer, si trova una chiamata sospetta all’impostazione di un timer di 17 secondi (Figura 5) con callback nulla. Come descritto nella documentazione ufficiale Microsoft, quando il puntatore alla funzione di callback da eseguire alla scadenza del timer è nullo allora la gestione deve essere effettuata manualmente nel loop di message pump: è dunque questo il timer che viene impostato dal packer, il cui termine scaturisce, come accennato inizialmente, la chiamata alla funzione _TForm_main_xvvTimer. La funzione _TForm_main_xvvTimer conferma di essere quella significativa per il packer, in quanto prima rimuove il timer, poi avvia la routine di unpacking e loading. Entrando nel dettaglio dell’algoritmo utilizzato per ottenere il codice unpacked, si osserva che, come ipotizzato inizialmente, il packer sfrutta la risorsa grafica .GIF mostrata in Figura 3, ricostruendone dapprima il nome T__6541957882 (carattere per carattere a partire dall’ultimo) per poi recuperarla e caricarla in memoria. Una volta ottenuta la GIF, il packer usa un placeholder, ossia la stringa WWEX, per cercare tutte le sequenze di dati ivi contenute. Aprendo la GIF offline con un normale editor di testo e seguendo questa strategia è possibile infatti estrarre 3 sequenze di dati univoche. La prima è una sequenza esadecimale apparentemente senza significato: 323f1f0a4b6a671f392f05545c393b5335390f1b482066533526441b4c24295332260e144c236707687b584d08687a036f7e5f4b0b68790162645c4c0d607e0169795d4a09657c036a7d534c17043f552e250919 La seconda è una sequenza di lettere “P”, lunga esattamente come la prima: PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP La terza, lunga circa 45 KB, è una sequenza binaria. Dall’analisi del codice si osserva che è la terza quella di immediato interesse: essa contiene il payload cifrato con un semplice cifrario ad addizione a chiave 0xEE, quest’ultima deoffuscata nel codice con semplici operazioni matematiche. Il risultato della decifratura è un nuovo PE, questa volta una dll. Senza entrare in ulteriori dettagli, il packer successivamente usa la seconda sequenza (“PPP…P”) come placeholder della dll decifrata e ne fa un “find-replace” con la prima (“323…9”). La motivazione di questa operazione verrà illustrata nel prossimo paragrafo ma è già chiaro che si tratta di un’informazione sicuramente importante che il packer vuole condividere con il suo payload. Il packer infine alloca una nuova area di memoria leggibile e scrivibile, copia il contenuto della dll, modifica le flag di protezione per rendere la memoria eseguibile e infine effettua un jump verso l’entry point. Analisi Downloader – Stage 2 Di seguito i metadati della libreria dll caricata in memoria: File metadata - Nome downloader.dll (nome scelto dall’autore del report) - Dimensione 44.544 byte MD5 9F7758529EF13EF97A609F8A74FB7173 - SHA1 A399B7DD77BBA8457AE1158D0C3FFA43E41F04E8 - SHA256 C990AF0F9E69A182F3A0C8A1764BDD5B03D64BFF22BF08BD7745947AFF8726D3 - Tipo Libreria condivisa .DLL a 32 bit Anche in questo caso il file è stato scritto e compilato in Delphi (Figura 8). Stavolta però la tabella degli import è molto più snella rispetto a quella dell’eseguibile e ciò permette di concludere che la dll ha la capacità di effettuare richieste http (tramite la libreria wininet.dll), manipolare file, caricare risorse, leggere chiavi di registro e soprattutto di caricare dinamicamente nuove librerie e funzioni. La tabella degli export invece si presenta vuota. Ciò in realtà non deve sorprendere perché il primo packer effettua un jump direttamente all’entry point della dll e non ha quindi necessità di utilizzare il sistema di import/export standard di Windows. Continuando l’analisi a partire dall’entry point della dll, si nota immediatamente il riutilizzo di alcune tecniche del primo packer, come la configurazione di un nuovo timer Win32 o l’utilizzo della stessa strategia di offuscamento delle stringhe. Il timer viene questa volta impostato con una chiamata dinamica alla funzione timeSetEvent (dichiarata obsoleta da Microsoft). A differenza del packer precedente però, la callback (rinominata “ma_malicious_timer_callback” in Figura 9) viene passata come argomento della funzione. Si prosegue con l’analisi ispezionando la callback del timer. Le stringhe deoffuscate all’interno della funzione rivelano i due seguenti URL: - hxxps://discordapp[.]com/ - hxxps://cdn.discordapp[.]com/attachments/720370823554138118/765061326015430686/Twetnbc La tecnica per ottenerli è molto simile a quella del primo packer, ma per deoffuscare il secondo URL il malware utilizza come base la prima sequenza di dati estratta dalla GIF (la stringa “323…9”). Sostanzialmente il dato che il packer aveva condiviso con la dll tramite il “find-replace” si è rivelato essere un URL cifrato. Questa tecnica di mascheramento e condivisione non è nuova, tuttavia è sicuramente utile: essa permette all’attaccante di riutilizzare la dll con URL diversi senza doverla modificare (bisogna adeguare soltanto il packer). Il primo URL viene usato semplicemente per il test della connessione (Figura 11) e corrisponde alla connessione rilevata dalla sandbox. Il secondo, se il test è positivo, è l’end point della seguente richiesta https. Si può verificare offline che l’URL porta al download di un file testuale contenente soltanto caratteri esadecimali. La routine di decodifica del contenuto del file è costituita da una semplice serie di operazioni logiche e aritmetiche. La parte più interessante è che una volta decodificato, il file scaricato da Discord mostra la sua vera natura: si tratta di un nuovo PE (una dll) che viene caricato in memoria ed eseguito con la stessa tecnica utilizzata dal packer. Il file analizzato in questo paragrafo può essere dunque classificato come downloader. Effettuando alcune ricerche OSINT sulle tecniche utilizzate dal malware e presentate in questo report si notano moltissime similarità con ModiLoader (conosciuto anche come DBatLoader o NatsoLoader). Questa scoperta permette di snellire le analisi dei successivi file. Prima di passare all’analisi del prossimo file è interessante riportare una tecnica utilizzata dal downloader, vale a dire la Threading based Sleep Evasion che ha permesso al malware di eludere l’analisi dinamica effettuata da alcune sandbox utilizzate. Si tratta brevemente della misurazione del tempo trascorso tra due porzioni di codice separate da una chiamata a sleep: se il totale supera la durata della chiamata allora vuol dire che qualcuno ha modificato il binario per evitare di attendere la scadenza della sleep. La tecnica funziona perché, in alcuni casi, le sandbox applicano una patch alla durata delle chiamate sleep in modo da evitare di attendere per troppo tempo l’esecuzione dei malware. Il codice decompilato che implementa la tecnica nel downloader è mostrato in Figura 12. Analisi Dropper – Stage 3 La nuova dll, come già visto con la precedente, non viene salvata sul file, ma caricata direttamente in memoria. Tuttavia anche in questo caso l’estrazione su file non risulta complicata: si possono ripetere manualmente le operazioni di decodifica sul file testuale scaricato dall’URL Discord oppure si può lasciare l’onere al debugger e poi semplicemente fare un dump del segmento di memoria in cui è stato caricato l’eseguibile. In entrambi i casi si ottiene un file con i seguenti metadati. File metadata: - Nome dropper.dll (nome scelto dall’autore del report) - Dimensione 342 528 byte MD5 5D8DA1B223952228040054DF7CD85420 - SHA1 715E7691F286E28853A24B5348F25F1426D2E747 - SHA256 84629AFC86A3CFA3A4A78C354222C1A8FDB1855524F4D58426628F71C124232F - Tipo Libreria condivisa .DLL a 32 bit Le caratteristiche più interessanti che emergono da un’analisi statica di base sono principalmente due: - il PE rivela inizialmente delle stringhe interessanti, quali comandi powershell, percorsi di sistema e stringhe di registro. Da un’analisi più attenta si osserva tuttavia che la dll fa il wrapping di un altro PE, il quale una volta estratto con un semplice editor esadecimale si rivela essere una nuova dll annidata. La maggior parte delle stringhe interessanti proviene in realtà da questa seconda dll ma essa in realtà non viene mai estratta nel codice, pertanto sarà ignorata in questo report e sarà descritta eventualmente in successivi approfondimenti; - la dll non presenta nessun import/export. Ciò in realtà non stupisce in quanto la precedente dll, downloader.dll, effettua una routine di caricamento dinamico di librerie e funzioni tramite le chiamate a LoadLibrary e GetProcAddress. Procedendo con l’analisi, si osserva che il malware effettua principalmente le seguenti operazioni: - crea due file Twetdrv.exe e tewT.url. Il primo è una copia del file “Files 224643, 4565577.exe” e viene creato nel seguente path: - %USERPROFILE%\AppData\Local\Microsoft\Windows\ il secondo viene invece creato nel seguente path: - %USERPROFILE%\AppData\Local e rappresenta un semplice link al primo. Il suo contenuto è mostrato in Figura 13; - per consentire la persistenza, crea una chiave di registro che richiama il file .url ad ogni avvio del sistema: - \HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\Twet - Twet=C:\Users\***UTENTE***\AppData\Local\tewT.url - decifra un nuovo payload caricato in memoria. Senza aggiungere ulteriori dettagli sull’algoritmo utilizzato, si tratta di un nuovo PE. - controlla se esiste il seguente path: - C:\Program Files (x86)\internet explorer\ieinstal.exe - in caso positivo, crea un nuovo processo ieinstal.exe e inietta il payload decifrato tramite la tecnica del process hollowing; - il processo termina, ma lascia in esecuzione il falso ieinstal.exe Analisi Payload - Con le stesse modalità descritte in precedenza è possibile estrarre su file l’eseguibile finale: File metadata: - Nome remcos.exe (nome scelto dall’autore del report) - Dimensione 144 896 byte MD5 536DA533A8C61FEEF7F6EAAEB5B9C4F9 - SHA1 20DF4C9C160911AE21333AF66692C2A2B276CB92 - SHA256 2484C2AE43E68BB41429A3B7C9A58A327AB315359703EDBECB9D40CE72922C54 - Tipo Eseguibile .EXE a 32 bit Il file inoltre, essendo un .EXE standard, può essere eseguito indipendentemente dagli stage precedenti. Per esso in realtà si ritiene sufficiente una semplice analisi statica e dinamica di base per comprenderne le caratteristiche peculiari. Anzitutto si osserva che il file presenta soltanto gli import alle funzioni LoadLibraryA e GetProcAddress. Successivamente si può notare una sezione .text scrivibile, con alta entropia e una serie di stringhe senza significato. Queste due caratteristiche sono tipiche dei packer automatici. Il packer utilizzato è infatti Morphine, noto per il suo algoritmo di wrapping del payload direttamente nella sezione .text tramite esecuzione di codice polimorfico. Senza entrare nei dettagli, il packer estrae il vero codice malevolo in memoria e lo esegue. Da un’analisi dinamica di base o tramite sandbox si osserva immediatamente che si tratta del noto RAT Remcos (Figura 15). Remcos è un tool ben conosciuto, in vendita sul web e nei forum di hacking, pertanto la sua analisi è omessa in questo report. Al seguito di alcune ricerche OSINT e dall’analisi di altri sample relativi a campagne osservate anche in questi giorni, si riporta che ModiLoader viene altresì sfruttato per la consegna di altre tipologie di malware, quali FormBook e Netwire.