dynmx Prototipo

dynmx (pronunciato dinamiche) è un approccio di rilevamento basato su firme per caratteristiche comportamentali di malware basate su sequenze di chiamate API di Windows. In modo semplificato, puoi pensare a dynmx come una sorta di YARA per tracce di chiamate API (i cosiddetti function log) provenienti da sandbox di malware. Quindi, la base dati per l'approccio di rilevamento non sono i campioni di malware stessi che vengono analizzati staticamente, ma i dati generati durante un'analisi dinamica del campione di malware in una sandbox di malware. Attualmente, dynmx supporta function log delle seguenti sandbox di malware:

• VMRay (function log, in formato testo e XML)
• CAPEv2 (file report.json)
• Cuckoo (file report.json)

L'approccio di rilevamento è descritto in dettaglio nella tesi magistrale Rilevamento basato su firme di caratteristiche comportamentali di malware con chiamate API di Windows. Questo progetto è l'implementazione prototipale di questo approccio ed è stato sviluppato durante la tesi magistrale. Le firme sono definite manualmente dagli analisti di malware nel DSL di firme dynmx e possono essere rilevate nei function log con l'aiuto di questo strumento. Caratteristiche e sintassi del DSL di firme dynmx si trovano anche nella tesi magistrale. Inoltre, puoi trovare firme di esempio di dynmx nel repository dynmx-signatures. Oltre a rilevare caratteristiche di malware basate su chiamate API, dynmx può estrarre risorse del sistema operativo utilizzate dal malware (un cosiddetto Modello di Attività di Accesso). Queste risorse vengono estratte esaminando le chiamate API e ricostruendo le operazioni sulle risorse del sistema operativo. Attualmente, nel modello vengono considerate le risorse del sistema operativo delle categorie filesystem, registro di sistema e rete.

Esempio

Nella sezione seguente vengono mostrati esempi per il rilevamento di caratteristiche di malware e per l'estrazione di risorse.

Rilevamento

Per questo esempio, scegliamo il campione di malware con hash SHA-256 c0832b1008aa0fc828654f9762e37bda019080cbdd92bd2453a05cfb3b79abb3. Secondo MalwareBazaar, il campione appartiene alla famiglia di malware Amadey. È disponibile un rapporto di analisi VMRay pubblico di questo campione che fornisce anche il function log tracciato da VMRay. Questo function log sarà la nostra base dati che useremo per il rilevamento.

Se volessimo sapere se il campione di malware utilizza una tecnica di iniezione chiamata Process Hollowing, possiamo provare a rilevare la seguente firma dynmx nel function log.```yaml dynmx_signature: meta: name: process_hollow title: Process Hollowing description: Detection of Process hollowing malware feature detection: proc_hollow: # Create legit process in suspended mode - api_call: ["CreateProcess[AW]", "CreateProcessInternal[AW]"] with: - argument: "dwCreationFlags" operation: "flag is set" value: 0x4 - return_value: "return" operation: "is not" value: 0 store: - name: "hProcess" as: "proc_handle" - name: "hThread" as: "thread_handle" # Injection of malicious code into memory of previously created process - variant: - path: # Allocate memory with read, write, execute permission - api_call: ["VirtualAllocEx", "VirtualAlloc", "(Nt|Zw)AllocateVirtualMemory"] with: - argument: ["hProcess", "ProcessHandle"] operation: "is" value: "$(proc_handle)" - argument: ["flProtect", "Protect"] operation: "is" value: 0x40 - api_call: ["WriteProcessMemory"] with: - argument: "hProcess" operation: "is" value: "$(proc_handle)" - api_call: ["SetThreadContext", "(Nt|Zw)SetContextThread"] with: - argument: "hThread" operation: "is" value: "$(thread_handle)" - path: # Map memory section with read, write, execute permission - api_call: "(Nt|Zw)MapViewOfSection" with: - argument: "ProcessHandle" operation: "is" value: "$(proc_handle)" - argument: "AccessProtection" operation: "is" value: 0x40 # Resume thread to run injected malicious code - api_call: ["ResumeThread", "(Nt|Zw)ResumeThread"] with: - argument: ["hThread", "ThreadHandle"] operation: "is" value: "$(thread_handle)" condition: proc_hollow as sequence

Basandoci sulla firma, possiamo trovare alcune funzionalità DSL che rendono *dynmx* potente:
* Definizione di sequenze di chiamate API con percorsi alternativi
* Corrispondenza di nomi di funzioni API con espressioni regolari
* Corrispondenza di argomenti e valori di ritorno con diversi operatori
* Archiviazione di variabili, ad esempio per tracciare gli handle nella sequenza di chiamate API
* Definizione di una condizione di rilevamento con operatori booleani (`AND`, `OR`, `NOT`)

Se eseguiamo *dynmx* con la firma mostrata sopra sulla funzione del campione `c0832b1008aa0fc828654f9762e37bda019080cbdd92bd2453a05cfb3b79abb3`, otteniamo il seguente output che indica che la firma è stata rilevata.```
$ python3 dynmx.py detect -i 601941f00b194587c9e57c5fabaf1ef11596179bea007df9bdcdaa10f162cac9.json -s process_hollow.yml


    |
  __|         _  _    _  _  _
 /  |  |   | / |/ |  / |/ |/ |  /\/
 \_/|_/ \_/|/  |  |_/  |  |  |_/ /\_/
          /|
          \|
            
 Ver. 0.5 (PoC), by 0x534a


[+] Parsing 1 function log(s)
[+] Loaded 1 dynmx signature(s)
[+] Starting detection process with 1 worker(s). This probably takes some time...

[+] Result
process_hollow	c0832b1008aa0fc828654f9762e37bda019080cbdd92bd2453a05cfb3b79abb3.txt

Possiamo approfondire impostando il formato di output su detail. Ora possiamo vedere la sequenza esatta delle chiamate API rilevata nel log delle funzioni. Inoltre, possiamo vedere che la firma è stata rilevata nel processo 51f0.exe.``` $ python3 dynmx.py -f detail detect -i 601941f00b194587c9e57c5fabaf1ef11596179bea007df9bdcdaa10f162cac9.json -s process_hollow.yml

|

__| _ _ _ _ _ / | | | / |/ | / |/ |/ | // _/|/ _/|/ | |/ | | |_/ /_/ /| |

Ver. 0.5 (PoC), by 0x534a

[+] Parsing 1 function log(s) [+] Loaded 1 dynmx signature(s) [+] Starting detection process with 1 worker(s). This probably takes some time...