Сергей Попов
10.04.2026, 15:23
https://forum.antichat.xyz/attachments/4951453/img_4ba71e5b94.png
Когда 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: первый рубеж расследования (https://forum.antichat.xyz/threads/592504/)
Журналы событий 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ОписаниеЗначение для расследования4104Script Block LoggingПолный текст выполненных PowerShell-скриптов, включая деобфусцированный код
Практика: извлечение и парсинг Event Logs
На живой системе можно быстро отфильтровать интересные события через PowerShell. Для поиска неудачных логонов (рекомендация INCIBE):
Код:
Get-WinEvent -LogName Security | Where-Object {$_.Id -eq 4625} | Select-Object TimeCreated, Message
Но при работе с образом диска нужны другие инструменты. Для офлайн-анализа я использую EvtxECmd из набора Eric Zimmerman Tools:
Bash:
# Парсим все 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. Дальше парсим:
Bash:
# Парсинг $MFT в формат CSV
MFTECmd.exe -f
"C:\Evidence\$MFT"
--csv
"C:\Output"
--csvf mft_parsed.csv
Что искать в выводе MFTECmd:
Подозрительные пути - исполняемые файлы в
C:\Windows\Temp\
,
C:\Users\Public\
,
C:\ProgramData\
(любимые директории атакующих - туда пишется без лишних привилегий)
Расхождение SI и FN timestamps - признак timestomping. В CSV-выводе MFTECmd есть отдельные колонки для обоих наборов меток
Удалённые файлы - записи с флагом
InUse: false
. Файл удалён, но метаданные на месте
ADS (Alternate Data Streams) - атакующие прячут payload в альтернативных потоках данных. MFTECmd их покажет
Пример: нашли запись для
C:\Windows\Temp\svchost.exe
с датой создания 2024-03-15 14:31:02. Легитимный svchost.exe живёт в
System32
, а не в
Temp
. Фиксируем временную метку и идём в Prefetch - был ли этот самозванец запущен?
Форензика реестра Windows: карта закрепления атакующего (https://forum.antichat.xyz/threads/588877/)
Реестр Windows - иерархическая база данных с конфигурациями ОС, программ и пользовательских настроек. Для атакующего реестр - основной механизм persistence. Для аналитика - карта того, как именно злоумышленник закрепился в системе.
Системные кусты (
SAM
,
SECURITY
,
SOFTWARE
,
SYSTEM
) лежат в
C:\Windows\System32\config\
. Пользовательские (
NTUSER.DAT
,
UsrClass.dat
) - в профиле каждого пользователя.
Ключи автозагрузки и закрепления
Основные ветки реестра, через которые атакующие обеспечивают persistence, с привязкой к техникам MITRE ATT&CK:
Registry Run Keys / Startup Folder (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
- путь к скрипту, выполняемому при логоне
Scheduled Task (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:
Bash:
# Вытаскиваем 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 последнего изменения ключа - когда именно было создано закрепление
Для системной информации перед анализом:
Bash:
# Имя компьютера, версия ОС, временная зона
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 7128Базовый PrefetchWindows 8+1024Интеграция с SuperFetch/SysMain, сжатие MAMWindows 10/111024Сохраняет до 8 последних временных меток запускаWindows ServerОтключён по умолчаниюТребует ручного включения через реестр
На серверных ОС Prefetch по умолчанию отключён. Если расследуете инцидент на сервере и Prefetch пуст - это не значит, что ничего не запускалось. Идите в Amcache и ShimCache.
Практика: парсинг Prefetch через PECmd
Bash:
# Парсинг всех 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-.pf
? След PsExec на целевом хосте - подтверждение lateral movement. Видите
POWERSHELL.EXE-.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
. Различия существенные:
ХарактеристикаAmcacheShimCacheХра нилищеОтдельный куст
Amcache.hve
Внутри куста
SYSTEM
SHA1-хешДаНетПодтверждает запускНе абсолютное доказательство - записи могут появляться при установке ПО. Подтверждайте через Prefetch или Event ID 4688Не всегда (может фиксировать и незапущенные файлы)Запись в реестрВ реальном времениПри выключении/перезагрузке системыПорядок записейХронологическийСте к (LIFO - последний вошёл, первый вышел)
Критический нюанс: ShimCache не гарантирует, что файл был запущен. Он фиксирует факт обращения к файлу подсистемой совместимости приложений - а это может произойти и при простом просмотре директории в Explorer. Поэтому данные ShimCache нужно подтверждать через Prefetch или Amcache. Без перекрёстной проверки рискуете написать в отчёте «запускался», когда на самом деле «просто лежал».
Практика: AmcacheParser и AppCompatCacheParser
Bash:
# Парсинг 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
Допустим, в ходе анализа обнаружилось следующее:
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
Event Log (System.evtx): Event ID 7045, Service Name: PSEXESVC, Service File Name:
%SystemRoot%\PSEXESVC.exe
, Time: 14:30:07
MFT: Запись для
C:\Windows\PSEXESVC.exe
, Created ($SI): 14:30:06, Created ($FN): 14:30:06 - метки совпадают, timestomping отсутствует
Prefetch:
PSEXESVC.EXE ('https://attack.mitre.org/techniques/T1570/')-AD70946C.pf
, Run Count: 1, Last Run: 14:30:07
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 - парсит десятки типов артефактов и собирает единую временную шкалу:
Bash:
# Создание 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\TimeZoneInformati on
)
Получить базовую информацию о системе: имя хоста, версия ОС, список пользователей
Шаг 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. После этого вопрос «зачем мне форензика, я же пентестер» отпадёт сам собой.
Когда 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: первый рубеж расследования (https://forum.antichat.xyz/threads/592504/)
Журналы событий 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ОписаниеЗначение для расследования4104Script Block LoggingПолный текст выполненных PowerShell-скриптов, включая деобфусцированный код
Практика: извлечение и парсинг Event Logs
На живой системе можно быстро отфильтровать интересные события через PowerShell. Для поиска неудачных логонов (рекомендация INCIBE):
Код:
Get-WinEvent -LogName Security | Where-Object {$_.Id -eq 4625} | Select-Object TimeCreated, Message
Но при работе с образом диска нужны другие инструменты. Для офлайн-анализа я использую EvtxECmd из набора Eric Zimmerman Tools:
Bash:
# Парсим все 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. Дальше парсим:
Bash:
# Парсинг $MFT в формат CSV
MFTECmd.exe -f
"C:\Evidence\$MFT"
--csv
"C:\Output"
--csvf mft_parsed.csv
Что искать в выводе MFTECmd:
Подозрительные пути - исполняемые файлы в
C:\Windows\Temp\
,
C:\Users\Public\
,
C:\ProgramData\
(любимые директории атакующих - туда пишется без лишних привилегий)
Расхождение SI и FN timestamps - признак timestomping. В CSV-выводе MFTECmd есть отдельные колонки для обоих наборов меток
Удалённые файлы - записи с флагом
InUse: false
. Файл удалён, но метаданные на месте
ADS (Alternate Data Streams) - атакующие прячут payload в альтернативных потоках данных. MFTECmd их покажет
Пример: нашли запись для
C:\Windows\Temp\svchost.exe
с датой создания 2024-03-15 14:31:02. Легитимный svchost.exe живёт в
System32
, а не в
Temp
. Фиксируем временную метку и идём в Prefetch - был ли этот самозванец запущен?
Форензика реестра Windows: карта закрепления атакующего (https://forum.antichat.xyz/threads/588877/)
Реестр Windows - иерархическая база данных с конфигурациями ОС, программ и пользовательских настроек. Для атакующего реестр - основной механизм persistence. Для аналитика - карта того, как именно злоумышленник закрепился в системе.
Системные кусты (
SAM
,
SECURITY
,
SOFTWARE
,
SYSTEM
) лежат в
C:\Windows\System32\config\
. Пользовательские (
NTUSER.DAT
,
UsrClass.dat
) - в профиле каждого пользователя.
Ключи автозагрузки и закрепления
Основные ветки реестра, через которые атакующие обеспечивают persistence, с привязкой к техникам MITRE ATT&CK:
Registry Run Keys / Startup Folder (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
- путь к скрипту, выполняемому при логоне
Scheduled Task (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:
Bash:
# Вытаскиваем 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 последнего изменения ключа - когда именно было создано закрепление
Для системной информации перед анализом:
Bash:
# Имя компьютера, версия ОС, временная зона
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 7128Базовый PrefetchWindows 8+1024Интеграция с SuperFetch/SysMain, сжатие MAMWindows 10/111024Сохраняет до 8 последних временных меток запускаWindows ServerОтключён по умолчаниюТребует ручного включения через реестр
На серверных ОС Prefetch по умолчанию отключён. Если расследуете инцидент на сервере и Prefetch пуст - это не значит, что ничего не запускалось. Идите в Amcache и ShimCache.
Практика: парсинг Prefetch через PECmd
Bash:
# Парсинг всех 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-.pf
? След PsExec на целевом хосте - подтверждение lateral movement. Видите
POWERSHELL.EXE-.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
. Различия существенные:
ХарактеристикаAmcacheShimCacheХра нилищеОтдельный куст
Amcache.hve
Внутри куста
SYSTEM
SHA1-хешДаНетПодтверждает запускНе абсолютное доказательство - записи могут появляться при установке ПО. Подтверждайте через Prefetch или Event ID 4688Не всегда (может фиксировать и незапущенные файлы)Запись в реестрВ реальном времениПри выключении/перезагрузке системыПорядок записейХронологическийСте к (LIFO - последний вошёл, первый вышел)
Критический нюанс: ShimCache не гарантирует, что файл был запущен. Он фиксирует факт обращения к файлу подсистемой совместимости приложений - а это может произойти и при простом просмотре директории в Explorer. Поэтому данные ShimCache нужно подтверждать через Prefetch или Amcache. Без перекрёстной проверки рискуете написать в отчёте «запускался», когда на самом деле «просто лежал».
Практика: AmcacheParser и AppCompatCacheParser
Bash:
# Парсинг 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
Допустим, в ходе анализа обнаружилось следующее:
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
Event Log (System.evtx): Event ID 7045, Service Name: PSEXESVC, Service File Name:
%SystemRoot%\PSEXESVC.exe
, Time: 14:30:07
MFT: Запись для
C:\Windows\PSEXESVC.exe
, Created ($SI): 14:30:06, Created ($FN): 14:30:06 - метки совпадают, timestomping отсутствует
Prefetch:
PSEXESVC.EXE ('https://attack.mitre.org/techniques/T1570/')-AD70946C.pf
, Run Count: 1, Last Run: 14:30:07
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 - парсит десятки типов артефактов и собирает единую временную шкалу:
Bash:
# Создание 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\TimeZoneInformati on
)
Получить базовую информацию о системе: имя хоста, версия ОС, список пользователей
Шаг 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. После этого вопрос «зачем мне форензика, я же пентестер» отпадёт сам собой.