Мы продолжаем цикл статей, посвящённых исследованию цифровых следов в компьютерах с ОС Windows. Если вы следите за нашими публикациями, наверняка заметили: с каждой новой темой анализ становится всё сложнее, ведь взятые по отдельности артефакты не дают всей картины. Современная криминалистика во многом опирается на сопоставление данных из разных источников. Собирая и сопоставляя данные из разных источников, специалисты восстанавливают целостную картину происшествия и формируют надёжную доказательную базу.

На сей раз мы рассмотрим артефакты файловой системы, автоматически создаваемые операционными системами Windows 10 и Windows 11, сосредоточившись на файлах, не привязанных к конкретным пользователям; в первую очередь — расположенным в каталоге C:\Windows. Анализ этих артефактов может помочь понять, какие программы запускались, определить неавторизованный доступ, увидеть признаки того, что кто-то активно работал за компьютером.

Чтобы не уходить далеко в сторону, несколько крупных тем мы сознательно опустим. Файлы кустов реестра Windows и журналы событий (.evtx) выходят за рамки этого материала; вы можете изучить криминалистический анализ журналов событий Windows 10 и 11, а также исследование реестра Windows. Мы также не будем разбирать файлы сторонних и даже встроенных в системе программ, включая артефакты встроенных приложений вроде Microsoft Edge, если они находятся за пределами системной папки. Наконец, каталог C:\ProgramData\ — где хранятся общие конфигурации приложений и некоторые системные данные — мы разберём в отдельной статье.

Примечание: текст рассчитан на читателя, который хорошо понимает внутреннее устройство Windows, структуру файловых систем и стандартные методы сбора криминалистических данных. Эта статья — техническая справка для опытных экспертов и специалистов по безопасности. Поведение артефактов и их доказательная ценность могут заметно различаться. На это влияют такие факторы, как версия сборки ОС, её редакция (клиентская или серверная), политики аудита, настройки журналирования, лимиты хранения данных и аппаратная поддержка (например, Modern Standby). Перед тем как делать окончательные выводы, документируйте эти параметры.

Переменные среды

На практике жёстко заданные пути не всегда ведут туда, куда вы рассчитываете. Если во время экспресс-анализа работающей системы или при автоматизированном сборе данных полагаться на жёстко прошитые пути вроде C:\Windows\, можно ошибиться. Особенно это касается систем с несколькими ОС или сложных конфигураций. При исследовании работающей системы лучше начинать с анализа переменных среды Windows, таких как %windir% или %SystemRoot%, а не использовать сразу C:\Windows. В большинстве случаев активная установка Windows будет именно в этой папке, но в редких случаях (например, если злоумышленник загрузил систему с внешнего накопителя, и вы застали этот момент) в ней может оказаться неактивная версия системы. Переменные среды укажут на активный системный каталог.

Кроме того, Windows использует ряд скрытых служебных папок, таких как %AppData% и %LocalAppData%, а также пути к профилям пользователей в %UserProfile% (или %HomeDrive%%HomePath%). Эти папки содержат множество артефактов, связанных с конкретным пользователем. Мы вернёмся к ним в другой статье, а пока сосредоточимся на общесистемных артефактах в каталоге Windows.

«Шумные» артефакты

В Windows есть большие массивы данных, которые постоянно меняются и редко помогают на первом этапе. Разбор таких данных отнимает время, засоряет хронологию и даёт много противоречивых сигналов. Обычно их лучше сразу исключить из первичного просмотра. При необходимости вы всегда сможете вернуться к ним, если расследование напрямую затрагивает соответствующую подсистему:

• Временные файлы системы (%WinDir%\Temp\*): Набор остатков от установщиков и «мусорных» файлов приложений. Содержимое меняется постоянно, а временные метки здесь нередко бывают некорректными, что сильно усложняет построение чёткой хронологии.
• Следы производительности загрузки (%WinDir%\Prefetch\ReadyBoot\*.etl): Файлы ETL, которые используются для оптимизации загрузки через SuperFetch/SysMain. Они быстро перезаписываются и в основном содержат показатели производительности. Это не то место, где нужно искать следы запуска программ в первую очередь.
• Динамические данные о производительности (
• Dynamic Performance Logs (%SystemDrive%\PerfLogs\*и %WinDir%\System32\LogFiles\WMI\*): Данные счётчиков производительности для мониторинга в реальном времени. Приоритет этих данных в качестве цифровых доказательств, как правило, низкий. Исключение — если вы расследуете злоупотребление ресурсами, попытки искусственно замедлить систему или работу средств профилирования.
• Кэши службы Defender (%WinDir%\ServiceProfiles\LocalService\AppData\Local\Microsoft\Windows Defender*): Обновления Защитника Windows и временные файлы, иногда в огромном количестве. Могут быть полезны, если расследование сфокусировано на самом Defender, но в остальных случаях это, скорее, шум.

Основные артефакты файловой системы Windows

База данных System Resource Utilization Monitor (SRUM)

Подсистема SRUM появилась ещё в Windows 8 и до сих пор используется в актуальных версиях системы вплоть до самых последних обновлений Windows 11. Как следует из названия System Resource Usage Monitor, подсистема SRUM отслеживает и фиксирует информацию об использовании ресурсов различными приложениями. В базу данных попадает информация о сетевых соединениях, а также о том, какие приложения или процессы запускались, в каком режиме (активном или фоновом) работали и когда они были завершены. Эти данные хранятся в течение 30 дней (этот период можно переопределить редактированием групповых политик) в файле SRUDB.dat. Формат файла — двоичный ESE (Extensible Storage Engine), с которым работают также службы Windows Search, Active Directory и Exchange.

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

Более подробно об этих данных мы писали в статье Анализ событий из системной базы SRUM.

• Путь: %WinDir%\System32\sru\SRUDB.dat
• База данных хранит счётчики для каждого приложения (объём отправленных и полученных данных в байтах). Это особенно полезно при расследовании возможных утечек информации.
• SRUM умеет разделять трафик по сетевым интерфейсам. Это помогает отличить, например, передачу данных по Wi-Fi от активности в корпоративной локальной сети.
• Статистика может оставаться в базе данных даже после удаления приложения.
• Временные метки SRUM отражают скорее интервал активности или период сбора данных, чем точное время запуска и остановки процессов.
• Перекрёстная проверка: Сопоставление данных о сетевой активности из SRUM с журналами брандмауэра Windows (например, Event ID 5156) поможет понять, к каким IP-адресам обращалась система. Также изучите куст реестра SOFTWARE для получения контекста о глобальных сетевых профилях.

Файлы Windows Prefetch

Файлы Prefetch — это артефакты кэширования, которые создаёт механизм предварительной выборки Windows (Prefetcher/SysMain) для ускорения запуска приложений. В самом начале после запуска приложения (обычно это около десяти секунд) Windows отслеживает файлы и страницы памяти, к которым обращается программа, и сохраняет краткую сводку на диск.

• Путь: %WinDir%\Prefetch*.pf
• Если вы обнаружили файл .pf, это может указывать на запуск соответствующего исполняемого файла.
• Имя файла обычно включает название исполняемого файла и восьмизначную хэш-сумму, связанную с путём его запуска.
• В Windows 10 и Windows 11 Prefetch обычно хранит до восьми последних временных меток и число запусков (в зависимости от версии ОС).
• Если злоумышленник запустит вредоносный код, а затем удалит исполняемый файл, файл .pf может сохраниться, пока его не перезапишут или не удалят.
• Внутренняя структура содержит списки каталогов и библиотек DLL, с которыми взаимодействовал исполняемый файл. Это помогает выявить возможные признаки подмены DLL.
• Перекрёстная проверка: Сравните временные метки Prefetch с журналом Security.evtx (событие Event ID 4688 — Создание процесса), если включён аудит процессов. Это поможет идентифицировать родительский процесс. AmCache поможет получить дополнительные метаданные файла (включая поля с хеш-суммами, если они доступны). ShimCache/AppCompatCache лучше рассматривать как вспомогательный источник контекста.

Базы данных Program Compatibility Assistant (PCA)

Служба PCA (PcaSvc) отслеживает устаревшие приложения и применяет настройки совместимости, чтобы старые программы работали в новых сборках Windows. Начиная с Windows 11 22H2, исследователи отмечают появление текстовых файлов телеметрии PCA (например, PcaAppLaunchDic.txt и PcaGeneralDb*.txt) в директории appcompat.

• Путь: %WinDir%\appcompat\pca\PcaAppLaunchDic.txt и %WinDir%\appcompat\pca\PcaGeneralDb*.txt
• Этот артефакт часто фиксирует запуски приложений через графический интерфейс (GUI), хотя есть исключения — многое зависит от того, как именно был запущен процесс.
• Записи могут включать пути к исполняемому файлу (иногда частично скрытые) вместе с временными метками, обычно в формате UTC.
• Это более новый источник данных по сравнению с «классическими» артефактами; его легко упустить. В то же время он может помочь восстановить картину запусков через GUI и может сохранять пути к удалённым программам.
• В некоторых ситуациях телеметрия PCA также даёт контекст о неудачных попытках запуска или проверках совместимости. Относитесь к этому аккуратно, сверяйте выводы с другими источниками.
• Перекрёстная проверка: Сопоставляйте записи PCA с кустом реестра NTUSER.DAT (особенно с разделом UserAssist). Сверяйте с журналом Security.evtx (событие Event ID 4624 — Успешный вход в систему), чтобы установить причастность конкретного пользователя.

Сведения о запуске Windows Diagnostic Infrastructure (WDI StartupInfo)

Каждому приложению из автозагрузки присваивается степень влияния на запуск Windows; эти данные отображаются в Диспетчере задач (Изучение автозагрузки Windows с помощью Windows Performance Analyzer). К примеру, степень влияния оценивается как «высокая», если приложение использует более 1 секунды времени процессора или свыше 3 МБ дисковых операций. Механизм StartupInfo собирает показатели производительности приложений во время загрузки ОС и генерирует XML-журналы, которые можно связать с конкретными SID пользователей.

• Путь: %WinDir%\System32\WDI\LogFiles\StartupInfo\<SID>_StartupInfo<index>.xml
• Эти файлы способны фиксировать множество процессов, которые запускаются примерно в первые 90 секунд после входа пользователя в систему.
• Они часто включают время запуска, данные о родительском процессе и командную строку, использованную для запуска программы.
• Благодаря этому StartupInfo — удобное место для поиска механизмов закрепления в системе, которые срабатывают вскоре после входа пользователя. Сюда входят и скрипты, которые запускаются незаметно в фоновом режиме.
• Перекрёстная проверка: Сравните подозрительные записи с ключами Run и RunOnce в NTUSER.DAT и SOFTWARE. Используйте событие Event ID 4624 из Security.evtx, чтобы зафиксировать временное окно входа в систему.

Следы Modern Standby и SleepStudy

На системах с поддержкой Modern Standby (или там, где есть данные SleepStudy) Windows создаёт связанные с этой функцией файлы ETL и отчёты. Они нужны для отслеживания переходов между состояниями питания и расхода заряда батареи. В зависимости от устройства и сборки это могут быть файлы наподобие UserNotPresentSession.etl.

• Путь: %WinDir%\System32\SleepStudy\*.etl
• Эти артефакты фиксируют время изменения состояний питания и оборудования — например, переход в режим пониженного энергопотребления и возврат к активному использованию.
• Они помогают оценить сценарии использования устройства и проверить гипотезы о физическом доступе, но по ним одним выводы делать нельзя: это лишь косвенные признаки.
• Журналы также могут указать на программные компоненты, которые мешали системе переходить в сон. Это полезно при подозрениях на непредвиденную фоновую активность.
• Перекрёстная проверка: Сопоставьте переходы из SleepStudy с соответствующими записями системного журнала (включая события Kernel-Power). Это поможет выстроить хронологию, которую можно обосновать. Обязательно уточните идентификаторы событий для конкретной версии и сборки Windows.

Репозиторий Windows Management Instrumentation (WMI)

WMI — базовый административный механизм. Он хранит определения классов, экземпляры и компоненты подписки на события в бинарных файлах репозитория собственного формата (включая OBJECTS.DATA, INDEX.BTR и MAPPING.MAP). Имеет смысл анализировать, если есть подозрение на заражение вредоносным ПО или взлом системы.

• Путь: %WinDir%\System32\wbem\Repository\ (и %WinDir%\System32\wbem\AutoRecover\)
• Это ключевое место для проверки, если вы подозреваете использование WMI для закрепления в системе. В первую очередь ищите постоянные подписки на события (permanent event subscriptions).
• Злоумышленники могут создавать фильтры и потребители событий WMI (Event Filters и Event Consumers), которые позволяют запускать команды при выполнении в системе определённых условий.
• Поскольку определения подписок и свойства потребителей хранятся внутри репозитория, его анализ может раскрыть логику закрепления, которая неочевидна при простом просмотре файлов.
• Копии вредоносных MOF-файлов могут появляться в папке wbem\AutoRecover. Это помогает восстановить закрепление после перестроения репозитория.
• Перекрёстная проверка: Сопоставьте находки в репозитории с журналами Microsoft-Windows-WMI-Activity/Operational и Microsoft-Windows-PowerShell/Operational. Событие Event ID 4104 из журналов PowerShell (журналирование блоков скриптов) особенно полезно, если оно включено и содержит нужные фрагменты кода.

Журналы устройств и приложений SetupAPI

Механизм SetupAPI управляет установкой устройств и драйверов; события записываются в журналы setupapi.*.log.

• Путь: %WinDir%\inf\setupapi.*.log
• В этих файлах фиксируются события установки устройств и драйверов. Они часто помогают определить, когда USB-устройство впервые подключили к системе.
• Также здесь отражаются этапы проверки цифровых подписей драйверов. Это помогает вычислить компоненты без цифровой подписи или с недействительными сертификатами.
• Журналы дают подробную историю изменений аппаратного обеспечения и связанных с ними установок драйверов и приложений. При восстановлении хронологии здесь часто приходится приводить время к одному часовому поясу.
• Перекрёстная проверка: Сопоставьте временные метки из SetupAPI с ключами USBSTOR и MountedDevices в кусте реестра SYSTEM. Это поможет связать физическое оборудование с буквами дисков. Затем сравните это с артефактами ShellBags, чтобы подтвердить факты просмотра файлов пользователем.

Журналы событий Wi-Fi (WLAN AutoConfig)

Windows может сохранять события для диагностики беспроводных систем (например, в файле Wifi.etl). Они привязаны к службе автонастройки WLAN (WLAN AutoConfig) и соответствующим источникам из журнала событий (Event Logs).

• Путь: %WinDir%\System32\LogFiles\WMI\Wifi.etl
• Трассировка даёт подробную хронологию беспроводной активности. Сюда входят события аутентификации, роуминг между точками доступа и события отключения.
• MAC-адреса точек доступа (BSSID) помогают примерно оценить местоположение или перемещения. Для этого их нужно сопоставить с внешними базами данных BSSID.
• Перекрёстная проверка: Сопоставьте найденные BSSID с кустом реестра SOFTWARE (например, Microsoft\Windows NT\CurrentVersion\NetworkList). Это добавит долгосрочный контекст о сохранённых и ранее обнаруженных сетях.

Метрики использования ПО (SUM) и журналирование доступа пользователей (UAL) (только для Windows Server)

Механизм UAL отслеживает входящие клиентские запросы к ролям Windows Server и сохраняет данные в базах ESE в каталоге %WinDir%\System32\LogFiles\Sum\. В основном это серверный артефакт, но о нём стоит помнить, если вы ведёте расследования, где задействованы и клиентские машины, и серверы.

• Путь: %WinDir%\System32\LogFiles\Sum\
• На поддерживаемых системах Windows Server механизм UAL может хранить историю доступа к ролям и службам до трёх лет. Это часто больше, чем срок хранения стандартных журналов безопасности.
• В зависимости от роли и конфигурации он может записывать идентификаторы клиентов, имена пользователей и временные метки доступа к службам.
• Это хороший долгосрочный источник для расследования перемещения злоумышленника внутри сети (lateral movement) или длительных вторжений на серверах, где основные журналы были очищены или перезаписаны.
• Перекрёстная проверка: Сопоставьте IP-адреса и учётные записи с сетевой телеметрией. Привяжите временные метки UAL к событию Event ID 4624 из Security.evtx (например, типы входа 3 и 10), если они применимы и доступны.

Артефакты с низким приоритетом

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

Журналы установки Windows и подсистемы Panther

Движок Panther генерирует журналы (такие как setupact.log и setuperr.log), которые документируют процесс установки и обновления Windows.

• Путь: %WinDir%\Panther\и файлы setuperr.log и setupact.log в подпапках
• Помогают выстроить хронологию серьёзных изменений в системе, увидеть решения, принятые при установке, и понять, как обрабатывались драйверы во время обновления или установки ОС.
• Чаще всего они полезны для поиска подозрительных компонентов, внедрённых во время обновлений, или для отслеживания принудительных откатов системы.
• Перекрёстная проверка: Сопоставляйте активность драйверов с журналами SetupAPI и кустом реестра SYSTEM.

Дампы сбоев системы Windows (Минидампы)

При серьёзных сбоях, известных как «экран смерти», Windows может сохранить данные о сбое на диск (в зависимости от системных настроек). Это включает небольшие файлы дампов в каталоге Minidump.

• Путь: %WinDir%\Minidump*.dmp (и полный дамп в %WinDir%\MEMORY.DMP)
• Минидампы удобны для первичного анализа сбоев (коды ошибок bugcheck, трассировки стека, контекст драйвера или процесса), но не подходят для полного восстановления содержимого оперативной памяти.
• Трассировки стека помогают выявить вредоносные или нестабильные драйверы. Иногда они также показывают следы внедрённого кода, который и привёл к сбою.
• Перекрёстная проверка: Сопоставьте временные метки дампа с событием Event ID 1001 (BugCheck) из журнала System.evtx.

Журналы трассировки событий AutoLogger

Некоторые диагностические подсистемы обходят стандартный просмотрщик событий (Event Viewer) и пишут данные напрямую в бинарные файлы .etl. Пример — файл AutoLogger-Diagtrack-Listener.etl.

• Путь: %WinDir%\System32\LogFiles\WMI\AutoLogger-Diagtrack-Listener.etl
• Поскольку это «диагностические» журналы, скрипты очистки системных журналов могут их не затронуть.
• Они дают частичную, но устойчивую картину поведения и хронологии подсистем. Иногда там сохраняется контекст, сопутствующий выполнению программ.
• Перекрёстная проверка: Сравните данные с событием Event ID 1102 из Security.evtx и другими событиями очистки журналов (например, Event ID 104 в соответствующих логах). Это поможет сузить временные рамки возможной антикриминалистической активности.

Кэш шрифтов Windows

Windows кэширует метрики шрифтов в двоичных файлах (таких как FNTCACHE.DAT) для ускорения отрисовки текста.

• Путь: %WinDir%\System32\FNTCACHE.DAT
• Неожиданные изменения здесь могут послужить индикатором специфических аномалий, которые потенциально могут указывать на применение достаточно экзотической атаки; сами по себе не являются определяющим событием.
• Если есть подозрение эксплуатации уязвимости через шрифты (например, в цепочке вредоносных документов), аномалии кэша шрифтов стоит изучать параллельно с анализом сбоев и фактами открытия документов.
• Перекрёстная проверка: Сопоставьте аномалии с журналом событий Application на предмет проблем со службой Font Cache. Также проверьте артефакты активности пользователя (например, ветку RecentDocs в NTUSER.DAT).

Заключение

Как и ранее описанные артефакты реестра и системных журналов, артефакты файловой системы нельзя использовать для полноценной реконструкции инцидента в отрыве от других источников. Перекрёстный анализ и сопоставление данных из нескольких источников — необходимая часть работы специалиста. И здесь важно понимать не только то, какие именно артефакты существуют в системе, но и то, как они связаны между собой. Сопоставление информации из файлов, записей в системном журнале и ключей реестра позволяет не просто установить факты, но и убедительно обосновать свою точку зрения в суде.

Для ускорение сбора данных из различных источников мы разработали продукт Elcomsoft Quick Triage, предназначенный для быстрого сбора широкого спектра системных артефактов с работающих систем, образов дисков или смонтированных томов. Но помните: даже лучшие в мире программы не установят взаимосвязи, не проведут вас за ручку через все этапы расследования и тем более — не примут решение за вас. Наш продукт поможет собрать, отфильтровать и систематизировать данные, но для установления фактов, интерпретации мотивов и выстраивания чёткой хронологии по-прежнему требуются усилия и профессиональный опыт специалиста.

Мы благодарны членам сообщества криминалистов, чьи исследования продолжают развивать нашу отрасль:

1. Forensic Analysis of Prefetch files in Windows (Magnet Forensics)
2. Diving into the Windows 11 Forensics PCA Artifact (Sygnia)
3. Investigating data exfiltration: key digital artifacts across Windows, Linux, and macOS (Magnet Forensics)
4. Who Left the Backdoor Open? Using Startupinfo for the Win (TrustedSec)
5. Modern standby SleepStudy (Microsoft Learn)
6. Finding Evil WMI Event Consumers with Disk Forensics (SANS Institute)
7. SUM UAL — Investigating Server Access with User Access Logging (The DFIR Spot)
8. Log files and resolving upgrade errors — Windows (Microsoft Learn)
9. Enabling Event Categories for a Text Log — Windows drivers (Microsoft Learn)
10. Windows Minidump Explained – What You Need to Know (Lenovo)
11. The Windows Forensic Journey — Wifi.etl (Medium)
12. Uncovering Hidden Forensic Evidence in Windows: The Mystery of AutoLogger-Diagtrack-Listener.etl (Fortinet)