Основы анализа вредоносного ПО: статический и динамический подход
Вредоносное ПО становится все более изощренным: маскируется под легитимное, обходит защитные механизмы и разными способами скрывает свою активность. Чтобы эффективно реагировать на инциденты и предотвращать повторные атаки, необходимо уметь анализировать ВПО: понимать, как оно работает, какие изменения вносит в систему, какие индикаторы компрометации оставляет и каким образом от него защищаться. Подробно о том, что такое ВПО, каким оно бывает и чем опасно, мы рассказывали в предыдущей статье.
Анализ ВПО необходим в различных направлениях кибербезопасности. В форензике и реагировании на инциденты (digital forensics and incident response, DFIR) он позволяет понять суть атаки и определить, как устранять последствия. В киберразведке (threat intelligence) используется, чтобы пополнить базу знаний об угрозах и исследовать активность злоумышленников. В разработке антивирусных и EDR‑решений — для создания сигнатур и моделей обнаружения. Также анализ ВПО играет важную роль в обучении специалистов.
Существует два основных подхода — статический и динамический. Статический анализ позволяет исследовать файл без его выполнения, динамический — подразумевает запуск подозрительного объекта в контролируемой среде, чтобы наблюдать за его поведением в реальном времени. На практике эти подходы комбинируются: даже простое ВПО может содержать скрытые функции, которые проявляются только в определенных условиях. Комплексный анализ позволяет не упустить важные детали.
Рассмотрим базовые принципы каждого подхода, преимущества и ограничения, а также приведем примеры инструментов, которые используют специалисты SOC.
Первичная проверка
Прежде чем приступать к детальному анализу, выполните быструю первичную проверку, чтобы понять, связан ли файл с уже известными угрозами. Для этого удобно использовать платформы, агрегирующие данные из множества источников. Они предоставляют актуальные сведения о вредоносной активности зачастую раньше, чем поставщики антивирусов. Наиболее популярный инструмент для такой проверки — VirusTotal. Также используются Hybrid Analysis, Malshare, Malpedia, Triage и другие. В предыдущей статье мы подробно разбирали особенности работы с такими платформами.
Но не все файлы разрешено загружать на публичные платформы. Объект может содержать чувствительную информацию, к тому же злоумышленники нередко отслеживают появление своих образцов на подобных ресурсах. В таких случаях подозрительный объект исследуют вручную, используя статический и динамический анализ.
Статический анализ
Статический анализ — это исследование кода и структуры программы без ее выполнения. С него начинается изучение подозрительного файла. На этом этапе анализируются содержимое объекта, его структура, используемые библиотеки и встроенные данные. Все это дает представление о возможной функциональности ВПО еще до его запуска.
Рассмотрим основные приемы статического анализа.
Извлечение метаданных файла
Сбор метаданных подозрительного файла позволяет получить базовую информацию об объекте, понять его тип и его возможную вредоносную активность.
Основные действия на этом этапе:
- Определить хеши. Вычислить MD5, SHA-1, SHA-256, чтобы сопоставить файл с известными образцами ВПО.
- Определить тип файла. Установить, исполняемый ли он (PE для Windows или ELF для Linux), например, с помощью утилиты file в Linux или специализированных PE‑инструментов (Portable Executable).
- Проанализировать информацию о сборке. Извлечь данные о времени компиляции, используемом компиляторе и других характеристиках, чтобы лучше понять особенности создания ВПО.
Определение хешей с помощью утилит ОС
Хеширование файлов — это преобразование массива входных данных произвольной длины в выходную битовую строку установленной длины (хеш‑сумму). Хеш‑сумма представляет собой уникальную строку символов, которая служит цифровым отпечатком содержимого файла.
Вычислить хеш файла в Windows поможет утилита certutil. Хотя программа предназначена для работы с сертификатами, она также позволяет определить хеш.
certutil -hashfile file.exe
FSR_launcher.exe с помощью certutil в командной строке Windows
Также используется PowerShell Get‑FileHash. Это командлет PowerShell для вычисления хеша файла одним из поддерживаемых алгоритмов. Командлет доступен начиная с PowerShell 5.0, входит в состав PowerShell Core, благодаря чему может использоваться в разных операционных системах.
Get-FileHash -Path "C:\path\to\file.exe" -Algorithm SHA256
mimikatz.exe с помощью командлета Get‑FileHash в PowerShell — алгоритмы SHA‑256, SHA‑1, SHA‑384, SHA‑512 и MD5
В Linux применяют стандартные утилиты sha256sum и md5sum.
hashmyfiles‑master.zip с помощью утилит md5sum и sha256sum в терминале Ubuntu
А также используют сторонние утилиты: HashMyFiles, Hash Tool, Hash Checker и др.
FSR_Launcher.exe, REPO.exe и Tick Tock.exe с помощью утилиты HashMyFiles — алгоритмы MD5, SHA‑1, CRC32, SHA‑256, SHA‑512 и SHA‑384
mimikatz.exe (x64 и Win32) в утилите HashTools
mimikatz.exe с помощью утилиты Hash Checker
Получив базовую информацию о файле и убедившись, что его нельзя идентифицировать по открытым источникам, аналитик может переходить к следующему этапу анализа — извлечению строк.
Извлечение строк
Извлечение строк позволяет быстро получить полезную информацию: IP‑адреса, домены, имена функций, пути к файлам или любые другие данные, которые не были обфусцированы или удалены разработчиком.
Строки в исполняемом файле обычно хранятся в формате ASCII или Unicode. Найти их поможет стандартная утилита strings в Unix или ее аналог для Windows из пакета Sysinternals от Марка Руссиновича.
HashMyFiles.exe с помощью утилиты strings в терминале Ubuntu
HashMyFiles.exe с помощью команды strings -№ 8 в терминале Ubuntu
FSR_Launcher.exe с сохранением результата в output.txt с помощью Strings v2.54 от Sysinternals в командной строке Windows
FSR_Launcher.exe, сохраненный в файл output.txt
Но эти инструменты могут не дать результата, если файл обфусцирован. В таких случаях применяется FLARE Obfuscated String Solver (FLOSS) от Mandiant — инструмент для извлечения строк из обфусцированного вредоносного кода. FLOSS анализирует исполняемый файл и находит функции, которые используются для декодирования или формирования строк во время выполнения программы. Для этого инструмент эмулирует выполнение и использует другие методы извлечения строк, скрытых в коде:
- Static strings — обычные строки, встроенные напрямую в
.rdataили.data. - Stack strings — строки, которые собираются по частям в локальной памяти, например, через mov или push.
- Decoded strings — строки, которые декодируются во время выполнения. FLOSS эмулирует выполнение декодирующих функций и возвращает итоговую строку.
- Tight loop deobfuscation — строки, каждый символ которых вычисляется по формулам внутри циклов. FLOSS распознает их и восстанавливает исходную строку.
mimikatz.exe инструментом FLOSS: метаданные файла, стековые строки (NTLM, Kerberos, WDigest) и начало раздела декодированных строк
mimikatz.exe инструментом FLOSS: извлечение статических и стековых строк, декодирование обфусцированных строк из 2516 функций
Найденные строки можно использовать для создания сигнатур обнаружения с помощью YARA‑правил.
Использование YARA‑правил
YARA — это инструмент на основе гибких настраиваемых правил для идентификации, классификации и обнаружения вредоносных файлов. Эти правила широко применяются в анализе ВПО, а также в системах обнаружения угроз: IDS, EDR, песочницах и других. YARA‑правила описывают признаки ВПО через строки, бинарные шаблоны и логические выражения, которые комбинируют найденные элементы.
YARA‑правило состоит из 3 блоков:
- meta — метаданные (автор, дата, описание);
- strings — строки или бинарные последовательности для поиска;
- condition — логическое выражение, определяющее, когда правило срабатывает.
Пример примитивного YARA‑правила:
rule Malware {
meta:
author = "SOC Analyst"
description = "Rule to detect known malware behavior with C2 and suspicious function"
date = "2025-06-03"
version = "1.1"
strings:
$s1 = "command-and-control.com" ascii nocase
$s2 = "InternetConnectA" ascii
$hex1 = { 6A 00 6A 01 6A 02 6A 03 FF 15 85 C0 75 0A 85 C0 74 0C }
condition:
(1 of ($s*)) or $hex1
}
Чтобы применить правило к файлу, достаточно одной команды:
yara rule.yar suspicious_file.exe
Если правило сработало, YARA выведет его название и путь к файлу. Это значит, что файл соответствует описанным признакам. Если вывода нет — совпадений не найдено. При сканировании целой директории путь к файлу заменяется на путь к папке:
yara rule.yar C:\samples\
Для запуска YARA‑правил по файловой системе и памяти используется Yara Loki — инструмент командной строки, разработанный Флорианом Ротом в качестве доступной альтернативы коммерческим сканерам. Yara Loki подходит для расследований инцидентов и ретроспективного поиска угроз.
Извлечение строк работает, только когда файл не защищен от анализа. Первый признак того, что файл упакован или зашифрован: строки не извлекаются или их содержимое выглядит бессмысленным.
PowerShell_Susp_Parameter_Combo, указывающего на подозрительный вызов PowerShell с параметрами обхода политик безопасности
Обнаружение упаковщиков
Если извлечение строк из исполняемого файла не дает результата, это может значить, что файл:
- упакован — сжат специальным программным упаковщиком;
- зашифрован или обфусцирован для усложнения анализа;
- собран с применением загрузчика, который разворачивает полезную нагрузку в памяти во время исполнения.
Чтобы проанализировать такой файл, необходимо понять его тип, изучив заголовок. В разных операционных системах форматы файлов различаются, но заголовок всегда содержит ключевые метаданные:
- тип файла (исполняемый, архив и т. д.);
- архитектуру;
- формат;
- информацию о коде и данных;
- сигнатуры (магические числа).
Знание сигнатур позволяет определить реальный тип файла независимо от его расширения. Например, файл с расширением .txt может на самом деле оказаться исполняемым PE‑файлом — это распространенный прием маскировки.
Формат PE особенно важен для Windows‑систем. Помимо сигнатуры MZ, по которой система опознает PE‑файл, заголовок содержит информацию об архитектуре, требуемых библиотеках, размерах секций кода и данных. Анализ этого заголовка позволяет выявить признаки упаковки — об этом подробнее в следующем разделе.
В Unix‑системах аналогичную роль играет формат ELF. Его заголовок содержит тип файла (исполняемый, библиотека или объектный файл), архитектуру, класс (32 или 64 бита) и адрес точки входа. Анализ заголовка ELF помогает понять назначение файла и выявить признаки модификации.
Определить, упакован ли файл, установить тип упаковщика или компилятора, использованных при сборке, позволяет программа PEiD.
gl.exe в PEiD v0.95: упаковщик не обнаружен, файл является 32‑битным GUI‑приложением с точкой входа в секции .text
Посмотреть заголовки PE‑файлов можно с помощью утилит CFF Explorer и Detect It Easy. На скрине ниже представлен анализ PE‑файла: видны секции, заголовки и hex‑дамп начала файла, где читается сигнатура MZ.
При анализе обращайте внимание на следующие признаки упаковки:
- Необычные секции. Вместо привычных
.text,.data,.rsrcможно увидеть.UPX,.aspack,.petite,.boomи другие нестандартные имена. - Маленький размер TXT‑секции. Если она весит 1–2 КБ, а файл — 1 МБ, скорее всего, остальное зашифровано и распакуется в память при запуске.
- Детектирование упаковщика. PEiD или Detect It Easy укажут, чем упакован файл, например
Packed with: UPX v3.91.
Если файл не упакован или был успешно распакован, следующий шаг — изучить, какие функции он использует.
Исследование динамически скомпонованных функций
После анализа структуры исполняемого файла и определения признаков упаковки или маскировки следующий важный этап в статическом анализе — изучение функций, которые использует файл. Это особенно важно, если файл не был упакован или, наоборот, был распакован. Так вы поймете, какие действия он потенциально выполняет в системе.
Исполняемые файлы используют различные функции из внешних библиотек:
- Импортируемые — уже готовые функции, которые программа берет из внешних библиотек, вместо того чтобы писать их заново. Это помогает уменьшить дублирование кода.
- Экспортируемые — функции, которые программа делает доступными для использования другими программами.
Библиотеки бывают двух типов:
- Статические. Весь код библиотеки копируется внутрь исполняемого файла, что делает его больше по размеру.
- Динамические. Библиотека загружается отдельно при запуске программы, что позволяет нескольким программам использовать один и тот же код.
Вредоносные программы чаще используют динамическую загрузку, так как она дает больше гибкости:
- Позволяет загружать нужные библиотеки во время выполнения, минуя статический импорт.
- Усложняет анализ, поскольку в таблице импорта нет прямого указания на все используемые функции.
- Позволяет менять библиотеки.
Для исследования динамически скомпонованных функций используется Dependency Walker — утилита, которая выводит список функций, загружаемых динамически. На левой панели отображается сама программа и все DLL, которые она импортирует. Выбрав конкретную DLL, справа вы увидите список используемых функций и полный список функций этой библиотеки, доступных для импорта.
mimikatz.exe в Dependency Walker: список импортируемых и экспортируемых функций, подключенные DLL‑библиотеки и их метаданные
Исполняемые файлы могут импортировать функции по порядковым номерам вместо имен — это дополнительный способ усложнить анализ. Чтобы восстановить имена функций по номерам, нужно воспользоваться полем Ordinal в Dependency Walker.
Так можно выявить подозрительные обращения к функциям типа VirtualAlloc, WriteProcessMemory, CreateRemoteThread и другим, связанным с инъекциями и запуском кода, а также установить зависимости от сторонних библиотек.
Для более детального изучения импортированных и экспортированных функций используется PeStudio. В отличие от Dependency Walker, этот инструмент не только показывает список функций, но и сразу помечает подозрительные вызовы, что ускоряет анализ.
mimikatz.exe в PeStudio 9.61: 30 подключенных DLL, из которых 16 помечены как подозрительные, с указанием количества импортируемых функций и назначения каждой библиотеки
mimikatz.exe в PeStudio: 288 функций помечены как подозрительные, среди них CreateRemoteThread, NtAdjustPrivilege, CreateProcessW и функции работы с сетевыми учетными данными из netapi32.dll
Знание, какие функции использует файл, позволяет понять его потенциальное поведение еще до запуска. Особого внимания заслуживает таблица импорта: в ней видно, к каким возможностям системы обращается программа.
Подозрительные функции в таблице импорта
С помощью анализа импортируемых функций можно узнать, какие библиотеки использует исполняемый файл, а также выявить потенциально вредоносное поведение еще до запуска. Особенно важно обращать внимание на часто используемые злоумышленниками функции. Их наличие может указывать на попытки внедриться в другие процессы, выполнить посторонний код, загрузить дополнительные компоненты, сохранить данные в системе или закрепиться в ней.
Функции, часто используемые во вредоносном ПО
| Функция | Назначение | Потенциальное поведение |
|---|---|---|
|
Загружать DLL и получать указатель на функцию вручную |
Динамически подгружают функции, обходят таблицы импорта и скрывают активность |
|
Запускать внешний процесс или команды |
Запускают вредоносный код или передают управление другому файлу |
|
Работать с реестром Windows |
Указывают на попытки закрепиться в системе через автозагрузку или изменить конфигурацию |
|
Создавать и записывать в файлы |
Сохраняют вредоносные компоненты на диске, собирают данные или создают временные файлы |
|
Подключаться к удаленному серверу |
Указывают на возможную связь с командным сервером или эксфильтрацию данных |
|
Выделять и изменять права доступа к памяти |
Позволяют подготовиться к внедрению кода и обойти Data Execution Prevention (DEP) |
|
Читать и записывать в память процесса |
Используются для инъекции кода, кейлоггинга и получения информации из других процессов |
|
Создавать поток в процессе |
Используются для инъекции кода, DLL‑инъекций, обхода EDR |
|
Устанавливать и удалять хуки |
Используются для кейлоггинга, мониторинга системных событий и перехвата действий пользователя |
|
Получать доступ к процессам и потокам |
Используются для манипуляции с процессами и внедрения |
|
Получать информацию о процессах и системе |
Позволяют обнаружить различные инструменты анализа и антидебага (антиотладки) |
|
Обнаруживать отладчик |
Обходят анализ и песочницы |
|
Завершать процесс |
Самоуничтожаются, разрушают антивирусные процессы |
|
Работать с учетными записями Windows |
Создают скрытых пользователей и повышают привилегии |
|
Шифровать данные |
Скрывают информацию, часто являются признаком вымогателя (ransomware) |
|
Кодировать данные |
Скрывают строки, используются для маскировки перед эксфильтрацией |
|
Задерживать исполнение |
Обходят песочницы, замедляют анализ |
|
Получать сетевую информацию |
Собирают разведданные о сети перед атакой |
|
Перечислять файлы |
Ищут файлы и документы, а также позволяют подготовиться к эксфильтрации |
Эти функции в таблице импорта могут свидетельствовать о типичной активности вредоносного ПО. Если в одном файле встречается сразу несколько таких функций, необходим дальнейший анализ.
Многие вредоносные программы не включают эти функции в явный импорт, чтобы не вызывать подозрений при поверхностном исследовании. Вместо этого ВПО загружает нужные DLL и функции в момент выполнения, используя LoadLibrary и GetProcAddress. Это позволяет избежать анализа через утилиты типа Dependency Walker, динамически выбирать нужные функции в зависимости от окружения и подгружать вредоносный инструментарий только при необходимости.
Это значительно усложняет анализ, требует динамического подхода или использования эмуляторов и отладчиков, чтобы отслеживать поведение программы в реальном времени.
Для быстрой оценки подозрительных функций удобно использовать MalAPI.io — бесплатный онлайн‑сервис, который показывает, как конкретная функция Windows API используется во вредоносных сценариях, к каким классам атак она относится и какое поведение с ней связано. Это ускоряет анализ таблицы импорта и помогает расставить приоритеты.
Рассмотрим функцию CreateToolhelp32Snapshot. На первый взгляд, это стандартный системный вызов для перечисления процессов и потоков. Но, согласно MalAPI.io, он активно используется вредоносным ПО перед инъекцией в процесс и относится к категориям Enumeration и Anti‑Debugging. Именно так сервис помогает быстро оценить контекст функции и понять ее роль в потенциально вредоносном сценарии.
Важную информацию о файле можно извлечь из его внутренней структуры — секций и заголовков.
Анализ структуры и заголовков файла
Заголовки исполняемых файлов, таких как PE‑файлы в Windows, предоставляют важную информацию о разных частях программы. Эти части (или секции) используются для хранения кода, данных, ресурсов и других компонентов. Их анализ помогает понять, как организован файл и как он работает.
Основные секции исполняемого файла:
| Секция | Описание |
|---|---|
.text |
Исполняемый код программы. Эта часть предназначена только для чтения, потому что в ней находится основная логика программы |
.data |
Данные, которые можно изменять во время работы программы. Это инициализированные данные, доступные для чтения и записи |
.rdata |
Данные, которые программа не изменяет, например строки и константы. Только для чтения |
.rsrc |
Ресурсы: иконки, изображения, строки и другие статические элементы, используемые программой |
Вредоносные программы могут создавать части с необычными атрибутами, например секции, которые разрешают выполнение кода в том месте, где обычно хранятся только данные. Это позволяет скрывать вредоносный код.
Рассмотрим основные заголовки PE‑файла, используя утилиту PEview.
IMAGE_FILE_HEADER — часть заголовка PE‑файла, которая содержит основную информацию о файле и помогает системе понять, как его интерпретировать и загружать.
| Секция | Описание |
|---|---|
| Машинная архитектура (Machine) |
Архитектура процессора, для которой был скомпилирован файл (например, x86 или x64) |
| Количество секций (NumberOfSections) |
Количество секций, содержащих исполняемый файл ( |
| Время создания (TimeDateStamp) |
Дата и время компиляции файла |
| Размер заголовка (SizeOfOptionalHeader) |
Размер следующего заголовка — |
| Характеристики (Characteristics) |
Характеристики файла: исполняемый ли он, является ли он DLL, а также другие атрибуты |
IMAGE_FILE_HEADER файла mimikatz.exe в PEview
IMAGE_OPTIONAL_HEADER — часть заголовка PE‑файла, которая содержит дополнительные параметры, необходимые для загрузки и исполнения программы. Несмотря на название Optional (необязательный), этот заголовок обязателен для всех исполняемых файлов.
| Секция | Описание |
|---|---|
| Адрес входной точки (EntryPoint) |
Адрес, с которого начинается выполнение программы. Это место в памяти, куда система передает управление после загрузки файла |
| Базовый адрес (ImageBase) |
Адрес в памяти, по которому система пытается загрузить файл. Если этот адрес уже занят, происходит переадресация (relocation) |
| Выравнивание секций (SectionAlignment) |
Способ, как секции будут выравниваться в памяти |
| Размер образа (SizeOfImage) |
Общий размер образа в памяти, включая все секции |
| Подсистема (Subsystem) |
Указание, для какой подсистемы скомпилирован файл (например, консольное приложение или графическое приложение) |
| Характеристики DLL (DllCharacteristics) |
Определение, содержит ли файл важные защитные механизмы, такие как защита от выполнения данных (DEP), рандомизация адресного пространства (ASLR) |
| Размер заголовков (SizeOfHeaders) |
Общий размер всех заголовков в файле |
IMAGE_SECTION_HEADER — заголовок, который описывает каждую секцию PE‑файла. Заголовки секций помогают понять, как программа организована и как взаимодействуют ее компоненты.
| Секция | Описание |
|---|---|
| Имя секции (Name) |
|
| Виртуальный размер (VirtualSize) |
Размер секции в памяти после загрузки |
| Виртуальный адрес (VirtualAddress) |
Адрес, по которому секция будет загружена в виртуальную память |
| Размер данных на диске (SizeOfRawData) |
Фактический размер секции в файле на диске |
| Указатель на данные (PointerToRawData) |
Место, где начинаются данные секции в файле |
| Характеристики секции (Characteristics) |
Права доступа к секции: чтение, запись, выполнение |
.text файла mimikatz.exe в PEview: секция содержит исполняемый код (IMAGE_SCN_CNT_CODE) с правами на выполнение и чтение
Обычно создание и наименование PE‑файлов — работа компилятора, и пользователь почти не может повлиять на этот процесс. Благодаря этому секции часто совпадают в разных исполняемых файлах, что делает любые отклонения потенциально подозрительными. При анализе стоит обращать внимание на следующие аномалии:
- Появление неизвестных или необычных секций в структуре файла.
- Необычное содержимое или структура в секциях
.text,.dataили.rdata. - Значительное превышение виртуального размера секции над ее размером на диске (это признак упаковки).
Быстро выявлять такие аномалии позволяет Detect It Easy (DIE) — утилита для анализа PE‑файлов и .NET‑сборок. С ее помощью можно определить тип файла, обнаружить упаковщик, просмотреть уровень энтропии (высокая энтропия указывает на сжатие или шифрование), импортируемые функции, строки и заголовки.
mimikatz.exe в Detect It Easy
Также стоит использовать dnSpy — инструмент для анализа и редактирования программ, написанных на платформе .NET. Он выступает как отладчик и декомпилятор .NET‑сборок, что полезно для реверс‑инжиниринга .NET‑приложений, включая ВПО. Если файл не использует упаковщик и является .NET‑приложением, dnSpy попытается восстановить исходный код. Это позволяет понять логику работы программы и изучить вредоносное поведение напрямую.
Все эти инструменты дают представление о файле, но не позволяют увидеть его внутреннюю логику на уровне кода. Для этого применяются дизассемблирование и декомпиляция.
Дизассемблирование и декомпиляция
Чтобы понять поведение исполняемого файла без его запуска, необходимо перейти на уровень кода с помощью дизассемблирования и декомпиляции.
Дизассемблирование — это преобразование машинного кода в ассемблерный, то есть в понятный человеку и близкий к архитектуре процессора. Когда программа компилируется, ее исходный код превращается в набор машинных инструкций, которые записываются в файл формата .exe или .dll. Дизассемблер считывает этот бинарный код и отображает его в форме команд процессора, например:
MOV EAX, 1 PUSH EBX CALL 0x401000
Из дизассемблирования можно узнать, какие функции вызываются, какая логика условного ветвления используется, как работает вредоносный код: с помощью инъекций, шифрования, загрузки пейлоадов, где располагается шелл‑код и какой API используется.
Декомпиляция — это преобразование бинарного кода в высокоуровневый язык, например C. Декомпилятор восстанавливает структуру функций, циклов и переменных, создавая приближенное представление исходного кода:
if (x == 5) {
do_something();
}
Декомпиляция позволяет:
- быстрее понять логику и цели программы;
- выявить вызовы подозрительных функций, использование паролей и других артефактов;
- написать более точные YARA‑правила на основе структуры и имен функций.
Основные инструменты для дизассемблирования и декомпиляции:
| Инструмент | Назначение | Особенности |
|---|---|---|
| IDA Pro / Free |
Дизассемблер + декомпилятор |
Поддерживает графы, отладчики, плагины. Версия Pro включает декомпилятор |
| Ghidra |
Дизассемблер + декомпилятор |
Активно обновляется, бесплатный. Поддерживает большое число архитектур, графы, есть возможность расширения |
| Binary Ninja |
Дизассемблер + декомпилятор |
Предлагает удобный графический интерфейс. Поддерживает плагины, предлагает интерактивный анализ кода. Есть бесплатная версия со всеми базовыми функциями. Платная версия включает поддержку плагинов, доступ к ML‑декомпиляции, а также приоритетные обновления и техподдержку |
| MalCat |
Анализатор PE/ELF |
Бесплатный, быстрый, с графическим интерфейсом, встроенными сигнатурами и криптоанализом |
Ghidra — бесплатный инструмент с открытым исходным кодом для реверс‑инжиниринга, разработанный Агентством национальной безопасности США. Ghidra позволяет анализировать двоичные файлы на уровне машинного кода, помогает понять их структуру и логику без доступа к исходному коду. Ключевые возможности — автоматическая декомпиляция в псевдокод на языке C, поддержка множества архитектур и возможность работы с большими проектами.
Ghidra предоставляет полезную информацию еще до начала полного анализа — на этапе импорта файла. В окне предимпорта можно увидеть:
- общую информацию о файле: имя, архитектуру, порядок байтов, адресацию;
- статистику: размер файла, количество блоков памяти, функций и определенных данных;
- компилятор и версию Ghidra, которой был создан проект;
- расположение файла и его хеши (MD5, SHA-256);
- список импортируемых библиотек и внешних зависимостей.
level_2.exe в Ghidra
Запуская полный автоматический анализ, можно выбрать нужные модули анализа. Это позволяет сфокусироваться на необходимых аспектах и не тратить время на избыточную обработку.
Отправной точкой для изучения проанализированного кода служит функция main: с нее начинается выполнение программы. Слева отображается дизассемблированный код, справа — декомпилированный псевдокод на C, что упрощает понимание логики.
level_2.exe в Ghidra: дизассемблированный код в центре и декомпилированный псевдокод функции __mainCRTStartup на C справа
main файла level_2.exe в Ghidra: видна логика обработки аргументов командной строки, выделение памяти и работа с файлами
Преимущества и недостатки статического анализа
К преимуществам относится:
- Минимизация рисков при исследовании. Программу не запускают, что исключает риск случайного выполнения вредоносного кода. Это особенно важно при работе с неизвестными или потенциально опасными образцами.
- Автоматизация и масштабируемость. Инструменты автоматизации позволяют быстро обрабатывать большие объемы файлов.
- Глубокое понимание логики. Удобно изучать структуру программы, используемые библиотеки, встроенные строки, алгоритмы, точки входа и взаимодействие с API.
- Выявление признаков упаковки или обфускации. Уже на раннем этапе можно обнаружить следы упаковки, шифрования или полиморфизма, что сигнализирует о возможной вредоносности.
- Определение индикаторов компрометации. Хеши, строки, домены, пути к файлам и другие артефакты можно извлечь заранее и использовать в правилах детектирования.
При этом следует учитывать следующие недостатки:
- Сложности при обфускации и упаковке. Современное ВПО часто использует механизмы защиты, из‑за которых сложно извлекать полезную информацию без предварительной распаковки или декодирования.
- Отсутствие поведенческой информации. Статический анализ не позволяет увидеть, как программа реально взаимодействует с системой, какие процессы запускает, куда подключается, какие файлы создает.
- Высокие требования к навыкам. Понимание дизассемблированного кода, API‑вызовов и работы операционной системы требует от аналитика опыта и подготовки.
- Риск ложных выводов. Без выполнения невозможно с полной уверенностью судить о намерениях программы: часть кода может не использоваться или активироваться только при определенных условиях.
Статический анализ дает отправную точку, но имеет принципиальное ограничение: он показывает, что программа может делать, а не то, что она делает на самом деле. Чтобы увидеть реальное поведение вредоносного ПО, необходимо его запустить. И здесь начинается динамический анализ.
Динамический анализ
Динамический анализ — это изучение вредоносного ПО во время его выполнения. Такой анализ проводят после запуска файла в контролируемой среде, чтобы наблюдать за действиями в реальном времени. Метод особенно полезен, когда статический анализ заходит в тупик — из‑за упаковки, шифрования или обфускации.
Динамический анализ позволяет:
- отследить, какие процессы запускает вредоносная программа;
- выявить изменения в файловой системе и реестре;
- зафиксировать сетевые подключения и каналы эксфильтрации данных;
- понять, какие функции ОС вызываются.
Рассмотрим, какие инструменты используются для этого метода анализа.
Песочницы
Песочница — это изолированная среда, в которой можно запускать подозрительные файлы без риска для основной системы.
Песочницы используют виртуализацию и эмуляцию сетевых сервисов, чтобы ВПО проявило свое реальное поведение. Метод позволяет автоматически зафиксировать его действия, предоставляет наглядные отчеты и подходит для первичного анализа, когда нужно быстро понять назначение образца.
Бесплатные облачные песочницы: Joe Sandbox, Hybrid Analysis и Any.Run. Для анализа также можно использовать сервис VirusTotal, который интегрирует несколько песочниц, чтобы анализировать поведение загруженных файлов.
Загрузив файл на одну из этих платформ, можно получить детализированную информацию о его поведении: дерево процессов
Не рекомендуется загружать на публичные платформы файлы, содержащие конфиденциальную информацию. В таких случаях используйте локально развернутые решения: как проприетарные, так и открытые, например Cuckoo Sandbox, REMnux или FlareVM.
Подробнее, как устроены песочницы изнутри, какие механизмы используются для изоляции и эмуляции среды, мы разберем в отдельной статье цикла — «Что такое песочница и как она работает: внутренняя кухня автоматического анализа».
Недостатки песочниц
У песочниц есть ряд ограничений, о которых важно помнить:
- Недостаток контекста запуска. На раннем этапе часто нет полной информации о том, как именно должно запускаться ВПО: какие параметры и дополнительные файлы требуются. В результате вредоносная логика может не сработать, если ей нужен конкретный аргумент или конфигурационный файл. Современные песочницы позволяют задавать параметры запуска и эмулировать окружение, но для этого нужен контекст, которого зачастую не хватает.
- Зависимость от C2. Некоторые образцы ВПО ожидают команды от управляющего сервера, чтобы активировать полезную нагрузку. Без связи с C2 песочница зафиксирует только пассивное поведение.
- Возможность ухода. Многие образцы используют отложенный запуск — через циклы, счетчики или нестандартные API, которые обходят механизмы перехвата функций. Это может привести к ложноотрицательным результатам — вредоносная активность просто не успевает проявиться.
- Обнаружение виртуальной среды. ВПО нередко определяет, что его запустили в виртуальной машине, и меняет поведение или прекращает выполнение. Не все песочницы противодействуют этим техникам.
- Зависимость от окружения. Некоторым образцам требуются определенные ключи реестра, файлы или конфигурации, которых нет в песочнице, а без них вредоносная логика не активируется.
- Проблемы с DLL. Если ВПО является DLL, корректный вызов всех экспортируемых функций в автоматическом режиме затрудняется.
- Несовместимость ОС. Песочница может использовать версию Windows, для которой ВПО не предназначено, что приведет к сбою или некорректному поведению.
Когда информации от песочницы недостаточно или нужен более детальный контроль над анализом, для динамического анализа используют другие инструменты.
Монитор процессов
Монитор процессов (Process Monitor, ProcMon) — инструмент мониторинга в Windows, отслеживающий в реальном времени обращения к файловой системе, реестру, процессам и системным вызовам. Он не предназначен для анализа сетевого трафика, но позволяет увидеть, как процессы используют сетевые API.
Из‑за большого объема данных ProcMon быстро накапливает миллионы событий, поэтому без фильтрации работать с ним сложно. Первое, что нужно сделать перед запуском ВПО, — настроить фильтры. Базовый сценарий: отфильтровать по имени процесса, чтобы видеть только активность исследуемого файла. Для этого в меню Filter выбирается пункт Filter и добавляется условие:
Process Name → is → malware.exe → Include
Также рекомендуется исключить системные процессы, которые создают фоновый шум: Explorer.exe, svchost.exe и инструменты самого ProcMon.
Procmon.exe, Procexp.exe, Autoruns.exe) и служебных операций (IRP_MJ_, FASTIO_) для сокращения шума при анализе
Основные колонки (на скриншоте выше — в столбце Column):
- Process Name — имя процесса.
- Operation — тип операции (RegSetValue, WriteFile, CreateProcess и т. д.).
- Path — путь к объекту, с которым взаимодействует процесс.
- Result — результат операции (
SUCCESS,ACCESS DENIEDи т. д.).
При анализе ВПО в ProcMon обращайте внимание на следующие процессы:
- Обращения к ключам реестра автозапуска:
HKCU\Software\Microsoft\Windows\CurrentVersion\Runи аналогичным. - Создание или изменение файлов в системных директориях:
System32,Temp,AppData. - Запуск дочерних процессов, особенно
cmd.exe,powershell.exe,rundll32.exe. - Попытки доступа с результатом
ACCESS DENIED— это может указывать на попытку повышения привилегий.
Полезный прием — запустить ProcMon до запуска ВПО, зафиксировать базовое состояние системы, затем запустить образец и сравнить. Так получится четко разграничить активность ВПО и фоновый шум системы.
Process Explore
Process Explorer — бесплатная утилита от Microsoft, которая расширяет стандартные возможности диспетчера задач. При динамическом анализе она позволяет в реальном времени наблюдать за поведением процессов и их взаимодействием с системой.
Обратите внимание на цветовую индикацию процессов:
- Фиолетовая — упакованные или скомпрометированные процессы.
- Красная — завершающиеся.
- Голубая — процессы, запущенные от имени текущего пользователя.
- Розовая — сервисы.
- Серая — приостановленные процессы.
Индикация позволяет быстро выявить аномалии даже при беглом просмотре.
Ключевые возможности Process Explorer при анализе ВПО:
- Иерархия процессов. Показывает дочерние процессы, запущенные вредоносным ПО. Например, тревожным сигналом будет, если Word запускает
cmd.exe. - Просмотр DLL и дескрипторов. Позволяет увидеть загруженные библиотеки, открытые файлы и ключи реестра, связанные с процессом. Помогает обнаружить DLL‑инъекции или хайджекинг (hijacking).
- Проверка цифровых подписей. Автоматически проверяет подписи исполняемых файлов. Неподписанный файл или подпись от неизвестного издателя — повод для дальнейшего анализа.
- Интеграция с VirusTotal. Позволяет отправить хеш процесса на проверку прямо из интерфейса — через правый клик по процессу → Check VirusTotal.com.
- Дамп памяти. Сохраняет состояние вредоносного процесса для дальнейшего анализа, даже если объект самоуничтожится в ходе работы.
При анализе ВПО обращайте внимание на процессы:
- без цифровой подписи;
- с необычными родительскими процессами;
- с именами, похожими на системные, но с другим путем или PID;
- запущенные из нестандартных директорий:
Temp,AppData, корень диска C.
Regshot
Regshot — простой инструмент с открытым исходным кодом, отслеживающий изменения в реестре Windows путем сравнения двух снимков его состояния: до и после запуска исследуемого файла.
Сценарий использования простой:
- Первый снимок. Делается до запуска ВПО, фиксирует текущее состояние реестра.
- Запуск ВПО. Образец запускается и получает время на выполнение своих действий.
- Второй снимок. Делается после завершения активности программы.
- Сравнение. Автоматически сравниваются два состояния и выводится список изменений.
В результате получаем четыре категории изменений: добавленные и удаленные ключи, добавленные и измененные значения.
При анализе ВПО обращайте внимание на следующие процессы:
- Добавление ключей в ветки автозапуска.
HKCU\Software\Microsoft\Windows\CurrentVersion\Run,HKLM\Software\Microsoft\Windows\CurrentVersion\Run— признак закрепления. - Создание новых служб. Например,
HKLM\SYSTEM\CurrentControlSet\Services. - Изменение политик безопасности. Например,
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies. - Добавление значений в нестандартные ветки реестра, особенно если путь указывает на
TempилиAppData.
Regshot удобен из‑за простоты: не требует настройки фильтров, предоставляет информацию о разнице реестра до и после запуска образца.
ApateDNS и FakeNet‑NG
Многие вредоносные программы после запуска стремятся связаться с внешними ресурсами, чтобы загрузить дополнительный код, отправить системную информацию или получить команды от C2‑сервера. Чтобы безопасно проанализировать это поведение, используются инструменты, имитирующие внешнюю сеть без реального подключения к интернету.
ApateDNS — простой DNS‑сервер компании Mandiant, предназначенный для перехвата и анализа DNS‑запросов от исследуемого приложения. Принцип работы: ApateDNS принимает все DNS‑запросы от ВПО, отвечает на них заранее заданным IP‑адресом и логирует все перехваченные домены с временными метками.
При анализе логов ApateDNS обращайте внимание на следующую информацию:
- Домены, которые ВПО запрашивает сразу после запуска. Это вероятные C2‑адреса.
- Нестандартные или сгенерированные домены. Это признак DGA (domain generation algorithm).
- Частота запросов. Слишком частые обращения к одному домену могут указывать на beaconing.
FakeNet‑NG — более продвинутый инструмент от FireEye, который эмулирует сразу несколько типов сетевых сервисов, в том числе DNS, HTTP, HTTPS, FTP, SMTP. В отличие от ApateDNS он не просто перехватывает DNS‑запросы, а полноценно отвечает на сетевые соединения, создавая иллюзию реальной сети. Это позволяет ВПО продолжить выполнение и раскрыть свою логику взаимодействия с сервером.
svchost.exe и необработанные TCP‑соединения от неизвестного процесса (PID 8136) к внешним адресам
В логах FakeNet‑NG можно увидеть:
- полные HTTP‑запросы: метод, URI, заголовки, тело запроса;
- передаваемые данные: что именно ВПО пытается отправить на сервер;
- используемые протоколы и порты: нестандартные порты могут указывать на попытку обхода фаервола;
- имена процессов, инициирующих соединения: помогает связать сетевую активность с конкретным процессом.
ApateDNS удобен, когда нужно быстро выяснить, к каким доменам обращается ВПО. FakeNet‑NG незаменим, когда важно понять, что именно передается и по каким протоколам. На практике их часто используют вместе: ApateDNS для первичной разведки, FakeNet‑NG для детального анализа трафика.
Wireshark
Wireshark — инструмент для захвата и анализа сетевого трафика. Он позволяет увидеть, с какими адресами пытается связаться вредоносная программа, какие данные передает и через какие протоколы взаимодействует с внешней инфраструктурой.
Ключевое преимущество Wireshark перед ApateDNS и FakeNet‑NG — возможность видеть весь трафик на уровне пакетов, включая содержимое передаваемых данных. Это особенно полезно, когда ВПО использует нестандартные протоколы или шифрование.
Для работы с трафиком ВПО важно уметь использовать фильтры: без них анализ превращается в поиск иголки в стоге сена. Несколько базовых примеров:
ip.addr == 192.168.1.100 — трафик конкретного хоста dns — только DNS-запросы http — только HTTP-трафик tcp.port == 4444 — подключения на конкретный порт http.request.method == "POST" — POST-запросы, часто используются для эксфильтрации
При анализе ВПО в Wireshark обращайте внимание на следующее:
- DNS‑запросы к неизвестным или сгенерированным доменам — это признак C2 или DGA.
- HTTP‑запросы методом POST с большим объемом данных — возможная эксфильтрация.
- Подключения на нестандартные порты — попытка обхода фаервола.
- Повторяющиеся запросы с одинаковым интервалом — beaconing.
- Трафик к IP‑адресам напрямую без DNS‑запроса — попытка скрыть C2‑домен.
- Использование легитимных протоколов для передачи данных — DNS‑туннелинг, ICMP‑туннелинг.
Wireshark удобно использовать вместе с FakeNet‑NG. Первый инструмент захватывает весь трафик и позволяет детально изучить каждый пакет, а второй эмулирует сетевые сервисы и отвечает на запросы ВПО.
Рассмотренные инструменты — базовый набор для динамического анализа. На практике арсенал аналитиков значительно шире, он подбирается в зависимости от конкретного образца и задачи. Но даже с этим набором можно понять, как подозрительная программа взаимодействует с системой:
- выявить поведение после запуска,
- зафиксировать попытки уклонения от обнаружения,
- получить ценные артефакты для дальнейшего расследования.
Преимущества и недостатки динамического анализа
К сильным сторонам этого подхода относятся:
- Наблюдение за реальным поведением. Позволяет увидеть, как программа ведет себя в процессе выполнения: какие процессы запускает, к каким узлам подключается, какие файлы читает, создает или изменяет. Это дает ценные поведенческие индикаторы.
- Обход обфускации и упаковки. В отличие от статического подхода, динамический анализ выявляет вредоносную активность, даже когда код упакован или зашифрован. При запуске программа часто самостоятельно расшифровывает себя в памяти.
- Выявление сетевой активности. Позволяет зафиксировать обращения к C2‑серверам, DNS‑запросы, HTTP и другие сетевые взаимодействия, включая использование нестандартных протоколов и портов.
- Формирование индикаторов компрометации (IoC). По результатам запуска можно извлечь множество артефактов: созданные файлы, ключи реестра, IP‑адреса, имена процессов, временные метки.
Следует учитывать и недостатки:
- Необходимость изолированной среды. Анализ должен проводиться в изолированной контролируемой среде, чтобы избежать реального заражения инфраструктуры.
- Ограниченность покрытия. Иногда программа ведет себя по‑разному в зависимости от внешних факторов. Один запуск может не охватить все ветви исполнения, особенно если используется проверка окружения или отложенные действия.
- Трудоемкость. Динамический анализ требует времени для запуска и наблюдения. Дополнительно необходима настройка инструментов мониторинга.
- Механизмы антианализа. Некоторые образцы обнаруживают песочницы и инструменты анализа, чтобы избежать выполнения вредоносного кода. Это затрудняет выявление истинного поведения.
Создание безопасной среды
Динамический анализ требует изолированной среды. Даже при осторожном подходе ВПО может распространиться на другие хосты, установить соединение с C2‑сервером или нанести иной ущерб инфраструктуре.
Для анализа используются виртуальные машины. Они позволяют изолировать выполнение ВПО от основной системы и быстро откатиться к чистому состоянию с помощью снапшотов. Сеть виртуальной машины настраивается изолировано: без доступа к интернету и корпоративной сети, но с эмуляцией сетевых сервисов через инструменты вроде FakeNet‑NG.
Чтобы быстро развернуть лабораторию для анализа ВПО, существуют специализированные дистрибутивы — REMnux (Linux‑среда с предустановленными инструментами для анализа) и FlareVM (Windows‑среда от Mandiant). Они содержат необходимый инструментарий без дополнительной установки, что ускоряет подготовку к работе.
Анализ вредоносного ПО — один из ключевых навыков специалистов по кибербезопасности. Он позволяет не просто идентифицировать угрозу, но и понять ее поведение, цели и методы обхода защитных механизмов, а значит, выстроить защиту и предотвратить повторные инциденты.
На практике наиболее эффективно сочетать статический и динамический анализ. Каждый из методов имеет свои сильные и слабые стороны, в связке они компенсируют недостатки друг друга.
Статический анализ без риска запуска кода дает быстрый обзор структуры файла: встроенные строки, хеши, подозрительные вызовы API и признаки упаковки. Динамический анализ дополняет его наблюдением за реальным поведением во время исполнения: какие процессы создаются, какие файлы затрагиваются, куда идут сетевые запросы. Вместе они позволяют выявить как сигнатурные, так и поведенческие индикаторы компрометации, повышают достоверность выводов и помогают обнаружить сложные образцы, использующие упаковку, шифрование и антианализ.
Освоение этих методов требует не только знания инструментов, но и аналитического мышления — умения задавать правильные вопросы, замечать аномалии и связывать разрозненные артефакты в единую картину атаки.