Применение Volatility 3 для форензики памяти и извлечения артефактов.

Статья подготовлена специально для форума LIMB.cc и отражает личное мнение автора. Информация может устареть, поэтому не является призывом к действию или гарантией результата. Ответственность за конечные решения лежит на читателе.

Вступление: Цифровая археология оперативной памяти​

Представьте последствия успешной кибератаки. Сервер компании подвергся компрометации. Злоумышленник, используя цепочку уязвимостей, получил права администратора, отключил системы мониторинга, похитил базу данных клиентов и скрыл свои следы, очистив логи. Казалось бы, расследование зашло в тупик — на диске не осталось улик. Но есть один носитель информации, который хранит мгновенный снимок всей активности системы в момент атаки — оперативная память (RAM).

В отличие от данных на диске, которые могут быть зашифрованы или удалены, информация в памяти — это незаменимый хранитель артефактов в их "живом", незашифрованном виде: пароли в открытом тексте, запущенные процессы (включая те, что никогда не касались диска, как бесфайловые малвари(Fileless Malware)), установленные сетевые соединения, открытые документы и ключи шифрования.

И на протяжении многих лет у каждого специалиста по инцидентам в арсенале был один главный инструмент для этой работы — Volatility Framework. Его вторая версия стала легендой, учебником по внутреннему устройству операционных систем. Но прогресс не стоит на месте. Устаревшая архитектура, сложность поддержки новых ОС и необходимость вручную подбирать "профили" для каждого дампа памяти начали тормозить расследования.

И вот выходит Volatility 3 — не просто обновление, а фундаментальный пересмотр всего инструмента. Он стал более быстрый, умный и универсальный, создан специально для реалий современной кибербезопасности. В этой статье мы не просто рассмотрим его новые функции — мы проведем практическое расследование, шаг за шагом извлекая артефакты из дампа памяти, чтобы показать, почему Volatility 3 стал новым стандартом для цифровых криминалистов.

Часть 1: Почему Volatility 3 — это не просто «апдейт», а смена парадигмы в расследованиях​

Знакомо ощущение, когда берешь в руки новый инструмент, и он ложится в руку так, будто был ее продолжением? Со мной такое случилось на втором часу работы с Volatility 3. Но чтобы вы поняли масштаб изменений, придется начать с небольшого лирического отступления.

Большие данные — большие проблемы

Помните свой первый дамп памяти? Я лично нет, но как однажды я расследовал кейс, где был дамп размером 4 ГБ. И знаете за сколько времени справился Volatility 2?? Полчаса. Для наших реалий это очень долгий результат, учитывая что при крупных инцидентах дамп может составлять более 100 ГБ

Некоторое время назад на одном из расследований мой знакомый столкнулся с дилеммой: у него был дамп на 84 ГБ с Windows Server 2019, и Volatility 2 с его вечными проблемами с профилями обрабатывал его шесть часов. Шесть часов! Пока ты ждешь, злоумышленник уже давно сменил тактику и ушел в другую систему.

Что не так со «старым добрым» Volatility 2?

Не поймите меня неправильно — Volatility 2 был и остается легендой. Но легендой, которая плохо масштабируется в современных реалиях.

• Профили. Боже, эти вечные поиски нужного профиля! Для Windows 10 21H2 нужно было точно знать сборку ОС, иначе — прощай, анализ. На одном из прошлых инцидентов мы потратили три часа только на то, чтобы найти правильный профиль для специализированной сборки Windows.
• Скорость. Плагины pslist или psscan на больших дампах могли работать десятки минут. А когда ты расследуешь инцидент, каждая минута дорога.
• Архитектура. Попробуйте написать кастомный плагин для Volatility 2. Это требует глубокого понимания внутренней архитектуры фреймворка. На создание простого плагина для парсинга кэша DNS у меня ушло два дня.

Volatility 3: первое впечатление​

Мой переход на Volatility 3 начался с разочарования. Я установил его через pip, взял тот самый 84-гигабайтный дамп полученного от знакомого и... привычно полез в документацию искать профиль.

Оказалось, что его нет.

«Нет, — подумал я, — просто я что-то не так делаю». Потратил полчаса на поиски, пока не наткнулся на примечание в документации: «Volatility 3 не требует внешних профилей для большинства операционных систем».

Я был настроен скептически. До сих пор помню, как запустил первую команду:

vol -f memory.dmp windows.info

И через 12 секунд получил полную информацию о системе: версия ОС, сборка, архитектура, время дампа — все, что нужно. Без профилей. Без танцев с бубном.

Архитектурные изменения, которые меняют всё

Покопавшись в документации и пообщавшись с разработчиками, я понял, в чем фундаментальное отличие.

Volatility 2 работал по принципу «внешнего словаря» — профиль рассказывал фреймворку, где что лежит в памяти. Volatility 3 использует интегрированную схему — он сам знает структуры данных современных ОС и сам находит нужные ему структуры.

Представьте, что раньше вам нужно было иметь отдельную карту для каждого города, а теперь у вас есть навигатор, который сам строит маршрут.

Но не всё так безоблачно

В процессе тестирования я наткнулся и на недостатки. Некоторые плагины из Volatility 2 пока не портированы. Сообщество только набирает обороты. Документация иногда отстает от возможностей фреймворка.

Однако главное преимущество перевешивает все недостатки: Volatility 3 создан для современных реалий. Для больших дампов, сложных инцидентов и быстрого реагирования.

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

Часть 2: Подготовка полигона​

Для практикума мы возьмем лабу со всеми известного CyberDefenders под названием BlackEnergy Lab.

Начнем с подготовки и установки всего что нам требуется, а именно: виртуальная машина(ОС роли не имеет, я работаю на винде в данный момент), Volatility 3, ну и хорошее настроение. Так выглядит установленный архив у меня на винде:

Вложение 4928 недоступно

Установка Volatility 3 для линуксойдов​

Сразу предупрежу: НЕ используйте pip install volatility3 как единственный способ. Это приведет к тому, что у вас будет установлена библиотека, но не будет скачан сама кодовая база с плагинами и символами — то есть, работать ничего не будет. Мы пойдем другим путем.
Способ 1: Основной
Этот способ гарантирует, что вы получите полную, актуальную версию фреймворка и сможете легко обновлять ее.

1. Клонируем репозиторий

Первым делом — идем на официальный GitHub проекта. Открываем терминал и выполняем:

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

• Важный момент: Обратите внимание на URL. Это официальный репозиторий Volatility Foundation, а не форк. Это гарантия получения чистого и актуального кода.

2. Переходим в директорию и устанавливаем зависимости

cd volatility3<br>pip3 install -r requirements.txt

• Что происходит? Мы устанавливаем все необходимые для работы Python-библиотеки, от которых зависит фреймворк. Это ключевой шаг, который многие пропускают, а потом сталкиваются с непонятными ошибками.

3. Проверяем установку

Самое время убедиться, что всё работает. Запустим фреймворк без аргументов:

python3 vol.py -h
Если вы увидели красивый ASCII-арт и длинный список доступных плагинов и опций — поздравляю, основа готова к работе.

Способ 2:Установка через pip
Да, я только что сказал его не использовать. Но если вам критически важна установка в систему, а не работа из директории, то делаем так:

pip3 install volatility3
А затем все равно клонируем репозиторий для получения полной кодобазы:

git clone https://github.com/volatilityfoundation/volatility3.git
cd volatility3
И уже оттуда запускаем vol.py, как в первом способе. Зачем тогда pip install? Это установит скрипт vol в вашу систему, но, по моим наблюдениям, этот путь менее надежен.

Установка Volatility 3 для виндусойдов:​

Главный принцип на Windows: избегайте путей с пробелами и кириллицей. Идеальный путь: C:\Tools\volatility3\.​

Установка Python 3 — Фундамент​

1. Качаем установщик: Идем на python.org, качаем последний Python 3.x (например, 3.11). Не берите версию 3.12, пока она не объявлена полностью совместимой.
2. Запускаем установщик — ВНИМАНИЕ НА ГАЛОЧКИ! Это самый важный момент.

• ВНИЗУ СТРАНИЦЫ: Галочка "Add python.exe to PATH" должна быть ВКЛЮЧЕНА. Это позволит запускать Python из командной строки.
• Сразу после этого: Нажимаем "Customize installation".
• На следующем экране галочка "Install for all users" тоже лишней не будет.

Завершаем установку.

Проверка: Открываем Командную строку (cmd) или PowerShell и пишем:

python --version
В ответ должны увидеть версию Python. Если команда не найдена — перезагрузите компьютер.

Хотя можно скачать архив ZIP, Git даст вам простой способ обновляться.

1. Качаем с git-scm.com.
2. Запускаем установщик. Можно смело жать "Next", соглашаясь с настройками по умолчанию.
3. Открываем PowerShell от имени администратора. (Правый клик на кнопке "Пуск" -> "Windows PowerShell (администратор)").
4. Клонируем репозиторий. Я рекомендую папку C:\Tools\powershellcd C:\ mkdir Tools cd Tools git clone https://github.com/volatilityfoundation/volatility3.git
5. Переходим в директорию и устанавливаем зависимости: powershellcd volatility3 pip install -r requirements.txt теперь должен работать, так как мы добавили Python в PATH.

Первый запуск и создание батч-файла для удобства​

Вот тут — ключевая магия для комфортной работы на Windows.

1. Проверяем, что всё работает: powershellpython vol.py -h (должна появиться справка)
2. Создаем батч-файл для упрощения жизни. Открываем Блокнот, копируем туда следующий код и сохраняем как vol.bat в папку C:\Tools\volatility3\:batch@echo off python "C:\Tools\volatility3\vol.py" %*
3. Добавляем папку в системный PATH.

• Откройте "Параметры Windows" -> "Система" -> "О программе" -> "Дополнительные параметры системы".
• Нажмите кнопку "Переменные среды...".
• В разделе "Системные переменные" найдите переменную Path, выделите ее и нажмите "Изменить...".
• Нажмите "Создать" и добавьте путь: C:\Tools\volatility3\.
• Нажмите "ОК" во всех окнах.

Что это дало? Теперь вы можете открыть любую командную строку или PowerShell из любого места, просто написать vol и это будет равносильно вызову python C:\Tools\volatility3\vol.py.

Проверка удобства: Закройте все терминалы, откройте новый и напишите:

vol -h
Вы должны увидеть ту же справку по Volatility 3. Поздравляю, Мы разобрались с установкой инструмента!

Часть 3: Первый контакт: Практическая разведка в памяти с помощью Volatility 3​

Если предыдущие части были про философию и настройку, то сейчас мы переходим к самой сути нашей работы — к расследованию. Забудьте про сухую теорию. Сейчас мы будем работать с памятью так, как это делает форензик в условиях реального инцидента: быстро, целенаправленно, выстраивая гипотезы и проверяя их.

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

1. Системная разведка: Кто ты? Какая ОС? Когда тебя "сняли"?
2. Процессный ландшафт: Что было запущено? Кто кого породил? Есть ли аномалии?
3. Сетевая активность: С кем общался компьютер? Были ли подозрительные соединения?
4. Форензика одного процесса: Если мы нашли подозрительный процесс — погружаемся в него с головой, извлекая всё: команды, DLL, скрытые нити.

В этой стратегии идеально все. Каждый следующий шаг диктуется результатами предыдущего. Volatility 3 в этом плане — идеальный партнер: он не заставляет вас бороться с его внутренней механикой, а позволяет все ресурсы направить на анализ улик.


Готовы? Убедитесь, что ваш Volatility 3 запускается командой vol, а путь к дампу
памяти не содержит кириллицы. У меня он лежит по пути C:\Users\111\Documents\Статьи\Применение Volatility 3 для форензики памяти и извлечения артефактов\volatility3-2.26.2>. У вас может быть другим.

Включайте аналитическое мышление. Поехали.

Сценарий

Многонациональная корпорация подверглась кибератаке, в результате которой были похищены конфиденциальные данные. В ходе атаки использовался ранее неизвестный вариант вредоносной программы BlackEnergy v2. Служба безопасности компании получила дамп памяти с заражённого компьютера и обратилась к вам как к аналитику SOC с просьбой проанализировать дамп, чтобы оценить масштаб и последствия атаки.

Введем команду python vol.py -h и посмотрим что нам интересного предлагает инструмент

Не удалось прогрузить медиа

Суть Volatility 3 в куче плагинов
Также посмотрим сколько весит наш подопытный:

Не удалось прогрузить медиа

Начнем же решение

Вопрос 1. Какой профиль Volatility лучше всего подходит для этой машины?​

Первым делом является определение профиля. Что же это такое? Профиль в Volatility 3 — это набор символов отладочной информации (PDB-файлов) ядра операционной системы, содержащий точные описания структур данных, их смещений в памяти и типов, необходимых для корректной интерпретации сырого дампа оперативной памяти.

Для чего нужен профиль? Операционная система (например, Windows) — это сложная структура, управляющая процессами, драйверами, сетевыми соединениями и т.д. Вся эта информация хранится в памяти в виде структур на языке C (например, _EPROCESS, _ETHREAD). Расположение и layout этих структур меняются от одной версии ОС к другой (Windows 10 vs Windows 11) и даже между сборками (Windows 10 1909 vs Windows 10 21H2).

Когда Volatility 3 хочет, например, найти список процессов, ей нужно:

1. Найти символ PsActiveProcessHead.
2. Знать структуру _EPROCESS, чтобы из этого списка извлечь имена процессов, их PID и т.д.

Профиль предоставляет эту информацию.

Для того, чтобы попытаться определить профиль мы будем использовать плагин windows.info . Он анализирует набор метаданных и нужен для анализа дампа памяти и определения потенциального профиля. Введем команду для использования этого плагина

python vol.py -f dump1.raw windows.info

Вот что нам выдает инструмент:

Не удалось прогрузить медиа

Без рюмки тут не разобраться
Итак, давайте установим профиль, используя данные которые нам выдал сия инструмент. Первое, что можно здесь обнаружить, так это строки:

Major/Minor       15.2600
NtMajorVersion  5
NtMinorVersion 1
Что же это значит, разберем подробнее:

• Windows 5.1 = Windows XP
• Build 2600 = оригинальная сборка XP

Следовательно мы уже можем установить, что ОС - Windows XP. Можно также установить разрядность операционки. Взглянем на строчки:

Is64Bit False
IsPAE   False
MachineType     332
CSDVersion      3
Это означает, что:

• 332 = i386 (32-битная архитектура)
• No PAE = физическое расширение адресов отключено
• CSDVersion 3 = Service Pack 3

Итого получаем: Windows XP Professional SP3. Ответ: WinXPSP3x86

Важно!!!!

Для конкретного дампа этот ответ является верным, но так как таск очень старый и делали его при помощи Volatility 2, правильным ответом является WinXPSP2x86. Далее таких помарок я делать не буду. Я считаю, что решил таск верно, не смотря на такие казусы

Вопрос 2. Сколько процессов выполнялось в момент получения изображения?​

Чтобы определить количество процессов, воспользуемся плагином windows.pslist

python vol.py -f dump1.raw windows.pslist

Вот, что мы получаем:

Не удалось прогрузить медиа

Самые внимательные уже заметили rootkit.exe
Здесь мы видим все процесс на момент снятия дампа. Всего процессов 24, но мы посмотрели не все процессы. Для более полного списка используем psscan.Вводим:

python vol.py -f dump1.raw windows.psscan

На выходе получаем

Не удалось прогрузить медиа

Из этого обилия нас интересуют процессы с пустой меткой времени или меткой времени выхода по умолчанию(N/A или 0000-00-00 00:00:00 UTC+0000). Сделав легкий подсчет находим 19 процессов. Следовательно, наш ответ: 19

Вопрос 3. Каков идентификатор процесса cmd.exe?​

Идентификатор процесса (PID) — системный примитив для управления исполняемыми объектами

Каждому процессу в операционной системе назначается целочисленный идентификатор (PID), выступающий первичным ключом в таблице процессов ядра. Через этот дескриптор система осуществляет диспетчеризацию ресурсов, контроль прав доступа и организацию межпроцессного взаимодействия.

Форензическая значимость PID

При анализе дампа памяти PID становится ключевым элементом реконструкции событий. С помощью Volatility 3 исследователь устанавливает родительско-дочерние связи между процессами, выявляет аномалии в последовательности распределения идентификаторов и коррелирует разрозненные артефакты активности.

Особенности практического анализа

Динамическая природа PID требует учета временного контекста — освобожденные идентификаторы могут быть переиспользованы, что осложняет трекинг кратковременных процессов. В Windows окружении системные процессы, такие как System с PID 4, служат отправными точками для построения процессного дерева.

Современные методы сокрытия вредоносной активности, включая подмену и переиспользование PID, делают этот артефакт одновременно ценным и сложным для интерпретации. Команды Volatility 3, такие как windows.psscan, используют низкоуровневые методы перечисления процессов, позволяя выявлять скрытые и завершенные процессы, невидимые стандартными методами перечисления.

Я воспользуюсь прошлой командой

python vol.py -f dump1.raw windows.psscan

Не удалось прогрузить медиа

PID написан слева, а PPID справа
Ответ: 1960

Вопрос 4. Как называется самый подозрительный процесс?​

Вот мы и подошли к самому веселому. Среди всех процессов мы должны предположить какой из процессов скорее всего является вредоносным. Тут никаких новых модулей мы не используем, также работаем с процессами. Тут скрин я не буду прилагать, ибо процесс итак видно. Используем psscan:

python vol.py -f dump1.raw windows.psscan

Видим процесс rootkit.exe. Он и является нашим ответом.

Вопрос 5. В каком процессе наиболее вероятен риск внедрения кода?​

Для решение этого вопроса нам понадобится плагин windows.malfind — это специализированный модуль Volatility 3 для обнаружения внедренного и скрытого кода в процессах Windows.

Принцип работы основан на анализе регионов памяти процессов с аномальными характеристиками. Плагин сканирует Virtual Address Descriptors (VAD) каждого процесса и ищет участки памяти с противоречивыми атрибутами защиты. Типичный признак вредоносного кода — область памяти с правами на выполнение (PAGE_EXECUTE_READWRITE), что нехарактерно для легитимных процессов.

Ключевые возможности включают обнаружение различных техник внедрения: инжект библиотек, shellcode, руткитов и полиморфного кода. Плагин анализирует как пользовательские процессы, так и системные службы, выявляя аномалии в правах доступа и содержимом памяти.

Итак введем команду:

python vol.py -f dump1.raw windows.malfind

Получаем огромный список данных

Не удалось прогрузить медиа

Здесь нас интересует процесс который имеет права на выполнения PAGE_EXECUTE_READWRITE . Мы Находим процесс svchost.exe.

Не удалось прогрузить медиа

Здесь мы замечаем MZ сигнатуру. Она говорит нам о том что это исполняемый PE файл. Также здесь имеются искомые нами права на выполнение. Делаем вывод, что процесс svchost.exe (PID 880) демонстрирует классические признаки инжекта кода - исполняемый файл, загруженный в приватную память с правами на выполнение и модификацию.

Вы спросите, а почему это не winlogon.exe ?

616 winlogon.exe 0x62220000 0x62223fff VadS PAGE_EXECUTE_READWRITE 4 1 Disabled N/A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 2a 00 2a 00 01 00 00 00 00 00 00 00 .............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Все просто. Он хоть и имеет множественные регионы с PAGE_EXECUTE_READWRITE, но он не имеет MZ сигнатуры, что дает нам исключить его из "списка подозреваемых". Итого получаем, что ответом является svchost.exe.

Вопрос 6. В недавнем процессе упоминается странный файл. Укажите полный путь к этому файлу.​

Для начала здесь я использую windows.dumpfiles . Это позволит извлечь мне файлы из памяти для последующего анализа.

python vol.py -f dump1.raw windows.dumpfiles --pid 880

Как оказалось мне на практике при решении таска ничего это не дало и я зашел в тупик

Далее я использовал плагин windows.handles. Это позволит мне обнаружить список открытых дескрипторов объектов для каждого процесса. Плагин показывает какие ресурсы (файлы, ключи реестра, мьютексы) в данный момент используются процессами, включая полные пути к файлам и типы объектов. Это помогает идентифицировать подозрительную активность, такую как работа с файлами в временных директориях или доступ к системным ресурсам из нетипичных процессов. Используем команду

python vol.py -f dump1.raw windows.handles --pid 880

Не удалось прогрузить медиа

Получаем на выходе что-то подобное. Проанализировав это, обнаружим очень ехидный драйвер str.sys.

880     svchost.exe     0x89af0cf0     
0x340   File    0x12019f       
\Device\HarddiskVolume1\WINDOWS\system32\drivers\str.sys
Почему же все подозрения упали именно на него??? Все проще некуда. Во-первых, он имеет очень нестандартное имя и прогуглив мы получаем что это вредоносный драйвер бота BlackEnergy v2. Ответ: C:\WINDOWS\system32\drivers\str.sys

Вопрос 7. Как называется внедренный файл DLL, загруженный из последнего процесса?​

Для идентификации внедренного DLL-файла, загруженного в процесс, используется плагин ldrmodules - плагин для обнаружения скрытых и внедренных DLL-библиотек в процессах Windows. Вводим

python vol.py -f dump1.raw windows.ldrmodules --pid 880

Получаем небольшой списочек

Не удалось прогрузить медиа

Что же тут бросается в глаза???? При детальном анализе процесса svchost.exe обнаружена подозрительная активность. Библиотека msxml3r.dll, загруженная в процесс, ведет себя нетипично для легитимных системных компонентов.

Что же вызывает подозрения?

Библиотека демонстрирует аномальное поведение - все ключевые маркеры её инициализации (InLoad, InInit, InMem) отображаются как False. В нормальных условиях системные DLL всегда проходят полный цикл загрузки и регистрируются во внутренних структурах Windows.

С высокой вероятностью мы наблюдаем результат внедрения вредоносного кода, маскирующегося под системную библиотеку. Рекомендуется срочная проверка цифровой подписи и сравнение хэша с эталонными образцами. Такая картина часто встречается при атаках класса "живой в памяти" (fileless), когда злоумышленники избегают записи на диск.

Ответ: msxml3r.dll

Вопрос 8. Каков базовый адрес внедренной библиотеки DLL?​

На этот вопрос я ответ не напишу, чтобы вы сами пораскинули мозгами и сделали весь таск. Здесь нам поможет плагин, который мы использовали сегодня - malfind. Его вывод покажет регион памяти с подозрительными характеристиками

Часть 4: Вывод и завершение статьи​

С помощью этой статьи мы прокачали практические навыки в сфере форензики памяти. Volatility 3 доказал свою эффективность как инструмент для быстрого реагирования на инциденты — от автоматического определения ОС до выявления сложных техник сокрытия вредоносной активности. На решение самого кейса я потратил где-то около 50 минут, учитывая, что ловил тупняки, но сама задача показалась мне не очень сложной, хоть и средний уровень сложности.

Мы убедились, что современные атаки всё чаще используют методы работы исключительно в памяти, что делает анализ дампов незаменимым этапом расследования. Обнаружение инъекций в системные процессы, подобных случаю с msxml3r.dll, наглядно показывает: даже самые продвинутые угрозы оставляют следы в оперативной памяти.

Помните: каждый дамп памяти — это уникальный снимок системы в момент времени, где можно найти не только следы атаки, но и инструменты, TTP злоумышленников и ценные артефакты. Дальнейший путь развития — углубление в автоматизацию анализа и изучение специфичных кейсов для Linux и macOS.

Надеюсь вам понравилась моя статья и тема форензики. Если хотите видеть продолжение подобных статей по этому чудному инструменту, форензике и антифорензике, то дайте знать. Благодарю за внимание и удачи вам в расследовании.