Разбор Memory Forensics с OtterCTF и знакомство с фреймворком Volatility
Недавно закончился OtterCTF (для интересующихся — ссылка на ctftime), который в этом году меня, как человека, достаточно плотно связанного с железом откровенно порадовал — была отдельная категория Memory Forensics, которая, по сути, представляла из себя анализ дампа оперативной памяти. Именно ее я хочу разобрать в этом посте, всем кому интересно — добро пожаловать под кат.
Введение
Возможно, на Хабре уже были статьи, описывающие работу с Volatility, но, к сожалению, я их не нашел. Если не прав — киньте в меня ссылкой в комментариях. Эта статья преследует две цели — показать, насколько бессмысленны все попытки администратора защитить систему, в случае если у атакующего есть дамп оперативной памяти и познакомить читателей с самым прекрасным, на мой взгляд, инструментом. Ну и, конечно же, обменяться опытом. Достаточно воды, приступим!
Знакомство с инструментом
Volatility — open-sorce фреймворк, который развивается сообществом. Написан на втором питоне и работает с модульной архитектурой — есть т.н. плагины, которые можно подключать для анализа и даже можно писать самому недостающие. Полный список плагинов, которые доступны из коробки можно посмотреть с помощью volatility -h .
Из-за питона инструмент кроссплатформенный, поэтому проблем с запуском под какой-то популярной ОС, на которой есть питон возникнуть не должно. Фреймворк поддерживает огромное количество профилей (в понимании Volatility — системы, с которых был снят дамп): от популярных Windows-Linux-MacOs до «напрямую» списанных dd-дампов и дампов виртуальных машин (как QEMU, так и VirtualBox). По-моему, очень неплохой наборчик.
Как бонус — поддержка почти любого адресного пространства, которое можно себе вообразить.
Кажется, пиара получилось чуть больше, чем планировалось изначально. Давайте попробуем заняться самим анализом.
Базовая информация и поверхностный анализ
Для тех, кто хочет проделывать все манипуляции по ходу статьи — ссылка на Mega с образом или можно с помощью wget:
Итак, образ у нас в руках, можно начинать анализ. Для начала, нужно понять, с какой системы снимали дамп. Для этого у волатилити есть прекрасный плагин imageinfo . Просто запускаем
В нашем случае выхлоп будет примерно следующим:
Итак, мы получили почти исчерпывающую информацию о нашем дампе — предположительно, с какой ОС он был сделан (отсортировано в порядке вероятности), локальную дату и время на момент снятия дампа, адресацию и еще много чего. Итак, мы поняли, что перед нами дамп Windows 7 Service Pack 1 x64. Можно копать вглубь!
What’s the password
Для начала, поймем, какие пользователи были в системе и, заодно, попробуем достать их пароли. Сами пароли достать сложнее, а поэтому понадеемся на то, что нам попался не очень умный человек и получится вскрыть хеш от его пароля. Остается достать его! Для этого попробуем посмотреть _CMHIVE — как правило, там всегда можно найти что-то интересное во время работы Windows. Для этого просто подключим плагин hivelist , при этом указав Win7 в профиле:
Прекрасно! Мы, предположительно, получили имя пользователя и, заодно, убедились, что нужные нам SYSTEM и SAM уже подгружены в память. Теперь просто достаем хеши и идем перебирать:
По итогу, у нас есть три пользователя — Administrator(31d6cfe0d16ae931b73c59d7e0c089c0) , Guest(31d6cfe0d16ae931b73c59d7e0c089c0) и наш Rick(518172d012f97d3a8fcc089615283940) . Хеши Windows 7 это NTLM и перебирать их реально долго. Могу сказать, что я у себя занимался этим почти сутки на игровой видеокарте и так и не пришел ни к чему. Поэтому можно пойти более простым путем и попробовать пробиться с помощью mimikatz . Не всегда панацея и не всегда работает, но, зато, если работает, то выдает результат всегда. Тут пригождается та самая универсальность volatility — есть пользовательский плагин mimikatz. Скачиваем в любую удобную папку и далее при запуске указываем путь к этой папке:
И сразу же получаем пароль пользователя:
General Info
Теперь, когда мы знаем, кто мы, надо бы понять, где мы. То есть хорошо бы узнать наш IP-адрес и имя машины. В случае с IP-адресом все просто — смотрим на список подключений на момент дампа с помощью netscan :
IP 192.168.202.131 найден. Конечно, это IP в локальной сети, но, к сожалению, из дампа больше не вытащишь — для того, чтобы достать внешний IP нужно побольше, чем просто дамп. Теперь достанем имя компа. Для этого просто прочитаем ветку SYSTEM реестра:
Супер, мы получили имя компа WIN-LO6FAF3DTFE .
Play Time
Просто смотрим на выхлоп netscan на предыдущем шаге и видим странные процесссы — LunarMS.exe . Гуглим — действительно, это видеоигра. Там же можно и найти IP-адрес, с которым открыто соединение — 77.102.199.102
Name game
Так как пользователь залогинен в этот канал, то имя должно быть просто в виде plain-text в дампе. Делаем strings и получаем флаг:
Из всех строк больше всего напоминает флаг 0tt3r8r33z3 . Пробуем и действительно — это он и есть!
Silly Rick
Судя по формулировке надо просто достать содержимое буфера обмена. На это у Volatility есть ответ — плагин clipboard . Проверяем и видим пароль:
Hide and Seek
Ну что же, если у нас три попытки, то будем осторожны, как нам и посоветовали =)
Для начала, получим список всех процессов с помощью pslist :
Мда. Как-то не очень удобно анализируемо. У нас есть еще один плагин — pstree , который выводит процессы в виде дерева (что, в общем-то, логично):
Ага! Есть подозрительные строчки
Как мы видим, процесс с PID’ом 3820 порождает процесс с PID’ом 3720. Повод проанализировать обоих. Для начала получим список dll-библиотек, которые используют процессы:
Так. Exe в папке с торрентами? Как-то странно. Еще и ntdll.dll тоже не внушает доверия. Попробуем получить список dll, которые использует процесс 3720:
Вау. А вот это совсем ненормально. Значит, первое предположение, что это именно тот троянчик, который мы ищем. Сдампим процесс с помощью memdump и проанализируем его любым декомпилятором:
Процесс анализа дампов уже не раз описан и на хабре, и в других источниках, поэтому я не буду повторяться, тем более, что этот вымогатель написан на .NET, так что не представляет сложности для анализа. Если все же будет нужно — пишите в комментариях, добавлю эту часть. Сейчас же просто скажу. что это действительно был искомый троянчик.
Bit by Bit и Graphics is for the weak
Во время анализа из предыдущего пункта можно было легко заметить адрес 1MmpEmebJkqXG8nQv4cjJSmxZQFVmFo63M , который и является флагом. Аналогично из этого же бинарника можно получить картинку с флагом для еще одной задачи, поэтому обьединяю их в один пункт
Recovery
По сути, эта задача тоже относится к бинарнику, но я вынес ее в отдельный пункт, потому что она очень сильно напоминает будни аналитика разной малвари и будет полезно показать процесс целиком. Открываем бинарник и находим функцию CreatePassword . По-моему, это «жжж» неспроста:
Как мы видим, пароль действительно случайный. Но мы знаем регулярное выражение abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890*!=&?&/ , которому удовлетворяет наш пароль. Теперь, если есть функция создания пароля, где-то должна быть функция его применения 😀
Немного пролистав, находим и ее:
Ну уже кое-что новое, теперь мы знаем, что длина пароля 15 символов. Попробуем вытащить его из дампа процесса и сразу же оценим, насколько все плохо:`
Неплохо. Можно, конечно, посидеть поперебирать ручками, но это как-то слишком. Применим немного черной магии!
Команда выглядит страшно, но стоит немного в нее вглядется и она становится кристально очевидной. Если это не так — опять-таки пинайте в комментариях, разберу по кирпичикам. А тем временем, мы сократили количество с миллиона до каких-то жалких трех тысяч. Посмотрим, что это за строки:
К сожалению, тут я не придумал элегантного решения и поэтому дальше исключительно логические рассуждения. Как мы помним с момента реверса наш бинарник содержит открытый ключ b03f5f7f11d50a3a . Что же, попробуем найти его в наших почти 3K строках руками. Ну или не совсем 🙂 Для этого немного поменяем нашу команду:
Итак, судя по этому выводу ключ где-то наверху предыдущего вывода. Первых строк, похожих на ключ не так много и тут действительно придется воспользоваться древним заклинанием BruteForce
Понятно, что не все строчки в нашей выборке являются ключами — более того, не все на него похожи. Так что количество вариантов сокащается еще сильнее. Пробуем подряд и на втором варианте находим ключ aDOBofVYUNVnmp7 , который и является флагом.
Вместо заключения
Спасибо, что дочитали мою статью до конца. Если есть какие-то косяки или недочеты — просьба писать в комментарии, постараюсь все исправить. Это не все задачи, которые были связаны с этим образом. Я продолжаю решать эту серию и по мере своего продвижения буду добавлять новые решения. Надеюсь, каждый вынес для себя что-то новое. Так же, если все будет окей, то через некоторое время я смогу запустить у себя чекер флагов для этих задач и любопытные смогут порешать сами, а потом, если что-то не получится — глянуть на мои решения. Всем добра :3
Eugeneer’s Digital Cloud World — цифровой мир в облаках
Блог творческого ИТ-практика. Возьми свою мысль и дай ей ускорение идеи. В моем фокусе: сети, безопасность, виртуализация, web, мультимедиа.
А А Saturday, 7 August 2021
Анализ дампа памяти фреймворком Volatility.
Криминалистический анализ дампов памяти — метод исследования, который включает в себя поиск и извлечение криминалистических артефактов из физической памяти компьютера (ОЗУ). В памяти компьютера хранится ценная информация о состоянии системы во время выполнения. Создание дампа памяти и его анализ дадут необходимую для расследования информацию, например о том, какие приложения работают в системе, к каким объектам (файлу, реестру и т. д.) эти приложения обращаются, сведения об актив ных сетевых соединениях, загруженных модулях, загруженных драйверах ядра и другую информацию. По этой причине криминалистический анализ дампов памяти используется при реагировании на компьютерные инциденты и анализе вредоносных программ.
Создание дампа памяти – это процесс получения дампа энергозависимой памяти (ОЗУ) в виде энергонезависимого хранилища информации (файла на диске). Существуют различные инструменты, которые позволяют создать дамп памяти физического устройства. Ниже приведен ряд инструментов, которые позволяют создать дамп физической памяти в Windows. Некоторые из них являются коммерческими, а многие можно скачать бесплатно после регистрации. Следующие инструменты работают как на 32-разрядных, так и на 64-разрядных компьютерах:
- Comae Memory Toolkit (DumpIt) от Comae Technologies (можно скачать бесплатно после регистрации): my.comae.io;
- Belkasoft RAM Capturer (можно скачать бесплатно после регистрации): belkasoft.com/ram-capturer;
- FTK Imager от AccessData (можно скачать бесплатно после регистрации): accessdata.com/product-download;
- Memoryze от FireEye (можно скачать бесплатно после регистрации): www.fireeye.com/services/freeware/memoryze.html;
- Surge Collect от Volexity (коммерческий): www.volexity.com/products-over-view/surge/;
- OSForensics от PassMark Software (коммерческий): www.osforensics.com/osforensics.html;
- WinPmem (бесплатный), часть криминалистического фреймворка Rekall Memory: blog.rekall-forensic.com/search?q=winpmem.
В большинстве случаев вы можете сделать дамп памяти виртуальной машины, приостановив ее. Например, после выполнения образца вредоносного ПО на рабочей станции VMware вы можете приостановить виртуальную машину, которая запишет гостевую память (RAM) в файл с расширением .vmem на диске главного компьютера. В случае с такими приложениями, как VirtualBox, когда дамп памяти нельзя сделать путем приостановки, вы можете использовать утилиту типа DumpIt на гостевом компьютере.
После того как вы сделали дамп памяти зараженной системы, следующим шагом является анализ полученного образа. Volatility представляет собой лучший фреймворк для компьютерной криминалистики с открытым исходным кодом, написанный на Python, позволяющий анализировать и извлекать цифровые артефакты из образа памяти. Volatility может работать на различных платформах (Windows, macOS и Linux). Он поддерживает анализ памяти из 32-разрядных и 64-разрядных версий Windows, MacOS и операционной системы Linux.
Volatility распространяется в нескольких форматах, и его можно скачать на странице www.volatilityfoundation.org/releases. В зависимости от операционной системы, на которой вы собираетесь запускать Volatility, следуйте процедуре установки для соответствующей ОС.
Самый быстрый способ начать работу с Volatility – использовать автономный исполняемый файл. Автономный исполняемый файл распространяется для операционных систем Windows, macOS и Linux. Его преимущество состоит в том, что вам не нужно устанавливать интерпретатор Python или зависимости Volatility, поскольку он поставляется с интерпретатором Python 2.7 и всеми необходимыми зависимостями.
Volatility состоит из ряда плагинов, которые могут извлекать различную информацию из образа памяти. Команда volatility-2.4.standalone.exe -h отображает поддерживаемые плагины.
Вы можете не знать, какой профиль использовать для вашего дампа. В этом случае вы можете использовать плагин imageinfo, который определит правильный профиль. Следующая команда отображает несколько профилей, предлагаемых плагином imageinfo. Вы можете использовать любой из предложенных фреймворком:
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» imageinfo
Следующая команда использует плагин pslist для вывода списка запущенных процессов из образа памяти, полученного из Windows ХР (32-разрядная версия) с пакетом обновления 3:
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 pslist —output-file=process.txt
Вывод по процессу с PID 684:
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 pslist -p 684
psscan – еще один плагин Volatility, в котором перечислены процессы, запущенные в системе. В отличие от pslist, psscan не обходит двусвязный список объектов _EPROCESS. Вместо этого он сканирует физическую память на предмет подписи объектов процесса. Другими словами, psscan использует иной подход для составления списка процессов по сравнению с плагином pslist. Вы можете подумать, для чего нужен плагин psscan, когда плагин pslist может сделать то же самое? Ответ заключается в технике, используемой psscan. Благодаря подходу, который он использует, он может обнаруживать завершенные и скрытые процессы:
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 psscan -v
При изучении процессов может быть полезно определить родительские/дочерние связи между процессами. В ходе исследования вредоносных программ это поможет вам понять, какие еще процессы связаны с вредоносным процессом. Плагин pstree отображает связи родительских и дочерних процессов, используя выходные данные из pslist и форматируя их в виде дерева. В следующем примере при запуске плагина pstree для зараженного образа памяти отображается связь процессов; дочерний процесс имеет отступ вправо и начинается с периодов:
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 pstree —output-file=prctree.txt
Злоумышленник может установить драйвер ядра для запуска в пространстве ядра и изменить теги пула или любое другое поле в _POOL_HEADER. Изменяя тег пула, злоумышленник может помешать правильной работе плагинов, которые полагаются на сканирование тегов пула. Другими словами, изменяя тег пула, можно скрыть процесс от psscan. Чтобы преодолеть эту проблему, плагин psxview использует извлечение информации о процессе из разных источников. Он перечисляет процесс семи разными способами. Сравнивая выходные данные из разных источников, можно обнаружить несоответствия, вызванные вредоносным ПО. На следующем скриншоте psxview перечисляет процессы, используя семь различных методов:
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 psxview —apply-rules
Вы также можете отфильтровать результаты для определенного типа объекта (Файл, Ключ, Процесс, Мьютекс и т. д.), используя опцию -t. Плагин используется для вывода списка мьютексов (mutex), открытых процессом (с pid 588):
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 handles -p 588 -t Mutant
В следующем примере образа памяти, зараженного руткитом TDL3, процесс svchost.exe (pid 884) имеет открытые дескрипторы файлов для вредоносной библиотеки DLL и драйвера ядра, связанного с руткитом:
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 handles -p 884 -t File
Чтобы вывести список загруженных модулей (исполняемых файлов и библиотек DLL), вы можете использовать плагин dlllist. Плагин dlllist также отображает полный путь, связанный с процессом:
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 dlllist -p 1300
Плагин ldrmodules сравнивает информацию о модуле из трех списков PEB (в памяти процесса) с информацией из структуры данных, находящейся в памяти ядра, известной как дескрипторы виртуальных адресов (virtual address descriptor – VAD):
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 ldrmodules -p 1300
В следующем примере образа памяти, зараженного вредоносным ПО, подключаемый модуль procdump используется для сброса исполняемого файла вредоносного процесса svchost.exe (pid 956). При помощи опции -D (—dump-dir) вы указываете имя каталога, в который выгрузите исполняемые файлы. Файл назван на основе pid процесса, такого как executable.PID.exe:
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 procdump -p 956 -D C:\JeaDemo
Следующая команда показывает пример использования плагина connections для вывода на экран активных подключений из дампа памяти:
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 connections
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 connscan
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 netscan
Чтобы вывести на экран раздел реестра, подразделы и его значения, вы можете использовать плагин printkey, предоставляя желаемый путь к ключу реестра, используя аргумент -K (—key):
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 printkey -K «Microsoft\Windows\CurrentVersion\Run»
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 printkey -K «Software\Microsoft\Windows\CurrentVersion\Run»
Плагины Volatility, такие как userassist, shellbags и shimcache, анализируют эти ключи реестра, содержащие двоичные данные, и отображают информацию в гораздо более удобочитаемом формате. Раздел реестра Userassist содержит список программ, которые были выполнены пользователем в системе, и время, когда программа была запущена:
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 userassist
Плагины shimcache и shellbags могут быть полезны при расследовании инцидента с вредоносным ПО. Плагин shimcache может быть полезен для доказательства наличия вредоносного ПО в системе и времени его работы. Плагин shellbags может предоставлять информацию о доступе к файлам, папкам, внешним устройствам хранения и сетевым ресурсам:
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 shimcache
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 shellbags
Чтобы вывести список служб и информацию о них, например отображаемое имя, тип службы и тип запуска, из образа памяти, можно использовать плагин svcscan:
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 svcscan
Плагин cmdscan перечисляет команды, выполняемые cmd.exe:
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 cmdscan
Плагин cmdscan отображает команды, выполненные злоумышленником. Чтобы понять, была команда выполнена успешно или нет, можно использовать плагин consoles:
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 consoles
Что осталось в истории web-браузера:
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 iehistory
Что осталось в буфере обмена:
:volatility-2.4.standalone.exe -f «Clone of WinXP_ZverCD.vmem» —profile=WinXPSP3x86 clipboard
Так что изучайте плагины фреймворка и память ПК. Удачи.
В подготовке поста использовались материалы из книги Монаппа К. А., Анализ вредоносных программ / пер. с анг. Д. А. Беликова. – М.: ДМК Пресс, 2019.
Volatility Usage
The most basic Volatility commands are constructed as shown below. Replace plugin with the name of the plugin to use, image with the file path to your memory image, and profile with the name of the profile (such as Win7SP1x64).
Here is an example:
For everything beyond this example, such as controlling the output format, listing the available plugins and profiles, or supplying plugin-specific options, see the rest of the text below.
There are several command-line options that are global (i.e. they apply to all plugins). This section is for folks who are new to Volatility or anyone who wants to become more familiar with what functionality can be tweaked.
You can display the main help menu by passing -h or —help on command-line. This shows the global options and lists the plugins available to the currently specified profile. If you do not specify a profile, you’ll be working with the default, WinXPSP2x86 , thus you’ll only see plugins that are valid for that operating system and architecture (for example, you won’t see linux plugins or windows plugins that only work on Vista). To specify a profile other than the default, see Selecting a Profile below.
The remainder of this section will discuss the various options in greater detail.
Selecting a Profile
Volatility needs to know what type of system your memory dump came from, so it knows which data structures, algorithms, and symbols to use. A default profile of WinXPSP2x86 is set internally, so if you’re analyzing a Windows XP SP2 x86 memory dump, you do not need to supply —profile at all. However, for all others, you must specify the proper profile name.
Note: If you do not know what type of system the memory dump is from, use the [imageinfo](Command Reference23#imageinfo) or [kdbgscan](Command Reference23#kdbgscan) plugins for a suggestion. These plugins are Windows-only.
If you want to see a list of supported profile names, do the following:
Alternatives to Command Line Options
If you’re about to enter a lengthy engagement and don’t want to type common plugin flags, there are two alternatives: environment variables and configuration files. If an option is not supplied on command-line, Volatility will try to get it from an environment variable and if that fails — from a configuration file.
Note also that to avoid confusion, the ( -h/—help ) option also lists the current value of each parameter so you can easily check what value is being used (from the environment or the config files).
On a Linux or OS X system you can set options by exporting them in your shell, as shown below:
Configuration files are typically » volatilityrc » in the current directory or
/.volatilityrc (user’s home directory), or at user specified path (using the —conf-file option). An example of the file contents is shown below:
Configuration files are particularly useful when processing several memory samples in one sitting.
Notes:
- Other plugin flags may be utilized in this way, for example KPCR , DTB or PLUGINS . When exporting variables, simply prefix VOLATILITY_ before the flag name (e.g. VOLATILITY_KPCR ). Otherwise, the flag name remains the same when adding it to the configuration file.
- If you have a path with a space or more in the name, spaces should be replaced with %20 instead (e.g. LOCATION=file:///tmp/my%20image.img ).
Enabling Debug Messages
If something isn’t happening in Volatility the way you’d expect, try running the command with -d/—debug . This will enable the printing of debug messages to standard error. If you really need to debug Volatility (as in using pdb debugger), then add -d -d -d to your commands.
Using the Cache
Note: Caching has been disabled at this time.
The cache allows Volatility to store arbitrary objects and constants for later retrieval. This can include, DTB, KDBG, or KPCR addresses, entire x86 page translation tables, or even hibernation decompression data structures. To enable use of the cache, add —cache to your commands. This feature pickles (serializes) the data in files on your disk, so if you want to choose the location of cache files, use —cache-directory . For more information, see the caching system page in the developer guide for your release version.
Setting the Timezone
Timestamps extracted from memory can either be in system-local time, or in Universal Time Coordinates (UTC). If they’re in UTC, Volatility can be instructed to display them in a time zone of the analyst’s choosing. To choose a timezone, use one of the standard timezone names (such as Europe/London, US/Eastern or most Olson timezones) with the —tz=TIMEZONE flag. Volatility attempts to use pytz if installed, otherwise it uses tzset.
Please note that specifying a timezone will not affect how system-local times are displayed. If you identify a time that you know is UTC-based, please file it as an issue in the issue tracker.
By default the _EPROCESS CreateTime and ExitTime timestamps are in UTC. Below is output from Volatility with pytz installed:
Below is output from the same sample using the —tz=America/Chicago option to get Central Standard Time:
Below is the same output above, but without the pytz library installed:
Setting the DTB
The DTB (Directory Table Base) is what Volatility uses to translate virtual addresses to physical addresses. By default, a kernel DTB is used (from the Idle/System process). If you want to use a different process’s DTB when accessing data, supply the address to —dtb=ADDRESS .
Setting the KDBG Address
This is a Windows-only option
Volatility scans for the _KDDEBUGGER_DATA64 structure using hard-coded signatures «KDBG» and a series of sanity checks. These signatures are not critical for the operating system to function properly, thus malware can overwrite them in attempt to throw off tools that do rely on the signature. Additionally, in some cases there may be more than one _KDDEBUGGER_DATA64 (for example if you apply a major OS update and don’t reboot), which can cause confusion and lead to incorrect process and module listings, among other problems. If you know the address add _KDDEBUGGER_DATA64 , you can specify it with —kdbg=ADDRESS and this override the automated scans. For more information, see the [kdbgscan](Command Reference#kdbgscan) plugin.
For Windows 8 and above, the —kdbg parameter should be the address of KdCopyDataBlock instead. For more information, see Windows 8 Memory Forensics.
Setting the KPCR Address
This is a Windows-only option
There is one KPCR (Kernel Processor Control Region) for each CPU on a system. Some Volatility plugins display per-processor information. Thus if you want to display data for a specific CPU, for example CPU 3 instead of CPU 1, you can pass the address of that CPU’s KPCR with —kpcr=ADDRESS . To locate the KPCRs for all CPUs, see the [kpcrscan](Command Reference#kpcrscan) plugin. Also note that starting in Volatility 2.2, many of the plugins such as [idt](Command Reference#idt) and [gdt](Command Reference#gdt) automatically iterate through the list of KPCRs.
Enabling Write Support
Write support in Volatility should be used with caution. Therefore, to actually enable it, you must not only type —write on command-line but you must type a «password» in response to a question that you’ll be prompted with. In most cases you will not want to use write support since it can lead to corruption or modification of data in your memory dump. However, special cases exist that make this feature really interesting. For example, you could cleanse a live system of certain malware by writing to RAM over firewire, or you could break into a locked workstation by patching bytes in the winlogon DLLs.
Specifying Additional Plugin Directories
Volatility’s plugin architecture can load plugin files and profiles from multiple directories at once. In the Volatility source code, most plugins are located in volatility/plugins . However, there is another directory ( volatility/contrib ) which is reserved for contributions from third party developers, or weakly supported plugins that simply aren’t enabled by default. To access these plugins you just type —plugins=contrib/plugins on command-line. It also enables you to create a separate directory of your own plugins that you can manage without having to add/remove/modify files in the core volatility directories.
Notes:
- Subdirectories will also be traversed as long as there is an __init__.py file (which can be empty) within them.
- The parameter to —plugins can also be a zip file containing the plugins such as —plugins=myplugins.zip .
- If the specified directory contains profiles, these will also be loaded. This is convenient for using generated Linux/Android/Mac profiles with the standalone executable of Volatility.
Due to the way plugins are loaded, the external plugins directory or zip file must be specified before any plugin-specific arguments (including the name of the plugin). Example:
Choosing an Output Format
By default, plugins use text renderers to standard output. If you want to redirect to a file, you can of course use the console’s redirection (i.e. > out.txt ) or you could use —output-file=out.txt . The reason you can also choose —output=FORMAT is for allowing plugins to also render output as HTML, JSON, SQL, or whatever you choose. However, there are no plugins with those alternate output formats pre-configured for use, so you’ll need to add a function named render_html , render_json , render_sql , respectively to each plugin before using —output=HTML .
Plugin Specific Options
Many plugins accept arguments of their own, which are independent of the global options. To see the list of available options, type both the plugin name and -h/—help on command-line.
Using Volatility as a Library
Although its possible to use Volatility as a library, we hope to support it better in the future. Currently, if you need to import volatility from one of your other python scripts, you can use the following example code: