Статья Анализ дампов памяти Volatility 3: практический workflow обнаружения малвари и инъекций

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

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

Аудитория - пентестеры и security-инженеры, которые знают, что такое _EPROCESS, но хотят отточить практику работы с 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.<plugin>, а 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 <vmname> dumpvmcore --filename=dump.elf (ELF-core, Volatility 3 его понимает); файл .sav доступен только после Save State; Hyper-V - checkpoint-файл

Контрольная сумма дампа фиксируется сразу: sha256sum output.raw > output.raw.sha256. Это не формальность - это chain of custody, без которой ваш отчёт не примут ни в суде, ни на review у заказчика.

Volatility 3 vs Volatility 2: что важно знать​

Ключевое отличие от двойки, которое путает всех, кто учился по старым руководствам: в тройке нет --profile. Вместо предопределённых профилей (Win10x64_18362 и подобных) используются символьные таблицы в формате ISF (Intermediate Symbol Format) - они автоматически скачиваются из репозитория символов при первом запуске. Для редких или кастомных билдов таблицу можно сгенерировать из PDB-файла Microsoft через python3 -m volatility3.framework.symbols.windows.pdbconv. На практике это означает:

• Не нужно угадывать точный билд Windows - фреймворк определяет его сам
• Минорные билды поддерживаются автоматически через ISF-символы, без обновления Volatility (хотя для новых мажорных версий ОС обновление фреймворка всё же может потребоваться)
• Синтаксис унифицирован: vol -f dump.raw windows.<plugin> (pip-установка) или python3 vol.py -f dump.raw windows.<plugin> (из репозитория)

Volatility 2 всё ещё полезна - у неё огромный зоопарк community-плагинов. Но для новых расследований рабочий инструмент - третья версия. Все команды в этой статье даны в синтаксисе Volatility 3.

Поиск скрытых процессов Windows: три плагина вместо одного​

Обнаружение вредоносного ПО в памяти начинается с перечисления процессов. В Volatility 3 анализ памяти по процессам обеспечивают три плагина, и каждый смотрит на данные принципиально по-разному. Использовать только один - значит гарантированно пропустить скрытые процессы.

Как pslist, pstree и psscan смотрят на данные​

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

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

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

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

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

Красные флаги в дереве процессов Windows​

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

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

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

Подозрительные имена. Случайные строки, имена с опечатками (svch0st.exe, lssas.exe), процессы из нетипичных директорий. На одном расследовании я видел svchost.exe из C:\ProgramData\ - в pstree он выглядел почти нормально, но путь выдал его с потрохами.

Вопрос к читателям​

Коллеги, кто работал с дампами, где windows.psscan показывал процессы, отсутствующие в windows.pslist - как вы верифицировали DKOM-сокрытие (T1014) и отделяли его от артефактов завершённых процессов? Конкретно: проверяли ли вы поле ExitTime в _EPROCESS напрямую через windows.volshell (dt("_EPROCESS", offset)) или шли через windows.cmdline --pid <PID> сразу? И второй момент - при обнаружении svchost.exe с нестандартным PPID (не services.exe) вы сначала запускаете windows.malfind --pid <PID> или windows.dlllist --pid <PID> для проверки загруженных модулей? Интересует порядок действий и конкретные флаги, которые вы используете в своём workflow при Volatility 3.