Prototipo de dynmx

dynmx (pronunciado dynamics) es un enfoque de detección basado en firmas para características de comportamiento de malware basado en secuencias de llamadas a la API de Windows. De manera simplificada, puede pensar en dynmx como una especie de YARA para trazas de llamadas a la API (los llamados registros de funciones) provenientes de sandboxes de malware. Por lo tanto, la base de datos para el enfoque de detección no son las muestras de malware en sí mismas, que se analizan estáticamente, sino los datos generados durante un análisis dinámico de la muestra de malware en una sandbox de malware. Actualmente, dynmx admite registros de funciones de las siguientes sandboxes de malware:

• VMRay (registro de funciones, formato de texto y XML)
• CAPEv2 (archivo report.json)
• Cuckoo (archivo report.json)

El enfoque de detección se describe en detalle en la tesis de maestría Detección basada en firmas de características de comportamiento de malware con llamadas a la API de Windows. Este proyecto es la implementación prototipo de este enfoque y se desarrolló en el transcurso de la tesis de maestría. Las firmas son definidas manualmente por analistas de malware en el DSL de firmas dynmx y pueden detectarse en registros de funciones con la ayuda de esta herramienta. Las características y la sintaxis del DSL de firmas dynmx también se pueden encontrar en la tesis de maestría. Además, puede encontrar firmas de muestra de dynmx en el repositorio dynmx-signatures. Además de detectar características de malware basadas en llamadas a la API, dynmx puede extraer recursos del SO que son utilizados por el malware (el llamado Modelo de Actividad de Acceso). Estos recursos se extraen examinando las llamadas a la API y reconstruyendo operaciones sobre los recursos del SO. Actualmente, los recursos del SO de las categorías sistema de archivos, registro y red se consideran en el modelo.

Ejemplo

En la siguiente sección, se muestran ejemplos de la detección de características de malware y de la extracción de recursos.

Detección

Para este ejemplo, elegimos la muestra de malware con la suma hash SHA-256 c0832b1008aa0fc828654f9762e37bda019080cbdd92bd2453a05cfb3b79abb3. Según MalwareBazaar, la muestra pertenece a la familia de malware Amadey. Hay un informe de análisis de VMRay público disponible de esta muestra, que también proporciona el registro de funciones rastreado por VMRay. Este registro de funciones será nuestra base de datos que utilizaremos para la detección.

Si quisiéramos saber si la muestra de malware utiliza una técnica de inyección llamada Process Hollowing, podemos intentar detectar la siguiente firma dynmx en el registro de funciones.```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

Basándose en la firma, podemos encontrar algunas características de DSL que hacen que *dynmx* sea potente:
* Definición de secuencias de llamadas a la API con rutas alternativas
* Coincidencia de nombres de funciones de llamadas a la API con expresiones regulares
* Coincidencia de valores de argumentos y retorno con varios operadores
* Almacenamiento de variables, por ejemplo, para hacer seguimiento de identificadores en la secuencia de llamadas a la API
* Definición de una condición de detección con operadores booleanos (`AND`, `OR`, `NOT`)

Si ejecutamos *dynmx* con la firma mostrada anteriormente contra la función de la muestra `c0832b1008aa0fc828654f9762e37bda019080cbdd92bd2453a05cfb3b79abb3`, obtenemos la siguiente salida que indica que la firma fue detectada.```
$ 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

Podemos obtener más detalles configurando el formato de salida a detail. Ahora, podemos ver la secuencia exacta de llamadas a la API que fue detectada en el registro de funciones. Además, podemos ver que la firma fue detectada en el proceso 51f0.exe.``` $ python3 dynmx.py -f detail detect -i 601941f00b194587c9e57c5fabaf1ef11596179bea007df9bdcdaa10f162cac9.json -s process_hollow.yml