advanced-threat-research/dotdumperUn unpacker e logger automatico per file destinati a DotNet Framework
Uno strumento automatico per unpacking e logging di file destinati al DotNet Framework! Questo strumento è stato presentato al Black Hat USA 2022. Al Black Hat Asia 2023, sono stati pubblicati DotDumperGUI e DotDumperNative, insieme alla versione 1.1-stable di DotDumper. Questi tre strumenti sono pensati per essere usati insieme, dove DotDumper 1.1-stable richiede la presenza delle DLL di DotDumperNative, mentre DotDumperGUI è inteso come interfaccia grafica per aprire e filtrare l'output JSON delle esecuzioni di DotDumper.
Il rilevamento e la classificazione automatici di qualsiasi file in modo affidabile è spesso considerato il Santo Graal dell'analisi malware. Le prove e le tribolazioni per arrivarci sono molte, motivo per cui la creazione di un tale sistema è tenuta in grande considerazione. Quando si tratta di binari destinati a DotNet, il nostro nuovo strumento open-source DotDumper mira ad assistere in diversi passaggi cruciali lungo il percorso: registrare l'attività (in memoria), scaricare segmenti di memoria interessanti ed estrarre caratteristiche dal campione dato.
In breve, l'unpacking manuale è un processo noioso che consuma una quantità di tempo sproporzionata per gli analisti. I binari offuscati aumentano ulteriormente il tempo che un analista deve dedicare per decomprimere un dato file. Scalando questo, le organizzazioni hanno bisogno di numerosi analisti che analizzano il malware quotidianamente, probabilmente in combinazione con una sandbox scalabile. Il tempo prezioso perso potrebbe essere utilizzato per approfondire campagne o campioni interessanti per scoprire nuove minacce, piuttosto che il malware generico e banale ampiamente diffuso. Dopotutto, gli analisti cercano i pochi aghi nel pagliaio.
Allora, che differenza fa DotDumper? Eseguire un campione malware basato su DotNet tramite DotDumper fornisce file di log di chiamate di funzione cruciali, contestualizzanti e comuni in tre formati (testo semplice leggibile dall'uomo, JSON e XML), oltre a copie di segmenti di memoria utili. In questo modo, un analista può scorrere il registro delle chiamate di funzione. Inoltre, i file scaricati possono essere scansionati per classificarli, fornendo ulteriori informazioni sul campione malware e sui dati che contiene. Ciò riduce il tempo vitale per i processi di triage e risposta agli incidenti e libera il tempo degli analisti SOC e dei ricercatori per esigenze di analisi più sofisticate.
Per registrare e dumpare le chiamate di funzione contestualizzanti e i loro risultati, DotDumper utilizza una miscela di reflection e hook gestiti, tutti scritti in puro C#. Di seguito, le caratteristiche chiave verranno evidenziate e approfondite, in combinazione con estratti dei risultati di DotDumper su un campione di AgentTesla stealer impacchettato, i cui hash sono riportati di seguito.
| Tipo di hash | Valore hash |
|---|---|
| SHA-256 | b7512e6b8e9517024afdecc9e97121319e7dad2539eb21a79428257401e5558d |
| SHA-1 | c10e48ee1f802f730f41f3d11ae9d7bcc649080c |
| MD-5 | 23541daadb154f1f59119952e7232d6b |
DotDumper è accessibile tramite un'interfaccia a riga di comando, con una varietà di argomenti. L'immagine seguente mostra il menu di aiuto. Nota che non tutti gli argomenti verranno discussi, ma piuttosto quelli più usati.
Il requisito minimo per eseguire un dato campione è fornire l'argomento “-file”, insieme a un nome file o un percorso file. Se viene fornito un percorso completo, viene utilizzato. Se viene fornito un nome file, vengono controllati la directory di lavoro corrente e la cartella della posizione dell'eseguibile di DotDumper.
A meno che non venga fornito un nome di directory, il nome della cartella “-log” viene impostato uguale al nome del file del campione senza estensione (se presente). La cartella si trova nella stessa cartella in cui risiede DotDumper, ed è lì che verranno salvati i log e i file dumpati.
Nel caso di una libreria o di un punto di ingresso alternativo in un binario, è necessario sovrascrivere il punto di ingresso usando “-overrideEntry true”. Inoltre, bisogna fornire la classe completamente qualificata, che include il namespace usando “-fqcn My.NameSpace.MyClass”. Questo dice a DotDumper quale classe selezionare, da cui viene recuperato il nome della funzione fornito (usando “-functionName MyFunction”).
Se la funzione selezionata richiede argomenti, bisogna fornire il numero di argomenti usando “-argc” e il numero di argomenti richiesti. I tipi e i valori degli argomenti devono essere forniti come “string|myValue int|9”. Nota che quando vengono usati spazi nei valori, l'argomento nell'interfaccia a riga di comando deve essere racchiuso tra virgolette per garantire che venga passato come un singolo argomento.
Altre opzioni meno usate come “-raceTime” o “-deprecated” sono sicure nelle loro impostazioni predefinite ma potrebbero richiedere modifiche in futuro a causa di cambiamenti nel DotNet Framework. Sono attualmente esposte nell'interfaccia a riga di comando per consentire facilmente modifiche, se necessario, anche se si sta utilizzando una versione precedente di DotDumper quando arriva il momento.
La registrazione e il dumping sono le due funzionalità principali di DotDumper. Per ridurre al minimo il tempo impiegato dall'analisi, la registrazione dovrebbe fornire contesto all'analista. Questo viene fatto fornendo all'analista le seguenti informazioni per ogni chiamata di funzione registrata:
Nota che per ogni file dumpato, il nome del file è uguale all'hash SHA-256 del file.
Per chiarire quanto sopra, viene fornito di seguito un estratto di un log. L'estratto mostra i dettagli per il suddetto campione AgentTesla, dove carica il secondo stadio usando la funzione Assembly.Load di DotNet.
![Il log per una chiamata alla funzione Assembly.Load(byte[] rawAssembly) intercettata](images/assembly_load.png)
Prima viene fornita l'ora di sistema locale, insieme al tipo di ritorno, al nome e agli argomenti della funzione originale. Secondo, viene fornita la traccia dello stack, dove mostra che la funzione main del campione porta a un costruttore, inizializza i componenti e chiama due funzioni personalizzate. La funzione Assembly.Load è stata chiamata da “NavigationLib.TaskEightBestOil.GGGGGGGGGGGGGGGGGGGG(String str)”. Questo fornisce contesto all'analista per trovare il codice attorno a questa chiamata se è di interesse.
Poi vengono fornite informazioni sull'ordine di chiamata degli assembly. Più stadi vengono caricati, più complesso diventa vedere attraverso quali stadi è avvenuta la chiamata. Normalmente ci si aspetta che uno stadio carichi il successivo, ma in alcuni casi gli stadi successivi utilizzano stadi precedenti in un ordine non lineare. Inoltre, vengono fornite informazioni sull'assembly di origine per arricchire ulteriormente i dati per l'analista.
Successivamente, viene fornito l'hash genitore. Il genitore di uno stadio è lo stadio precedente, che in questo esempio non è ancora presente. Lo stadio appena caricato avrà questo stadio come genitore. Ciò consente all'analista di correlare gli eventi più facilmente.
Infine, vengono memorizzati il tipo e il valore di ritorno della funzione, insieme al tipo, al nome e al valore di ogni argomento passato alla funzione hookata. Se una qualsiasi variabile è più grande di 100 byte, viene invece memorizzata su disco. Viene quindi inserito un riferimento nel log per fare riferimento al file, piuttosto che mostrare il valore. La soglia è stata impostata per evitare intoppi nella stampa del log, poiché alcuni array sono grandi migliaia di indici.
Secondo la documentazione di Microsoft, la reflection è meglio riassunta come “[…] fornisce oggetti che incapsulano assembly, moduli e tipi”. In breve, ciò consente la creazione e l'invocazione dinamica di classi e funzioni DotNet dal campione malware. DotDumper contiene un caricatore riflessivo che consente a un analista di caricare e analizzare sia eseguibili che librerie, purché siano basati sul DotNet Framework.
Per utilizzare il caricatore, è necessario scegliere di sovrascrivere il punto di ingresso nell'interfaccia a riga di comando, specificare la classe (incluso il namespace in cui risiede) e il nome della funzione all'interno di un dato file. Opzionalmente, è possibile fornire argomenti alla funzione specificata, per tutti i tipi nativi e i loro array. Esempi di tipi nativi sono int, string, char e array come int[], string[] e char[]. Tutti gli argomenti devono essere forniti tramite l'interfaccia a riga di comando, dove devono essere specificati sia il tipo che il valore.
Non sovrascrivere il punto di ingresso comporta l'utilizzo del punto di ingresso predefinito. Per impostazione predefinita, viene passato un array di stringhe vuoto alla funzione main del campione, come se il campione fosse eseguito senza argomenti.
Inoltre, la reflection è spesso utilizzata dai caricatori per invocare una data funzione in una data classe nello stadio successivo. A volte vengono passati anche argomenti, che vengono utilizzati successivamente per decrittare una risorsa. Nel suddetto campione AgentTesla, si verifica esattamente questo scenario. Gli hook relativi all'invocazione di DotDumper registrano queste occorrenze, come si può vedere di seguito.
Il nome della funzione nella prima riga non è una funzione interna del DotNet Framework, ma piuttosto una chiamata a una funzione specifica nel secondo stadio. I tipi e i nomi dei tre argomenti sono elencati nella firma della funzione. I loro valori si trovano nella sezione delle informazioni sugli argomenti della funzione. Ciò permetterebbe a un analista di caricare il secondo stadio in un caricatore personalizzato con i valori dati per gli argomenti, o addirittura di farlo usando DotDumper caricando lo stadio precedentemente dumpato e fornendo gli argomenti.
Prima di approfondire gli hook gestiti, è necessario capire come funzionano gli hook. Ci sono due variabili principali da considerare qui: la funzione target e una funzione controllata chiamata hook. In parole povere, la memoria alla funzione target (es. Assembly.Load) viene alterata per saltare invece all'hook. In questo modo, il flusso di esecuzione del programma viene deviato. L'hook può quindi eseguire azioni arbitrarie, opzionalmente chiamare la funzione originale, dopodiché restituisce l'esecuzione al chiamante insieme a un valore di ritorno se necessario. Il diagramma seguente illustra questo processo.
Sapere cosa sono gli hook è essenziale per capire cosa sono gli hook gestiti. Il codice gestito viene eseguito in un ambiente virtuale e gestito, come il runtime DotNet o la macchina virtuale di Java. Ottenere l'indirizzo di memoria in cui risiede la funzione gestita differisce da un linguaggio non gestito come C. Una volta ottenuti gli indirizzi di memoria corretti per entrambe le funzioni, l'hook può essere impostato accedendo direttamente alla memoria usando C# unsafe, insieme al servizio di interoperabilità di DotNet per chiamare funzionalità native dell'API Windows.
Dalla versione DotDumper v1.1-stable, DotDumper può anche hookare funzioni non gestite (o native, se preferite). Il reindirizzamento delle funzioni può essere qualsiasi combinazione da e verso funzioni gestite e non gestite, con un'importante avvertenza. Qualsiasi funzione non gestita che utilizza un hook gestito non sarà in grado di leggere correttamente i valori dello stack. Pertanto, è necessario un componente nativo (chiamato DotDumperNative). Questo componente comunica tramite una named pipe con DotDumper stesso, utilizzando quindi il suo sistema di logging centralizzato, intercettando le chiamate non gestite con accesso agli argomenti delle funzioni presenti nello stack.
Poiché DotDumper è scritto in puro C# senza dipendenze esterne, è possibile estendere facilmente il framework usando Visual Studio. Il codice è documentato in questo blog, su GitHub, e nelle classi, nelle funzioni, e in-line nel codice sorgente. Questo, in combinazione con lo schema di denominazione chiaro, consente a chiunque di modificare lo strumento come preferisce, riducendo al minimo il tempo e lo sforzo che bisogna spendere per comprendere lo strumento. Invece, permette a sviluppatori e analisti allo stesso modo di concentrare i loro sforzi sul miglioramento dello strumento.
Sebbene la funzionalità di supporto timeout sandbox non sia stata modificata né alterata, non era stata documentata in precedenza. Poiché DotDumper esegue il file che gli viene fornito, la sua esecuzione continuerà fino a quando il campione termina. Il malware entra spesso in uno stato di “attesa”, in cui una certa condizione deve essere soddisfatta prima che si riattivi, oppure il malware continua l'esecuzione in un processo diverso (con l'aiuto dell'iniezione di processo). Ad esempio, un thread appena creato in un processo hollowed restituisce solo quando ha terminato.
Per evitare stalli, DotDumper ha un gestore di stagnazione. Ogni volta che i risultati di un hook vengono registrati, un contatore viene incrementato. Se questo contatore rimane invariato dopo tre intervalli consecutivi di 20 secondi, DotDumper presuppone che sia stato rilevato uno stato di stagnazione. In tal caso, l'ora di sistema viene impostata al 30-12-2200 12:00 per forzare il timeout della sandbox, dopodiché notifica l'analista tramite il logger e si termina. Il timeout della sandbox si verifica quando il tempo trascorso dalla data corrente fino alla data appena impostata supera i soliti 5 o 10 minuti. Anche se il runtime della sandbox è impostato su ore o giorni, viene superato.
Il motivo per interrompere l'analisi è risparmiare tempo e risorse, poiché un invio con un timeout di 10 minuti potrebbe richiedere solo 2 minuti per essere eseguito. In questo modo, si potrebbe eseguire più campioni nello stesso intervallo di tempo con il gestore di stagnazione. Una panoramica della logica del gestore di stagnazione è mostrata di seguito.
Con gli obiettivi e le caratteristiche di DotDumper chiari, potrebbe sembrare che ci siano sovrapposizioni con strumenti pubblicamente noti come ILSpy, dnSpyEx, de4dot o pe-sieve. Nota che non c'è intenzione di proclamare che uno strumento sia migliore di un altro, ma piuttosto come gli strumenti differiscono.
L'obiettivo di DotDumper è registrare e dumpare chiamate di funzione cruciali, contestualizzanti e comuni da campioni destinati a DotNet. ILSpy è un disassemblatore e decompilatore DotNet, ma non permette l'esecuzione del file. dnSpyEx (e il suo predecessore dnSpy) utilizza ILSpy come componente di disassemblaggio e decompilazione, aggiungendo un debugger. Ciò consente di ispezionare e manipolare manualmente la memoria. de4dot è usato esclusivamente per deoffuscare binari DotNet, migliorando la leggibilità del codice per occhi umani. L'ultimo strumento in questo confronto, pe-sieve, è pensato per rilevare e dumpare malware da processi in esecuzione, indipendentemente dal linguaggio di programmazione utilizzato. La tabella seguente fornisce una panoramica grafica degli strumenti sopra menzionati.
DotDumper è in costante revisione e sviluppo, tutto incentrato su due aree principali: correzione di bug e aggiunta di nuove funzionalità. Durante lo sviluppo, il codice è stato testato, ma a causa dell'iniezione di hook nelle funzioni del DotNet Framework che possono essere soggette a modifiche, è molto probabile che ci siano bug nel codice. Chiunque incontri un bug è invitato ad aprire un issue sul repository GitHub, che verrà poi esaminato. La proposta di nuove funzionalità è possibile anche tramite il repository GitHub. Per chi ha un account GitHub, o per chi preferisce non interagire pubblicamente, sentiti libero di inviarmi un messaggio privato sul mio Twitter.
Inutile dirlo, se hai usato DotDumper durante un'analisi, o lo hai usato in modo creativo, sentiti libero di contattarmi in pubblico o in privato! Non c'è niente di meglio che sentire parlare dell'utilizzo di uno strumento fatto in casa!
Ci sono altre novità in serbo per DotDumper, e un aggiornamento verrà inviato alla comunità non appena sarà disponibile!
