Сергей Попов
14.04.2026, 17:30
https://forum.antichat.xyz/attachments/4951520/img_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) - рабочая лошадка для автоматизированного сбора и парсинга артефактов (https://forum.antichat.xyz/threads/592462/) 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\Wind ows\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\W indows\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\W indows\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: анализ оперативной памяти (https://forum.antichat.xyz/threads/592199/)
Дамп оперативной памяти - самый волатильный и одновременно самый ценный источник доказательств. В 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 дают отличные лабы). Потому что когда алерт прилетает в два часа ночи, времени на чтение документации уже не будет.
Два часа ночи. Уведомление от 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) - рабочая лошадка для автоматизированного сбора и парсинга артефактов (https://forum.antichat.xyz/threads/592462/) 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\Wind ows\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\W indows\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\W indows\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: анализ оперативной памяти (https://forum.antichat.xyz/threads/592199/)
Дамп оперативной памяти - самый волатильный и одновременно самый ценный источник доказательств. В 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 дают отличные лабы). Потому что когда алерт прилетает в два часа ночи, времени на чтение документации уже не будет.