Источник:
Сегодня я расскажу, как извлекать данные из таблицы MFT, получать информацию из файлов Prefetch и монитора использования системных ресурсов (srum), а еще — анализировать файлы логов операционной системы. При исследовании образа оперативной памяти мы познакомимся с внутренним устройством памяти Windows и найдем артефакты, свидетельствующие о компрометации системы.
Расследование киберинцидентов — это очень увлекательное занятие, требующее определенных знаний и навыков. Отточить их помогают специальные лабораторные работы, имитирующие реальные случаи успешных атак злоумышленников и взлома, с которыми встречаются на практике специалисты по информационной безопасности. Сегодня мы разберем лабораторную работу
с ресурса
.
По сценарию лабораторной работы произошел взлом Active Directory, злоумышленники смогли захватить корпоративный контроллер домена. Наша задача — провести расследование инцидента и узнать, как хакерам удалось проникнуть в сеть. Для исследования у нас имеется побитовая копия системного диска скомпрометированной машины, оперативной памяти, а также информация об объектах домена.
Загрузим файл
и начнем их исследовать.
По результатам разбора этой лабораторной необходимо ответить на ряд вопросов, но я покажу только само решение и не буду озвучивать ответы. Тебе придется повторить весь процесс самостоятельно — так ты лучше поймешь и закрепишь материал.
Инструменты
В архиве задания содержится файл 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 диска С
Как видно из рисунка выше, GUID диска C — fad905b3-fb35-4dbd-ab31-a44f022809d2, такую же информацию можно получить из логов системы, просмотрев событие eventid 142 журнала Microsoft-Windows-Ntfs/Operational.
Теперь найдем порты служб на PC01, для этого перейдем к файлу Windows/System32/drivers/etc/services.
Содержимое файла services
Здесь мы можем увидеть, что служба Remote Man Server работает на порте 9535. Проанализируем файл System.evtx и найдем отметку времени, когда произошло незапланированное отключение, а также узнаем, сколько времени проработал компьютер. Для этого можно воспользоваться утилитой TurnOnTimesView, либо придется анализировать лог вручную.
Результат работы утилиты 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 и укажем путь до пользовательского каталога.
Получение истории из браузера Firefox
История Firefox
Пользователь labib 22.11.2021 в 19:45:52 UTC посетил сайт bluedemy.cyberdefenders.org.
Проанализируем базу данных управления использованием системных ресурсов (srum), которая присутствует в современных системах Windows и собирает статистику выполнения двоичных файлов. Эта база хранится в файле C:\Windows\System32\sru\\RUDB.dat. С использованием утилиты srum-dump проанализируем srum и найдем, сколько байтов было принято браузером Firefox.
Работа Srum-dump утилиты
Не забываем также указать файл 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 содержат имя исполняемого файла, количество его запусков, метки времени, а также список файлов и каталогов, с которыми взаимодействовал исполняемый файл.
Содержимое файла Unpaid Invoice.XLS
Поле Last Run содержит дату последних семи запусков. Как видно из рисунка выше, пользователь открыл файл Unpaid Invoice.xls, при этом последняя метка времени запуска приложения Excel.exe — 22.11.2021 в 19:38:16 UTC. Осталось выяснить, что представляет собой вредоносный файл Unpaid Invoice.xls, по его MD5:
.
Файл содержит VBA-скрипт. Вытащим его с помощью olevba. При запуске появляются ошибки, поэтому мы запустим утилиту с параметром --show-pcode. Техника встраивания вредоносного кода в содержащий макрос документ называется
.
olevba --show-pcode Unpaid\ Invoice.xls
Результат работы утилиты olevba
Извлечем p-code, найдем шелл и проанализируем его.
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), которое свидетельствует об обнаружении вредоносного файла.
Логи Windows Defender
Пользователь 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), далее начинается выполнение команды.
Вызов PowerShell с аргументом -h
Выполнение вредоносного скрипта
После выполнения обратной оболочки в файле Unpaid Invoice.xls злоумышленник получил доступ к компьютеру, затем он начал выполнять команды PowerShell, показанные на рисунке выше. Извлечем их из логов и преобразуем в текстовый вид.
PowerShell команды, выполненные злоумышленником
Злоумышленник запустил новую оболочку PowerShell от имени пользователя labib для устойчивого доступа к скомпрометированному компьютеру с IP-адресом 192.168.112.128, на порте 1337. Далее взломщик пытался авторизоваться на хосте DC01 c учетными данными пользователя labib. В 21:20:29 зафиксировано событие 4648 — авторизация на компьютере DC01 от пользователя labib, имя процесса PowerShell.exe.
Событие 4648
В 21:20:46 также зафиксированы попытки входа на PC01 с адреса 192.168.112.128, авторизоваться пытался тот же пользователь labib.
Сетевой вход
В 21:51:15 UTC от имени пользователя labib выполнен скрипт Invoke-ACLPwn.ps1. Этот скрипт предназначен для удаления списков ACL в Active Directory, настроенных небезопасно, а также для сбора данных об объектах домена.
Выполнение скрипта Invoke-ACLPwn.ps1
Для получения доступа к компьютеру DC01 злоумышленнику необходимо завладеть учетной записью пользователя 0xMohammed, который входит в группу Domain Admins. В 22:56:23 UTC обнаружено подключение к DC01 c помощью службы WinRM, идентификатор события 6.
Открытие WinRM
В 22:58:44 UTC зафиксировано событие авторизации на хосте DC01, при этом были введены учетные данные пользователя 0xMohammed.
Попытка входа в систему
С этого момента злоумышленник выполнял команды PowerShell уже от имени пользователя 0xMohammed. В 23.11.2021 13:32:44 UTC доменный пользователь CYBERDEFENDERS\0xMohammed зарегистрировал задачу MicrosoftEdge, идентификатор события 106. Найдем эту задачу в каталоге Windows\System32\Tasks\MicrosoftEdge.
Созданная задача MicrosoftEdge
Согласно матрице
, такая техника атаки называется T1053.005, атакующий использовал управляющий сервер c2.cyberdefenders.org.
Теперь проверим историю команд PowerShell. Для пользователя administrator в файле C:/Users/administrator/AppData/Roaming/Microsoft/Windows/PowerShell/PSReadline/ConsoleHost_history.txt хранится следующая информация.
Содержимое файла ConsoleHost_history.txt пользователя administrator
При исследовании артефактов, извлеченных из побитовой копии образа хоста 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.
www
Качественный анализ поиска удаленного выполнения команд PowerShell описан в статье
.
Службы WinRM для взаимодействия используют протокол
, который отправляет сообщения 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
Для загрузки файла svchost.exe используется следующая команда PowerShell: Invoke-WebRequest
-OutFile svchost.exe. Спускаемся ниже и видим запуск данного файла.
Запуск файла svchost
Иногда сложно найти вредоносный процесс в памяти Windows, в этом случае можно получить дампы всех процессов в системе и проверить их с помощью антивируса.
python2.7 vol.py -f memory.dmp --profile=Win2016x64_14393 procdump -D procdmp/
Обнаруженный вредоносный файл
Процесс svchost.exe, идентификатор `3140, вредоносный и относится к семейству шифровальщиков
. Получим информацию о привилегиях этого процесса в системе, для чего воспользуемся плагином privs.
python2.7 vol.py -f memory.dmp --profile=Win2016x64_14393 privs -p 3140
Привилегии процесса svchost.exe
Количество привилегий по умолчанию у этого вредоносного процесса — 25. Давай проведем глубокий анализ вредоносного процесса 3140, но прежде немного поговорим о структурах исполняемых объектов в памяти.
Найдем поле PoolTag структуры _POOL_HEADER исследуемого процесса. В памяти Windows есть следующие криминалистически важные исполняемые объекты: _FILE_OBJECT — экземпляр открытого файла, представляющий доступ процесса или модуля ядра к файлу, _EPROCESS — структура процесса в памяти, _TOKEN, _ETHREAD и многое другое.
info
Описание структуры памяти Windows представлено в книге
.
Каждый исполняемый объект Windows хранится в следующей структуре.
Пул исполняемого объекта
Пул ядра — это диапазон памяти, который можно разделить на мелкие блоки для хранения данных любого типа.
Структура _POOL_HEADER
Структура _POOL_HEADER содержит элемент PoolTag — состоящеиз ASCII-символов четырехбайтовое значение. Этот элемент создан Microsoft для отладки и аудита ядра. Элемент PoolTag может иметь значения Proc, Thrd, File и другие. Многие плагины Volatility для поиска объектов в памяти используют метод сканирования PoolTag, чтобы находить скрытые и завершенные процессы, а также руткиты. Размер структуры _POLL_HEADER составляет 10 байт.
Структура _OBJECT_HEADER общая для всех типов исполняемых объектов. Размер Optional Header в структуре пула исполняемого объекта определяется в зависимости от содержимого поля InfoMask.
Структура _OBJECT_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)
Содержимое структуры _OBJECT_HEADER
Значение поля 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)
Содержимое структуры _POOL_HEADER процесса 3140
Переводим значение 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-байтового ключа в памяти
Шифровальщик сохранил 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
Поиск адреса процесса lsass.exe
Переходим по адресу ffffba033ef746c0.
.process /r /p ffffba033ef746c0
Парсим lsass.exe.
!mimikatz
Находим пользователя 0xMohammed и видим следующую информацию.
MasterKey пользователя 0xMohammed
Мастер‑ключ пользователя 0xMohammed — 1652c67aa6719519492e67d1b39cab91e7804eb26b259ff351b60df34ee808804314cbfbcf03afbf3bae3ef2790f2c363ca0a9c8791e0e80d490c26afe77c3be.
Выводы
Мы исследовали образ оперативной памяти, познакомились со структурами _EPROCESS и _FILE_OBJECT, разобрались, как происходит сканирование пула тегов и какие данные там хранятся. Обнаружили, что злоумышленник получил доступ к компьютеру DC01 с помощью службы WinRM, а также вытащили переданные им команды PowerShell.
Мы провели расследование стендового инцидента и ответили на вопросы лабораторной работы. Злоумышленник с адреса 192.168.112.128 скомпрометировал хост PC01, используя фишинговое сообщение с вредоносным вложением. Перехватил учетные данные пользователя labib и администратора домена 0xMohammed. Затем с помощью службы WinRM получил доступ к хосту DC01, тем самым скомпрометировал контроллер домена и загрузил на него шифровальщик семейства DarkSide.
Чтобы увидеть нужно авторизоваться или зарегистрироваться.
Сегодня я расскажу, как извлекать данные из таблицы MFT, получать информацию из файлов Prefetch и монитора использования системных ресурсов (srum), а еще — анализировать файлы логов операционной системы. При исследовании образа оперативной памяти мы познакомимся с внутренним устройством памяти Windows и найдем артефакты, свидетельствующие о компрометации системы.
Расследование киберинцидентов — это очень увлекательное занятие, требующее определенных знаний и навыков. Отточить их помогают специальные лабораторные работы, имитирующие реальные случаи успешных атак злоумышленников и взлома, с которыми встречаются на практике специалисты по информационной безопасности. Сегодня мы разберем лабораторную работу
Чтобы увидеть нужно авторизоваться или зарегистрироваться.
Чтобы увидеть нужно авторизоваться или зарегистрироваться.
По сценарию лабораторной работы произошел взлом Active Directory, злоумышленники смогли захватить корпоративный контроллер домена. Наша задача — провести расследование инцидента и узнать, как хакерам удалось проникнуть в сеть. Для исследования у нас имеется побитовая копия системного диска скомпрометированной машины, оперативной памяти, а также информация об объектах домена.
Загрузим файл
Чтобы увидеть нужно авторизоваться или зарегистрироваться.
По результатам разбора этой лабораторной необходимо ответить на ряд вопросов, но я покажу только само решение и не буду озвучивать ответы. Тебе придется повторить весь процесс самостоятельно — так ты лучше поймешь и закрепишь материал.
Инструменты
- Утилиты
: Registry Explorer, MFTECmd.Чтобы увидеть нужно авторизоваться или зарегистрироваться.
- Утилиты
: fulleventlogview, winprefetchview, browsinghistoryview, TurnOnTimesView.Чтобы увидеть нужно авторизоваться или зарегистрироваться.
-
— утилита для восстановления данных с диска.Чтобы увидеть нужно авторизоваться или зарегистрироваться.
- Volatility Framework 2.6.1 — инструмент, реализованный на Python версии 2 и предназначенный для извлечения артефактов из образцов энергозависимой памяти.
-
— инструмент для восстановления PST-контейнеров в EML.Чтобы увидеть нужно авторизоваться или зарегистрироваться.
-
— программа для анализа shell-кода.Чтобы увидеть нужно авторизоваться или зарегистрироваться.
- Srum-dump — утилита для извлечения информации из базы данных управления использованием системных ресурсов.
-
— инструмент для анализа и получения образов диска.Чтобы увидеть нужно авторизоваться или зарегистрироваться.
-
— утилиты для анализа аварийных дампов.Чтобы увидеть нужно авторизоваться или зарегистрироваться.
- Olevba — инструмент для извлечения и анализа исходного кода макросов VBA из документов MS Office (OLE и OpenXML).
- Imageinfo — плагин для определения операционной системы, пакета обновлений и аппаратной архитектуры исследуемого образа.
- Pstree позволяет просматривать список процессов в виде дерева.
- Memdump извлекает все резидентные страницы памяти в процессе.
- Filescan — плагин для поиска объектов FILE_OBJECT в памяти с помощью сканирования тегов пула. Этот плагин найдет все открытые файлы.
- Dumpfiles извлекает кешированные файлы из образа памяти.
- Netscan ищет сетевые артефакты в 32- и 64-разрядных дампах памяти. Этот плагин находит конечные точки TCP, UDP, а также локальные и удаленные IP-адреса.
- Printkey ищет значения в указанном разделе реестра Windows.
- Userassist позволяет получить информацию из ключа реестра UserAssist.
- Mftparser — этот плагин сканирует записи главной таблицы файлов (MFT) в памяти и выводит информацию о временных метках файлов.
- Autoruns — подключаемый плагин для поиска точек сохранения исполняемых файлов в системе. Для его подключения необходимо добавить плагин в каталог plugins инструмента Volatility.
- Volshell — плагин для интерактивного изучения образа памяти, использует IPython.
- Procdump — плагин для получения дампа исполняемого файла.
- 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 диска С
Как видно из рисунка выше, GUID диска C — fad905b3-fb35-4dbd-ab31-a44f022809d2, такую же информацию можно получить из логов системы, просмотрев событие eventid 142 журнала Microsoft-Windows-Ntfs/Operational.
Теперь найдем порты служб на PC01, для этого перейдем к файлу Windows/System32/drivers/etc/services.
Содержимое файла services
Здесь мы можем увидеть, что служба Remote Man Server работает на порте 9535. Проанализируем файл System.evtx и найдем отметку времени, когда произошло незапланированное отключение, а также узнаем, сколько времени проработал компьютер. Для этого можно воспользоваться утилитой TurnOnTimesView, либо придется анализировать лог вручную.
Результат работы утилиты 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 и укажем путь до пользовательского каталога.
Получение истории из браузера Firefox
История Firefox
Пользователь labib 22.11.2021 в 19:45:52 UTC посетил сайт bluedemy.cyberdefenders.org.
Проанализируем базу данных управления использованием системных ресурсов (srum), которая присутствует в современных системах Windows и собирает статистику выполнения двоичных файлов. Эта база хранится в файле C:\Windows\System32\sru\\RUDB.dat. С использованием утилиты srum-dump проанализируем srum и найдем, сколько байтов было принято браузером Firefox.
Работа Srum-dump утилиты
Не забываем также указать файл 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 содержат имя исполняемого файла, количество его запусков, метки времени, а также список файлов и каталогов, с которыми взаимодействовал исполняемый файл.
Содержимое файла Unpaid Invoice.XLS
Поле Last Run содержит дату последних семи запусков. Как видно из рисунка выше, пользователь открыл файл Unpaid Invoice.xls, при этом последняя метка времени запуска приложения Excel.exe — 22.11.2021 в 19:38:16 UTC. Осталось выяснить, что представляет собой вредоносный файл Unpaid Invoice.xls, по его MD5:
Чтобы увидеть нужно авторизоваться или зарегистрироваться.
Файл содержит VBA-скрипт. Вытащим его с помощью olevba. При запуске появляются ошибки, поэтому мы запустим утилиту с параметром --show-pcode. Техника встраивания вредоносного кода в содержащий макрос документ называется
Чтобы увидеть нужно авторизоваться или зарегистрироваться.
olevba --show-pcode Unpaid\ Invoice.xls
Результат работы утилиты olevba
Извлечем p-code, найдем шелл и проанализируем его.
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), которое свидетельствует об обнаружении вредоносного файла.
Логи Windows Defender
Пользователь 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), далее начинается выполнение команды.
Вызов PowerShell с аргументом -h
Выполнение вредоносного скрипта
После выполнения обратной оболочки в файле Unpaid Invoice.xls злоумышленник получил доступ к компьютеру, затем он начал выполнять команды PowerShell, показанные на рисунке выше. Извлечем их из логов и преобразуем в текстовый вид.
PowerShell команды, выполненные злоумышленником
Злоумышленник запустил новую оболочку PowerShell от имени пользователя labib для устойчивого доступа к скомпрометированному компьютеру с IP-адресом 192.168.112.128, на порте 1337. Далее взломщик пытался авторизоваться на хосте DC01 c учетными данными пользователя labib. В 21:20:29 зафиксировано событие 4648 — авторизация на компьютере DC01 от пользователя labib, имя процесса PowerShell.exe.
Событие 4648
В 21:20:46 также зафиксированы попытки входа на PC01 с адреса 192.168.112.128, авторизоваться пытался тот же пользователь labib.
Сетевой вход
В 21:51:15 UTC от имени пользователя labib выполнен скрипт Invoke-ACLPwn.ps1. Этот скрипт предназначен для удаления списков ACL в Active Directory, настроенных небезопасно, а также для сбора данных об объектах домена.
Выполнение скрипта Invoke-ACLPwn.ps1
Для получения доступа к компьютеру DC01 злоумышленнику необходимо завладеть учетной записью пользователя 0xMohammed, который входит в группу Domain Admins. В 22:56:23 UTC обнаружено подключение к DC01 c помощью службы WinRM, идентификатор события 6.
Открытие WinRM
В 22:58:44 UTC зафиксировано событие авторизации на хосте DC01, при этом были введены учетные данные пользователя 0xMohammed.
Попытка входа в систему
С этого момента злоумышленник выполнял команды PowerShell уже от имени пользователя 0xMohammed. В 23.11.2021 13:32:44 UTC доменный пользователь CYBERDEFENDERS\0xMohammed зарегистрировал задачу MicrosoftEdge, идентификатор события 106. Найдем эту задачу в каталоге Windows\System32\Tasks\MicrosoftEdge.
Созданная задача MicrosoftEdge
Согласно матрице
Чтобы увидеть нужно авторизоваться или зарегистрироваться.
Теперь проверим историю команд PowerShell. Для пользователя administrator в файле C:/Users/administrator/AppData/Roaming/Microsoft/Windows/PowerShell/PSReadline/ConsoleHost_history.txt хранится следующая информация.
Содержимое файла ConsoleHost_history.txt пользователя administrator
При исследовании артефактов, извлеченных из побитовой копии образа хоста 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.
www
Качественный анализ поиска удаленного выполнения команд 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
Для загрузки файла svchost.exe используется следующая команда PowerShell: Invoke-WebRequest
Чтобы увидеть нужно авторизоваться или зарегистрироваться.
Запуск файла svchost
Иногда сложно найти вредоносный процесс в памяти Windows, в этом случае можно получить дампы всех процессов в системе и проверить их с помощью антивируса.
python2.7 vol.py -f memory.dmp --profile=Win2016x64_14393 procdump -D procdmp/
Обнаруженный вредоносный файл
Процесс svchost.exe, идентификатор `3140, вредоносный и относится к семейству шифровальщиков
Чтобы увидеть нужно авторизоваться или зарегистрироваться.
python2.7 vol.py -f memory.dmp --profile=Win2016x64_14393 privs -p 3140
Привилегии процесса svchost.exe
Количество привилегий по умолчанию у этого вредоносного процесса — 25. Давай проведем глубокий анализ вредоносного процесса 3140, но прежде немного поговорим о структурах исполняемых объектов в памяти.
Найдем поле PoolTag структуры _POOL_HEADER исследуемого процесса. В памяти Windows есть следующие криминалистически важные исполняемые объекты: _FILE_OBJECT — экземпляр открытого файла, представляющий доступ процесса или модуля ядра к файлу, _EPROCESS — структура процесса в памяти, _TOKEN, _ETHREAD и многое другое.
info
Описание структуры памяти Windows представлено в книге
Чтобы увидеть нужно авторизоваться или зарегистрироваться.
Каждый исполняемый объект Windows хранится в следующей структуре.
Пул исполняемого объекта
Пул ядра — это диапазон памяти, который можно разделить на мелкие блоки для хранения данных любого типа.
Структура _POOL_HEADER
Структура _POOL_HEADER содержит элемент PoolTag — состоящеиз ASCII-символов четырехбайтовое значение. Этот элемент создан Microsoft для отладки и аудита ядра. Элемент PoolTag может иметь значения Proc, Thrd, File и другие. Многие плагины Volatility для поиска объектов в памяти используют метод сканирования PoolTag, чтобы находить скрытые и завершенные процессы, а также руткиты. Размер структуры _POLL_HEADER составляет 10 байт.
Структура _OBJECT_HEADER общая для всех типов исполняемых объектов. Размер Optional Header в структуре пула исполняемого объекта определяется в зависимости от содержимого поля InfoMask.
Структура _OBJECT_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)
Содержимое структуры _OBJECT_HEADER
Значение поля 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)
Содержимое структуры _POOL_HEADER процесса 3140
Переводим значение 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-байтового ключа в памяти
Шифровальщик сохранил 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
Поиск адреса процесса lsass.exe
Переходим по адресу ffffba033ef746c0.
.process /r /p ffffba033ef746c0
Парсим lsass.exe.
!mimikatz
Находим пользователя 0xMohammed и видим следующую информацию.
MasterKey пользователя 0xMohammed
Мастер‑ключ пользователя 0xMohammed — 1652c67aa6719519492e67d1b39cab91e7804eb26b259ff351b60df34ee808804314cbfbcf03afbf3bae3ef2790f2c363ca0a9c8791e0e80d490c26afe77c3be.
Выводы
Мы исследовали образ оперативной памяти, познакомились со структурами _EPROCESS и _FILE_OBJECT, разобрались, как происходит сканирование пула тегов и какие данные там хранятся. Обнаружили, что злоумышленник получил доступ к компьютеру DC01 с помощью службы WinRM, а также вытащили переданные им команды PowerShell.
Мы провели расследование стендового инцидента и ответили на вопросы лабораторной работы. Злоумышленник с адреса 192.168.112.128 скомпрометировал хост PC01, используя фишинговое сообщение с вредоносным вложением. Перехватил учетные данные пользователя labib и администратора домена 0xMohammed. Затем с помощью службы WinRM получил доступ к хосту DC01, тем самым скомпрометировал контроллер домена и загрузил на него шифровальщик семейства DarkSide.
