ANTICHAT - Форензика Windows при расследовании инцидентов: методика сбора и анализа артефактов

https://forum.antichat.xyz/attachmen...24c2e96ed5.png

Два часа ночи. Уведомление от SIEM: на контроллере домена нетипичный логин, следом - создание службы и сетевая активность в сторону внешнего IP. К утру атакующий может зашифровать всю инфраструктуру. У вас окно в несколько часов, чтобы понять масштаб компрометации, найти точку входа и перекрыть lateral movement. Каждое ваше действие с этого момента - либо фиксация улик, либо их уничтожение. Третьего варианта нет.

Форензика Windows при расследовании инцидентов - это не академическое упражнение с красивыми схемами. Это конкретная последовательность действий: что снять первым, какой артефакт даст ответ на какой вопрос, какой инструмент запустить и как не затереть доказательства в процессе. Здесь я разберу полный цикл - от порядка волатильности до построения единого таймлайна, с акцентом на артефакты, которые обычно упускают из виду в русскоязычных гайдах (а зря - именно в них часто лежит ответ).
Порядок сбора доказательств при инциденте
Первая ошибка, которую допускают при цифровой криминалистике Windows, - хватать всё подряд. Вторая - выключить машину «чтобы вирус не распространялся». Обе ведут к потере критических данных. Лично видел, как дежурный админ ребутнул скомпрометированный хост «на всякий случай» - и мы потеряли ключи шифрования из RAM вместе с активными сетевыми соединениями к C2.

Порядок волатильности определяет, что исчезнет раньше всего. Собирайте строго сверху вниз:

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

Код:

netstat -anob

и

Код:

arp -a

до любых других действий.
Pagefile и Hiberfil.sys - могут быть перезаписаны при активной работе системы.
Event Logs - перезаписываются по достижении лимита размера. Атакующий может очистить журналы целенаправленно.
Реестр, Prefetch, Amcache - сохраняются на диске, но могут быть затёрты при перезагрузке или обновлении.
MFT и $UsnJrnl - более устойчивы, но записи переиспользуются.
Полный образ диска - наименее волатильный, но требует времени на создание.

На практике: пришли к хосту - первым делом снимаете дамп RAM, потом собираете артефакты триажа через KAPE, и только затем, если есть время и необходимость, создаёте полный образ диска. Перезагружать хост до снятия памяти - недопустимо. Точка.
Инструменты форензики Windows для сбора артефактов
Выбор инструмента зависит от сценария: физический доступ к хосту, удалённый триаж десятков машин или работа с уже снятым образом. Разберу три инструмента, которые закрывают большинство задач при расследовании инцидентов.
KAPE: автоматический сбор артефактов Windows
KAPE (Kroll Artifact Parser and Extractor) - рабочая лошадка для автоматизированного сбора и парсинга артефактов Windows. Работает в два этапа: Targets (что собирать) и Modules (как парсить).

Для быстрого триажа при инциденте берите набор

Код:

!SANS_Triage

:

Bash:

Код:

# Сбор ключевых артефактов с живой системы

KAPE.exe --tsource C: --tdest E:

\

Evidence

\

%m --target

!

SANS_Triage --vhdx %m

Эта команда соберёт Event Logs, реестр, Prefetch, Amcache, $MFT, $UsnJrnl, LNK-файлы, Jump Lists, SRUM и другие артефакты - всё в один VHDX-контейнер. На типичной рабочей станции это занимает 5–15 минут вместо часа на полный образ диска. Разница ощутимая, когда у вас 20 хостов в очереди.

Для парсинга собранного:

Bash:

Код:

# Парсинг всех собранных артефактов через модули Eric Zimmerman

KAPE.exe --msource E:

\

Evidence

\

WORKSTATION01 --mdest E:

\

Parsed

\

WORKSTATION01 --module

!

EZParser

Модуль

Код:

!EZParser

прогонит данные через MFTECmd, PECmd, AmcacheParser, EvtxECmd, LECmd, JLECmd и другие утилиты Eric Zimmerman, выдав на выходе набор CSV-файлов, готовых к анализу.
FTK Imager: образы дисков и дампы памяти
FTK Imager от Exterro - бесплатный инструмент для создания forensic-образов. Три основных сценария:

Дамп RAM: File → Capture Memory → указываете путь на внешний носитель. Получаете .mem-файл для анализа в Volatility.
Образ диска: File → Create Disk Image → формат E01 (с компрессией и верификацией хеша).
Экспорт отдельных файлов: открываете образ или живую систему, навигируете к нужному артефакту (например,

Код:

$MFT

), правый клик → Export Files.

Важный момент: FTK Imager при снятии дампа RAM с живой системы добавляет минимальный footprint, но всё же изменяет содержимое памяти. Записывайте дамп на внешний USB-носитель, а не на диск исследуемой машины. На системах с включённым Secure Boot, HVCI или Credential Guard FTK Imager может не получить полный дамп - в таких случаях попробуйте WinPmem, Magnet RAM Capture или Belkasoft RAM Capturer. Изолированные VBS-области памяти недоступны для любого user-mode инструмента, тут уж ничего не поделаешь.
Velociraptor: удалённый триаж десятков хостов
Когда инцидент затрагивает не один хост, а целый сегмент сети, бегать с флешкой - не вариант. Velociraptor позволяет развернуть агент на эндпоинтах и собирать артефакты удалённо через VQL-запросы (Velociraptor Query Language).

Типичный сценарий: после обнаружения компрометации одного хоста запускаете hunt по всему домену для поиска следов lateral movement:

SQL:

Код:

-- Поиск подозрительных служб на всех эндпоинтах

SELECT

Name

,

DisplayName

,

PathName

,

StartMode

FROM

Artifact

.

Windows

.

System

.

Services

(

)

WHERE

PathName

=

~

"(?i)(temp|public|appdata)"

Velociraptor особенно хорош тем, что позволяет собирать артефакты с десятков хостов параллельно. При инцидентах с шифровальщиками, когда нужно за час определить все скомпрометированные машины, это не просто удобство - это необходимость.
Анализ артефактов Windows: что и где искать
Каждый артефакт отвечает на свой вопрос расследования. Ниже разберу ключевые категории с акцентом на то, что редко освещается в русскоязычных материалах по криминалистическому анализу Windows.
Артефакты файловой системы NTFS: $MFT и $UsnJrnl
Master File Table ($MFT) - центральная таблица файловой системы NTFS. Каждая запись содержит два набора временных меток:

Код:

$STANDARD_INFORMATION

(легко подделать через timestomping) и

Код:

$FILE_NAME

(подделать значительно сложнее). Расхождение между ними - красный флаг.

Парсинг через MFTECmd:

Bash:

Код:

MFTECmd.exe -f

"E:\Evidence\$MFT"

--csv

"C:\Output"

--csvf mft_parsed.csv

В выходном CSV ищите:

Исполняемые файлы в нетипичных путях:

Код:

C:\Windows\Temp\

,

Код:

C:\Users\Public\

,

Код:

C:\ProgramData\
Расхождение

Код:

SI Created

и

Код:

FN Created

- признак timestomping
Записи с

Код:

InUse: false

- удалённые файлы, метаданные которых сохранились
Alternate Data Streams (ADS) - атакующие прячут payload в альтернативных потоках данных

$UsnJrnl (Update Sequence Number Journal) - журнал изменений NTFS. Этот артефакт часто упускают при расследовании, и совершенно напрасно: он хранит хронологию создания, удаления, переименования и модификации файлов. Даже если $MFT-запись уже переиспользована, $UsnJrnl может хранить запись об операции.

Bash:

Код:

# Парсинг $UsnJrnl ($J - альтернативный поток данных $UsnJrnl)

MFTECmd.exe -f

"E:\Evidence\$J"

--csv

"C:\Output"

--csvf usnjrnl_parsed.csv

Сценарий из практики: атакующий удалил свой инструмент после запуска. Запись в $MFT уже перезаписана новым файлом. Но $UsnJrnl сохранил запись

Код:

FileCreate

с именем файла, родительской директорией и временной меткой - этого хватило, чтобы восстановить цепочку событий и привязать бинарник к конкретному времени доставки.
LNK-файлы и Jump Lists: следы обращения к файлам
LNK-файлы - ярлыки, которые Windows автоматически создаёт при открытии файлов. По данным исследования FRSecure, они хранятся в

Код:

C:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Recent

и сохраняются даже после удаления самого файла. Для криминалистического анализа Windows это золото: LNK-файл докажет, что пользователь открывал конкретный документ, даже если тот уже удалён.

Каждый LNK-файл содержит:

Абсолютный путь к целевому файлу
Временные метки создания, модификации и последнего доступа к цели
MAC-адрес машины, на которой файл был изначально создан (из TrackerDataBlock / Distributed Link Tracking; присутствует не во всех LNK-файлах, в Windows 10 1803+ часто не заполняется), и серийный номер тома источника
Размер целевого файла

Парсинг через LECmd:

Bash:

Код:

# Парсинг всех LNK-файлов пользователя

LECmd.exe -d

"E:\Evidence\Users\john\AppData\Roaming\Microsoft\Windows\Recent"

--csv

"C:\Output"

--csvf lnk_parsed.csv

Jump Lists - расширение концепции LNK-файлов на уровне приложений. Согласно данным FRSecure, делятся на два типа:

AutomaticDestinations - автоматически заполняются при запуске приложения, связанного с файлом
CustomDestinations - создаются при закреплении файла в меню Пуск или панели задач

Оба типа хранятся в подпапках директории Recent. Файлы именуются с AppID - идентификатором приложения, который расшифровывается через публичные таблицы соответствий.

Bash:

Код:

# Парсинг Jump Lists

JLECmd.exe -d

"E:\Evidence\Users\john\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations"

--csv

"C:\Output"

--csvf jumplists_parsed.csv

Jump Lists особенно ценны при расследовании утечек данных: они показывают, какие конкретно файлы открывались в каком приложении, с точными временными метками. Если кто-то тянул данные через Excel - Jump Lists это покажут.
SRUM: скрытый журнал запуска программ
System Resource Usage Monitor (SRUM) - артефакт, введённый в Windows 8, который практически не упоминается в русскоязычных материалах по форензике Windows. А зря. Он хранит данные об использовании ресурсов приложениями с дефолтным retention period 30 дней (настраивается через реестр), хотя на практике данные часто живут значительно дольше из-за особенностей механизма очистки.

По данным FRSecure, база SRUM располагается в

Код:

C:\Windows\System32\sru\SRUDB.dat

и содержит:

Полный путь к исполняемым файлам
CPU-время в foreground и background
SID пользователя, запустившего процесс
Объём сетевого трафика по каждому приложению
Временные метки активности

Пока Windows работает, данные SRUM временно хранятся в реестре (

Код:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SRUM\Extensions

) и примерно раз в час сбрасываются в SRUDB.dat. При аварийном выключении не сброшенные данные теряются - поэтому при триаже живой системы собирайте и SRUDB.dat, и куст реестра SOFTWARE. Утилита srum_dump2 объединяет оба источника.

Для парсинга используется SRUM Dump 2 (автор - Mark Baggett):

Bash:

Код:

# Парсинг SRUM с указанием базы и куста реестра SOFTWARE

srum_dump2.exe -i

"E:\Evidence\SRUDB.dat"

-r

"E:\Evidence\SOFTWARE"

На выходе - XLSX-файл с вкладками по категориям: сетевая активность, использование ресурсов, запуск приложений. Вот конкретный пример: SRUM покажет, что на хосте 3 дня назад запускался

Код:

rclone.exe

с передачей 4 ГБ данных на внешний IP - даже если сам бинарник уже удалён. Без SRUM вы бы этого просто не узнали.
Shellbags и UserAssist: цифровые отпечатки действий пользователя
Shellbags фиксируют каждое обращение пользователя к папке через проводник Windows. Данные хранятся в двух местах:

Код:

NTUSER.DAT

(

Код:

HKCU\SOFTWARE\Microsoft\Windows\Shell

) и

Код:

UsrClass.dat

(

Код:

HKCU\SOFTWARE\Classes

). Согласно FRSecure, записи Shellbags сохраняются даже после удаления самой папки - это критически важно при поиске следов доступа к внешним носителям или сетевым шарам.

Bash:

Код:

# Визуальный анализ Shellbags

ShellBagsExplorer.exe

# Загрузите NTUSER.DAT и UsrClass.dat через File → Load offline hive

ShellBags Explorer (Eric Zimmerman) отобразит дерево всех директорий, к которым обращался пользователь, с временными метками первого и последнего доступа. Типичный сценарий: ищете следы эксфильтрации - Shellbags покажут, что пользователь заходил в

Код:

\\fileserver\finance\reports

Код:

E:\backup

(USB-носитель) в один и тот же день. Совпадение? Не думаю.

UserAssist - ключ реестра в

Код:

NTUSER.DAT

, который записывает каждый запуск GUI-приложения. По данным FRSecure, имена программ кодируются ROT-13 (да, серьёзно - простейшая подстановка букв, «защита» уровня детского шифра), а для каждой записи фиксируется количество запусков и время последнего запуска.

Парсинг через Registry Explorer или RegRipper:

Bash:

Код:

rip.exe -r

"E:\Evidence\Users\john\NTUSER.DAT"

-p userassist

UserAssist покажет, что пользователь дважды запускал

Код:

mstsc.exe

(Remote Desktop) и один раз -

Код:

cmd.exe

в конкретное время. В связке с данными Event Logs это формирует полную картину действий пользователя.
Форензика реестра Windows: карта закрепления атакующего
Реестр - основной механизм persistence для атакующего. Кусты

Код:

SAM

Код:

SECURITY

Код:

SOFTWARE

Код:

SYSTEM

лежат в

Код:

C:\Windows\System32\config\

. Пользовательские кусты

Код:

NTUSER.DAT

- в профиле каждого пользователя.

Ключевые ветки для поиска закрепления, с привязкой к верифицированным техникам MITRE ATT&CK:

Registry Run Keys / Startup Folder (T1547.001, persistence, privilege-escalation):

В кусте

Код:

SOFTWARE

Код:

Microsoft\Windows\CurrentVersion\Run
Код:

Microsoft\Windows\CurrentVersion\RunOnce

Код:

NTUSER.DAT

- те же ключи, но для конкретного пользователя. Плюс:

Код:

Environment\UserInitMprLogonScript

- скрипт, выполняемый при логоне

Windows Service (T1543.003, persistence, privilege-escalation):

Службы описаны в

Код:

SYSTEM\CurrentControlSet\Services\

. Поле

Код:

ImagePath

указывает на исполняемый файл. Атакующий создаёт вредоносную службу или подменяет существующую.

Services Registry Permissions Weakness (T1574.011, persistence, privilege-escalation, defense-evasion):

Если ACL на ключах реестра служб настроены криво, атакующий может подменить

Код:

ImagePath

легитимной службы - создавать новую не требуется.

Scheduled Task (T1053.005, execution, persistence, privilege-escalation):

Задачи хранятся как XML в

Код:

C:\Windows\System32\Tasks\

и регистрируются в реестре. Ищите нестандартные задачи с подозрительными путями к исполняемым файлам.

BITS Jobs (T1197, defense-evasion, persistence):

Background Intelligent Transfer Service используется для скачивания файлов. Атакующие применяют

Код:

bitsadmin

для загрузки payload и закрепления через задания BITS - удобно и тихо, потому что BITS-трафик часто не мониторят.

Автоматизированный поиск persistence через RegRipper:

Bash:

Код:

# Извлечение всех точек закрепления из куста SOFTWARE

rip.exe -r

"E:\Evidence\config\SOFTWARE"

-p soft_run

# Анализ служб из куста SYSTEM

rip.exe -r

"E:\Evidence\config\SYSTEM"

-p services

На что обращать внимание:

Пути к исполняемым файлам за пределами

Код:

Program Files

и

Код:

Windows
Base64-кодированные команды PowerShell в значениях ключей
Timestamp последнего изменения ключа - момент установки закрепления

Анализ журналов событий Windows
Event Logs - первый источник, за который берётся DFIR-аналитик. Файлы

Код:

.evtx

лежат в

Код:

C:\Windows\System32\winevt\Logs\

. По данным Belkasoft, Windows ведёт три основных журнала (Security, System, Application), журнал Setup, а также десятки операционных логов отдельных компонентов. При настроенном Windows Event Forwarding события агрегируются в журнал Forwarded Events. Для DFIR критически важны операционные логи: Microsoft-Windows-Sysmon/Operational, Microsoft-Windows-PowerShell/Operational, Microsoft-Windows-TerminalServices-LocalSessionManager/Operational.

Ключевые Event ID при расследовании:

Event IDЖурналЗначение4624SecurityУспе шный логон (Logon Type 3 = сетевой, Type 10 = RDP)4625SecurityНеудачная попытка логона4648SecurityЛогон с явным указанием учётных данных4688SecurityСоздание процесса (если включён аудит)4720SecurityСоздание учётной записи7045SystemУстановка новой службы1116Microsoft-Windows-DefenderОбнаружение вредоносного ПО4672SecurityНазначение специальных привилегий (индикатор admin-логона)1102SecurityОчистка журнала аудита (антифорензика)4697SecurityУстан овка службы (аналог 7045 в Security)4104Microsoft-Windows-PowerShell/OperationalScriptBlock logging (содержимое выполненных скриптов)1Microsoft-Windows-Sysmon/OperationalСоздание процесса (с хешами и parent process)3Microsoft-Windows-Sysmon/OperationalСетевое соединение процесса

Примечание: Sysmon-события (ID 1, 3) и расширенное логирование PowerShell (ID 4104) требуют предварительной настройки - по умолчанию они не включены. Если у вас в инфраструктуре не настроен Sysmon - считайте, что вы расследуете инцидент с одним глазом закрытым.

Парсинг через EvtxECmd:

Bash:

Код:

EvtxECmd.exe -d

"E:\Evidence\winevt\Logs"

--csv

"C:\Output"

--csvf all_events.csv

Согласно рекомендации Belkasoft, интеграция Sigma-правил значительно ускоряет анализ. Sigma - универсальный формат описания правил детектирования для журналов событий. Hayabusa (open-source) применяет Sigma-правила к EVTX-файлам и выдаёт отфильтрованные подозрительные события:

Bash:

Код:

# Анализ журналов событий с применением Sigma-правил

hayabusa.exe csv-timeline -d

"E:\Evidence\winevt\Logs"

-o

"C:\Output\sigma_hits.csv"

Паттерн, который стоит запомнить: Event ID 4624 с Logon Type 3 и практически одновременный Event ID 7045 в System.evtx с установкой службы - классическая сигнатура PsExec или аналогичного инструмента lateral movement. Увидели такую пару - копайте глубже.
Memory forensics Windows: анализ оперативной памяти
Дамп оперативной памяти - самый волатильный и одновременно самый ценный источник доказательств. В RAM лежат расшифрованные данные, инжектированный код, активные сетевые соединения - всё то, что не попадает на диск при использовании fileless-техник. Нет дампа памяти - нет половины картины.

После снятия дампа через FTK Imager анализ проводится в Volatility 3:

Bash:

Код:

# Список запущенных процессов с родительскими PID

python vol.py -f

"E:\Evidence\memory.mem"

windows.pstree

# Сетевые соединения (активные и закрытые)

python vol.py -f

"E:\Evidence\memory.mem"

windows.netscan

# Поиск инжектированного кода в процессах

python vol.py -f

"E:\Evidence\memory.mem"

windows.malfind

# Извлечение командных строк процессов

python vol.py -f

"E:\Evidence\memory.mem"

windows.cmdline

На что обращать внимание при анализе:

Процессы с нетипичными родителями:

Код:

svchost.exe

с parent не

Код:

services.exe

- это сразу подозрительно
Процессы с подозрительными путями:

Код:

cmd.exe

запущен из

Код:

C:\Temp\
Сетевые соединения к внешним IP от системных процессов
Код:

malfind

покажет участки памяти с правами RWX (Read-Write-Execute) - типичный индикатор инжекции кода

Лично я начинаю с

Код:

pstree

- дерево процессов сразу показывает аномалии в иерархии. Если

Код:

powershell.exe

порождён

Код:

wmiprvse.exe

- это почти наверняка lateral movement через WMI.
Построение timeline: от артефактов к хронологии атаки
Отдельные артефакты - это фрагменты пазла. Ценность расследования - в их корреляции. Timeline analysis объединяет все временные метки из всех источников в единую хронологию.
Super Timeline через plaso
Plaso (log2timeline) - стандартный инструмент для создания super timeline из образа диска:

Bash:

Код:

# Создание super timeline из образа диска

log2timeline.py timeline.plaso E:

\

Evidence

\

disk_image.E01

# Фильтрация и экспорт в CSV

psort.py -o l2tcsv timeline.plaso -w timeline.csv

"date > '2024-03-15 00:00:00' AND date  connections.txt

Код:

tasklist /v > processes.txt

(флаг

Код:

-b

требует прав администратора)
[*]Зафиксировать системное время:

Код:

w32tm /query /status

[/LIST]Фаза 2 - Сбор артефактов триажа (15–30 минут)

Запустить KAPE с таргетом

Код:

!SANS_Triage

на внешний носитель
Убедиться, что собраны: Event Logs, реестр, $MFT, $UsnJrnl, Prefetch, Amcache, SRUM, LNK, Jump Lists

Фаза 3 - Полный образ (если требуется)

Создать E01-образ диска через FTK Imager с верификацией хеша
Зафиксировать хеш-суммы MD5 и SHA1 в протоколе

Фаза 4 - Анализ (на forensic-станции)

Парсинг артефактов через KAPE

Код:

!EZParser

или вручную через EZ Tools
Прогон Event Logs через Hayabusa с Sigma-правилами
Анализ RAM через Volatility 3:

Код:

pstree

,

Код:

netscan

,

Код:

malfind

,

Код:

cmdline
Построение timeline - plaso или ручная корреляция
Маппинг обнаруженных действий на техники MITRE ATT&CK
Документирование цепочки атаки с доказательной базой

Фаза 5 - Проверка масштаба

Поиск IOC (хеши, IP, имена файлов) на других хостах через Velociraptor или SIEM
Проверка VSS на скомпрометированных хостах для восстановления затёртых доказательств

Каждый этап документируйте: время начала, время завершения, хеш-суммы собранных данных, используемые инструменты. Без документирования ваши доказательства - просто набор файлов, которые ничего не докажут.
Заключение
Форензика Windows при расследовании инцидентов - это выстроенная методика с чётким порядком действий, а не набор разрозненных техник, которые применяют по настроению.

Порядок волатильности определяет последовательность сбора - RAM первым, образ диска последним
Ни один артефакт не работает в изоляции - сила расследования в корреляции Event Logs, MFT, реестра, Prefetch, SRUM и других источников
Артефакты, которые часто упускают (SRUM, LNK, Jump Lists, Shellbags, $UsnJrnl), нередко содержат доказательства, отсутствующие в более очевидных местах
Автоматизация сбора через KAPE и Velociraptor критична при масштабных инцидентах
Документирование каждого шага - без цепочки хранения доказательств вся работа бесполезна

Описанная методика покрывает большинство типовых инцидентов: от шифровальщиков до инсайдерских утечек. Соберите forensic-kit на флешку, отработайте порядок действий на тестовых образах (потренируйтесь - CyberDefenders и DFIR.training дают отличные лабы). Потому что когда алерт прилетает в два часа ночи, времени на чтение документации уже не будет.