Sergei webware
24.04.2026, 12:25
https://forum.antichat.xyz/attachments/4951773/img_b4ba83e133.png
За последний год через мою лабораторию прошло больше двадцати дампов с инцидентов, где вредоносная программа жила исключительно в оперативке - ни одного файла на диске. Fileless-атаки, reflective DLL injection, Cobalt Strike beacon в RWX-регионе легитимного svchost.exe - для классической дисковой форензики всё это невидимо. Единственный способ вытащить такие артефакты - анализ дампов памяти Volatility 3 (https://forum.antichat.xyz/threads/592659/).
Русскоязычные руководства по 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-регионы в чужом адресном пространстве
Скрытые процессы (https://forum.antichat.xyz/threads/592623/) - 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-файл
Контрольная сумма дампа фиксируется сразу:
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.
(pip-установка) или
python3 vol.py -f dump.raw windows.
(из репозитория)
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 его не увидит. Просто не увидит, и всё.
https://forum.antichat.xyz/attachments/4951773/1777015623063.png
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-руткитами (https://forum.antichat.xyz/threads/592639/) - отвязанные от ActiveProcessLinks, но физически существующие в пуле
Завершённые процессы, чья память ещё не переиспользована ядром
Процессы из других сессий, которые pslist мог не показать
Правило корреляции при DFIR анализе памяти: если
windows.psscan
показывает процесс, которого нет в
windows.pslist
- это либо скрытый процесс (копать немедленно), либо завершённый (проверить ExitTime). Отсутствие ExitTime у процесса, которого нет в pslist - серьёзный красный флаг. Я при таком раскладе сразу переключаюсь на
windows.cmdline
и
windows.malfind
для этого PID, не тратя время на
остальные.
https://forum.antichat.xyz/attachments/4951773/1777015593168.png
Красные флаги в дереве процессов 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
сразу? И второй момент - при обнаружении
svchost.exe
с нестандартным PPID (не
services.exe
) вы сначала запускаете
windows.malfind --pid
или
windows.dlllist --pid
для проверки загруженных модулей? Интересует порядок действий и конкретные флаги, которые вы используете в своём workflow при Volatility 3.
За последний год через мою лабораторию прошло больше двадцати дампов с инцидентов, где вредоносная программа жила исключительно в оперативке - ни одного файла на диске. Fileless-атаки, reflective DLL injection, Cobalt Strike beacon в RWX-регионе легитимного svchost.exe - для классической дисковой форензики всё это невидимо. Единственный способ вытащить такие артефакты - анализ дампов памяти Volatility 3 (https://forum.antichat.xyz/threads/592659/).
Русскоязычные руководства по 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-регионы в чужом адресном пространстве
Скрытые процессы (https://forum.antichat.xyz/threads/592623/) - 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-файл
Контрольная сумма дампа фиксируется сразу:
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.
(pip-установка) или
python3 vol.py -f dump.raw windows.
(из репозитория)
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 его не увидит. Просто не увидит, и всё.
https://forum.antichat.xyz/attachments/4951773/1777015623063.png
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-руткитами (https://forum.antichat.xyz/threads/592639/) - отвязанные от ActiveProcessLinks, но физически существующие в пуле
Завершённые процессы, чья память ещё не переиспользована ядром
Процессы из других сессий, которые pslist мог не показать
Правило корреляции при DFIR анализе памяти: если
windows.psscan
показывает процесс, которого нет в
windows.pslist
- это либо скрытый процесс (копать немедленно), либо завершённый (проверить ExitTime). Отсутствие ExitTime у процесса, которого нет в pslist - серьёзный красный флаг. Я при таком раскладе сразу переключаюсь на
windows.cmdline
и
windows.malfind
для этого PID, не тратя время на
остальные.
https://forum.antichat.xyz/attachments/4951773/1777015593168.png
Красные флаги в дереве процессов 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
сразу? И второй момент - при обнаружении
svchost.exe
с нестандартным PPID (не
services.exe
) вы сначала запускаете
windows.malfind --pid
или
windows.dlllist --pid
для проверки загруженных модулей? Интересует порядок действий и конкретные флаги, которые вы используете в своём workflow при Volatility 3.