Статья Детектирование lateral movement через доверенные учётки: обнаружение горизонтального перемещения без вредоносного кода

Сервисная учётка SCCM три ночи подряд генерировала Type 3 logon на семнадцати хостах - маршрут каждый раз не совпадал со штатным расписанием патч-менеджмента. CrowdStrike Falcon молчал. Антивирус - тоже. Ни одного подозрительного файла. Проблему нашли, когда аналитик L2 заметил несовпадение source workstation в Event ID 4776 с типичным паттерном. Время - 3:17 ночи.

По данным CrowdStrike Global Threat Report 2025, 75% вторжений в 2024 году использовали действительные учётные данные, а среднее время от initial access до начала lateral movement - 62 минуты. Рекорд - 51 секунда. IBM X-Force Threat Intelligence Index 2025 фиксирует рост атак через легитимные credentials на 71% год к году, в dark web ежедневно всплывает свыше 6000 свежих наборов учёток. Атакующие не стали изобретательнее - они просто перестали приносить свои инструменты.

Почему EDR слеп к identity-based lateral movement​

Living off the land при горизонтальном перемещении создаёт специфическую слепую зону. Когда атакующий запускает wmic /node:target process call create, PsExec через ADMIN$ или PowerShell Remoting через WinRM - каждое действие выглядит как штатная администраторская операция. EDR-агент видит запуск процесса от легитимного пользователя через легитимный инструмент. Нет payload для песочницы, нет сигнатуры для антивируса, нет beacon для сетевого IDS.

Пример из каталога LOLBAS: Wmic.exe (MITRE ATT&CK T1218 - System Binary Proxy Execution, T1105 - Ingress Tool Transfer) - штатная утилита WMI, которую админы запускают каждый день. Для EDR на уровне user-mode хуков (а это характерно для агентов без kernel ETW-TI) отличить wmic /node:DC01 process list от wmic /node:DC01 process call create "cmd /c ..." без контекста аутентификации невозможно. Нужно знать: кто запустил, откуда, в какое время, делал ли раньше.

Verizon DBIR 2025 подтверждает масштаб: 38% утечек данных связаны с компрометацией учётных данных. Mandiant M-Trends 2025 фиксирует медиану обнаружения атакующего в 11 дней - глобальный исторический минимум. При этом 57% организаций узнают об инциденте от внешней стороны, а не от собственного SOC. Неприятная цифра.

Детектирование lateral movement через доверенные учётные записи - задача не для сигнатур. Это корреляция событий аутентификации и поведенческая аналитика SOC.

Анатомия событий Windows при горизонтальном перемещении в сети​

Event ID и их реальное значение для детектирования​

Прежде чем строить правила, нужно точно понимать, что фиксирует каждое событие и на каком хосте оно появляется.

Event ID	Что фиксирует	Где генерируется	Ключевые поля для lateral movement
4624	Успешный логон	Целевой хост (destination)	LogonType, TargetUserName, IpAddress, LogonProcessName, AuthenticationPackageName
4648	Логон с явным указанием credentials	Исходный хост (source)	TargetServerName, SubjectUserName
4672	Назначение специальных привилегий	Целевой хост	SubjectUserName, PrivilegeList
4776	Валидация NTLM-credentials	DC для доменных учёток, локально для локальных	TargetUserName, Workstation (source NetBIOS name; IP-адрес здесь отсутствует - для корреляции с IP нужен join с 4624 или сетевыми логами)

Принципиальный момент по 4776: это событие фиксирует валидацию NTLM на Domain Controller для доменных учёток и на локальной машине для локальных. При Pass-the-Hash DC получает запрос на NTLM-валидацию от workstation, который в нормальной обстановке никогда не обращался к этому DC для этой учётки. Один из ключевых индикаторов PtH - и большинство SOC его вообще не мониторят (об этом ниже).

Связка 4624 (Type 3 на целевом хосте) + 4672 (привилегированный логон там же) от учётки, которая раньше к этому хосту не обращалась - ранний сигнал горизонтального перемещения.

Поле Computer и ловушка DC-коллекции​

Поле Computer в Windows Security Log - это хост-получатель события (destination), не источник подключения. Для обнаружения lateral sweep группировка идёт по паре (IpAddress, TargetUserName) - одна учётка с одного IP аутентифицируется на множестве хостов:

index=wineventlog EventCode=4624 LogonType=3
| stats dc(Computer) as target_count values(Computer) as targets by IpAddress TargetUserName
| where target_count > 5
| sort -target_count

Если события собираются централизованно с Domain Controller - ситуация меняется. В логах DC поле Computer всегда равно имени контроллера домена. Lateral sweep на 50 хостов будет выглядеть как 50 обращений к одному DC. Для определения реального целевого хоста нужны поля TargetServerName и IpPort. Без этого разделения правило бесполезно - я видел такие «рабочие» правила в трёх разных SOC, и все три пропускали реальный sweep.

[Применимо: внутренний пентест, среды с централизованным сбором логов через Windows Event Forwarding или Splunk Universal Forwarder на DC]

Детектирование Pass the Hash и аномалий Kerberos аутентификации​

PtH: артефакт seclogo и корреляция 4776​

Pass the Hash (T1550.002, Lateral Movement) - техника, при которой атакующий использует NTLM-хеш для аутентификации без знания пароля. Классическая методика обнаружения, описанная в работе Mubix и Skip Duckwall «Still Passing the Hash 15 Years Later», опирается на специфический артефакт в Event ID 4624 (Type 3) на целевом хосте:

• На исходном хосте (при использовании Mimikatz sekurlsa::pth): Event 4624 с LogonType = 9 (NewCredentials), LogonProcessName = seclogo (артефакт Secondary Logon Service), AuthenticationPackageName = Negotiate, PackageName (NTLM only) = NTLM V2
• На целевом хосте: Event 4624 с LogonType = 3, AuthenticationPackageName = NTLM - NTLM вместо ожидаемого Kerberos для доменной учётки в AD-среде уже аномалия
• seclogo сам по себе не маркер PtH - он появляется и при штатных вызовах RunAs/Secondary Logon. Ключевой индикатор на target - именно NTLM-аутентификация там, где ожидается Kerberos

Второй индикатор - Event ID 4776 на DC. PtH-сигнал: событие 4776 на Domain Controller от нетипичного значения поля Workstation (source) в комбинации с Event ID 4624 Type 3 NTLM на target host. Если рабочая станция бухгалтера вдруг отправляет NTLM-запрос для учётки domain admin - это алерт.

Kerberos: RC4 как маркер Kerberoasting​

Steal or Forge Kerberos Tickets (T1558, Credential Access) объединяет Kerberoasting, Pass-the-Ticket, Golden и Silver Ticket. Все техники строятся на получении или подделке Kerberos-билетов.

Kerberoasting - любой доменный пользователь запрашивает TGS-билеты для сервисных аккаунтов и брутит их офлайн. В Event ID 4769 ключевой маркер - тип шифрования 0x17 (RC4_HMAC_MD5). Современные домены используют AES (0x12, 0x11), и запрос RC4-билетов от рабочей станции, которая обычно работает с AES - явная аномалия. Дополнительный сигнал: аномальное количество TGS-запросов с одного хоста за короткий интервал.

Pass-the-Ticket - кража TGT или TGS из памяти LSASS и использование на другом хосте. Детект: Event ID 4768/4769 с IP-адресом, не совпадающим с тем, что выдавал оригинальный TGT. Для серверных и сервисных учёток - сильный сигнал. Для пользователей с ноутбуками - высокий FP из-за смены IP при переподключении к Wi-Fi (и этот FP убивает мотивацию аналитиков разгребать алерты).

Sigma-правила и ограничения по конкретным EDR​

В SigmaHQ (github.com/SigmaHQ/sigma) доступны правила для обнаружения PtH:

• win_security_potential_pass_the_hash.yml - ищет аномалии seclogo в 4624
• win_security_pass_the_hash_2.yml - корреляции по событиям управления учётками
• win_susp_ntlm_auth.yml - подозрительная NTLM-аутентификация
• win_system_lsasrv_ntlmv1.yml - использование устаревшего NTLMv1

Валидировать правила можно через Atomic Red Team (github.com/redcanaryco/atomic-red-team): тесты «Mimikatz Pass the Hash», «crackmapexec Pass the Hash» и «Invoke-WMIExec Pass the Hash» для T1550.002 воспроизводят именно те артефакты, которые правила ловят.

Теперь про ограничения по вендорам - и тут начинается интересное. Обнаружение PtH через seclogo работает при условии расширенного аудита (Advanced Audit Policy → Logon/Logoff → Audit Logon). CrowdStrike Falcon ≥6.x имеет встроенное правило на PtH, но срабатывает оно на Mimikatz-паттерн обращения к LSASS, а не на сам факт hash-based аутентификации - кастомный инструмент для PtH пройдёт мимо. SentinelOne детектирует через behavioral AI, но при кастомных реализациях (не Mimikatz/Impacket) детект нестабилен. Elastic Security 8.x+ использует комбинацию endpoint events и транслированных Sigma-правил, но требует ручной настройки аудита на уровне GPO.

Ни один EDR сам по себе не закрывает обнаружение lateral movement без сигнатур. SIEM с правильно настроенным аудитом - обязательное дополнение.

UEBA и поведенческий анализ: baseline учётных записей без маркетинга​

UEBA (User and Entity Behavior Analytics) - термин, который превратился в маркетинговый buzzword. Но за ним стоит конкретная инженерная задача: отличить штатное поведение учётной записи от аномального. Без baseline любое правило на детектирование аномалий учётных записей будет давать либо 200 FP в день, либо молчать на реальных инцидентах. Третьего не дано.

Что включить в baseline​

Для каждой учётной записи и каждого хоста собирается:

• Временной профиль - когда обычно аутентифицируется (часы, дни недели)
• Сетевой профиль - с каких IP/подсетей подключается
• Целевой профиль - к каким хостам обращается (уникальные Computer за 30 дней)
• Протокольный профиль - Kerberos vs NTLM, интерактивный vs сетевой логон
• Объёмный профиль - сколько уникальных целевых хостов за час/день

Пороги для аномальной аутентификации в SIEM​

Конкретные пороги, работающие в Splunk для среды на 500+ хостов:

• Учётка обратилась к >5 уникальным хостам по Type 3 за 1 час (при baseline ≤2) → medium
• Сервисная учётка впервые за 30 дней аутентифицировалась на хосте вне её обычного списка → high
• Любая учётка с Type 3 в окне 00:00–06:00 при baseline без ночной активности → medium
• >3 Event ID 4672 на ранее не посещаемых хостах за 24 часа → high

index=wineventlog EventCode=4624 LogonType=3
| bin _time span=1h
| stats dc(Computer) as host_count values(Computer) as targets by _time IpAddress TargetUserName
| where host_count > 5
| lookup user_baseline.csv TargetUserName OUTPUT avg_hourly_hosts
| where host_count > avg_hourly_hosts * 3

Таблица user_baseline.csv не появляется сама - её генерирует saved search, пересчитывающий средние показатели за 30 дней. Без регулярного обновления baseline (раз в неделю минимум) правило деградирует: либо тонет в false positive, либо пропускает реальные инциденты. В Elastic KQL аналогичная логика реализуется через Runtime Fields и Transforms.

Для среды с Zeek-сенсорами (бывший Bro) полезно дополнять Windows-логи данными сетевого уровня: Zeek фиксирует SMB-сессии, Kerberos-тикеты и NTLM-аутентификации на уровне трафика - то, что не попадёт в Windows Event Log при неполном аудите.

Evasion: как атакующий обходит поведенческие детекты lateral movement​

Раздел, которого не хватает в большинстве русскоязычных статей о горизонтальном перемещении. Знание детектов без понимания их обхода - половина картины.

Темпоральный и объёмный evasion​

Маскировка под рабочее время.

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

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

Место в kill chain: от credential access до domain admin​

Lateral movement (TA0008) не существует изолированно. Перед ним - credential access: атакующий получает хеши, билеты или токены. Оба инструмента (wmic, PsExec) - подписанные Microsoft бинарники, которые EDR по умолчанию не блокирует.

После lateral movement - privilege escalation до domain admin, DCSync или развёртывание ransomware. Детектирование только одного звена цепочки недостаточно: нужна корреляция между credential access (аномальные обращения к LSASS) → lateral movement (нетипичные Type 3 логоны) → privilege escalation (появление новых привилегий 4672 на контроллере домена).

На бумаге формула простая. В проде baseline для каждого звена нужно строить и поддерживать отдельно - и это та рутина, которая отличает работающий SOC от SOC, который «видит всё, но не понимает ничего». На HackerLab.pro есть задачи в категориях AD и forensics, где цепочку credential access → lateral movement нужно собрать из сырых логов - хороший способ прощупать, насколько ваши правила корреляции выдержат реальный сценарий.

Я провёл последний год, настраивая правила корреляции для identity-based атак в трёх разных SIEM (Splunk, Elastic, MaxPatrol), и вынес одно наблюдение, которое редко звучит вслух: большинство SOC-команд вообще не мониторят Event ID 4776. Настраивают 4624, иногда 4625, ставят пару готовых Sigma-правил - и считают lateral movement покрытым.

А ведь 4776 на DC от нетипичного workstation source - единственное событие, которое позволяет отловить PtH до того, как атакующий окажется на целевом хосте. Seclogo-артефакт в 4624 фиксирует факт уже состоявшейся аутентификации. 4776 фиксирует попытку. Разница - десятки секунд, которые при 62-минутном breakout time от CrowdStrike дают реальное окно реагирования.

Вторая проблема - baseline. Все говорят про UEBA, но мало кто готов вложить инженерные часы в построение и еженедельное обновление профилей для каждой сервисной учётки. Без этого пороги берутся с потолка, и через месяц правила либо отключают из-за шума, либо забывают проверять.

Детектирование lateral movement через доверенные учётки - это не про покупку «правильного» EDR. Это про дисциплину аудита, про еженедельный пересчёт baseline и про аналитика, который в 3:17 ночи видит не просто Event ID 4776, а понимает - этот workstation source здесь впервые.