0x534a/dynmxDetecção baseada em assinaturas de características de malware com base em sequências de chamadas da API do Windows. É como o YARA para rastros de API de sandbox!
dynmx (pronuncia-se dinâmica) é uma abordagem de deteção baseada em assinaturas para características comportamentais de malware usando sequências de chamadas de API do Windows. De forma simplificada, pode pensar no dynmx como uma espécie de YARA para rastreios de chamadas de API (os chamados function logs) provenientes de sandboxes de malware. Portanto, a base de dados para a abordagem de deteção não são as próprias amostras de malware analisadas estaticamente, mas sim dados gerados durante uma análise dinâmica da amostra de malware numa sandbox de malware. Atualmente, o dynmx suporta function logs das seguintes sandboxes de malware:
report.json)report.json)A abordagem de deteção é descrita em detalhe na dissertação de mestrado Signature-Based Detection of Behavioural Malware Features with Windows API Calls. Este projeto é a implementação protótipo desta abordagem e foi desenvolvido no âmbito da dissertação de mestrado. As assinaturas são definidas manualmente por analistas de malware na DSL de assinaturas dynmx e podem ser detetadas em function logs com a ajuda desta ferramenta. As funcionalidades e a sintaxe da DSL de assinaturas dynmx também podem ser encontradas na dissertação de mestrado. Além disso, pode encontrar assinaturas dynmx de exemplo no repositório dynmx-signatures. Para além de detetar características de malware com base em chamadas de API, o dynmx pode extrair recursos do SO utilizados pelo malware (o chamado Access Activity Model). Estes recursos são extraídos examinando as chamadas de API e reconstruindo operações sobre recursos do SO. Atualmente, os recursos do SO das categorias sistema de ficheiros, registo e rede são considerados no modelo.
Na secção seguinte, são mostrados exemplos para a deteção de características de malware e para a extração de recursos.
Para este exemplo, escolhemos a amostra de malware com o hash SHA-256 c0832b1008aa0fc828654f9762e37bda019080cbdd92bd2453a05cfb3b79abb3. De acordo com MalwareBazaar, a amostra pertence à família de malware Amadey. Existe um relatório de análise da VMRay público desta amostra, que também fornece o function log rastreado pela VMRay. Este function log será a nossa base de dados para a deteção.
Se quisermos saber se a amostra de malware utiliza uma técnica de injeção chamada Process Hollowing, podemos tentar detetar a seguinte assinatura dynmx no 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
Com base na assinatura, podemos encontrar algumas funcionalidades DSL que tornam o *dynmx* poderoso:
* Definição de sequências de chamadas de API com caminhos alternativos
* Correspondência de nomes de funções de chamada de API com expressões regulares
* Correspondência de valores de argumentos e retorno com vários operadores
* Armazenamento de variáveis, por exemplo, para rastrear handles na sequência de chamadas de API
* Definição de uma condição de detecção com operadores booleanos (`AND`, `OR`, `NOT`)
Se executarmos o *dynmx* com a assinatura mostrada acima contra a função da amostra `c0832b1008aa0fc828654f9762e37bda019080cbdd92bd2453a05cfb3b79abb3`, obtemos a seguinte saída indicando que a assinatura foi 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 entrar em mais detalhes definindo o formato de saída para detail. Agora, podemos ver a sequência exata de chamadas de API que foi detectada no log da função. Além disso, podemos ver que a assinatura foi detectada no 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...