NTLM через HTTP — самый тихий путь к контроллеру домена

Исследователь Логан Гоинс из компании SpecterOps представил технику эксплуатации NTLM-аутентификации, которая позволяет обойти ограничения низкоуровневого доступа в корпоративных сетях и уводить выполнение инструментов с заражённой рабочей станции.

Суть метода в том, что вместо кражи паролей или хэшей злоумышленник может использовать контекст текущего пользователя для HTTP-аутентификации, после чего эта аутентификация ретранслируется в LDAP на контроллере домена. Дальнейшие действия выполняются уже через SOCKS5-прокси с Linux-хоста, что позволяет минимизировать взаимодействие с системой, находящейся под контролем средств защиты.

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

Даже более «щадящие» способы, вроде Beacon Object Files, всё равно подразумевают активность на машине. Новый приём даёт возможность вынести выполнение на сторонний сервер, не требуя при этом компрометации пароля или билета Kerberos, которые зачастую недоступны из-за Credential Guard, политики сложности паролей и других механизмов.

Решение основано на использовании NTLM через HTTP. Windows-клиенты SMB и LDAP по умолчанию применяют подпись трафика, что препятствует ретрансляции. Однако HTTP-запросы, в том числе формируемые сервисом WebClient, не включают обязательной подписи.

Обычно это открывает дорогу для атак через WebDav и даёт привилегии уровня SYSTEM, но в зрелых инфраструктурах WebClient может быть отключён, запуск его тщательно отслеживается, а использование вспомогательных файлов или команд заблокировано. Поэтому акцент делается на простейшей HTTP-аутентификации, пусть и только в пользовательском контексте.

Ограничение такого подхода в том, что изменить критические атрибуты учётной записи вроде msDs-AllowedToActOnBehalfOfOtherIdentity или altSecurityIdentities невозможно, так как объект класса user не может модифицировать их самостоятельно. Из-за этого релей приходится направлять исключительно в LDAP, используя недавно добавленный в Impacket ntlmrelayx режим LDAP-socks. Именно эта возможность позволяет проксировать аутентифицированные сессии и запускать инструменты вроде certipy с Linux-сервера, избегая запуска обнаруживаемых .NET-сборок (например, Certify) на жертве.

Важно, что атака не сработает, если на контроллере домена включена обязательная подпись LDAP и channel binding для LDAPS. Эти опции с Windows Server 2025 активируются по умолчанию при развёртывании нового DC, но многие крупные организации по-прежнему не применяют их повсеместно из-за проблем совместимости со старой инфраструктурой.

Для реализации схемы используется компактная .NET-программа, которая выполняет один HTTP-запрос с параметром UseDefaultCredentials, что инициирует NTLM-аутентификацию текущего пользователя. Дальше подключается dev-версия Impacket с поддержкой LDAP-socks, а также C2-фреймворк Mythic (в примере применялся агент Apollo). Настраивается SOCKS5-прокси, обратное перенаправление портов и сервер ntlmrelayx.

После запуска вспомогательной утилиты SharpHTTP.exe происходит пересылка учётных данных через HTTP, их ретрансляция на LDAP, и ntlmrelayx поднимает дополнительный SOCKS-порт для взаимодействия с контроллером домена. Уже через этот канал можно выполнять команды Linux-утилит, не передавая пароли явно: ntlmrelayx сам подставляет перехваченный контекст.

Практическая ценность подхода демонстрируется на примере анализа Active Directory Certificate Services. Инструмент certipy способен автоматически выявлять уязвимые шаблоны сертификатов, чего не умеет BOF из репозитория TrustedSec. При использовании релея certipy успешно получает данные из LDAP, а поле пароля может содержать любое фиктивное значение — реальная аутентификация происходит прозрачно.

С точки зрения защиты основной вывод в том, что необходимо удерживать атакующего в пределах конечной точки, где EDR видит его действия. Отправка NTLM-аутентификации через HTTP оставляет минимум телеметрии, поэтому критически важно активировать требования подписи LDAP и channel binding для LDAPS.

Это заставляет злоумышленников прибегать к более заметным и рискованным техникам кражи материальных учётных данных на хосте. Политики включаются через GPO: параметр «Domain controller: LDAP server signing requirements» переводится в режим Require signing, а «Domain controller: LDAP server channel binding token requirements» — в Always. Только совместное включение этих двух опций полностью блокирует возможность ретрансляции.

Таким образом, новая методика показывает, что даже без паролей и хэшей можно использовать NTLM-контекст для взаимодействия с LDAP, сохраняя активность вне зоны действия EDR. Но её эффективность напрямую зависит от настроек безопасности контроллеров домена, и именно здесь лежит главный шанс администраторов остановить такие атаки.