Статья Детектирование бокового перемещения Windows: правила корреляции для SOC-аналитика

Понедельник, 9:15 утра. В дашборде Splunk - 47 событий Event ID 4624 Type 3 от одной сервисной учётки на 12 разных серверов. Все произошли между пятницей 22:40 и воскресеньем 03:10. К моменту, когда L2-аналитик собрал таймлайн, картина уже сложилась: учётку svc_backup скомпрометировали через дамп LSASS в пятницу вечером, а потом два дня тихо ходили по серверам через SMB. Три файловых сервера зашифрованы, NTDS.dit скопирован. Компания с выстроенным бэкап-процессом восстановилась за четверо суток, но простой и incident response обошлись дороже годового бюджета на мониторинг.

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

Какие Event ID оставляет боковое перемещение в логах Windows​

Детектирование бокового перемещения Windows начинается с понимания того, какие события генерируются на каждом этапе. Проблема в том, что атакующий использует те же протоколы и механизмы, что и легитимный администратор: SMB/Windows Admin Shares (T1021.002), WinRM (T1021.006), RDP (T1021.001). Отдельно взятое событие - шум. Цепочка событий - сигнал. Подробнее - в нашем обзоре обнаружение apt атак.

Ниже - карта Event ID, на которые опираются правила корреляции SIEM. Источники: Security.evtx, System.evtx, Sysmon, WinRM Operational.

Event ID	Источник	Что фиксирует	Связанные TTP
4624 (Type 3)	Security	Сетевой логон (SMB, WinRM, PsExec)	T1021.002, T1550.002
4624 (Type 10)	Security	Интерактивный RDP-логон	T1021.001
4648	Security	Логон с явным указанием учётных данных	T1550.002, T1078.002
4672	Security	Назначение привилегированных прав при входе	T1078.002
4688	Security	Создание процесса (net.exe, nltest, wmic.exe)	Reconnaissance
7045	System	Установка нового сервиса	T1569.002 / T1543.003; в связке с PsExec - T1021.002
5140 / 5145	Security	Доступ к сетевым шарам (ADMIN$, C$, IPC$)	T1021.002
4662	Security	Операция с объектом AD (репликация)	T1003.006 (DCSync)
Sysmon 3	Sysmon	Исходящее сетевое соединение от процесса	Все lateral-техники

Согласно руководству CyberDefenders по обнаружению бокового перемещения, критически важны Event ID 4624 Type 3 и 4648 в связке - они фиксируют и факт сетевого входа, и использование явных учётных данных, что характерно для Pass the Hash (T1550.002) и credential replay.

А теперь неприятная правда: без Sysmon и без включённого аудита доступа к шарам (5140/5145 отключены по умолчанию) половина артефактов бокового перемещения просто не попадает в логи. По данным NetWitness, именно пробелы в логировании дают атакующим пространство для незаметного перемещения: "Poor log visibility prevents security teams from seeing how attackers move between systems using legitimate credentials and normal tools.""Бедные видимые логи предотвращают команду защиты от понимания, как хакеры перемещаются между системами используя легитимные данные и нормальные инструменты" Если у вас не включён аудит шар - считайте, что вы наблюдаете за парковкой через одну камеру из четырёх.

Правила корреляции SIEM для обнаружения бокового перемещения​

Аномальная аутентификация: pass the hash и явные учётные данные​

Pass the Hash (T1550.002) оставляет характерный след: Event ID 4624 Type 3 с LogonProcessName = NtLmSsp, AuthenticationPackageName = NTLM и KeyLength = 0 (для локальных учёток TargetDomainName совпадает с именем хоста-цели). Отличие от штатной активности - скорость и веер: один аккаунт за короткий промежуток аутентифицируется на нескольких хостах.

Как отмечает SOC-команда Expel, Event ID 4648 фиксирует попытку входа с явным указанием учётных данных - типичный сценарий, когда атакующий запускает процессы с правами другого пользователя. Корреляция 4624 Type 3 + 4648 от одного источника к нескольким целям в окне 15 минут - один из надёжных индикаторов обнаружения бокового перемещения.

Пример правила для Splunk (адаптируется под Elastic KQL заменой index на соответствующий index pattern, sourcetype на event.provider, полей - на ECS-маппинг):

index=wineventlog (EventCode=4624 Logon_Type=3) OR EventCode=4648
| bin _time span=15m
| stats dc(eval(if(EventCode=4624,ComputerName,null()))) as target_count, values(ComputerName) as targets, count(eval(EventCode=4648)) as explicit_creds, values(IpAddress) as source_ips by TargetUserName, _time
| where target_count > 3 AND explicit_creds > 0

Что делает это правило: считает количество уникальных хостов, на которые зашёл один пользователь по сети (Type 3) за 15-минутное окно. Если больше трёх - и при этом есть 4648 (явные кредентиалы) от того же пользователя - генерируется алерт.

Нюанс, который часто упускают: Event ID 4624 Type 3 пишется на целевом хосте, а 4648 - на хосте-источнике. Корреляция работает по имени пользователя, а не по ComputerName. Порог "3 хоста" - стартовая точка; для сервисных учёток, которые штатно обращаются к десяткам серверов, порог может быть 20+, но с дополнительным условием - отклонение от baseline.

Ограничение: в среде с NLA-аутентификацией RDP, Kerberos и pass-the-ticket (T1550.003) событие 4624 Type 3 может не генерироваться в привычном формате. Для Kerberos-среды нужны дополнительные правила по Event ID 4769 (запрос сервисного билета).

Удалённое создание сервисов: PsExec и WMI​

PsExec - самый шумный способ бокового перемещения. На целевом хосте создаётся сервис (Event ID 7045 в System.evtx), копируется psexesvc.exe на ADMIN$ (Event ID 5145), порождаются дочерние процессы от psexesvc.exe (Event ID 4688). По меркам lateral movement - это как ходить по офису с мегафоном.

По данным Expel, для детектирования PsExec достаточно отслеживать Event ID 7045 с именем сервиса PSEXESVC или короткой случайной буквенной строкой (Impacket по умолчанию генерирует 4-символьное имя, но длина может варьироваться в зависимости от версии/форка). В Splunk:

index=wineventlog source="WinEventLog:System" EventCode=7045
| regex ServiceName="(?i)^(psexesvc|[a-zA-Z]{4,8})$"
| table _time, ComputerName, ServiceName, ServiceFileName, AccountName

WMI обычно тише PsExec. Ориентир - цепочка: Event ID 4624 Type 3 -> порождение процесса от wmiprvse.exe (Event ID 4688, ParentProcessName содержит wmiprvse.exe). Wmic.exe - штатный бинарь Windows для WMI-операций. В LOLBAS он классифицирован как execute-proxy для локального обхода (T1218); для удалённого выполнения через WMI (lateral movement) применяется Windows Management Instrumentation (T1047) - отдельная техника, не связанная с LOLBAS-категориями wmic.

Ограничение: WMI-логирование не включается по умолчанию. Без настроенного аудита WMI-провайдера (Microsoft-Windows-WMI-Activity/Operational) детектирование по логам будет неполным. Я встречал среды, где WMI-аудит включали уже после инцидента - и обнаруживали, что атакующий использовал WMI как основной канал неделями.

RDP и WinRM: когда легитимный доступ становится вектором​

RDP (T1021.001) генерирует Event ID 4624 Type 10 (RemoteInteractive). Само по себе событие не аномальное, но корреляция событий Windows может выявить два паттерна:

1. RDP-логон с нехарактерного хоста. Если администратор обычно подключается с WS-ADMIN01, а логон приходит с WS-USER42 - повод копнуть глубже.
2. RDP-сессия в нерабочее время + последующее выполнение recon-команд (Event ID 4688: net group "Domain Admins" /domain, nltest /domain_trusts). Два события по отдельности - ничего. Вместе - красный флаг.

Для WinRM (T1021.006) SOC аналитик ориентируется на Event ID 91 в журнале Microsoft-Windows-WinRM/Operational (создание сессии) и Event ID 4624 Type 3 от wsmprovhost.exe. По данным Expel, Event ID 53504 в журнале Microsoft-Windows-WinRM/Operational фиксирует аутентифицирующий аккаунт для PowerShell Remoting.

От одиночного алерта к цепочке: многоэтапная корреляция​

Одиночные правила ловят отдельные техники. Но боковое перемещение - это всегда последовательность: разведка -> аутентификация -> выполнение -> перемещение к следующей цели. По данным Cymulate, "correlation rules reveal multi-stage attacks" - именно связывание событий в цепочку отличает рабочий SOC от генератора шума.

Как строить многоэтапную корреляцию для SIEM правил детектирования:

1. Определить временное окно. Типичный lateral movement укладывается в 30-60 минут от разведки до первого перемещения. Для автоматизированных атак (Cobalt Strike, Impacket) - 5-10 минут. Если ваше правило смотрит окно в 24 часа - вы утонете в ложняках.
2. Связать этапы. Практическая цепочка для мониторинга бокового перемещения:
   • Event ID 4688 с процессами net.exe, nltest.exe, dsquery.exe (разведка) на хосте A
   • Затем Event ID 4624 Type 3 от хоста A на хосты B, C, D (перемещение)
   • Затем Event ID 7045 или 4688 (ParentProcess = wmiprvse.exe) на хостах B, C, D (выполнение)
3. Включить контекст учётных данных. Event ID 4672 (привилегированный логон) после 4624 Type 3 на нескольких хостах - маркер использования доменного админа (T1078.002, Domain Accounts).

Скомпрометированные сервисные учётки и инсайдерская угроза​

Отдельная головная боль - обнаружение бокового перемещения через легитимные учётки. Когда скомпрометирован svc_monitoring или svc_backup, каждое отдельное событие выглядит штатно. Здесь работает только baseline-подход:

• Фиксируете обычные пары "учётка -> целевые хосты" за 30 дней.
• Любое новое соединение сервисного аккаунта к ранее не посещавшемуся хосту - алерт средней критичности.
• Тот же аккаунт + нерабочие часы + доступ к ADMIN$ - алерт высокой критичности.

Для доменных аккаунтов (T1078.002) baseline строится аналогично, но с дополнительным контролем объёма: если пользователь за час аутентифицировался на 15 хостах вместо обычных 2-3 - это аномалия даже без других индикаторов.

Отдельно про очистку логов (T1070.001, Clear Windows Event Logs). Если атакующий подчищает следы, Event ID 1102 в журнале Security фиксирует сам факт очистки. Корреляция: 1102 после серии 4624 Type 3 - это не паранойя, а практически подтверждённый инцидент. Кто-то прошёлся по серверам и потом стёр логи? Ну, это уже не "аномальная активность" - это incident response.

Detection-чеклист для SOC-аналитика​

Готовый список действий для выстраивания детектирования бокового перемещения в SIEM. Каждый пункт - конкретное действие, реализуемое за один спринт.

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Последний пункт - самый важный. Правило, которое не тестировалось на контролируемой эмуляции, - это гипотеза, а не защита.

На практике команды нередко останавливаются на пункте 5, считая детектирование выстроенным. В реальности без baseline (пункт 4) любое правило на Type 3 логоны генерирует десятки ложных срабатываний в день - и аналитики начинают его игнорировать. А без тестирования (пункт 10) правило может молчать месяцами, пока реальный инцидент не покажет, что порог выставлен неверно или парсинг полей сломался после обновления SIEM. По данным Illumio за 2025 год, около 90% организаций столкнулись с тем или иным видом lateral movement за прошедший год, и среднее время простоя на инцидент превысило 7 часов. Это цена за каждый непротестированный алерт и каждый час без корреляции.

И ещё одна вещь, о которой мало кто говорит: корреляционные правила деградируют. Инфраструктура меняется - появляются новые сервисные учётки, переезжают серверы, добавляются подсети. Правило, написанное полгода назад, может ловить уже несуществующие паттерны и пропускать актуальные. Без ежеквартальной ревизии baseline и порогов detection engineering превращается в театр безопасности. Если хотите систематизировать подход к detection engineering от сбора логов до полноценного playbook по incident response - на курсе "Специалист SOC" в Codeby Academy эту цепочку проходят целиком, с лабами и разбором реальных кейсов.