За последний год через мою лабораторию прошло больше двадцати дампов с инцидентов, где вредоносная программа жила исключительно в оперативке - ни одного файла на диске. Fileless-атаки, reflective DLL injection, Cobalt Strike beacon в RWX-регионе легитимного svchost.exe - для классической дисковой форензики всё это невидимо. Единственный способ вытащить такие артефакты - анализ дампов памяти Volatility 3.

Русскоязычные руководства по memory forensics почти все построены вокруг Volatility 2 с обязательным
, CTF-задачек и перечисления команд без объяснения, что конкретно показывает каждый плагин и почему
и
дают разные результаты. Эта статья - не справочник по ключам. Это пошаговый workflow расследования инцидента: от снятия дампа через WinPmem до получения IoC, готовых для отчёта. Каждый шаг привязан к конкретной технике MITRE ATT&CK, и я объясню, какие аномалии искать в выводе плагина, а какие - спокойно отбросить как фолзы.

Аудитория - пентестеры и security-инженеры, которые знают, что такое
, но хотят отточить практику работы с memory forensics инструментами.
Почему дамп RAM - первый артефакт при реагировании на инцидент
Образ диска на 250+ ГБ скачивается часами. Дамп RAM на 8–32 ГБ снимается за минуты. Но дело не только в размере - оперативная память хранит то, чего на диске нет в принципе:

• Расшифрованный payload - малварь шифрует себя на диске, но в RAM работает в открытом виде. Это ключевое преимущество анализа оперативной памяти forensics-методами
  
• Инжектированный код - Process Injection (T1055, Defense Evasion / Privilege Escalation) файлов не оставляет, только RWX-регионы в чужом адресном пространстве
  
• Скрытые процессы - Rootkit (T1014, Defense Evasion) манипулирует ядерными структурами, выдёргивая процесс из списка, но pool-теги остаются в физической памяти. MITRE описывает T1014 для нескольких платформ, однако публичные атомарные тесты Atomic Red Team для этой техники пока есть только под Linux
  
• Сетевые соединения - активные C2-коннекты с PID, портами и IP, которые лог файервола мог просто не записать
  
• Учётные данные - LSASS Memory (T1003.001, Credential Access) хранит хэши и билеты Kerberos прямо в памяти процесса lsass.exe

Поэтому первый вопрос при реагировании - «можно ли тупо снять дамп памяти?», а уже потом - «когда будет готов образ диска?». По данным Pentest Partners, дамп 8 ГБ обрабатывается Volatility 3 заметно быстрее, чем двойкой на том же объёме, что делает тройку предпочтительным инструментом для DFIR анализа памяти.
Подготовка к анализу дампов памяти Volatility 3
Требования к окружению и снятие дампа
Перед первой командой - контрольный список:

• Аналитическая станция: Linux (Kali, SIFT Workstation) или Windows 10+, Python 3.8+, минимум 16 ГБ RAM для комфортной работы с дампами 8–32 ГБ
  
• Volatility 3: установка через pip -
  
  Код:

  pip3 install volatility3

  (после чего доступна команда
  
  Код:

  vol

  ), либо из GitHub -
  
  Код:

  git clone https://github.com/volatilityfoundation/volatility3.git

  , затем
  
  Код:

  pip3 install -r requirements.txt

  и запуск
  
  Код:

  python3 vol.py

  из корня репозитория. После pip-установки используется
  
  Код:

  vol -f dump.raw windows.

  , а
  
  Код:

  python3 vol.py

  - только при запуске из клонированного репозитория
  
• Символы: при первом запуске Volatility 3 сама стягивает ISF-таблицы символов для Windows; для offline-режима можно скачать их заранее из репозитория volatility3
  
• YARA: установленный
  
  Код:

  yara-python

  для сканирования сигнатурами - подробнее в разделе про автоматизацию

Дамп снимается до анализа и до перезагрузки хоста (перезагрузили - потеряли всё):

• Windows: WinPmem - для legacy-версии (winpmem_mini_x64_rc2.exe) запуск
  
  Код:

  winpmem_mini_x64_rc2.exe output.raw

  создаёт дамп в формате raw; для современной ветки (v4+, Velocidex) -
  
  Код:

  winpmem.exe output.raw

  (raw по умолчанию), иначе формат указывается явно через флаги
  
• Linux: LiME - модуль собирается под ядро целевой системы (
  
  Код:

  cd LiME/src && make

  ), затем загружается:
  
  Код:

  insmod lime.ko "path=/tmp/dump.lime format=lime"

  . Использовать .ko с другого хоста нельзя - модуль привязан к kernel version magic, и ядро просто откажется его грузить
  
• Виртуальные машины: VMware - файл
  
  Код:

  .vmem

  лежит рядом с
  
  Код:

  .vmx

  ; VirtualBox -
  
  Код:

  VBoxManage debugvm  dumpvmcore --filename=dump.elf

  (ELF-core, Volatility 3 его понимает); файл
  
  Код:

  .sav

  доступен только после Save State; Hyper-V - checkpoint-файл

Контрольная сумма дампа фиксируется сразу:
. Это не формальность - это chain of custody, без которой ваш отчёт не примут ни в суде, ни на review у заказчика.
Volatility 3 vs Volatility 2: что важно знать
Ключевое отличие от двойки, которое путает всех, кто учился по старым руководствам: в тройке нет
. Вместо предопределённых профилей (
и подобных) используются символьные таблицы в формате ISF (Intermediate Symbol Format) - они автоматически скачиваются из репозитория символов при первом запуске. Для редких или кастомных билдов таблицу можно сгенерировать из PDB-файла Microsoft через
. На практике это означает:

• Не нужно угадывать точный билд Windows - фреймворк определяет его сам
  
• Минорные билды поддерживаются автоматически через ISF-символы, без обновления Volatility (хотя для новых мажорных версий ОС обновление фреймворка всё же может потребоваться)
  
• Синтаксис унифицирован:
  
  Код:

  vol -f dump.raw windows.

  (pip-установка) или
  
  Код:

  python3 vol.py -f dump.raw windows.

  (из репозитория)

Volatility 2 всё ещё полезна - у неё огромный зоопарк community-плагинов. Но для новых расследований рабочий инструмент - третья версия. Все команды в этой статье даны в синтаксисе Volatility 3.
Поиск скрытых процессов Windows: три плагина вместо одного
Обнаружение вредоносного ПО в памяти начинается с перечисления процессов. В Volatility 3 анализ памяти по процессам обеспечивают три плагина, и каждый смотрит на данные принципиально по-разному. Использовать только один - значит гарантированно пропустить скрытые процессы.
Как pslist, pstree и psscan смотрят на данные

обходит двусвязный список
в структуре
. Это тот же список, который показывает Windows Task Manager. Если руткит отвязал процесс от списка через Direct Kernel Object Manipulation (DKOM) - технику, характерную для Rootkit (T1014) - pslist его не увидит. Просто не увидит, и всё.



берёт данные из того же связного списка, но рисует иерархию parent-child. Вот тут-то и начинается самое интересное.
, порождённый из
- сигнал о выполнении команд через Windows Command Shell (T1059.003), характерный для макросов и эксплойтов в документах. А
без родительского
- сигнал маскировки под системный процесс (T1036.005) или Process Injection (T1055).

работает иначе - сканирует физическую память по pool-тегу
с последующей валидацией полей
(DTB, PCB.Header). В Windows 10/11 метод по-прежнему работает, хотя его надёжность снижена из-за изменений в kernel pool allocator (segment heap, dynamic lookaside lists) - поэтому psscan дополнительно валидирует поля структуры. Этот плагин находит:

• Процессы, скрытые DKOM-руткитами - отвязанные от ActiveProcessLinks, но физически существующие в пуле
  
• Завершённые процессы, чья память ещё не переиспользована ядром
  
• Процессы из других сессий, которые pslist мог не показать

Правило корреляции при DFIR анализе памяти: если
показывает процесс, которого нет в
- это либо скрытый процесс (копать немедленно), либо завершённый (проверить ExitTime). Отсутствие ExitTime у процесса, которого нет в pslist - серьёзный красный флаг. Я при таком раскладе сразу переключаюсь на
и
для этого PID, не тратя время на
остальные.



Красные флаги в дереве процессов Windows
При поиске малвари в памяти через дерево процессов смотрите на несколько категорий аномалий.

Нарушение стандартной иерархии Windows. У каждого системного процесса есть каноническое расположение и родитель.
всегда запускается из
и живёт в
. Если
порождён из
или запущен из
- это не svchost, а малварь в красивом фантике. Как отмечает Varonis в своём руководстве по Volatility, атакующие часто именуют вредоносные процессы именами легитимных Windows-сервисов, чтобы визуально затеряться в pstree.

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

Подозрительные имена. Случайные строки, имена с опечатками (
,
), процессы из нетипичных директорий. На одном расследовании я видел
из
- в pstree он выглядел почти нормально, но путь выдал его с потрохами.
Вопрос к читателям
Коллеги, кто работал с дампами, где
показывал процессы, отсутствующие в
- как вы верифицировали DKOM-сокрытие (T1014) и отделяли его от артефактов завершённых процессов? Конкретно: проверяли ли вы поле
в
напрямую через
(
) или шли через
сразу? И второй момент - при обнаружении
с нестандартным PPID (не
) вы сначала запускаете
или
для проверки загруженных модулей? Интересует порядок действий и конкретные флаги, которые вы используете в своём workflow при Volatility 3.