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

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

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

Порядок сбора доказательств при инциденте​

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

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

1. Оперативная память (RAM) - теряется при выключении. Содержит ключи шифрования, инжектированный код, активные сетевые соединения, аргументы командной строки запущенных процессов.
2. Сетевые соединения и таблицы маршрутизации - меняются каждую секунду. Снимите netstat -anob и arp -a до любых других действий.
3. Pagefile и Hiberfil.sys - могут быть перезаписаны при активной работе системы.
4. Event Logs - перезаписываются по достижении лимита размера. Атакующий может очистить журналы целенаправленно.
5. Реестр, Prefetch, Amcache - сохраняются на диске, но могут быть затёрты при перезагрузке или обновлении.
6. MFT и $UsnJrnl - более устойчивы, но записи переиспользуются.
7. Полный образ диска - наименее волатильный, но требует времени на создание.

На практике: пришли к хосту - первым делом снимаете дамп RAM, потом собираете артефакты триажа через KAPE, и только затем, если есть время и необходимость, создаёте полный образ диска. Перезагружать хост до снятия памяти - недопустимо. Точка.

Инструменты форензики Windows для сбора артефактов​

Выбор инструмента зависит от сценария: физический доступ к хосту, удалённый триаж десятков машин или работа с уже снятым образом. Разберу три инструмента, которые закрывают большинство задач при расследовании инцидентов.

KAPE: автоматический сбор артефактов Windows​

KAPE (Kroll Artifact Parser and Extractor) - рабочая лошадка для автоматизированного сбора и парсинга артефактов Windows. Работает в два этапа: Targets (что собирать) и Modules (как парсить).

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

# Сбор ключевых артефактов с живой системы
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 хостов в очереди.

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

# Парсинг всех собранных артефактов через модули 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:

-- Поиск подозрительных служб на всех эндпоинтах
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:

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 может хранить запись об операции.

# Парсинг $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:

# Парсинг всех 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 - идентификатором приложения, который расшифровывается через публичные таблицы соответствий.

# Парсинг 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):

# Парсинг 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 сохраняются даже после удаления самой папки - это критически важно при поиске следов доступа к внешним носителям или сетевым шарам.

# Визуальный анализ 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:

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:

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

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

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

EvtxECmd.exe -d "E:\Evidence\winevt\Logs" --csv "C:\Output" --csvf all_events.csv

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

# Анализ журналов событий с применением 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:

# Список запущенных процессов с родительскими 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 из образа диска:

# Создание 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 < '2024-03-16 00:00:00'"

Super timeline объединяет метки из MFT, Event Logs, Prefetch, реестра, браузерной истории и десятков других источников. Фильтрация по временному диапазону позволяет сфокусироваться на окне инцидента.

Ручная корреляция артефактов​

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

14:28 - Event ID 4624, Logon Type 10 (RDP) от нетипичного хоста → начальный доступ

14:31 - Запись в $MFT: создан файл C:\Windows\Temp\svc.exe → доставка инструмента

14:31 - $UsnJrnl: FileCreate для svc.exe в \Windows\Temp\ → подтверждение

14:32 - Prefetch: появился файл SVC.EXE-A1B2C3D4.pf → доказательство запуска

14:32 - Amcache: запись о svc.exe с SHA1-хешем → идентификация бинарника

14:32 - SRUM: svc.exe зафиксирован с сетевой активностью → связь с C2

14:33 - Event ID 7045: создана служба WindowsUpdateSvc с путём к svc.exe → закрепление (T1543.003)

14:35 - Event ID 4624, Logon Type 3 на соседнем хосте → lateral movement

Каждый артефакт подтверждает данные остальных. Ни один из них в отдельности не дал бы полной картины. Именно в корреляции - сила форензики.

Volume Shadow Copy: восстановление затёртых доказательств​

Volume Shadow Copy Service (VSS) - встроенный механизм Windows для создания точек восстановления. Для расследования инцидентов VSS - это машина времени: если атакующий удалил свои инструменты или очистил журналы, предыдущие теневые копии могут содержать нетронутые версии этих артефактов.

# Просмотр доступных теневых копий
vssadmin list shadows

# Монтирование теневой копии для анализа (через mklink)
mklink /d C:\VSS_Mount \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\

После монтирования вы получаете доступ к файловой системе на момент создания снимка - включая Event Logs, реестр, Prefetch и любые другие артефакты. Сравнение текущего состояния с состоянием из VSS позволяет обнаружить, что именно было удалено или изменено атакующим. На одном расследовании именно VSS помог восстановить Event Logs, которые атакующий аккуратно вычистил - а про теневые копии забыл.

Сравнение инструментов форензики Windows​

Инструмент	Тип	Сценарий	Сильная сторона	Ограничение
KAPE	Сбор и парсинг	Триаж живой системы	Скорость, модульность	Нет GUI для анализа
FTK Imager	Imaging, экспорт	Снятие образов и RAM	Бесплатный, надёжный	Нет парсинга артефактов
Velociraptor	Удалённый сбор	Массовый триаж по сети	Масштабируемость, VQL	Требует развёртывания сервера
Autopsy	Анализ образов	Глубокий анализ диска	Бесплатный, плагины	Медленный на больших образах
Volatility 3	Memory forensics	Анализ дампов RAM	Детекция инжекций, rootkit	Только командная строка
Eric Zimmerman Tools	Парсинг артефактов	Разбор конкретных артефактов	Точность, скорость	Каждый артефакт - отдельная утилита
Hayabusa	Event Log анализ	Быстрый triage по Sigma	Автоматическая детекция	Только журналы событий

По данным сравнительного анализа Cyber Triage, при выборе платформы для анализа стоит учитывать шесть параметров: скорость обработки, покрытие артефактов, автоматический анализ, возможности автоматизации, коллаборация и стоимость. Для задач DFIR в корпоративной среде оптимальная комбинация, которую я бы рекомендовал: KAPE для сбора, Eric Zimmerman Tools для парсинга, Volatility 3 для памяти и Hayabusa для быстрого анализа журналов.

Чек-лист сбора доказательств при инциденте​

Этот чек-лист - порядок действий при реагировании. Выполняйте строго по порядку:

Фаза 1 - Фиксация волатильных данных (первые 15 минут)

1. Снять дамп RAM через FTK Imager на внешний носитель
2. Выполнить из elevated (Run as Administrator) командной строки: netstat -anob > connections.txt и tasklist /v > processes.txt (флаг -b требует прав администратора)
3. Зафиксировать системное время: w32tm /query /status

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

1. Запустить KAPE с таргетом !SANS_Triage на внешний носитель
2. Убедиться, что собраны: Event Logs, реестр, $MFT, $UsnJrnl, Prefetch, Amcache, SRUM, LNK, Jump Lists

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

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

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

1. Парсинг артефактов через KAPE !EZParser или вручную через EZ Tools
2. Прогон Event Logs через Hayabusa с Sigma-правилами
3. Анализ RAM через Volatility 3: pstree, netscan, malfind, cmdline
4. Построение timeline - plaso или ручная корреляция
5. Маппинг обнаруженных действий на техники MITRE ATT&CK
6. Документирование цепочки атаки с доказательной базой

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

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

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

Заключение​

Форензика Windows при расследовании инцидентов - это выстроенная методика с чётким порядком действий, а не набор разрозненных техник, которые применяют по настроению.

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

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