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...

[+] Result Function log: c0832b1008aa0fc828654f9762e37bda019080cbdd92bd2453a05cfb3b79abb3.txt Signature: process_hollow Process: 51f0.exe (PID: 3768) Number of Findings: 1 Finding 0 proc_hollow : API Call CreateProcessA (Function log line 20560, index 938) proc_hollow : API Call VirtualAllocEx (Function log line 20566, index 944) proc_hollow : API Call WriteProcessMemory (Function log line 20573, index 951) proc_hollow : API Call SetThreadContext (Function log line 20574, index 952) proc_hollow : API Call ResumeThread (Function log line 20575, index 953)

### Resources
Um die zugegriffenen Betriebssystemressourcen aus einem Funktionsprotokoll zu extrahieren, können wir einfach den *dynmx*-Befehl `resources` gegen das Funktionsprotokoll ausführen. Ein Beispiel der detaillierten Ausgabe wird unten für die Probe mit der SHA-256-Hashsumme `601941f00b194587c9e57c5fabaf1ef11596179bea007df9bdcdaa10f162cac9` gezeigt. Dies ist ein CAPE-Sandbox-Bericht, der Teil des [Avast-CTU Public CAPEv2 Dataset](https://github.com/avast/avast-ctu-cape-dataset) ist.```
$ python3 dynmx.py -f detail resources --input 601941f00b194587c9e57c5fabaf1ef11596179bea007df9bdcdaa10f162cac9.json


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

 Ver. 0.5 (PoC), by 0x534a


[+] Parsing 1 function log(s)
[+] Processing function log(s) with the command 'resources'...

[+] Result
Function log: 601941f00b194587c9e57c5fabaf1ef11596179bea007df9bdcdaa10f162cac9.json (/Users/sijansen/Documents/dev/dynmx_flogs/cape/Public_Avast_CTU_CAPEv2_Dataset_Full/extracted/601941f00b194587c9e57c5fabaf1ef11596179bea007df9bdcdaa10f162cac9.json)
	Process: 601941F00B194587C9E5.exe (PID: 2008)
		Filesystem:
			C:\Windows\SysWOW64\en-US\SETUPAPI.dll.mui (CREATE)
			API-MS-Win-Core-LocalRegistry-L1-1-0.dll (EXECUTE)
			C:\Windows\SysWOW64\ntdll.dll (READ)
			USER32.dll (EXECUTE)
			KERNEL32.dll (EXECUTE)
			C:\Windows\Globalization\Sorting\sortdefault.nls (CREATE)
		Registry:
			HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OLEAUT (READ)
			HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup (READ)
			HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\SourcePath (READ)
			HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion (READ)
			HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\DevicePath (READ)
			HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings (READ)
			HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings\DisableImprovedZoneCheck (READ)
			HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings (READ)
			HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Security_HKLM_only (READ)
	Process: 601941F00B194587C9E5.exe (PID: 1800)
		Filesystem:
			C:\Windows\SysWOW64\en-US\SETUPAPI.dll.mui (CREATE)
			API-MS-Win-Core-LocalRegistry-L1-1-0.dll (EXECUTE)
			C:\Windows\SysWOW64\ntdll.dll (READ)
			USER32.dll (EXECUTE)
			KERNEL32.dll (EXECUTE)
			[...]
			C:\Users\comp\AppData\Local\vscmouse (READ)
			C:\Users\comp\AppData\Local\vscmouse\vscmouse.exe:Zone.Identifier (DELETE)
		Registry:
			HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OLEAUT (READ)
			HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup (READ)
			[...]
	Process: vscmouse.exe (PID: 900)
		Filesystem:
			C:\Windows\SysWOW64\en-US\SETUPAPI.dll.mui (CREATE)
			API-MS-Win-Core-LocalRegistry-L1-1-0.dll (EXECUTE)
			C:\Windows\SysWOW64\ntdll.dll (READ)
			USER32.dll (EXECUTE)
			KERNEL32.dll (EXECUTE)
			C:\Windows\Globalization\Sorting\sortdefault.nls (CREATE)
		Registry:
			HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OLEAUT (READ)
			HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup (READ)
			HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\SourcePath (READ)
			HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion (READ)
			HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\DevicePath (READ)
			HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings (READ)
			HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings\DisableImprovedZoneCheck (READ)
			HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings (READ)
			HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Security_HKLM_only (READ)
	Process: vscmouse.exe (PID: 3036)
		Filesystem:
			C:\Windows\SysWOW64\en-US\SETUPAPI.dll.mui (CREATE)
			API-MS-Win-Core-LocalRegistry-L1-1-0.dll (EXECUTE)
			C:\Windows\SysWOW64\ntdll.dll (READ)
			USER32.dll (EXECUTE)
			KERNEL32.dll (EXECUTE)
			C:\Windows\Globalization\Sorting\sortdefault.nls (CREATE)
			C:\ (READ)
			C:\Windows\System32\uxtheme.dll (EXECUTE)
			dwmapi.dll (EXECUTE)
			advapi32.dll (EXECUTE)
			shell32.dll (EXECUTE)
			C:\Users\comp\AppData\Local\vscmouse\vscmouse.exe (CREATE,READ)
			C:\Users\comp\AppData\Local\iproppass\iproppass.exe (DELETE)
			crypt32.dll (EXECUTE)
			urlmon.dll (EXECUTE)
			userenv.dll (EXECUTE)
			wininet.dll (EXECUTE)
			wtsapi32.dll (EXECUTE)
			CRYPTSP.dll (EXECUTE)
			CRYPTBASE.dll (EXECUTE)
			ole32.dll (EXECUTE)
			OLEAUT32.dll (EXECUTE)
			C:\Windows\SysWOW64\oleaut32.dll (EXECUTE)
			IPHLPAPI.DLL (EXECUTE)
			DHCPCSVC.DLL (EXECUTE)
			C:\Users\comp\AppData\Roaming\Microsoft\Network\Connections\Pbk\_hiddenPbk\ (CREATE)
			C:\Users\comp\AppData\Roaming\Microsoft\Network\Connections\Pbk\_hiddenPbk\rasphone.pbk (CREATE,READ)
		Registry:
			HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OLEAUT (READ)
			HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup (READ)
			[...]
		Network:
			24.151.31.150:465 (READ)
			http://24.151.31.150:465 (READ,WRITE)
			107.10.49.252:80 (READ)
			http://107.10.49.252:80 (READ,WRITE)

Basierend auf der gezeigten Ausgabe und den aufgerufenen Ressourcen können wir einige Malware-Funktionen ableiten:

Innerhalb des Prozesses 601941F00B194587C9E5.exe (PID 1800) wird der Zone Identifier der Datei C:\Users\comp\AppData\Local\vscmouse\vscmouse.exe gelöscht
Einige DLLs werden dynamisch geladen
Der Prozess vscmouse.exe (PID: 3036) verbindet sich mit den Netzwerkendpunkten http://24.151.31.150:465 und http://107.10.49.252:80

Die aufgerufenen Ressourcen sind interessant für die Identifizierung von host- und netzwerkbasierten Erkennungsindikatoren. Darüber hinaus können Ressourcen in dynmx-Signaturen verwendet werden. Ein bekanntes Beispiel ist die Erkennung von Persistenzmechanismen in der Registry.``` dynmx_signature: meta: name: run_keys_persistence title: Run Keys Persistence description: Detection of persistence based on Registry Run Keys detection: run_keys: - resource: category: "registry" access_operations: ["write"] with: - attribute: "location" operation: "regex" value: "^(HKEY_CURRENT_USER|HKEY_LOCAL_MACHINE)\\Software\\Microsoft\\Windows\\CurrentVersion\\(Run|RunOnce|RunOnceEx)\\" startup_folders_keys: - resource: category: "registry" access_operations: ["write"] with: - attribute: "location" operation: "regex" value: "^(HKEY_CURRENT_USER|HKEY_LOCAL_MACHINE)\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\(Shell Folders|User Shell Folders)\\" condition: run_keys as simple or startup_folders_keys as simple

## Installation
Um die Software nutzen zu können, muss Python 3.9 auf dem Zielsystem verfügbar sein. Zusätzlich müssen die folgenden Python-Pakete installiert werden:
* `anytree`,
* `lxml`,
* `pyparsing`,
* `PyYAML`,
* `six` und
* `stringcase`

Um die Pakete zu installieren, führen Sie den unten gezeigten `pip3`-Befehl aus. Es wird empfohlen, eine virtuelle Python-Umgebung zu verwenden, anstatt die Pakete systemweit zu installieren.```
pip3 install -r requirements.txt

Verwendung

Um den Prototyp zu verwenden, führen Sie einfach den Haupt-Einstiegspunkt dynmx.py aus. Die Nutzungsinformationen können mit dem Befehlszeilenparameter -h wie unten gezeigt angezeigt werden.``` $ python3 dynmx.py -h usage: dynmx.py [-h] [--format {overview,detail}] [--show-log] [--log LOG] [--log-level {debug,info,error}] [--worker N] {detect,check,convert,stats,resources} ...

Detect dynmx signatures in dynamic program execution information (function logs)

optional arguments: -h, --help show this help message and exit --format {overview,detail}, -f {overview,detail} Output format --show-log Show all log output on stdout --log LOG, -l LOG log file --log-level {debug,info,error} Log level (default: info) --worker N, -w N Number of workers to spawn (default: number of processors - 2)

sub-commands: task to perform

{detect,check,convert,stats,resources} detect Detects a dynmx signature check Checks the syntax of dynmx signature(s) convert Converts function logs to the dynmx generic function log format stats Statistics of function logs resources Resource activity derived from function log

Im Allgemeinen können, wie in der Ausgabe gezeigt, mehrere Befehlszeilenparameter bezüglich der Protokollverwaltung, des Ausgabeformats für Ergebnisse oder der Mehrfachverarbeitung definiert werden. Des Weiteren muss ein Befehl ausgewählt werden, um eine bestimmte Aufgabe auszuführen. Bitte beachten Sie, dass die Anzahl der Arbeiter nur Befehle betrifft, die Mehrfachverarbeitung nutzen. Derzeit sind dies die Befehle `detect` und `convert`.

Die Befehle haben spezifische Befehlszeilenparameter, die durch die Angabe des Parameters `-h` an den Befehl erkundet werden können, z.B. für den Befehl `detect` wie unten gezeigt.```
$ python3 dynmx.py detect -h
usage: dynmx.py detect [-h] --sig SIG [SIG ...] --input INPUT [INPUT ...] [--recursive] [--json-result JSON_RESULT] [--runtime-result RUNTIME_RESULT] [--detect-all]

optional arguments:
  -h, --help            show this help message and exit
  --recursive, -r       Search for input files recursively
  --json-result JSON_RESULT
                        JSON formatted result file
  --runtime-result RUNTIME_RESULT
                        Runtime statistics file formatted in CSV
  --detect-all          Detect signature in all processes and do not stop after the first detection

required arguments:
  --sig SIG [SIG ...], -s SIG [SIG ...]
                        dynmx signature(s) to detect
  --input INPUT [INPUT ...], -i INPUT [INPUT ...]
                        Input files

Als Nutzer von dynmx können Sie entscheiden, wie die Ausgabe strukturiert ist. Wenn Sie sich dafür entscheiden, das Protokoll auf der Konsole anzuzeigen, indem Sie den Parameter --show-log definieren, besteht die Ausgabe aus zwei Abschnitten (siehe Auflistung unten). Das Protokoll wird zuerst angezeigt und danach die Ergebnisse des verwendeten Befehls. Standardmäßig wird das Protokoll weder auf der Konsole angezeigt noch in eine Protokolldatei geschrieben (die mit dem Parameter --log definiert werden kann). Aufgrund der Mehrfachverarbeitung sind die Einträge in der Protokolldatei nicht unbedingt in chronologischer Reihenfolge.```

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

Ver. 0.5 (PoC), by 0x534a

[+] Log output 2023-06-27 19:07:38,068+0000 [INFO] (main) [PID: 13315] []: Start of dynmx run [...] [+] End of log output

[+] Result [...]

Der Detailgrad der Ergebnisausgabe kann über den Befehlszeilenparameter `--output-format` festgelegt werden, der auf `overview` für eine zusammenfassende Ergebnisdarstellung oder auf `detail` für eine detaillierte Ergebnisdarstellung gesetzt werden kann. Wenn Sie beispielsweise das Ausgabeformat auf `detail` setzen, enthalten die auf der Konsole angezeigten Erkennungsergebnisse die genauen API-Aufrufe und Ressourcen, die zur Erkennung geführt haben. Die overview-Ausgabe zeigt lediglich an, welche Signatur in welchem Funktionsprotokoll erkannt wurde.

## Beispiel-Befehlszeilen
Erkennung einer *dynmx*-Signatur in einem Funktionsprotokoll mit einem Worker-Prozess```
python3 dynmx.py -w 1 detect -i "flog.txt" -s dynmx_signature.yml

Konvertierung eines Funktionslogs in das dynmx generische Funktionslog-Format``` python3 dynmx.py convert -i "flog.txt" -o /tmp/

Signatur überprüfen (nur grundlegende Plausibilitätsprüfungen)```
python3 dynmx.py check -s dynmx_signature.yml

Erhalten Sie eine detaillierte Liste der von einer Malware-Probe verwendeten Ressourcen basierend auf dem Funktionsprotokoll (access activity model)``` python3 dynmx.py -f detail resources -i "flog.txt"

## Fehlerbehebung
Bitte bedenken Sie, dass dieses Werkzeug ein Proof-of-Concept ist, das neben der Erstellung der Masterarbeit entwickelt wurde. Daher ist die Codequalität nicht immer die beste und es können Fehler und Bugs auftreten. Ich habe versucht, das Werkzeug im gegebenen Zeitrahmen so robust wie möglich zu gestalten.

Der beste Weg, Fehler zu beheben, ist die Aktivierung der Protokollierung (auf der Konsole und/oder in einer Logdatei) und die Einstellung der Protokollstufe auf `debug`. Ausnahmehandler sollten detaillierte Fehler in das Log schreiben, was bei der Fehlerbehebung helfen kann.

dynmx

Beliebteste

dynmx Prototyp

Beispiel

Erkennung

Verwendung