Анализ памяти с Volatility

Как из сырого дампа памяти восстановить картину работы системы с помощью фреймворка Volatility.

Volatility — открытый фреймворк для анализа дампов оперативной памяти: он разбирает внутренние структуры ОС и восстанавливает список процессов, соединений, модулей и других артефактов из сырого образа RAM.

Напоминание: анализируем только легально полученные дампы своих или подведомственных систем. Дальше — методология защитника, разбирающего инцидент.

Зачем это знать защитнику

Дамп памяти сам по себе — это гигабайты бинарного «шума». Volatility превращает его в понятные таблицы: какие процессы работали, кто с кем соединялся по сети, какие команды вводились. Для реагирования на инцидент это даёт ответы на ключевые вопросы: запущено ли что-то подозрительное, есть ли скрытое соединение с командным сервером, что именно сделал злоумышленник. Без анализа памяти fileless-атаку часто вообще невозможно доказать.

Ещё одна причина освоить инструмент — скорость. Во время инцидента время идёт на минуты, и аналитик, который помнит десяток ключевых плагинов и порядок их применения, реагирует кратно быстрее того, кто впервые открывает документацию. Поэтому Volatility учат заранее, на учебных дампах, а не впервые в бою.

Профили и символы: почему это важно

Чтобы разобрать сырую память, инструменту нужно знать точную раскладку структур ядра конкретной ОС — а она меняется от версии к версии и даже между сборками. Volatility 2 решал это профилями: аналитик вручную подбирал профиль под ОС. Volatility 3 перешёл на таблицы символов (Symbol Tables): фреймворк сам определяет систему по сигнатурам ядра и подтягивает нужные символы. Практический вывод для защитника: для редких или старых сборок ОС символов может не быть «из коробки», и их приходится генерировать заранее — это стоит проверить до инцидента, а не во время него.

С чего начинается анализ

Современный Volatility 3 сам определяет версию ОС по символам, поэтому достаточно указать файл дампа и нужный плагин. Базовый запуск:

python3 vol.py -f mem.lime windows.pslist

Флаг -f задаёт файл дампа, дальше идёт имя плагина. Имена устроены по семействам: windows.*, linux.*, mac.*.

Базовые плагины и что они извлекают

Процессы

С процессов начинают любой разбор. Три взаимодополняющих взгляда:

Сравнение pslist и psscan — классический приём: если процесс есть в psscan, но отсутствует в pslist, его, возможно, спрятали из списка ядра. Об этом — отдельный урок.

Сетевые соединения

Плагин windows.netscan восстанавливает сокеты и соединения: локальный и удалённый адрес, порт, состояние и процесс-владелец. Так находят канал управления (C2): неприметный процесс, держащий исходящее соединение на чужой IP по нестандартному порту.

Командные строки

windows.cmdline показывает, с какими аргументами запускался каждый процесс. Это золото: в аргументах часто видны пути к полезной нагрузке, закодированные команды PowerShell, адреса серверов. Аналогично windows.consoles вытаскивает буфер ввода-вывода консоли — то, что реально набирал атакующий.

Инъекции и модули

windows.malfind ищет области памяти с подозрительными признаками: исполняемые страницы без файла на диске, начинающиеся с сигнатуры MZ кода. Это указывает на инъекцию кода в чужой процесс. windows.dlllist и windows.ldrmodules сверяют загруженные библиотеки.

Реестр и дескрипторы

Память хранит и слепок реестра Windows: плагины семейства windows.registry.* читают кусты прямо из RAM, что позволяет увидеть ключи автозапуска и точки закрепления (persistence) такими, какими они были в момент снятия. Плагин windows.handles показывает дескрипторы процесса — открытые файлы, ключи реестра, мьютексы. Уникальный мьютекс — частый «отпечаток» конкретного семейства вредоносного ПО, по которому его опознают.

Как это работает под капотом

Каждый процесс в Windows описан структурой ядра _EPROCESS, и эти структуры связаны в двусвязный список. pslist идёт по этому списку — быстро, но обманываемо. psscan же сканирует всю память в поисках байтовой сигнатуры _EPROCESS, не доверяя спискам ядра, поэтому видит то, что от списка отцепили. Понимание этой разницы и есть суть форензики памяти.

Результат плагина — это таблица строк, и удобно сразу прикинуть, сколько в дампе процессов и нет ли явных дублей. Небольшой разбор условного вывода pslist на стандартной библиотеке Python:

from collections import Counter

# Условные строки вывода pslist: (PID, имя процесса)
rows = [
    (4, "System"), (520, "smss.exe"), (612, "csrss.exe"),
    (700, "svchost.exe"), (888, "svchost.exe"), (1100, "explorer.exe"),
    (1340, "svchost.exe"), (2200, "powershell.exe"),
]

names = Counter(name for _, name in rows)
print("Всего процессов:", len(rows))
for name, count in names.most_common(3):
    print(f"  {name}: {count}")

Вывод:

Всего процессов: 8
  svchost.exe: 3
  System: 1
  smss.exe: 1

Несколько svchost.exe — это норма для Windows, но именно под такие легитимные имена любит маскироваться вредоносное ПО, поэтому каждый экземпляр потом проверяют по родителю и пути.

Методология анализа

Профессиональный разбор идёт по воронке от общего к частному:

1. Снять обзор: pstree — увидеть аномальные цепочки запуска.
2. Сверить pslist с psscan — выявить скрытые и завершённые процессы.
3. Для подозрительных PID посмотреть cmdline и netscan.
4. Прогнать malfind на инъекции кода.
5. Зафиксировать находки и сопоставить с диском и логами.

Как защититься

• Включите расширенное логирование (Sysmon, аудит создания процессов) — память покажет момент, а логи дадут историю.
• Сохраняйте эталонный список нормальных процессов хоста, чтобы быстро видеть «лишнее».
• Автоматизируйте сбор артефактов в плейбук, чтобы аналитик не вспоминал команды в стрессе.
• Тренируйте чтение вывода Volatility на учебных дампах (TryHackMe, образцы из открытых наборов).

Итоги

• Volatility разбирает сырой дамп в таблицы процессов, соединений, команд и модулей.
• pslist идёт по списку ядра, psscan — по сигнатурам; их расхождение выдаёт скрытое.
• cmdline и netscan раскрывают намерения: что запускали и куда соединялись.
• malfind ищет инъекции кода — исполняемую память без файла на диске.