Статья Lateral movement через доверенные учётные записи: почему EDR молчит при валидных credentials

На каждом втором внутреннем пентесте - одна и та же картина. EDR стоит на всех хостах, SIEM собирает логи, политики настроены. А я прохожу от рядовой рабочей станции до контроллера домена, не вызвав ни одного алерта. Причина банальна до скуки: валидные учётные данные и штатные протоколы Windows. Для СЗИ мои действия неотличимы от работы сисадмина, который в три ночи решил проверить бэкапы.

Дальше - конкретные техники lateral movement через доверенные учётные записи: от получения credentials до горизонтального перемещения. С разбором, какие артефакты каждая техника генерирует (и не генерирует) в логах, и почему большинство EDR/SIEM-стеков это пропускает.

Масштаб проблемы: горизонтальное перемещение в сети без единого алерта​

Горизонтальное перемещение в сети - точка, в которой инцидент ценой в пару часов реагирования превращается в катастрофу масштаба всей инфраструктуры. По данным CrowdStrike 2026 Global Threat Report, среднее время от первичного доступа до начала lateral movement для eCrime-групп - 29 минут. При этом 82% всех детектов приходятся на действия без вредоносного кода: злоупотребление легитимными инструментами и валидными credentials. Согласно Verizon DBIR 2025, украденные учётные данные стали причиной 22% всех подтверждённых утечек - больше, чем любой другой вектор первичного доступа.

Суть проблемы: современные СЗИ построены вокруг сигнатурного и поведенческого анализа вредоносного кода. Когда атакующий аутентифицируется как легитимный пользователь через штатный протокол (RDP, SMB, WMI), антивирус и EDR не видят ничего подозрительного - вредоносного кода попросту нет. Есть авторизованный сеанс от доверенной учётной записи. Это фундаментальная слепая зона, которую одним лишь EDR не закрыть.

Credential abuse атаки: как атакующий получает «чистый» материал​

Прежде чем перемещаться горизонтально, нужно получить credentials. Ниже приведены основные методы с пояснением, когда они на практике работают.

LSASS Memory (T1003.001) - дамп памяти процесса lsass.exe через Mimikatz, ProcDump или direct syscalls. Извлекает NTLM-хэши и Kerberos-билеты активных сессий. Работает на Windows 10/11 при отключённом Credential Guard. Если EDR - hook-first (Kaspersky, ESET), прямой вызов sekurlsa::logonpasswords детектится на раз. В гибридных EDR (CrowdStrike, Defender for Endpoint) придётся возиться с unhooking или direct syscalls.

NTDS (T1003.003) - копирование базы Active Directory ntds.dit с контроллера домена. Нужен доступ уровня Domain Admin или Backup Operator. Типичный вектор: ntdsutil через штатный Volume Shadow Copy или secretsdump.py из Impacket. Содержит NTLM-хэши всех аккаунтов домена - полный улов.

DCSync (T1003.006) - имитация репликации контроллера домена через MS-DRSR протокол. Требует привилегий Replicating Directory Changes / Replicating Directory Changes All, которые по умолчанию есть у Domain Admins. Инструменты: Mimikatz (lsadump::dcsync) или secretsdump.py из Impacket. Не создаёт процессов на целевом DC - только сетевой трафик: TCP/135 (RPC endpoint mapper) + динамически выделяемый высокий RPC-порт. Красота в том, что на DC вообще ничего не запускается.

Kerberoasting (T1558.003) - запрос TGS-билетов для сервисных учётных записей с SPN, с последующим офлайн-брутом хэшей. Любой доменный пользователь может запросить эти билеты - штатное поведение Kerberos, так задумано. Инструменты: Rubeus (kerberoast), GetUserSPNs.py из Impacket. На стороне SIEM единственный артефакт - событие 4769 (Kerberos Service Ticket Operations) с шифрованием RC4 (0x17) вместо AES.

Credentials from Web Browsers (T1555.003) и Password Managers (T1555.005) - извлечение сохранённых паролей. APT31, по данным расследования PT ESC, использовала SharpChrome.exe именно для этого вектора в кампаниях 2024-2025 годов против российского IT-сектора. Люди хранят пароли в браузере - и APT-группы это прекрасно знают.

Выбор вектора lateral movement: decision tree для пентестера​

Одна из типичных ошибок начинающих - запуск Pass-the-Hash на всё подряд без оглядки на контекст. На внутренних engagement'ах, я пользуюсь вот такой таблицей принятия решений:

Условие	Техника	MITRE ATT&CK	Инструмент	Сценарий
Есть NTLM-хэш, NTLM не отключён	Pass the Hash	T1550.002	CrackMapExec, Impacket	Legacy/Modern без Credential Guard
Есть Kerberos TGT или TGS	Pass the Ticket	T1558	Rubeus, Mimikatz	AD-среды, внутренний пентест
Есть plaintext-пароль, включён RDP	RDP abuse	T1021.001	mstsc, xfreerdp	Grey box, нужен GUI-доступ
Есть NTLM-хэш, включён Restricted Admin Mode	RDP via PtH	T1550.002+T1021.001	xfreerdp /restricted-admin	Обход NTLM-мониторинга, нужен GUI
Есть NTLM-хэш, нужно удалённое выполнение	SMB/Admin Shares	T1021.002	PsExec, smbexec.py	Legacy-инфраструктура
Есть credentials, нужна скрытность	WMI exec	T1047	wmiexec.py	Обход Sysmon Event ID 1
Есть только доменная учётка без привилегий	Kerberoasting	T1558.003	Rubeus, GetUserSPNs.py	Первый шаг escalation
Целевые хосты в отдельном сегменте	NTLM Relay / Coercion	T1557.001	Responder, ntlmrelayx	Внутренний пентест, flat network

Главное правило: выбор техники определяется не тем, какой инструмент вы умеете запускать, а тем, какие артефакты вы готовы оставить в логах.

Pass the Hash атака и обход СЗИ на практике (T1550.002)​

Pass the Hash (T1550.002, тактики Defense Evasion и Lateral Movement) - базовая техника горизонтального перемещения. Атакующий использует NTLM-хэш вместо пароля для аутентификации на удалённой системе. Windows NTLM по дизайну принимает хэш как доказательство аутентичности - отдельная уязвимость тут не нужна. Протокол так устроен.

Применимость: работает в любой среде, где не отключён NTLM. На практике - 90%+ корпоративных сетей, потому что legacy-приложения (сетевые принтеры, старые ERP, файловые шары) ломаются при полном отключении NTLMv2. Credential Guard (Windows 10 Enterprise+) защищает LSASS на защищённом хосте от дампа и предотвращает использование хранящихся на нём NTLM-хэшей/TGT. Но если хэш получен иным путём (NTDS, фишинг, Responder) - PtH-аутентификация на целевых хостах без Credential Guard работает как часы.

Что видит и чего не видит EDR: CrackMapExec при выполнении cme smb 192.168.1.0/24 -u admin -H <hash> создаёт легитимное SMB-соединение на порту 445 и аутентифицируется через NTLMSSP. На стороне цели генерируется событие 4624 (Logon Type 3 - Network Logon). EDR на целевом хосте видит входящее сетевое подключение от авторизованного пользователя. И молчит. Sysmon Event ID 3 (Network Connection) зафиксирует соединение, но без корреляции с источником это просто шум.

# Pass the Hash через CrackMapExec - стандартный синтаксис
# Проверка доступа к подсети по SMB с NTLM-хэшем
cme smb 192.168.1.0/24 -u svc_backup -H aad3b435b51404eeaad3b435b51404ee:5f4dcc3b5aa765d61d8327deb882cf99

# Выполнение команды на целевом хосте
cme smb dc01.corp.local -u svc_backup -H <hash> -x "whoami /priv"

# Дамп NTDS через DRSUAPI на DC (требует прав DCSync)
secretsdump.py -hashes :5f4dcc3b5aa765d61d8327deb882cf99 corp/svc_backup@dc01.corp.local

Ограничения техники: при включённом SMB Signing на контроллерах домена (по умолчанию для DC, но часто отключён на рабочих станциях) relay-атаки не работают - а вот прямой PtH с валидным хэшем всё ещё проходит. Если сеть сегментирована и рабочие станции не имеют доступа к SMB (порт 445) на серверах - техника бесполезна: аутентификация пройдёт, но трафик не дойдёт.

Overpass-the-Hash и Pass the Ticket Kerberos​

Когда в домене отключён NTLMv1 и ведётся мониторинг NTLM-аутентификации, атакующий переключается на Kerberos. Overpass-the-Hash - конвертация NTLM-хэша в Kerberos TGT через AS-REQ. Rubeus делает это командой asktgt /user:svc_backup /rc4:<hash>, после чего полученный TGT инжектится в текущую сессию.

Pass the Ticket (T1558) - прямое использование украденного Kerberos-билета (TGT или TGS) для доступа к ресурсам. При PtT с TGS обращений к DC нет вообще (билет уже содержит сервисную авторизацию). При PtT с TGT - TGS-запрос к KDC всё-таки произойдёт и сгенерирует событие 4769. На стороне целевого хоста событие 4624 с Logon Type 3 - идентичное легитимному входу.

Kerberoasting (T1558.003) заслуживает отдельного внимания: это единственная техника credential access, для которой достаточно обычного доменного пользователя без каких-либо привилегий. По стандарту Kerberos, любой аутентифицированный пользователь может запросить TGS для любого сервиса с зарегистрированным SPN. Полученный билет зашифрован хэшем пароля сервисной учётной записи - и ломается офлайн. SIEM видит только событие 4769, причём одним из индикаторов будет тип шифрования RC4-HMAC (etype 23, 0x17) вместо AES-256 (etype 18, 0x12). Сам по себе RC4 не доказывает атаку - он встречается легитимно для legacy-сервисов. Надёжный индикатор - массовый запрос TGS для множества SPN от одного аккаунта за короткий период. Вот это уже подозрительно.

Living off the land техники: RDP, SMB и WMI​

Три протокола, на которые приходится абсолютное большинство lateral movement в реальных engagement'ах.

RDP (T1021.001) - согласно Sophos 2024 Active Adversary Report, злоупотребление RDP фигурирует в 90% инцидентов с ransomware. Атакующий получает полный GUI-доступ через стандартный клиент mstsc.exe. На целевом хосте - событие 4624 (Logon Type 10 - Remote Interactive). EDR видит легитимный процесс svchost.exe → rdpclip.exe. Где тут вредоносный код? Нигде.

SMB/Admin Shares (T1021.002) - Impacket psexec.py подключается к ADMIN$, копирует бинарник сервиса и запускает его через Service Control Manager. Это генерирует Sysmon Event ID 1 (Process Create) и событие 7045 (New Service Installed). smbexec.py тоже создаёт временный сервис (событие 7045 генерируется), но использует cmd.exe (T1059.003) с перенаправлением вывода в файл на ADMIN$ - другой набор артефактов. А wmiexec.py использует WMI и не создаёт нового сервиса на стороне жертвы, поэтому событие 7045 не срабатывает вовсе.

Выбирайте инструмент не по удобству, а по набору артефактов. Если на целевых хостах Sysmon с конфигурацией SwiftOnSecurity - psexec.py будет виден сразу. wmiexec.py пройдёт тише. А если нужна максимальная скрытность - atexec.py создаёт scheduled task (T1053.005) для выполнения команды и затем удаляет его, оставляя минимум следов (только событие 4698/4699 в Security log при аудите Scheduled Tasks). На engagement'ах чаще всего я начинаю с wmiexec.py и переключаюсь на atexec.py, если вижу, что Sysmon настроен агрессивно.

Обход СЗИ с помощью легитимных учётных записей: почему EDR молчит​

Разберём конкретные причины - на уровне артефактов, а не маркетинговых слайдов.

Нет вредоносного процесса. EDR анализирует исполняемые файлы и их поведение. При PtH через CrackMapExec на атакующей машине запускается Python-процесс, а на целевой - штатный svchost.exe или wmiprvse.exe. На целевой машине нет ни нового процесса, ни подозрительного бинарника. EDR-у буквально не за что зацепиться.

Аутентификация идёт по штатным каналам. NTLM-аутентификация обрабатывается lsass.exe на целевой стороне. Для EDR это стандартная операция, аналогичная входу админа через mstsc. Отличить одно от другого по локальным артефактам - невозможно.

Сетевой трафик неотличим от легитимного. SMB на порту 445, RDP на 3389, WMI через DCOM на 135 - штатные протоколы Windows-администрирования. NTA (Network Traffic Analysis) без глубокого context-aware анализа не может отличить администратора от атакующего с его хэшем.

Сервисные учётные записи работают 24/7. Компрометация привилегированных учёток типа svc_backup или svc_sql особенно опасна: их активность не привязана к рабочему графику. Impossible Travel и временные аномалии - основные эвристики UEBA - для service accounts просто не срабатывают. Сервисная учётка залогинилась в 3 ночи? Ну так она каждую ночь логинится.

CVE-2025-24054: свежий пример credential abuse в дикой природе​

CVE-2025-24054 (CVSS 6.5, MEDIUM, вектор CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N, CWE-73 - External Control of File Name or Path) - уязвимость в Windows NTLM, классифицированная Microsoft как Spoofing, но фактически приводящая к утечке NTLMv2-хэша пользователя на контролируемый атакующим SMB-сервер. Через специально сформированные .library-ms файлы (достаточно их отображения в Explorer - даже открывать не нужно) атакующий провоцирует отправку NTLMv2-хэша жертвы на свой сервер. Уязвимы практически все поддерживаемые версии Windows: клиентские и серверные ОС, включая Windows 10 (все билды), Windows 11, Windows Server 2016–2025 (для Server 2008 R2 / 2012 - только при наличии ESU). Полный список - в advisory MSRC.

Уязвимость внесена в CISA KEV (Known Exploited Vulnerabilities) и активно эксплуатируется в дикой природе. По данным CrowdStrike, кампания в марте 2025 года нацелилась на государственные учреждения Польши и Румынии - собранные хэши использовались именно для последующего lateral movement внутри инфраструктуры.

Вектор UI:R означает, что требуется действие пользователя (открытие файла или папки), но при грамотной social engineering это не проблема. APT31 в кампаниях 2024-2025 годов использовала фишинговые письма с вложениями, маскирующимися под рабочие документы - и люди открывали.

На Exploit-DB опубликованы несколько PoC (EDB-52280, EDB-52478, EDB-52480), так что эксплуатация доступна даже менее квалифицированным атакующим.

Обнаружение lateral movement в SIEM: что реально работает​

Если вы в red team - вам нужно знать, что ловится, чтобы это обходить. Если в blue team - чтобы настроить. Карта событий Windows по каждой технике:

Техника	Event ID	Что видно	Что не видно
Pass the Hash (T1550.002)	4624 (Type 3), 4776	NTLM-аутентификация с source IP	Отличие PtH от легитимного NTLM-входа
RDP abuse (T1021.001)	4624 (Type 10), 4778/4779	Факт RDP-подключения, source IP	Легитимный ли пользователь
PsExec/SMB (T1021.002)	7045, 4624 (Type 3)	Новый сервис + сетевой логон	smbexec тоже создаёт сервис (7045); без 7045 работают wmiexec/atexec
WMI exec	4624 (Type 3), WMI-Activity/Operational	Сетевой логон	Конкретная выполненная команда
Kerberoasting (T1558.003)	4769	TGS-запрос, тип шифрования	Отличие единичного запроса от разведки
DCSync (T1003.006)	4662	Доступ к объекту DS, операция Replication	Легитимная репликация DC

Согласно MITRE D3FEND, для детектирования Pass the Hash эффективны Process Lineage Analysis (D3-PLA) и Process Spawn Analysis (D3-PSA) - отслеживание цепочки родительских процессов. Для RDP и SMB - User Geolocation Logon Pattern Analysis (D3-UGLPA) и Protocol Metadata Anomaly Detection (D3-PMAD).

# Поиск подозрительных NTLM-аутентификаций (Type 3) с нетипичных хостов
# Для Windows SIEM - анализ событий 4624 за последние 24 часа
# NB: индексы Properties[] зависят от версии ОС; для надёжности используйте [xml]$_.ToXml() с именованными полями
Get-WinEvent -FilterHashtable @{LogName='Security';Id=4624;StartTime=(Get-Date).AddHours(-24)} |
  Where-Object { $_.Properties[8].Value -eq 3 -and $_.Properties[18].Value -notmatch 'KNOWN_ADMIN_IPS' } |
  Select-Object TimeCreated, @{N='User';E={$_.Properties[5].Value}}, @{N='SourceIP';E={$_.Properties[18].Value}}

Корреляция по одному типу событий бесполезна - и это нужно принять. Единственный надёжный способ детектировать lateral movement через доверенные учётные записи - cross-event корреляция: один аккаунт → логоны на множество хостов за короткий период → с нового source IP → в нерабочее время. Это требует настроенного SIEM с baseline'ом нормальной активности для каждой учётной записи. На практике такой baseline есть у единиц.

Grey box: горизонтальное перемещение злоумышленника от доменного пользователя до DA​

Типичный сценарий внутреннего пентеста в режиме grey box - самый частый формат реальных engagement'ов. Разберём по шагам.

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

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

На протяжении всех шести этапов мы не запустили ни одного вредоносного исполняемого файла на целевых хостах. Все инструменты работали на машине атакующего, а на стороне жертвы использовались исключительно штатные механизмы Windows: NTLM-аутентификация, Kerberos, WMI, SMB. Для EDR на целевых хостах это серия легитимных административных входов. Ни одного алерта.

Именно поэтому APT-группы (включая APT31, по данным расследований PT ESC за 2024-2025 годы) делают ставку на валидные учётные данные и living off the land техники: они работают даже против зрелых SOC с настроенным мониторингом.