Прототип dynmx

dynmx (произносится динамикс) — это подход к обнаружению на основе сигнатур поведенческих особенностей вредоносного ПО, использующий последовательности вызовов Windows API. Упрощенно можно считать dynmx своего рода YARA для трассировок вызовов API (так называемых функциональных логов), получаемых из песочниц для вредоносного ПО. Таким образом, основой данных для обнаружения являются не сами образцы вредоносного ПО, анализируемые статически, а данные, генерируемые в ходе динамического анализа образца в песочнице. В настоящее время dynmx поддерживает функциональные логи следующих песочниц:

• VMRay (функциональный лог, текстовый и XML-форматы)
• CAPEv2 (файл report.json)
• Cuckoo (файл report.json)

Подход к обнаружению подробно описан в магистерской диссертации Signature-Based Detection of Behavioural Malware Features with Windows API Calls. Данный проект является прототипной реализацией этого подхода и был разработан в рамках магистерской диссертации. Сигнатуры вручную определяются аналитиками вредоносного ПО на предметно-ориентированном языке сигнатур dynmx и могут быть обнаружены в функциональных логах с помощью этого инструмента. Особенности и синтаксис предметно-ориентированного языка dynmx также описаны в магистерской диссертации. Кроме того, примеры сигнатур dynmx можно найти в репозитории dynmx-signatures. Помимо обнаружения особенностей вредоносного ПО на основе вызовов API, dynmx может извлекать ресурсы операционной системы, используемые вредоносным ПО (так называемая Модель Доступа к Ресурсам). Эти ресурсы извлекаются путём анализа вызовов API и восстановления операций с ресурсами ОС. В настоящее время в модели учитываются ресурсы ОС категорий файловая система, реестр и сеть.

Пример

В следующем разделе приведены примеры обнаружения особенностей вредоносного ПО и извлечения ресурсов.

Обнаружение

Для этого примера выберем образец вредоносного ПО с SHA-256 хеш-суммой c0832b1008aa0fc828654f9762e37bda019080cbdd92bd2453a05cfb3b79abb3. Согласно MalwareBazaar, образец относится к семейству вредоносного ПО Amadey. Существует публичный отчёт анализа VMRay этого образца, который также предоставляет функциональный лог, записанный VMRay. Этот функциональный лог будет нашей основной базой данных, которую мы используем для обнаружения.

Если мы хотим узнать, использует ли образец вредоносного ПО технику внедрения, называемую Process Hollowing, мы можем попытаться обнаружить следующую сигнатуру dynmx в функциональном логе.```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

Основываясь на сигнатуре, можно выделить некоторые возможности DSL, которые делают *dynmx* мощным:
* Определение последовательностей вызовов API с альтернативными путями
* Сопоставление имен функций вызовов API с регулярными выражениями
* Сопоставление аргументов и возвращаемых значений с помощью нескольких операторов
* Хранение переменных, например, для отслеживания дескрипторов в последовательности вызовов API
* Определение условия обнаружения с помощью булевых операторов (AND, OR, NOT)

Если запустить *dynmx* с показанной выше сигнатурой для функции образца `c0832b1008aa0fc828654f9762e37bda019080cbdd92bd2453a05cfb3b79abb3`, мы получим следующий вывод, указывающий, что сигнатура была обнаружена.```
$ 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

Мы можем углубиться в детали, установив формат вывода в detail. Теперь мы можем увидеть точную последовательность вызовов API, которая была обнаружена в журнале функций. Кроме того, мы можем видеть, что сигнатура была обнаружена в процессе 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...