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

https://forum.antichat.xyz/attachmen...2b4cf2b4f7.png

На каждом втором внутреннем пентесте - одна и та же картина. 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. Ниже приведены основные методы с пояснением, когда они на практике работают.

https://forum.antichat.xyz/attachmen...7557922813.png

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 HashT1550.002CrackMapExec, ImpacketLegacy/Modern без Credential GuardЕсть Kerberos TGT или TGSPass the TicketT1558Rubeus, MimikatzAD-среды, внутренний пентестЕсть plaintext-пароль, включён RDPRDP abuseT1021.001mstsc, xfreerdpGrey box, нужен GUI-доступЕсть NTLM-хэш, включён Restricted Admin ModeRDP via PtHT1550.002+T1021.001xfreerdp /restricted-adminОбход NTLM-мониторинга, нужен GUIЕсть NTLM-хэш, нужно удалённое выполнениеSMB/Admin SharesT1021.002PsExec, smbexec.pyLegacy-инфраструктураЕсть credentials, нужна скрытностьWMI execT1047wmiexec.pyОбход Sysmon Event ID 1Есть только доменная учётка без привилегийKerberoastingT1558.003Rubeus, GetUserSPNs.pyПервый шаг escalationЦелевые хосты в отдельном сегментеNTLM Relay / CoercionT1557.001Responder, ntlmrelayxВнутренний пентест, flat network

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

https://forum.antichat.xyz/attachmen...7557959435.png

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

создаёт легитимное SMB-соединение на порту 445 и аутентифицируется через NTLMSSP. На стороне цели генерируется событие 4624 (Logon Type 3 - Network Logon). EDR на целевом хосте видит входящее сетевое подключение от авторизованного пользователя. И молчит. Sysmon Event ID 3 (Network Connection) зафиксирует соединение, но без корреляции с источником это просто шум.

https://forum.antichat.xyz/attachmen...7557980641.png

Код:

Код:

# 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  -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:

, после чего полученный 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), 4776NTLM-аутентификация с 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/atexecWMI exec4624 (Type 3), WMI-Activity/OperationalСетевой логонКонкретная выполненная командаKerberoasting (T1558.003)4769TGS-запрос, тип шифрованияОтличие единичного запроса от разведки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 с настроенным мониторингом.