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

Когда SOC-аналитику прилетает алерт о компрометации хоста, начинается гонка со временем. Атакующий мог закрепиться через реестр, запустить разведку, прыгнуть латерально на соседний хост - и всё это оставило следы в десятках системных артефактов. Загвоздка в том, что ни один артефакт сам по себе полной картины не даёт. Event Log покажет факт логона, но промолчит про запущенный бинарник. Prefetch подтвердит запуск, но не скажет, откуда файл вообще взялся на диске. MFT хранит временные метки, но без контекста из реестра они - просто цифры.

Здесь я разберу пять категорий артефактов Windows - Event Logs, MFT, реестр, Prefetch и Amcache - и покажу, как их анализировать на практике: конкретные команды, инструменты Эрика Циммермана, интерпретация вывода. Не абстрактные списки «что бывает», а пошаговый процесс расследования инцидента с корреляцией данных между артефактами и построением единого таймлайна.

Зачем нужна корреляция артефактов Windows​

Типичный сценарий: на рабочей станции сработал EDR на подозрительный процесс. Аналитик SOC уровня L1 зафиксировал алерт, но процесс уже завершился. Что произошло? Как атакующий попал на хост? Есть ли persistence? Куда он двинулся дальше?

Каждый из пяти основных артефактов Windows forensics отвечает на свою часть вопроса:

Артефакт	Что показывает	Где лежит
Event Logs	Логоны, создание процессов, установка служб	C:\Windows\System32\winevt\Logs\
$MFT	Создание, изменение, удаление файлов с временными метками	Корень тома NTFS
Реестр	Persistence, конфигурация системы, история USB	C:\Windows\System32\config\, NTUSER.DAT
Prefetch	Факт и время запуска исполняемых файлов	C:\Windows\Prefetch\
Amcache / ShimCache	История выполнения программ, метаданные бинарников	C:\Windows\appcompat\Programs\Amcache.hve, реестр SYSTEM

Сила DFIR-расследования - в перекрёстной валидации. Prefetch показывает запуск mimikatz.exe в 14:32, Event Log фиксирует Event ID 4624 типа 3 (сетевой логон) в 14:30 с нетипичного хоста, MFT подтверждает создание файла mimikatz.exe в 14:31 - картина складывается. Без корреляции каждый из этих фактов по отдельности мог быть пропущен или неверно интерпретирован.

Анализ Event Logs Windows: первый рубеж расследования​

Журналы событий Windows - первое, куда лезет DFIR-аналитик. Файлы .evtx лежат в C:\Windows\System32\winevt\Logs\ и содержат структурированные записи обо всём - от логонов до создания процессов. По данным INCIBE, Event Logs позволяют реконструировать хронологию событий, идентифицировать активность пользователей и атакующих, обнаружить вредоносную деятельность.

Ключевые Event ID для DFIR-аналитика​

Не все журналы одинаково полезны. Вот набор Event ID, которые я проверяю первыми при каждом расследовании:

Security.evtx - аутентификация и доступ:

Event ID	Описание	На что смотреть
4624	Успешный логон	Поле Logon Type: 2 = интерактивный, 3 = сетевой, 10 = RDP. Источник (Workstation Name, Source Network Address)
4625	Неудачный логон	Массовые попытки = брутфорс. Код ошибки: 0xC000006D = неверный пароль
4672	Назначение специальных привилегий	Любой логон с привилегиями SeDebugPrivilege - подозрителен
4688	Создание процесса	Командная строка процесса (если включён аудит). Родительский процесс
4720	Создание учётной записи	Атакующий создал бэкдор-аккаунт

System.evtx - службы и драйверы:

Event ID	Описание	Значение для расследования
7045	Установка новой службы	PSExec, Cobalt Strike - все создают службы. Поле Service File Name критично
7036	Изменение состояния службы	Старт/стоп подозрительных служб

Microsoft-Windows-PowerShell/Operational.evtx:

Event ID	Описание	Значение для расследования
4104	Script Block Logging	Полный текст выполненных PowerShell-скриптов, включая деобфусцированный код

Практика: извлечение и парсинг Event Logs​

На живой системе можно быстро отфильтровать интересные события через PowerShell. Для поиска неудачных логонов (рекомендация INCIBE):

Get-WinEvent -LogName Security | Where-Object {$_.Id -eq 4625} | Select-Object TimeCreated, Message

Но при работе с образом диска нужны другие инструменты. Для офлайн-анализа я использую EvtxECmd из набора Eric Zimmerman Tools:

# Парсим все evtx-файлы в CSV для дальнейшего анализа
EvtxECmd.exe -d "E:\C\Windows\System32\winevt\Logs" --csv "C:\Output" --csvf timeline_events.csv

Результат - CSV-файл, который загружаем в Timeline Explorer (тоже EZ Tools) и фильтруем по Event ID, времени, пользователю. Искать нужно аномалии: логоны в нерабочее время, сетевые логоны (Type 3) от неизвестных хостов, установку служб с подозрительными путями к бинарникам.

Ещё один приём, который лично у меня срабатывает чаще, чем хотелось бы: если в Security.evtx вы видите Event ID 4624 с Logon Type 3 и тут же Event ID 7045 в System.evtx с установкой службы - это классический паттерн PSExec или аналогичного инструмента для lateral movement. Две записи с разницей в пару секунд - и вектор перемещения как на ладони.

MFT анализ NTFS: файловая система как свидетель​

Master File Table ($MFT) - сердце файловой системы NTFS. Каждый файл и каталог на томе имеет запись в MFT с четырьмя временными метками (MACE): Modified, Accessed, Changed ($MFT entry), Entry created (birth). Нюанс: начиная с Windows Vista, метка Last Access по умолчанию не обновляется при чтении файла (параметр NtfsDisableLastAccessUpdate), так что Access time может врать. Даже если файл удалён, его запись в MFT может сохраняться до тех пор, пока не будет перезаписана новой.

Что хранит запись MFT и почему это важно​

Каждая MFT-запись содержит два набора временных меток:

• $STANDARD_INFORMATION ($SI) - стандартные метки, которые обновляет ОС и которые легко подделывает атакующий (timestomping)
• $FILE_NAME ($FN) - метки, обновляемые только при определённых операциях с файлом, подделать их значительно сложнее

Расхождение между $SI и $FN - классический индикатор timestomping. $SI показывает дату создания в 2019 году, а $FN - в 2024? Файл однозначно подкрутили для маскировки.

Практика: анализ MFT через MFTECmd​

Для извлечения $MFT из образа - FTK Imager: открываем образ, переходим в корень тома, правой кнопкой на $MFT → Export Files. Дальше парсим:

# Парсинг $MFT в формат CSV
MFTECmd.exe -f "C:\Evidence\$MFT" --csv "C:\Output" --csvf mft_parsed.csv

Что искать в выводе MFTECmd:

1. Подозрительные пути - исполняемые файлы в C:\Windows\Temp\, C:\Users\Public\, C:\ProgramData\ (любимые директории атакующих - туда пишется без лишних привилегий)
2. Расхождение SI и FN timestamps - признак timestomping. В CSV-выводе MFTECmd есть отдельные колонки для обоих наборов меток
3. Удалённые файлы - записи с флагом InUse: false. Файл удалён, но метаданные на месте
4. ADS (Alternate Data Streams) - атакующие прячут payload в альтернативных потоках данных. MFTECmd их покажет

Пример: нашли запись для C:\Windows\Temp\svchost.exe с датой создания 2024-03-15 14:31:02. Легитимный svchost.exe живёт в System32, а не в Temp. Фиксируем временную метку и идём в Prefetch - был ли этот самозванец запущен?

Форензика реестра Windows: карта закрепления атакующего​

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

Системные кусты (SAM, SECURITY, SOFTWARE, SYSTEM) лежат в C:\Windows\System32\config\. Пользовательские (NTUSER.DAT, UsrClass.dat) - в профиле каждого пользователя.

Ключи автозагрузки и закрепления​

Основные ветки реестра, через которые атакующие обеспечивают persistence, с привязкой к техникам MITRE ATT&CK:

Ссылка скрыта от гостей

(T1547.001, persistence, privilege-escalation):

В кусте SOFTWARE (закрепление с правами системы/администратора):

• Microsoft\Windows\CurrentVersion\Run
• Microsoft\Windows\CurrentVersion\RunOnce
• Microsoft\Windows\CurrentVersion\RunServices
• Microsoft\Windows\CurrentVersion\RunServicesOnce

В кусте NTUSER.DAT (закрепление с правами пользователя):

• Те же ключи Run, RunOnce - но для конкретного пользователя

Дополнительно в SOFTWARE:

• Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit - подмена процесса инициализации при логоне
• Microsoft\Windows NT\CurrentVersion\Winlogon\Shell - подмена оболочки

Logon Script - Windows (T1037.001, persistence, privilege-escalation):

Скрипты входа, привязанные к профилю пользователя через NTUSER.DAT:

• Environment\UserInitMprLogonScript - путь к скрипту, выполняемому при логоне

Ссылка скрыта от гостей

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

Задачи хранятся как XML в C:\Windows\System32\Tasks\ и регистрируются в реестре. Ищите нестандартные задачи с подозрительными путями к исполняемым файлам.

Create or Modify System Process: Windows Service (T1543.003, persistence, privilege-escalation):

Службы описаны в SYSTEM\CurrentControlSet\Services\. Каждый подключ - отдельная служба. Поле ImagePath указывает на исполняемый файл. Атакующий может создать собственную вредоносную службу или подменить существующую.

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

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

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

Background Intelligent Transfer Service используется для скачивания файлов. Злоумышленники применяют bitsadmin для загрузки payload и закрепления через задания BITS.

Практика: разбор реестра через Registry Explorer и RegRipper​

Для визуального анализа реестра из образа диска - Registry Explorer (EZ Tools). Загружаете куст (например, SOFTWARE из C:\Windows\System32\config\), переходите к нужному ключу и видите значения с Last Write Time.

Для автоматизации - RegRipper:

# Вытаскиваем persistence из куста SOFTWARE
rip.exe -r "E:\C\Windows\System32\config\SOFTWARE" -p soft_run

Плагин soft_run покажет все значения в ключах Run/RunOnce. На что смотреть:

• Пути к исполняемым файлам за пределами Program Files и Windows
• Base64-encoded команды PowerShell в значениях (классика жанра)
• Timestamp последнего изменения ключа - когда именно было создано закрепление

Для системной информации перед анализом:

# Имя компьютера, версия ОС, временная зона
rip.exe -r "E:\C\Windows\System32\config\SYSTEM" -p compname
rip.exe -r "E:\C\Windows\System32\config\SOFTWARE" -p winver
rip.exe -r "E:\C\Windows\System32\config\SYSTEM" -p timezone

Знание временной зоны критично - все дальнейшие временные метки нужно приводить к единому формату UTC. Забудете про это - потом будете час искать «пропавшие» два часа в таймлайне.

Prefetch файлы: доказательство запуска программ​

Prefetch - механизм Windows для ускорения повторного запуска приложений. С точки зрения форензики - доказательство того, что конкретный бинарник был выполнен на системе. По данным INCIBE, даже если исполняемый файл удалён, его след может остаться в Prefetch с именем, расположением и датой запуска.

Файлы .pf лежат в C:\Windows\Prefetch\. Имя файла формируется по схеме: ИМЯПРОЦЕССА-ХЕШПУТИ.pf, где хеш рассчитывается от пути запуска. Это позволяет отличить cmd.exe, запущенный из System32, от cmd.exe из Temp - а разница, сами понимаете, принципиальная.

Эволюция Prefetch по версиям Windows​

Поведение Prefetch различается в зависимости от версии ОС:

Версия Windows	Лимит файлов	Особенности
XP - Windows 7	128	Базовый Prefetch
Windows 8+	1024	Интеграция с SuperFetch/SysMain, сжатие MAM
Windows 10/11	1024	Сохраняет до 8 последних временных меток запуска
Windows Server	Отключён по умолчанию	Требует ручного включения через реестр

На серверных ОС Prefetch по умолчанию отключён. Если расследуете инцидент на сервере и Prefetch пуст - это не значит, что ничего не запускалось. Идите в Amcache и ShimCache.

Практика: парсинг Prefetch через PECmd​

# Парсинг всех Prefetch-файлов в директории
PECmd.exe -d "E:\C\Windows\Prefetch" --csv "C:\Output" --csvf prefetch_all.csv

# Парсинг конкретного файла с детальным выводом
PECmd.exe -f "E:\C\Windows\Prefetch\MIMIKATZ.EXE-12F4A52B.pf"

Что покажет PECmd в детальном режиме:

• Executable Name - имя запущенного процесса
• Run Count - сколько раз запускался
• Last Run - до 8 последних временных меток запуска (Windows 10/11)
• Volume information - буква тома и серийный номер
• Directories referenced - директории, к которым обращался процесс
• Files referenced - файлы, которые процесс загрузил (DLL, конфигурации)

Обнаружили PSEXESVC.EXE-[I].pf? След PsExec на целевом хосте - подтверждение lateral movement. Видите POWERSHELL.EXE-[/I].pf с Run Count = 47 на машине бухгалтера? Это как минимум повод залезть в логи PowerShell (Event ID 4104). Бухгалтеры PowerShell не запускают 47 раз. Никогда.

Для быстрого списка Prefetch-файлов на живой системе:

Get-ChildItem -Path C:\Windows\Prefetch -Filter *.pf | Select-Object Name, LastWriteTime | Sort-Object LastWriteTime -Descending

Amcache и ShimCache: артефакты расследования выполнения программ​

Amcache и ShimCache (AppCompatCache) - два родственных, но разных артефакта, которые фиксируют информацию о программах в системе. По данным Magnet Forensics,

Ссылка скрыта от гостей

о выполнении программ на Windows-системах. Понимание различий между ними критично для корректной интерпретации - путать их между собой на расследовании чревато ложными выводами.

Amcache.hve: что внутри​

Amcache.hve - отдельный куст реестра в C:\Windows\appcompat\Programs\Amcache.hve. Хранит:

• Полный путь к исполняемому файлу
• SHA1-хеш файла (можно тут же проверить по базам IOC)
• Размер файла
• Временные метки (компиляции, модификации)
• Информацию об издателе (Publisher)
• Данные об установленных программах и драйверах

Ключевое свойство Amcache - наличие SHA1-хеша. Получили хеш подозрительного бинарника - тут же на VirusTotal или по внутренним IOC-спискам. Лично я начинаю именно с хешей из Amcache: это самый быстрый способ отсеять известную малварь от легитимного софта.

ShimCache (AppCompatCache): разница с Amcache​

ShimCache хранится в кусте реестра SYSTEM по пути CurrentControlSet\Control\Session Manager\AppCompatCache. Различия существенные:

Характеристика	Amcache	ShimCache
Хранилище	Отдельный куст Amcache.hve	Внутри куста SYSTEM
SHA1-хеш	Да	Нет
Подтверждает запуск	Не абсолютное доказательство - записи могут появляться при установке ПО. Подтверждайте через Prefetch или Event ID 4688	Не всегда (может фиксировать и незапущенные файлы)
Запись в реестр	В реальном времени	При выключении/перезагрузке системы
Порядок записей	Хронологический	Стек (LIFO - последний вошёл, первый вышел)

Критический нюанс: ShimCache не гарантирует, что файл был запущен. Он фиксирует факт обращения к файлу подсистемой совместимости приложений - а это может произойти и при простом просмотре директории в Explorer. Поэтому данные ShimCache нужно подтверждать через Prefetch или Amcache. Без перекрёстной проверки рискуете написать в отчёте «запускался», когда на самом деле «просто лежал».

Практика: AmcacheParser и AppCompatCacheParser​

# Парсинг Amcache
AmcacheParser.exe -f "E:\C\Windows\appcompat\Programs\Amcache.hve" --csv "C:\Output" --csvf amcache.csv

# Парсинг ShimCache из куста SYSTEM
AppCompatCacheParser.exe -f "E:\C\Windows\System32\config\SYSTEM" --csv "C:\Output" --csvf shimcache.csv

В выводе AmcacheParser ищите:

• Бинарники с подозрительными путями (Temp, Public, AppData)
• Файлы без цифровой подписи (Publisher = пусто) в системных директориях
• SHA1-хеши - проверяйте через threat intelligence платформы

В выводе AppCompatCacheParser обратите внимание на поле Executed (True/False, если определено) и Last Modified Time - сопоставляйте с данными из MFT и Prefetch.

Собираем пазл: корреляция артефактов и построение таймлайна​

Отдельные артефакты - фрагменты. Реальная картина инцидента появляется, когда выстраиваешь единую временную шкалу.

Сценарий: реконструкция lateral movement​

Допустим, в ходе анализа обнаружилось следующее:

1. Event Log (Security.evtx): Event ID 4624, Logon Type 3, Source: 10.0.1.15, User: admin, Time: 2024-03-15 14:30:05 UTC
2. Event Log (System.evtx): Event ID 7045, Service Name: PSEXESVC, Service File Name: %SystemRoot%\PSEXESVC.exe, Time: 14:30:07
3. MFT: Запись для C:\Windows\PSEXESVC.exe, Created ($SI): 14:30:06, Created ($FN): 14:30:06 - метки совпадают, timestomping отсутствует
4. Prefetch: [URL='https://attack.mitre.org/techniques/T1570/']PSEXESVC.EXE[/URL]-AD70946C.pf, Run Count: 1, Last Run: 14:30:07
5. ShimCache: Запись для C:\Windows\PSEXESVC.exe, Last Modified: 14:30:06

Читаем: в 14:30 с хоста 10.0.1.15 - сетевой логон (Type 3) под учёткой admin. Через 2 секунды на диске появился PSEXESVC.exe (MFT), тут же зарегистрирован как служба (Event ID 7045) и запущен (Prefetch фиксирует один запуск). Классический PsExec для lateral movement - пять артефактов, одна история.

Super timeline через Plaso​

Для масштабного расследования, где нужно скоррелировать тысячи артефактов, есть log2timeline/Plaso - парсит десятки типов артефактов и собирает единую временную шкалу:

# Создание super timeline из образа диска (долгий процесс, можно идти за кофе)
log2timeline.py --storage-file timeline.plaso /path/to/disk/image.E01

# Фильтрация и экспорт в CSV
psort.py -o l2tcsv timeline.plaso "date > '2024-03-15 00:00:00' AND date < '2024-03-16 00:00:00'" -w filtered_timeline.csv

Plaso автоматически парсит Event Logs, MFT, Prefetch, Amcache, реестр, LNK-файлы, журналы браузеров и десятки других источников. Результат - единый CSV, где события из разных артефактов выстроены хронологически. Загружаете в Timeline Explorer и видите полную последовательность действий атакующего.

Чек-лист DFIR-аналитика: порядок анализа артефактов​

Практический порядок действий при расследовании инцидента на Windows-хосте:

Шаг 1 - подготовка:

• Снять побитовую копию диска (dd, FTK Imager, R-Studio)
• Примонтировать образ в режиме «только чтение»
• Зафиксировать временную зону из реестра (SYSTEM\CurrentControlSet\Control\TimeZoneInformation)
• Получить базовую информацию о системе: имя хоста, версия ОС, список пользователей

Шаг 2 - быстрый скан:

• Прогнать файловую систему через YARA-правила (Loki Scanner, Spyre)
• Проверить каталоги Temp, Public, AppData на нетипичные исполняемые файлы

Шаг 3 - Event Logs:

• Экспортировать через EvtxECmd в CSV
• Отфильтровать критичные Event ID (4624, 4625, 4688, 7045, 4104)
• Зафиксировать временные рамки подозрительной активности

Шаг 4 - Prefetch и выполнение:

• Парсинг через PECmd
• Сопоставить запуски подозрительных бинарников с Event Logs
• Проверить Run Count и все временные метки Last Run

Шаг 5 - Amcache и ShimCache:

• Извлечь SHA1-хеши через AmcacheParser
• Проверить хеши по IOC-базам и VirusTotal
• Подтвердить выполнение через перекрёстную проверку с Prefetch

Шаг 6 - MFT:

• Парсинг через MFTECmd
• Поиск timestomping (расхождение $SI и $FN)
• Восстановление метаданных удалённых файлов

Шаг 7 - реестр:

• Проверить все ключи persistence через Autoruns на примонтированном образе
• Детальный разбор подозрительных ключей через Registry Explorer
• Автоматический сбор через RegRipper

Шаг 8 - корреляция:

• Построить super timeline (Plaso или ручная корреляция CSV в Timeline Explorer)
• Восстановить полную хронологию инцидента
• Задокументировать цепочку: initial access → execution → persistence → lateral movement

Что забывают русскоязычные гайды​

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

SRUM (System Resource Usage Monitor) - база данных C:\Windows\System32\sru\SRUDB.dat хранит 30-дневную историю использования ресурсов приложениями: сетевую активность, время CPU, дисковые операции. По данным Elcomsoft, SRUM часто сохраняется даже после зачистки других артефактов. Причина банальна: про SRUM мало кто знает - в том числе атакующие. Они вычищают Event Logs, удаляют Prefetch, а SRUM тихо лежит себе и всё помнит.

PCA (Program Compatibility Assistant) - начиная с Windows 11 22H2, файл C:\Windows\appcompat\pca\PcaAppLaunchDic.txt фиксирует запуски приложений в текстовом формате. Новый артефакт, который большинство гайдов не покрывает, а он содержит те же данные о выполнении, что и Prefetch, но в другом формате.

WDI StartupInfo - XML-журналы в C:\Windows\System32\WDI\LogFiles\StartupInfo\ содержат информацию о приложениях автозагрузки с привязкой к SID конкретного пользователя. Полезно, когда нужно определить, под какой учёткой запустился подозрительный процесс при старте системы.

Эти артефакты дополняют классическую пятёрку и могут дать информацию, которую атакующий не позаботился уничтожить.

Обратная перспектива: что видит пентестер​

Для пентестеров и red team операторов понимание форензик-артефактов - вопрос OPSEC. Каждая техника MITRE ATT&CK оставляет определённый след, и знать его - значит контролировать свой шум:

• PsExec → Event ID 7045 + 4624 (Type 3) + Prefetch PSEXESVC.EXE + MFT-запись + ShimCache
• Создание службы (T1543.003) → Event ID 7045 + реестр SYSTEM\CurrentControlSet\Services\ + ShimCache бинарника
• Scheduled Task (T1053.005) → Event ID 4698 (создание задачи) + XML в C:\Windows\System32\Tasks\ + MFT-запись
• Registry Run Keys (T1547.001) → Timestamp последнего изменения ключа Run + Prefetch для запускаемого бинарника
• BITS Jobs (T1197) → Event ID 59/60 в Microsoft-Windows-Bits-Client/Operational.evtx + Prefetch для загруженного файла

Знание этих цепочек позволяет или грамотно зачистить следы (red team), или целенаправленно искать их (blue team). Две стороны одной медали - и чем лучше знаешь обе, тем сильнее как специалист.

Попробуйте на своём тестовом стенде запустить PsExec и пройтись по всем пяти артефактам. Увидите, сколько следов остаётся от одного-единственного lateral movement. После этого вопрос «зачем мне форензика, я же пентестер» отпадёт сам собой.