dynmx Prototyp

dynmx (ausgesprochen Dynamics) ist ein signaturbasierter Erkennungsansatz für verhaltensorientierte Schadsoftware-Merkmale basierend auf Windows-API-Aufrufsequenzen. Vereinfacht kann man sich dynmx als eine Art YARA für API-Aufrufspuren (sogenannte Funktionslogs) vorstellen, die von Malware-Sandboxes stammen. Daher basiert die Datenbasis für den Erkennungsansatz nicht auf den Malware-Samples selbst, die statisch analysiert werden, sondern auf Daten, die während einer dynamischen Analyse des Malware-Samples in einer Malware-Sandbox generiert werden. Derzeit unterstützt dynmx Funktionslogs der folgenden Malware-Sandboxes:

• VMRay (Funktionslog, textbasiertes und XML-Format)
• CAPEv2 (report.json Datei)
• Cuckoo (report.json Datei)

Der Erkennungsansatz wird ausführlich in der Masterarbeit Signature-Based Detection of Behavioural Malware Features with Windows API Calls beschrieben. Dieses Projekt ist die prototypische Implementierung dieses Ansatzes und wurde im Rahmen der Masterarbeit entwickelt. Die Signaturen werden manuell von Malware-Analysten in der dynmx-Signatur-DSL definiert und können mit Hilfe dieses Tools in Funktionslogs erkannt werden. Merkmale und Syntax der dynmx-Signatur-DSL sind ebenfalls in der Masterarbeit zu finden. Darüber hinaus finden Sie Beispiel-Dynmx-Signaturen im Repository dynmx-signatures. Zusätzlich zur Erkennung von Malware-Merkmalen auf Basis von API-Aufrufen kann dynmx Betriebssystemressourcen extrahieren, die von der Malware verwendet werden (ein sogenanntes Access Activity Model). Diese Ressourcen werden durch die Untersuchung der API-Aufrufe und die Rekonstruktion von Operationen auf Betriebssystemressourcen extrahiert. Derzeit werden Betriebssystemressourcen der Kategorien Dateisystem, Registry und Netzwerk im Modell berücksichtigt.

Beispiel

Im folgenden Abschnitt werden Beispiele für die Erkennung von Malware-Merkmalen und die Extraktion von Ressourcen gezeigt.

Erkennung

Für dieses Beispiel wählen wir das Malware-Sample mit der SHA-256-Hashsumme c0832b1008aa0fc828654f9762e37bda019080cbdd92bd2453a05cfb3b79abb3. Laut MalwareBazaar gehört das Sample zur Malware-Familie Amadey. Es ist ein öffentlicher VMRay-Analysebericht dieses Samples verfügbar, der auch das von VMRay aufgezeichnete Funktionslog bereitstellt. Dieses Funktionslog wird unsere Datenbasis sein, die wir für die Erkennung verwenden werden.

Wenn wir wissen möchten, ob das Malware-Sample eine Injection-Technik namens Process Hollowing verwendet, können wir versuchen, die folgende dynmx-Signatur im Funktionslog zu erkennen.```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

Basierend auf der Signatur können wir einige DSL-Funktionen erkennen, die *dynmx* leistungsstark machen:
* Definition von API-Aufrufsequenzen mit alternativen Pfaden
* Abgleich von API-Aufruffunktionsnamen mit regulären Ausdrücken
* Abgleich von Argument- und Rückgabewerten mit mehreren Operatoren
* Speicherung von Variablen, z. B. um Handles in der API-Aufrufsequenz zu verfolgen
* Definition einer Erkennungsbedingung mit booleschen Operatoren (`AND`, `OR`, `NOT`)

Wenn wir *dynmx* mit der oben gezeigten Signatur gegen die Funktion der Probe `c0832b1008aa0fc828654f9762e37bda019080cbdd92bd2453a05cfb3b79abb3` ausführen, erhalten wir die folgende Ausgabe, die anzeigt, dass die Signatur erkannt wurde.```
$ 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

Wir können mehr ins Detail gehen, indem wir das Ausgabeformat auf detail setzen. Nun können wir die genaue API-Aufrufsequenz sehen, die im Funktionsprotokoll erkannt wurde. Darüber hinaus sehen wir, dass die Signatur im Prozess 51f0.exe erkannt wurde.``` $ 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...