Как зафиксировать имя процесса, запущенного подозрительным файлом: методы мониторинга и форензики

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

Почему простое наблюдение в диспетчере задач недостаточно

Диспетчер задач и tasklist показывают снимок состояния в момент запроса. Короткоживущие процессы (например, дропперы, запускающие полезную нагрузку и завершающиеся за миллисекунды) успевают исчезнуть до того, как аналитик откроет консоль. Более того, имя процесса в списке может не совпадать с именем исходного файла: легитимный бинарный файл может быть переименован, запущен через интерпретатор (PowerShell, mshta, wscript) или внедрен в легитимный процесс через инъекцию. Фиксация требует постоянного мониторинга событий создания процесса с записью контекста: командной строки, родительского процесса, хеша образа, пользователя и целостности подписи.

Нативный аудит Windows: политика «Аудит создания процессов»

Базовый механизм без стороннего ПО — включение политики аудита Audit Process Creation (Event ID 4688). Она записывает в журнал Security каждое создание процесса с указанием:

• Имени нового процесса (New Process Name).
• Полной командной строки (при включенной опции «Include command line» в подполитике Audit Process Creation).
• Имени родительского процесса (Creator Process Name) и его PID.
• SID учётной записи, инициировавшей запуск.
• Уровня целостности (Mandatory Label).

По умолчанию командная строка не логируется. Включается через gpedit.msc → Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Detailed Tracking → Audit Process Creation → «Include command line in process creation events». После включения события 4688 начинают содержать поле CommandLine, что критично для различения легитимного запуска powershell.exe от обфусцированной команды.

Ограничения нативного аудита:

• Высокая громкость событий на рабочих станциях (тысячи в час), требующая централизованного сбора (SIEM, Windows Event Forwarding).
• Отсутствие хеша образа процесса (нужно коррелировать с Sysmon или отдельным скриптом).
• Возможность обхода: злоумышленник с правами администратора может отключить аудит или очистить журнал.

Sysmon: де-факто стандарт для глубокой видимости

System Monitor (Sysmon) от Microsoft Sysinternals — наиболее распространённый бесплатный драйвер ядра, генерирующий богатые события в отдельный журнал Microsoft-Windows-Sysmon/Operational. Ключевые события для фиксации имени процесса:

• Event ID 1 — Process Create: Image (путь к исполняемому файлу), CommandLine, CurrentDirectory, User, LogonId, IntegrityLevel, Hashes (MD5, SHA1, SHA256, IMPHASH), ParentImage, ParentCommandLine, ParentProcessId.
• Event ID 5 — Process Terminated: позволяет сопоставить начало и конец жизни процесса.
• Event ID 10 — Process Access: фиксирует попытки открытия процесса с правами VM_READ, VM_WRITE, PROCESS_CREATE_THREAD — индикатор инъекций.

Конфигурация Sysmon задаётся XML-файлом. Минимально полезный набор правил для перехвата подозрительных запусков включает:

• Логирование всех созданий процессов ().
• Сбор хешей SHA256 и IMPHASH для каждого образа.
• Исключение известного шума (например, частые запуски conhost.exe, dllhost.exe из легитимных путей) через условия C:\Windows\System32\conhost.exe в блоке .

Sysmon не предотвращает выполнение, только фиксирует. Драйвер подписан Microsoft, работает в режиме ядра и устойчив к завершению из пользовательского режима без прав SYSTEM. Для продакшена конфигурацию рекомендуется брать из проверенных репозиториев (SwiftOnSecurity, Olaf Hartong) и адаптировать под среду.

EDR и XDR: автоматическая корреляция и блокировка

Корпоративные решения EDR (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint, Kaspersky EDR, Elastic Defend) используют те же источники данных (ETW, колбэки ядра, мини-фильтры ФС), но добавляют:

• Дерево процессов в реальном времени с визуализацией родительско-дочерних связей.
• Автоматическое обогащение: репутация хеша (VirusTotal, внутренние базы), совпадение с MITRE ATT&CK, детекты на поведении (например, rundll32.exe без аргументов DLL, mshta.exe с HTTP-URL).
• Возможность ретроспективного поиска: «покажи все процессы с именем svchost.exe, запущенные не из C:\Windows\System32\ за последние 30 дней».
• Реактивные действия: изоляция хоста, убийство процесса, карантин файла.

Если в организации развёрнут EDR, ручной разбор Sysmon/4688 нужен только для углубленного расследования (threat hunting) или когда EDR пропустил событие из-за агрессивных исключений.

Procmon и ручной захват в лабораторной среде

Process Monitor (Procmon) — инструмент для ад-хок анализа на конкретной машине. Он перехватывает вызовы файловой системы, реестра, сети и процесса/потока. Для фиксации имени процесса подозрительным файлом:

1. Запустите Procmon от администратора.
2. Установите фильтр: Operation is Process Create → Include.
3. Добавьте колонки: Process Name, PID, Command Line, Parent Process, Image Path, Integrity, User.
4. Включите «Enable Boot Logging», если нужно поймать процессы на ранней загрузке (редко требуется для подозрительных пользовательских файлов).
5. Запустите подозрительный файл (в изолированной ВМ!).
6. Сохраните лог в .pml или экспортируйте в CSV для парсинга скриптами.

Procmon не подходит для постоянного мониторинга: он потребляет много памяти, не работает как сервис и не выживает после перезагрузки без настройки Boot Logging. Его роль — воспроизведение инцидента в песочнице и сбор эталонного поведения для написания правил детекта.

WMI и PowerShell: запрос уже запущенных процессов

Если процесс уже работает и нужно зафиксировать его параметры «здесь и сейчас» без предварительной настройки аудита:

• Get-WmiObject Win32_Process | Select-Object Name, ProcessId, ParentProcessId, CommandLine, ExecutablePath, CreationDate, @{N=’Owner’;E={$_.GetOwner().User}}
• Get-CimInstance Win32_Process — более современный аналог, работает через WS-MAN.
• Get-Process -IncludeUserName (PowerShell 7+) — быстрый снимок, но без командной строки и родителя.

Для удалённого опроса используйте Invoke-Command с WinRM или WMI RPC (порт 135 + динамические порты). Ограничение: WMI видит только процессы, живущие в момент запроса. Короткоживущие уже исчезнут.

ETW и пользовательские потребители событий

Event Tracing for Windows (ETW) — низкоуровневая трассировка, на которой строятся Sysmon, EDR и Windows Performance Recorder. Провайдер Microsoft-Windows-Kernel-Process (GUID {22FB2CD6-0E7B-422B-A0C7-2FAD1FD0E716}) генерирует события создания/завершения процесса (Opcode 1/2) с минимальной задержкой и без записи в журналы событий. Собственный потребитель (на C#, C++ или через logman/tracelog) позволяет:

• Получить события в реальном времени без нагрузки на Event Log.
• Фильтровать по имени образа, командной строке, родителю до записи на диск.
• Интегрироваться с внутренними системами детекта без развёртывания агентов.

Сложность: необходимость парсить бинарные события (TDH), обрабатывать потерю буфера при высокой нагрузке, поддерживать совместимость версий Windows. Обычно оправдано только для разработчиков собственных сенсоров.

Форензические артефакты: восстановление имени после факта

Если мониторинг не был настроен заранее, имя процесса можно восстановить из артефактов:

Артефакт	Что даёт	Инструменты извлечения
Prefetch (C:\Windows\Prefetch\*.pf)	Имя исполняемого файла, путь, количество запусков, последнее время запуска, список загруженных DLL, объём прочитанных/записанных данных	PECmd (Eric Zimmerman), WinPrefetchView, dfir-prefetch-parser
Amcache (C:\Windows\AppCompat\Programs\Amcache.hve)	Полный путь к файлу, SHA1, имя продукта, версия, время первого/последнего запуска, признак выполнения (File/Shortcut/Installer)	AmcacheParser, Registry Explorer, KAPE
Shimcache (AppCompatCache) в SYSTEM hive	Путь к исполняемому файлу, время последней модификации файла (не запуска!), флаг выполнения	AppCompatCacheParser, Registry Explorer
UserAssist (NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist)	Запуски через Explorer (ярлыки, Start Menu), счётчик запусков, время последнего запуска (ROT13-кодированные GUID)	UserAssistView, Registry Explorer
SRUM (C:\Windows\System32\sru\SRUDB.dat)	Сетевая и CPU активность по процессам за последние 30–60 дней, имя приложения, пользователь, байты в/вы	SRUM-Dump, KAPE
Event Logs (System, Application, PowerShell Operational)	Кодовые ошибки запуска, блокировки AppLocker/WDAC, события PowerShell (4103, 4104 — Script Block Logging)	Get-WinEvent, EVTXtract, Hayabusa, Chainsaw

Важно: Prefetch и Amcache заполняются асинхронно (через несколько минут после запуска). Shimcache обновляется при перезагрузке. Для актуального расследования собирайте образ диска (KAPE, FTK Imager) и парсите офлайн.

Типичные сценарии и что искать

Сценарий 1: Файл запущен напрямую пользователем

Родительский процесс — explorer.exe или cmd.exe/powershell.exe интерактивной сессии. Имя процесса совпадает с именем файла (если не переименован). Проверяйте: подпись файла, репутация хеша, нестандартное расположение (Temp, Downloads, AppData), аргументы командной строки.

Сценарий 2: Запуск через «живой по земле» (LOLBins)

Файл — скрипт (.ps1, .vbs, .js, .bat) или библиотека, запускаемая через rundll32.exe, regsvr32.exe, mshta.exe, wmic.exe, certutil.exe. Имя процесса в логе — имя LOLBin, а не исходного файла. Исходный файл виден в командной строке аргументов. Детектируйте по аномальным аргументам: HTTP URL в mshta, /i:http в regsvr32, encodedcommand в powershell.

Сценарий 3: Инъекция в легитимный процесс

Подозрительный файл запускает легитимный процесс (например, notepad.exe, svchost.exe из System32) в режиме suspended, пишет в его память шелл-код и резюмирует поток. В логах создания процесса (4688, Sysmon EID 1) имя — легитимное. Индикаторы: несоответствие командной строки типичной для этого бинаря, вызов NtCreateThreadEx/CreateRemoteThread (Sysmon EID 8 — CreateRemoteThread), нестандартные загруженные модули (EID 7 — Image Load) или расхождение хеша образа на диске и в памяти.

Сценарий 4: Запуск от имени SYSTEM через задачу/службу

Родитель — services.exe или svchost.exe (taskhostw). Проверяйте: кто создал задачу/службу (Event ID 4698, 7045), не подменён ли бинарник службы (ImagePath в реестре), не использована ли уязвимость повышения привилегий.

Практический чек-лист настройки базового мониторинга

1. Включите Advanced Audit Policy: Audit Process Creation (Success) + «Include command line».
2. Разверните Sysmon с конфигурацией, собирающей хеши SHA256/IMPHASH и логирующей все Process Create (Event ID 1).
3. Настройте форвардинг журналов Security и Sysmon в SIEM / лог-агрегатор (Winlogbeat, NXLog, Azure Monitor Agent).
4. Создайте базовые детекты: процесс не из System32/SysWOW64 с именем системного бинаря; PowerShell с EncodedCommand/DownloadString/Invoke-Expression; mshta/regsvr32/rundll32 с сетевыми индикаторами; родитель Office-приложений, порождающий cmd/powershell.
5. Включите PowerShell Script Block Logging (Event ID 4104) и Module Logging (4103) для перехвата обфусцированных скриптов.
6. Настройте хранение логов минимум 90 дней (требования соответствия и ретро-хант).
7. Проводите еженедельный threat hunting: поиск аномалий в дереве процессов, редких комбинаций «родитель → ребёнок», процессов без подписи с высокой энтропией имени.

Ограничения и противодействие атакующим

Атакующие знают про Sysmon и 4688. Типичные техники обхода:

• Unhooking / ETW patching: перезапись функций ntdll.dll в памяти процесса, чтобы драйвер не получал колбэки. Защита: драйверы EDR в режиме ядра, VBS/HVCI (Virtualization-Based Security), мониторинг целостности модулей ntdll.
• PPID Spoofing: указание фальшивого родительского PID через PROC_THREAD_ATTRIBUTE_PARENT_PROCESS в CreateProcess. В логах родитель будет легитимным (например, explorer.exe), хотя реально запустил злоумышленник. Детект: расхождение между PPID в событии создания и реальным вызывающим потоком (требует EDR/колбэков ядра).
• Process Hollowing / Herpaderping: создание процесса в suspended, замена образа в памяти, резюме. Имя процесса в логе — легитимный путь, но на диске файл другой. Детект: сравнение хеша из события создания (Sysmon логирует хеш образа на диске) с хешем в памяти (требует дамп памяти или EDR).
• Direct Syscalls: вызов системных функций напрямую, минуя ntdll, чтобы избежать userland-хуков. Не скрывает событие создания процесса от ядра (ETW/Sysmon), но скрывает от пользовательских API-хуков.
• Clearing logs: wevtutil cl Security, wevtutil cl «Microsoft-Windows-Sysmon/Operational». Защита: форвардинг логов на удалённый коллектор в реальном времени, защита журналов SACL, алерт на очистку журналов (Event ID 1102).

Когда подключать специалиста по реагированию на инциденты

Самостоятельный сбор логов и анализ дерева процессов достаточен для триажа: понять, был ли запуск, какой процесс появился, каковы его связи. Эскалация нужна, если:

• Обнаружены признаки компрометации: инъекция в системный процесс, обход защиты, движение по сети (Pass-the-Hash, SMB admin shares), выгрузку данных.
• Требуется форензический образ диска и памяти для судебного порядка или страхового кейса.
• Инцидент затрагивает несколько хостов, контроллеры домена или критическую инфраструктуру.
• Нет компетенций по анализу дампов памяти (Volatility, Rekall) или реверс-инжинирингу вредоносного кода.

Материал носит информационный характер и не заменяет профессионального расследования инцидентов информационной безопасности. При обнаружении признаков активной компрометации критических систем обратитесь к квалифицированным специалистам DFIR и соблюдайте процедуры сохранения доказательств, установленные в вашей организации и законодательством.

С чего начать прямо сейчас

Если у вас нет настроенного сбора событий создания процессов — начните с включения Advanced Audit Policy и развёртывания Sysmon на тестовой группе хостов. Это даст видимость за 15–30 минут работы без затрат на лицензии. Параллельно настройте форвардинг логов в центральное хранилище; локальные журналы перезаписываются за часы на активных станциях. Для разовых проверок подозрительных файлов используйте изолированную ВМ с Procmon и снапшотом до запуска. Регулярно пересматривайте исключения в Sysmon и EDR: слишком широкие исключения — основная причина пропуска инцидентов.