Elementi importanti dell’analisi: 

• Tecniche di anti-analysis
• Tecniche di anti-debugging
• Process hollowing mediante il processo WWAHost.exe
• Tecniche avanzate di evasion 
• DLL dropping ed exports 
• Environment information gathering routines
• Files gathering loops routines
• Connessioni Command and Control

Introduzione 

Nella presente analisi è stato preso in considerazione un sample di Beep malware avente hash ab5dc89a301b5296b29da8dc088b68d72d8b414767faf15bc45f4969c6e0874e. Il threat in questione è divenuto piuttosto noto all’interno della security community a causa del fatto che utilizzi molteplici ed avanzate tecniche di anti-VM, anti-debugging, evasion ma contestualmente anche di anti-analysis. Il malware effettua il dropping di un’ulteriore libreria DLL malevola scaricata ed eseguita, nonché esegue tasks di injection attraverso l’utilizzo di tecniche di process hollowing, mediante il processo WWAHost.exe. Un dettaglio particolare e curioso riguarda il fatto che Beep malware utilizzi la funzione di beeping di sistema al fine di identificare l’ambiente d’esecuzione e dedurre così se si tratti di un environment virtualizzato, ad esempio macchine virtuali o sandboxes. [0] 

Lo scopo di Beep Malware è quello di effettuare, durante la sua Cyber Kill Chain, la sottrazione di files, dati personali della vittima, dettagli ed informazioni dell’environment in cui viene eseguito (come, ad esempio, gli intervalli di tempo del performance counter) e trasmetterli verso un server remoto del malicious actor. I dettagli hardware ed environment awareness della macchina compromessa vengono utilizzati sia per individuare la tipologia della macchina infettata e sia al fine di dedurre se si tratti di un ambiente virtualizzato o meno. 

Matrice TTPs:

Analisi statica e dinamica 

Il sample analizzato è stato compilato in C++ e l’entrypoint è settato all’indirizzo 10004268: 

A seguire i dettagli della mappatura di memoria del PE, dove si può evincere la presenza della sezione .gfids, contenente i dettagli della configurazione di compilazione dello stesso: 

All’interno degli exports di Beep malware si evidenziano le seguenti items sospette con le relative RVA (indirizzi di memoria virtuali relativi):  

Tra le funzioni rilevabili dall’import effettuato dall’eseguibile vi sono dettagli di creazione di files, creazione di threads ed attivazioni di contesti d’esecuzione (mediante le funzioni CreateActCtxA e ActivateActCtx): 

A seguire un dettaglio relativo alla funzione DecodePointer, utilizzabile al fine di decodificare puntatori precedentemente codificati per nascondere i valori degli oggetti pointers: 

Verificando il manifest del PE si nota una setting requestedExecutionLevel “asInvoker”, ovvero l’utilizzo delle impostazioni di sicurezza di default dell’utente: 

Qui alcune stringhe sospette estraibili dal sample, nonché un riferimento alla libreria advapi32, la quale può essere impiegata per la gestione del registro di sistema e il controllo di chiavi di registro specifiche inerenti a VirtualBox: 

Fra le stringhe estratte dal threat vi sono riferimenti alla libreria bxl220wm49.dll ed a export items, nonché le evidenze sopra citate, ovvero CreateActCtxA ed ActivateActCtx: 

L’Exported entry KRsvHAq possiede istruzioni di compare ed un’istruzione di salto condizionale jl, il quale effettua un “salto condizionale” con comparazione con segno nel caso in cui il secondo operando sia minore del primo: 

Vi è poi un’istruzione di xor tra i parametri 0E4Bh e il registro edx. Le istruzioni xor vengono utilizzate per tasks di deobfuscation dinamica, la quale indica un ulteriore elemento di anti-analysis in termini statici: 

Un dettaglio fondamentale inerente alle funzioni richiamate da Beep Malware, risiede nel fatto che esso utilizzi le functions QueryPerformanceCounter, GetSystemTimeAsFileTime al fine di verificare la tipologia dell’ambiente d’esecuzione e verificare quindi se le stesse stiano avvenendo all’interno di un ambiente virtualizzato o meno. 

Da un’analisi dell’entropia del PE si evince come la sezione .text, la quale contiene istruzioni CPU eseguibili, risulti essere in uno status di “packed”, pertanto diversi dettagli ottenibili da un assessment o da un’analisi statica non sono facilmente intelligibili: 

La funzione CreateActCtxA viene richiamata all’interno della label loc_1000E861, successivamente vi sono poi riferimenti ad operazioni di xor tra i registri edx ed eax con i valori rispettivamente 4Fh e 138h, ciò avviene all’interno di un flusso d’esecuzione richiamato precedentemente alla label loc_1000E861: 

Qui un dettaglio al riferimento alla funzione IsDebuggerPresent, la quale può essere utilizzata in ambito di anti-debugging e debuggers checking: 

A seguire ulteriori evidenze legate alle exported items; all’interno dell’entry HwjP316n31 vi è una chiamata alla stessa, ciò viene eseguito in base ad un’istruzione cmp tra i valori edx+0BCh ed il registro eax 

L’exported entry KRsvHAq salva all’interno degli attributi arg_4, arg_8, arg_14 e arg_18 determinati valori esadecimali che vengono utilizzati in flussi condizionali, successivamente vengono poi richiamate rispettivamente le labels loc_1001143D oppure loc_1001144B: 

L’exported entry PLWQ7G9 richiama alcune funzioni, tra cui sub_10013310 successivamente ad operazioni di push e lea, utilizzate al fine di salvare alcuni indirizzi di memoria, ad esempio, ebx+1DFh nel registro eax, la funzione sub_10001160 ma soprattutto all’interno della funzione sub_10001780 viene richiamata l’exported entry Ymkg06Q0r 

A seguire un’evidenza di richiamo alla funzione SuspendThread all’interno del contesto d’esecuzione della funzione sub_10011920: 

Il modulo Ymkg06Q0r possiede ulteriori operazioni di XOR inerenti ai registri edx, ebx, ecx ed edi. Quest’ultimo con il valore 17C2h: 

La presenza di numerosi contesti d’esecuzione esterne, exported entries e la decentralizzazione di alcuni dati salvati nei registri, denota ancora una volta la volontà di bypassare la detection phase di security solutions con un approccio di anti-analysis, rendendo pertanto più difficoltosa la contestualizzazione dell’intero flusso d’esecuzione, nonché dell’assessment del Portable Executable stesso. 

Analizzando il source code di Beep si notano istruzioni di goto verso indirizzi di memoria richiamati esternamente al di fuori del ciclo while, ove viene incrementato il valore di eax57 con un offset di 12. 

All’interno della funzione DllRegisterServer() è possibile individuare l’utilizzo della variabile v2 con il valore esadecimale 0x1636 per il richiamo esterno della funzione denominata fun_10003c30 con lo scopo di effettuare la registrazione dei moduli esportati. 

Contestualmente al richiamo della funzione ActivateActCtx viene utilizzata la funzione GetModuleFileNameA, che può essere richiamata al fine di ottenere i dettagli del percorso di un modulo caricato dal processo corrente. 

Portable Executable assessment 

Effettuando una disamina degli indicatori più sospetti del sample di Beep Malware è possibile avere contezza di diversi attributi: l’export table, la presenza della DLL bxl220wm49.dll, funzioni di gestione del registro di sistema, file management, discovery, reckoning, environment information discovery. 

Tra i metadati di compilazione vi è l’evidenza di “Export1400”, relativa a Visual Studio 2015: 

Il sample è stato compilato il 7 Febbraio 2023: 

Qui ulteriori riferimenti alle funzioni già citate in precedenza: in particolare le funzioni SuspendThread, VirtualAlloc, QueryPerformanceCounter, GetSystemTimeAsFileTime, IsDebuggerPresent: 

Big.dll utilizza la funzione SetFilePointerEx, la quale può essere utilizzata nell’ambito di files gathering loops senza avere problematiche riguardanti overlapped operations. 

Analizzando il listato assembly del malware possiamo notare numerose funzioni di calling e contestualmente istruzioni JE (Jump Equal) al fine di creare flussi condizionali: 

Qui alcuni dettagli relativi alle sezioni dell’eseguibile, ove si possono evincere, disassemblando la sezione .rdata, alcuni riferimenti inerenti alle funzioni CreateFileA (utilizzabile in fase di malware dropping) e CreateActCtxA. 

Da un assessment ulteriore della libreria big.dll possiamo notare informazioni di metadati associabili a Borland Delphi 3.0: 

A seguire alcuni riferimenti al numero dei RVAs (Relative Virtual Addresses), il cui valore risulta essere 10: 

Attraverso un’inspection del codice esadecimale del Portable Executable si notano riferimenti alla libreria bxl220wm49.dll, la funzione di registrazione di DLLs DllRegisterServer e la function CreateFileA. 

Debugging 

Effettuando una sessione di debugging di Beep si evidenziano chiamate alle funzioni LoadLibraryExW, LoadLibraryExA e LoadLibraryA al fine di caricare il modulo principale nel processo in running: 

Effettuando chiamate a DLL Exports il debugging process giunge ad ottenere dettagli delle cartelle del sistema operativo. 

Nello screenshot sottostante si osservano diverse istruzioni assembly INT3, sovente relative a contesti di anti-debugging, nonché debugging checking: 

Successivamente viene eseguita la funzione ConvertThreadToFiber al fine di inizializzare la gestione dei threads delle esecuzioni malevole concorrenziali: 

Effettuando un dump della sezione in esecuzione .text durante la fase di debugging, possiamo notare operazioni di XOR dei registri EAX, EBX, EDX; nonché l’esecuzione della funzione di files pointing SetFilePointerEx: 

Lo scopo di Beep Malware è quello di ottenere, mediante cicli di files gathering (attraverso l’utilizzo di funzioni come SetFilePointerEx), i dati della vittima e sottrarli tramite connessioni Command and Control, come evidenziato da network communications in dynamic sandboxes detonations: 

L’indirizzo IP contattato dal sample è 37.1.215[.]220, il quale è stato registrato da “3NT Solutions LLP” negli Stati Uniti. Esso è associato al dominio webcam-inverted[.]holydithers[.]com e possiede numerose porte aperte e protocolli utilizzati, tra cui OpenSSH e Exim Smtpd (protocollo di Mail Transfer Agent): 

IOCs: 

• ab5dc89a301b5296b29da8dc088b68d72d8b414767faf15bc45f4969c6e0874e 
• 4f1c2f80f58c4730e37b445504018bb6 
• 6132dc571dbc11298635e034d98b463c4edeb305 
• 37.1.215[.]220 
• bxl220wm49.dll 

Regola YARA: 

rule BeepRule{      

strings:          

$beepString = ” bxl220wm49″ 

$beepHex = {62 78 6c 32 32 30 77 6d 34 39 }       

$beepString1 = “KRsvHAq” 

$beepHex1 = {4b 52 73 76 48 41 71} 

$beepIP = “37.1.215.220” 

condition:         $beepString or $beepHex or $beepString1 or $beepHex1 or $beepIP } 

CONCLUSIONI: 

Beep Malware risulta essere una minaccia molto decentralizzata per quanto riguarda i moduli d’esecuzione. Esso sfrutta operazioni di DLL dropping ed exports al fine di garantire una fase di evasion più profonda. Il malware utilizza sia tecniche comuni con altre tipologie di threats, come ad esempio operazioni di anti-debugging ed anti-analysis, sia tecniche di evasion ed execution più sofisticate e difficili da rilevare. In questo secondo caso non si può non citare l’abilità di Beep Malware di effettuare Process Hollowing mediante istanze del processo WWAHost.exe. Tale circostanza rende più complesso un rilevamento da parte di una soluzione antimalware o EDR, nonché in fase di logs inspection. Un’altra importante ed insolita evidenza è relativa al fatto che Beep malware utilizzi la funzione di sistema di beeping per identificare l’ambiente d’esecuzione virtualizzato; ciò poteva essere alternativamente effettuato mediante un controllo di specifici eseguibili all’interno della cartella di sistema C:\Windows\System32, oppure specifici processi, servizi e chiavi di registro. Tuttavia la scelta fatta dagli autori di Beep potrebbe essere associata al fatto che la metodologia di environment information gathering utilizzata, sia più generalizzata ed efficiente al fine di individuare più tipologie di ambienti d’esecuzione virtualizzati. 

Non è difficile pensare che nuovi threats futuri possano prendere spunto dalla metodologia d’evasion utilizzata da Beep e, almeno potenzialmente, ciò potrebbe aprire le porte allo sviluppo di nuove minacce ancora più avanzate in termini di infection chain, utilizzando però lo stesso livello di undetectable ability rendendoli sempre più efficaci e difficili da individuare e contenere. 

Riferimenti: 

[0] (introduzione di Beep malware relativa a process hollowing technique): Beepin’ Out of the Sandbox: Analyzing a New, Extremely Evasive Malware (minerva-labs.com)