Выявление lateral movement через WMI и PsExec: разбор связки Sysmon и Windows Event Log

По данным CrowdStrike Global Threat Report 2025, среднее время от первичного доступа в сеть до начала lateral movement — 62 минуты. Рекорд — 51 секунда. При этом 75% вторжений опираются на украденные учётные данные, а не на эксплойты: атакующий входит под валидным логином, берёт штатные инструменты Windows и двигается по сети через протоколы, без которых инфраструктура не работает. Lateral movement (горизонтальное перемещение — когда атакующий прыгает с одного хоста на другой внутри сети) через PsExec и WMI — два канала, которые всплывают в инцидентах чаще всего. Разберу оба: как выглядит атака глазами атакующего, что видит SOC-аналитик (специалист центра мониторинга безопасности) в логах и как связать разрозненные события в единый таймлайн.

Бизнес-логика атаки и место lateral movement в kill chain

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

В терминах MITRE ATT&CK (открытая база тактик и техник атак; T-коды вроде T1021 — её идентификаторы) lateral movement — это тактика TA0008. PsExec и WMI попадают под технику T1021 — Remote Services. Оба инструмента относятся к Living off the Land (использование встроенных возможностей ОС вместо стороннего вредоносного ПО): WMI внесён в каталог LOLBAS как утилита Wmic.exe, PsExec — легитимная утилита Sysinternals, которую использует каждый второй Windows-администратор. Именно поэтому их так сложно отличить от нормальной работы.

Полная цепочка атаки:

1. Initial Access — атакующий попадает на первую машину
2. Credential Access — собирает учётные данные (дампит процесс LSASS, вытаскивает NTLM-хэши)
3. Lateral Movement — перемещается на соседние хосты через PsExec, WMI, RDP ← разбираем этот шаг
4. Privilege Escalation + Domain Compromise — добирается до Domain Admin
5. Impact — шифрование, кража данных, закрепление

Для SOC здесь критичен контекст: lateral movement почти всегда идёт ПОСЛЕ кражи учётных данных. По данным IBM X-Force Threat Intelligence Index 2025, число атак с использованием действительных учётных данных выросло на 71% за год, а Verizon DBIR 2025 фиксирует, что 38% утечек связаны с украденными credentials. Видите аномальный logon — первый вопрос не «что он делает», а «откуда у него пароль».

Детектирование PsExec в Sysmon и Windows Event Log

PsExec — утилита удалённого выполнения команд из набора Sysinternals. Механика простая и предсказуемая:

1. Подключается к целевой машине по SMB (протокол доступа к файлам и административным ресурсам Windows, порт 445)
2. Копирует файл PSEXESVC.exe на административную шару ADMIN$ — скрытая сетевая папка \\target\ADMIN$, доступная только администраторам
3. Создаёт и запускает Windows-службу из этого файла, которая принимает команды через именованный канал (named pipe — механизм межпроцессного взаимодействия Windows) \\.\pipe\psexesvc

Эта трёхшаговая механика делает PsExec одним из самых «шумных» инструментов lateral movement — артефакты остаются на каждом этапе. Для начинающего аналитика это хорошая новость: пропустить PsExec в логах сложнее, чем заметить.

Работает если: есть учётные данные локального администратора на целевом хосте + открыт порт 445 (SMB) между хостами. Применимо ко всем версиям Windows начиная с XP/Server 2003.

Не работает если: межсетевой экран блокирует SMB между сегментами; параметр LocalAccountTokenFilterPolicy не разрешает удалённый доступ к ADMIN$ для локальных учёток; EDR перехватывает создание новой службы или именованного канала.

Ключевые события для детектирования PsExec

На целевом хосте (куда прыгнул атакующий) ищите эту цепочку:

Sysmon (System Monitor) — бесплатный драйвер-монитор от Microsoft (Sysinternals), который расширяет стандартное логирование Windows: пишет создание процессов, сетевые соединения, изменения файлов и реестра в отдельный журнал. Без Sysmon у вас только Event ID 4688 (стандартное логирование создания процессов) — оно показывает меньше деталей: нет хэшей файлов, нет информации о родительской команде. Разница примерно как между «кто-то вошёл в здание» и «Иванов вошёл через дверь №3 в 14:32, с ключом серии B, в кармане лежал молоток».

Вот как выглядит ключевой артефакт — Sysmon Event ID 1 на целевом хосте:

EventID: 1
Image: C:\Windows\PSEXESVC.exe
ParentImage: C:\Windows\System32\services.exe
CommandLine: C:\Windows\PSEXESVC.exe
IntegrityLevel: System
User: NT AUTHORITY\SYSTEM

Даже если атакующий переименует бинарь PsExec, внутреннее имя (Internal Name) в метаданных файла остаётся PsExec, и именованный канал \psexesvc не меняется. По данным Red Canary, клоны PsExec (RemCom, PAExec, CSExec) создают свои именованные каналы — \remcom_comunication, pipe с подстрокой PAExec, \csexecsvc — но механика та же: SMB, копирование, создание службы. Детект по Event ID 7045 + Sysmon 1 с ParentImage services.exe ловит и клоны.

Артефакт, который часто упускают: ключ реестра HKCU\Software\Sysinternals\PsExec\EulaAccepted на машине-источнике (откуда запускали PsExec). Этот ключ появляется при первом запуске утилиты и не исчезает при переименовании. Если при расследовании нашли этот ключ на хосте — с него кто-то запускал PsExec, даже если самого бинаря уже нет.

WMI lateral movement: обнаружение в логах Sysmon и Windows Event Log

WMI (Windows Management Instrumentation — подсистема управления и мониторинга Windows) — штатный механизм для удалённого выполнения команд, инвентаризации и управления. В отличие от PsExec, WMI не копирует файл на целевой хост и не создаёт службу. Атакующий вызывает метод Win32_Process::Create() через DCOM (Distributed Component Object Model — механизм удалённого взаимодействия компонентов Windows), и уже существующий системный процесс WmiPrvSE.exe (WMI Provider Host) выполняет команду. Грубо говоря, PsExec приносит с собой чемодан и ставит палатку, а WMI пользуется тем, что уже стоит на месте.

Инструмент wmiexec.py из набора Impacket делает именно это: подключается к WMI-интерфейсу целевого хоста через DCOM и запускает произвольную команду. По данным Cybereason, есть и более хитрые варианты: атакующий может создать подкласс Win32_Process и вызывать методы через него, обходя прямой мониторинг Win32_Process::Create. Впрочем, WMI-Activity ETW (Event Tracing for Windows — встроенная система трассировки событий) всё равно фиксирует реальный провайдер, который обрабатывает запрос.

Работает если: учётные данные с правами локального администратора + открыты порты 135 (RPC endpoint mapper) и динамический порт для DCOM на целевом хосте.

Не работает если: DCOM отключён или заблокирован на уровне межсетевого экрана; WMI namespace ACL ограничивают удалённый доступ; настроен расширенный аудит WMI-Activity с блокированием подозрительных вызовов.

Ключевые события для детектирования WMI

Ключевая разница с PsExec: при WMI нет Event ID 7045 (создание службы) и нет файла на ADMIN$. Зато есть характерная цепочка WmiPrvSE.exe → cmd.exe, которую легитимное администрирование порождает редко. Ещё один специфический артефакт wmiexec.py — перенаправление вывода в файл __output на шаре ADMIN$: cmd.exe /Q /c whoami 1> \\127.0.0.1\ADMIN$\__output 2>&1. Штатный wmic.exe так не делает — если видите __output в логах Sysmon Event ID 11, это почти наверняка Impacket.

Нюанс, который подробно разобран на Хабре: отличить легитимное использование WMI (администратор запускает wmic для инвентаризации) от атаки по протоколу DCOM практически невозможно на уровне одного события. Различия сводятся к деталям реализации: wmiexec.py аутентифицируется через NTLM (протокол аутентификации Windows с использованием хэша пароля), а доменные машины — через Kerberos. Но опытный атакующий исправит это. Поэтому детект WMI — это больше про статистику и контекст: ОТКУДА, КОГДА и КАК ЧАСТО идёт WMI-вызов. Один вызов в рабочее время с сервера SCCM — норма. Пять вызовов в 3 часа ночи с рабочей станции бухгалтера — повод разбираться.

Конфигурация Sysmon и требования к окружению для анализа lateral movement

Прежде чем разбирать дамп — убедитесь, что логи вообще генерируются. По данным OWASP, недостаточное логирование входит в Top 10 рисков (A09:2021 — Security Logging and Monitoring Failures). Я видел инфраструктуры, где Sysmon стоял на 3 из 200 хостов — и все три были тестовыми.

Минимальные требования для воспроизведения:

• ОС: Windows 10/11 или Windows Server 2016+ на целевых хостах
• Sysmon: версия 14+, конфигурация SwiftOnSecurity (публичный шаблон на GitHub) — покрывает Event ID 1, 3, 11, 17, 18 из коробки
• SIEM (система управления событиями безопасности): Splunk, Elastic Security или аналог. Для локального анализа — Event Viewer или Get-WinEvent в PowerShell
• Для генерации тестового трафика: Kali Linux с Impacket (psexec.py, wmiexec.py). Публичные датасеты Security Datasets (ранее Mordor) содержат готовые цепочки lateral movement с полными логами Sysmon — можно анализировать без собственного стенда
• RAM: 4+ ГБ на каждую VM, 8+ ГБ для хоста виртуализации при стенде из двух машин

Что обязательно включить в аудит Windows:

1. Advanced Audit Policy → Logon/Logoff: включить Audit Logon (Event ID 4624) и Audit Special Logon (Event ID 4672)
2. System Event Log: убедиться, что журнал System пересылается в SIEM (Event ID 7045 генерируется по умолчанию)
3. Sysmon: минимальный набор — Event ID 1, 3, 11, 17/18
4. WMI-Activity: включается через Event Viewer, по умолчанию отключён на рабочих станциях — без него WMI-атаки видны только по процессным артефактам

Совет: если разворачиваете стенд впервые, начните с датасетов Security Datasets. Там уже есть готовые EVTX-файлы с lateral movement — загружаете в Event Viewer и разбираете, не тратя время на настройку двух VM.

Пошаговый разбор дампа lateral movement: делай раз, делай два, делай три

Сценарий: атакующий со скомпрометированного хоста WORKSTATION01 (10.0.1.10) перемещается на файловый сервер FILESERVER01 (10.0.1.45) — сначала через PsExec, затем через WMI. Задача — восстановить полную цепочку по логам.

Шаг 1 — находим аномальные сетевые логоны

Начинаем с Event ID 4624 (Logon Type 3 — сетевой вход) на целевом хосте. В SIEM (здесь синтаксис Splunk SPL, адаптируйте под свой стек):

index=wineventlog sourcetype=WinEventLog:Security EventCode=4624 Logon_Type=3
| search NOT user="*$" NOT user="ANONYMOUS LOGON"
| stats count BY dest, src_ip, user
| sort count

Зачем: фильтруем компьютерные учётки (*$) и анонимные сессии, считаем количество логонов по каждой паре «источник — цель» и сортируем по возрастанию. Редкие (и потенциально подозрительные) события оказываются наверху. Это базовый приём — чем реже событие, тем больше оно заслуживает внимания.

Ожидаемый результат: видим, что пользователь admin с IP 10.0.1.10 выполнил logon на FILESERVER01 в 14:32:17, а затем ещё на два хоста в течение следующих четырёх минут. Один логон администратора — норма. Пять логонов за три минуты на разные серверы — красный флаг.

Шаг 2 — строим дерево процессов на целевом хосте

Переключаемся на Sysmon-логи FILESERVER01 и ищем процессы, созданные в окрестности 14:32.

Для PsExec — ищем Sysmon Event ID 1 с ParentImage = services.exe: находим Image: C:\Windows\PSEXESVC.exe, время 14:32:19 — через 2 секунды после logon. Далее PSEXESVC.exe порождает cmd.exe с аргументом whoami. Параллельно в System Log — Event ID 7045 с именем службы PSEXESVC и типом запуска demand start. Цепочка замкнулась: logon → служба → процесс.

Для WMI — ищем Sysmon Event ID 1 с ParentImage = WmiPrvSE.exe: находим Image: cmd.exe, CommandLine: cmd.exe /Q /c whoami 1> \\127.0.0.1\ADMIN$\__output 2>&1, время 14:35:41. Перенаправление вывода в файл __output на ADMIN$ — характерная подпись wmiexec.py из Impacket. Штатный WMI так не работает.

Как понять, что получилось: если ParentImage = services.exe или WmiPrvSE.exe, а дочерний процесс — cmd.exe или powershell.exe с нехарактерными аргументами — вы нашли точку исполнения. Запомните эту пару: родительский процесс + дочерний процесс. В 90% расследований lateral movement именно она выводит на след.

Шаг 3 — собираем полный таймлайн и определяем цепочку перемещения

Связываем три источника данных в единую картину:

Таймлайн показывает: за 3,5 минуты атакующий применил два канала lateral movement к одному хосту. Первый — PsExec (создание службы, файл на диске). Второй — WMI через wmiexec.py (тише, но с характерным артефактом __output).

Следующий шаг расследования: проверить Sysmon Event ID 10 на WORKSTATION01 — был ли доступ к процессу LSASS (Local Security Authority Subsystem Service, хранит данные аутентификации в памяти) перед lateral movement. Это покажет, как атакующий получил credentials. Также проверить Sysmon Event ID 3 — исходящие соединения на порт 445 и 135 покажут полный список целей.

PsExec или WMI: что проще детектировать SOC-аналитику

Практический вывод: PsExec-детект выстраивается за день, WMI-детект требует понимания, какие WMI-операции нормальны для конкретной инфраструктуры. В репозитории SigmaHQ по тегу T1021 (Remote Services) доступно 98 готовых правил, которые конвертируются в синтаксис вашего SIEM (Sigma — универсальный формат описания правил детектирования, что-то вроде YARA, но для логов). Начинать стоит с них — не надо писать правила с нуля.

Большинство SOC-команд, с которыми я работал, строят детекты lateral movement вокруг отдельных Event ID: «если Event 7045 — алерт». Это ловит атакующего-новичка, но не того, кто использует WMI, DCOM-объекты или WinRM. Реальный детект — корреляция: сетевой logon (4624 Type 3) + создание процесса (Sysmon 1 с подозрительным ParentImage) + временное окно в секунды. Без связки этих событий одно Event ID 7045 — это «может быть, IT-отдел поставил агент мониторинга», а не инцидент.

Вторая проблема — WMI-трафик тонет в легитимном фоне. По данным Mandiant M-Trends 2025, медианное время нахождения злоумышленника в сети — 11 дней. За это время атакующий успевает подстроить свои WMI-вызовы так, чтобы они выглядели штатными. Единственное, что его выдаёт — нехарактерная цепочка WmiPrvSE.exe → cmd.exe с перенаправлением вывода в \\127.0.0.1\ADMIN$\__output. Но для этого нужен Sysmon с правильным конфигом и аналитик, который знает, где смотреть.

Без Sysmon детект lateral movement превращается в лотерею — а недостаточное логирование, по оценке OWASP, входит в Top 10 рисков безопасности (A09:2021). Если только начинаешь работать с логами и расследованиями — на IB Basics (codeby.school) можно выстроить эту базу системно, от понятий до первых рабочих задач в SOC.