ESC8. Как один HTTP‑интерфейс может стоить вам домена
ESC8 — это атака, при которой злоумышленник эскалирует привилегии с помощью ретрансляции NTLM на веб‑сервисы Active Directory Certificate Services (AD CS).
Техника использует веб‑интерфейсы выдачи сертификатов в AD CS, которые принимают NTLM‑аутентификацию, и перенаправляет (ретранслирует) NTLM‑запросы высокопривилегированного аккаунта (например, контроллера домена) на сервер сертификатов. В результате злоумышленник может получить цифровой сертификат, удостоверяющий его в домене как пользователя или компьютер.
Например, успешно проведенная атака ESC8 позволяет скомпрометировать контроллер домена: получить сертификат на имя учетной записи контроллера, а затем аутентифицироваться в любом сервисе от его имени, фактически захватив контроль над доменом.
ESC8 выделяют как одну из самых опасных атак, поскольку она может привести к полной компрометации инфраструктуры Active Directory.
Как работает NTLM‑релей в контексте ESC8
Шаг 1. Злоумышленник запускает подконтрольный HTTP‑сервер.
Шаг 2. Атакующий добивается, чтобы привилегированная учетная запись пользователя или компьютера автоматически прошла NTLM‑аутентификацию на подконтрольном сервере. Такой прием называется NTLM coercion (принуждение к аутентификации по NTLM) и реализуется, например, с помощью уязвимостей или техник вроде PetitPotam.
Шаг 3. Злоумышленник ретранслирует перехваченные NTLM‑сообщения (challenge/response) на уязвимый HTTP‑интерфейс AD CS, например Web Enrollment. Если этот интерфейс принимает NTLM без усиленной защиты, например без Extended Protection, он доверяет аутентификации и считает, что запрос пришел от самой жертвы. В запросе атакующий заранее указывает собственный сгенерированный приватный ключ и имя жертвы, например dc01.corp.local.
Шаг 4. AD CS, принявший NTLM‑аутентификацию, считает запрос легитимным и выдает сертификат, подписанный доверенным CA.
Итог. Поскольку злоумышленник заранее сгенерировал приватный ключ и указал его в запросе, он теперь имеет полный доступ к сертификату, действующему от имени жертвы. Такой сертификат можно использовать для Kerberos-аутентификации через PKINIT, получить TGT от имени жертвы — и дальше действовать в инфраструктуре как полноценный контроллер домена.
Таким образом, ESC8 — это комбинация ошибки конфигурации AD CS (доверие к NTLM без проверки) и NTLM‑релея, которая может привести к эскалации привилегий до уровня доменной учетной записи.
Для успешной реализации ESC8 требуются определенные уязвимости и условия в инфраструктуре Active Directory и AD CS:
- Уязвимый веб‑сервис AD CS.
- Уязвимый шаблон ESC 8.
- Включенная аутентификация NTLM в домене.
- Возможность принудить к NTLM‑аутентификации.
- Автоматическая выдача сертификатов.
В организации должен быть развернут веб‑интерфейс выдачи сертификатов AD CS, который принимает NTLM‑аутентификацию и не защищен от релей-атак. К таким интерфейсам относятся:
- Legacy Web Enrollment — устаревший веб‑портал по адресу
http://<CA-сервер>/certsrv/(на базе ASP). По умолчанию доступен только по HTTP (без шифрования) и принимает только NTLM‑аутентификацию. Это делает его напрямую уязвимым к атакам NTLM‑релея. - Certificate Enrollment Web Service (CES) и Certificate Enrollment Policy Web Service (CEP) — актуальные службы веб‑регистрации, работающие через IIS. По умолчанию они поддерживают протокол Negotiate, то есть допускают как Kerberos, так и NTLM. Обычно они настроены на HTTPS, но одного этого недостаточно, если не включена расширенная защита. Без Extended Protection злоумышленник все равно может выполнить релей-атаку по NTLM через TLS‑канал.
- Network Device Enrollment Service (NDES) — служба регистрации сетевых устройств (SCEP). По умолчанию публикует URL типа
http://<CA-сервер>/certsrv/mscep/(и HTTPS‑вариант). Она также использует Negotiate-авторизацию, потенциально позволяя понижение до NTLM. По умолчанию Extended Protection отключена, что делает службу уязвимой аналогично CEP/CES.
Что такое Extended Protection for Authentication
Это механизм безопасности, предназначенный для защиты от атак типа man-in‑the‑middle (MitM), особенно актуальных при NTLM‑аутентификации. Основа этой технологии — channel binding tokens (CBT), которые привязывают аутентификационные данные к защищенному TLS‑каналу. Это гарантирует, что переданные учетные данные невозможно будет использовать повторно или перенаправить на другой сервис.
Для защиты интерфейсов AD CS, например Web Enrollment, CES или CEP, критически важно, чтобы в IIS была включена расширенная защита Extended Protection. Именно это предотвращает успешную реализацию NTLM‑релея через HTTPS.
На скриншоте ниже показано, как должна быть настроена защита от NTLM‑релея на уровне IIS.
В разделе Authentication для сайта (например, Web Enrollment или CES/CEP) должна быть включена Windows Authentication, а в ее Advanced Settings установлено:
- Extended Protection: Required.
- Enable Kernel-mode authentication: включено (стоит галочка).
Такие настройки позволяют использовать CBT, предотвращающие релей NTLM на доверенные сервисы.
В итоге, если на CA‑сервере запущены Web Enrollment, CEP/CES или NDES без надлежащих настроек защиты (только HTTP или HTTPS без привязки канала), они становятся целевыми точками для NTLM‑релея.
Например, если интерфейс certsrv доступен по HTTP либо HTTPS‑интерфейсы не используют Extended Protection, злоумышленник сможет ретранслировать на них учетные данные NTLM.
В скомпрометированном центре сертификации должен быть хотя бы один шаблон, который разрешает выдачу сертификатов для учетных записей компьютеров или пользователей и поддерживает их использование для аутентификации (например, содержит EKU Client Authentication или Smart Card Logon).
В реальных инфраструктурах такое условие почти всегда выполняется, например:
- Стандартные шаблоны Computer или Domain Controller позволяют доменным компьютерам автоматически получать сертификаты для Kerberos- или TLS‑аутентификации.
- Шаблоны User, Smartcard Logon или производные часто доступны для всех пользователей домена (например, через группу Domain Users) и также содержат EKU для клиентской аутентификации.
Если такой шаблон опубликован в CA, не требует одобрения администратора и доступен для регистрации (Enroll) от имени соответствующей учетной записи (например, Domain Computers или Domain Users), злоумышленник может использовать его в атаке.
Например, при NTLM‑релее атакующий способен заставить контроллер домена (DC01$) пройти NTLM‑аутентификацию на своем сервере, после чего ретранслировать ее на CA и получить сертификат на имя DC01$.
Аналогично при успешной релейной атаке на пользователя, например администратора, сертификат будет выдан на его имя, и злоумышленник сможет аутентифицироваться в AD от его лица.
Рассмотрим параметры шаблона сертификатов с именем ESC 8, которые позволяют использовать его в атаке через NTLM‑релей:
- Отсутствие требований к одобрению.
Видно, что на вкладке Issuance Requirements:- не включена опция CA certificate manager approval;
- не требуются авторизованные подписи.
Значит, любой, у кого есть право Enroll, может получить сертификат без участия администратора. Это критично при атаке ESC8. - Свободное задание имени субъекта.
На вкладке Subject Name включена опция Supply in the request, что позволяет злоумышленнику вручную задать UPN или DNS‑имя в запросе. Это создает условия для спуфинг-атак, если шаблон дополнительно не защищен. - Широкий доступ — право Enroll у всех.
Видно, что на вкладке Security права Enroll выданы группе Authenticated Users, а также Domain Users. Это означает, что запросить сертификат по этому шаблону может любой пользователь домена, включая компьютерные учетные записи — в случае релейной атаки AD CS не отличит их от легитимных. - EKU содержит Client Authentication.
На вкладке Extensions → Application Policies видно, что шаблон содержит:- Encrypting File System;
- Secure Email;
- Client Authentication.
Когда есть EKU Client Authentication, полученный сертификат может быть использован для аутентификации в домене, например через Kerberos PKINIT или Schannel (TLS).
В совокупности все эти настройки делают шаблон ESC 8 идеальной целью для атаки ESC8:
- сертификаты выдаются автоматически;
- имя субъекта указывается вручную;
- право получения сертификата есть у любого пользователя;
- сертификат пригоден для входа в AD.
В эксплуатационной среде такие шаблоны нужно либо закрывать, либо перерабатывать с ограничением доступа, включением одобрения и запретом ручного ввода полей Subject/SAN.
Атака NTLM‑релея возможна, только когда в инфраструктуре не отключена NTLM‑аутентификация.
Во многих организациях NTLM включен по умолчанию, потому что его отключение — сложный и чувствительный процесс, который может нарушить работу старых систем и приложений. Если в сети используется NTLM (особенно NTLMv1), это создает условие для атаки.
В атаке ESC8 злоумышленники чаще всего выбирают в качестве жертвы контроллер домена, поскольку его компрометация дает максимальные привилегии в инфраструктуре. Чтобы реализовать атаку, требуется так называемое принуждение к NTLM‑аутентификации (NTLM coercion). Это означает заставить DC самому подключиться к машине атакующего и пройти NTLM‑аутентификацию.
Наиболее известные техники coercion:
- PetitPotam (MS‑EFSRPC)
— атака через вызов RPC‑интерфейса шифрования файловой системы. - Print Spooler / MS‑RPRN
— использование бага в службе печати, позволяющего отправлять вызовы на удаленный SMB. - Эксплуатация DCOM, MS‑WPRN, WebDAV и других менее распространенных, но также применимых протоколов.
Бывает, что контроллер не защищен, например включен диспетчер печати или не установлены патчи на EFSRPC вроде KB5005413. Тогда злоумышленник может легко заставить DC обратиться к произвольному UNC‑адресу, контролируемому атакующим, тем самым инициировав NTLM‑релей-атаку, в том числе ESC8.
Если же на такие сервисы установлены соответствующие патчи, атакующий будет вынужден искать другую цель.
Один из ключевых факторов, облегчающих реализацию атаки ESC8, — это настройка центра сертификации и шаблонов, при которой сертификаты автоматически выдаются без участия администратора.
В инфраструктуре с Enterprise CA по умолчанию используется поведение, при котором все запросы на сертификаты одобряются автоматически, если шаблон это разрешает. Такой подход реализован через параметр RequestDisposition = 0×1, означающий «выдать сразу».
Однако если вручную настроить CA или шаблон сертификата на поведение «ручное одобрение», то даже в случае атаки ESC8 запрос попадет в статус Pending и сертификат не будет выдан без проверки администратором. Такая настройка реализуется через значение RequestDisposition = 0×101.
Вот пример конфигурации CA Policy Module, где выбрано поведение по умолчанию «Следовать настройкам шаблона, иначе автоматически выдавать сертификат»:
Такой режим максимально упрощает работу системам авторегистрации, но в случае уязвимого шаблона (например, в технике ESC8) позволяет атакующему получить сертификат немедленно, без возможности блокировки на стороне администратора.
Таким образом, составляющие для ESC8 следующие:
- в инфраструктуре установлен AD CS с уязвимым HTTP-/HTTPS‑веб‑сервисом;
- опубликован подходящий шаблон сертификата с автоматической выдачей;
- допускается NTLM‑аутентификация.
Когда все условия присутствуют, злоумышленнику остается лишь найти способ заставить привилегированный аккаунт совершить NTLM‑вход в его систему.
Рассмотрим шаги атаки ESC8 на примере компрометации контроллера домена с помощью NTLM‑релея на AD CS. Предположим, что в домене развернут уязвимый веб‑сервис AD CS (например, http://ca-server/certsrv/), а у злоумышленника уже есть начальный доступ в сеть (например, скомпрометирована учетная запись без привилегий на рабочей станции).
Сначала злоумышленник ищет в сети веб‑интерфейс службы сертификатов, который работает по протоколу HTTP, в нашем случае http://ca-server/certsrv/. Такие интерфейсы могут быть уязвимы для атак, особенно если они не используют защищенное соединение HTTPS. Для их поиска можно использовать специальные инструменты, например Certify.exe или стандартную команду Windows certutil.exe. Если обнаруживается веб‑интерфейс, работающий по HTTP, это сигнал о потенциальной уязвимости:
Затем злоумышленник использует известные техники Windows, позволяющие инициировать NTLM‑аутентификацию от имени контроллера домена (основного сервера, управляющего сетью) на свой подставной сервер. Одна из таких техник — PetitPotam, которая вызывает обращение контроллера к подконтрольному сетевому ресурсу атакующего. В результате этого DC автоматически проходит NTLM‑аутентификацию и раскрывает хеши (challenge/response).
Злоумышленник осуществляет NTLM‑релей, перенаправляя запрос аутентификации от контроллера домена на уязвимый веб‑сервис AD CS. Для этого используются инструменты вроде ntlmrelayx.py из набора Impacket. AD CS, не проверяя источник, принимает запрос как легитимную NTLM‑аутентификацию от контроллера домена и выдает сертификат на имя последнего.
Веб‑сервис AD CS, приняв аутентификацию, выдает злоумышленнику сертификат, который обычно предназначен для контроллера домена. Этот сертификат подтверждает личность контроллера и может использоваться для аутентификации в сети.
С полученным сертификатом злоумышленник может запросить TGT у службы Kerberos и аутентифицироваться в домене от имени контроллера домена. Для этого применяются инструменты вроде RubeusNTDS.dit, содержащей все хеши паролей в домене).
Таким образом, атакующий может:
- изменять конфигурацию сети и политики;
- создавать, удалять или изменять любые учетные записи;
- экспортировать пароли всех пользователей домена, включая администраторов;
- закрепиться в инфраструктуре незаметно для стандартного мониторинга.
Распознавать факт проведения атаки ESC8 непросто, так как она не эксплуатирует 0‑day-уязвимости или вредоносный код, а использует штатные функции: аутентификацию и выдачу сертификатов. Тем не менее внимательное отслеживание событий безопасности и конфигураций может выявить попытки атаки и предрасположенность системы к ней. Рассмотрим подходы к обнаружению.
Атаку ESC8 можно вычислить, сопоставив несколько событий в журналаx Windows, указывающих на аномальную последовательность.
Входы учетных записей компьютеров на CA‑сервере по NTLM
На сервере, где запущен AD CS, в Security-журнале может появиться событие 4624 (successful logon) с признаками: Account Name, оканчивающееся на $ (компьютер), Target Server = ваш CA‑сервер и Auth Package = NTLM (NtLmSsp).
В обычной работе домена компьютеры не используют NTLM для обращения к службе сертификации. Доменные члены при авторегистрации сертификатов обращаются к CA по Kerberos, если он доступен. Поэтому успешный сетевой вход от имени учетной записи типа DC1$ или WEB1$ на сервере CA с использованием NTLM‑аутентификации — уже тревожный звоночек. Такие события можно отфильтровать в SIEM, например:
EventID=4624 AND TargetHost = "<Имя_CA>" AND LogonType = 3 AND SubjectUserName ENDSWITH "$" AND AuthenticationPackageName="NTLM"
События выдачи сертификатов на CA
При включенном аудите действий службы сертификации (в свойствах CA включен аудит события Issue and manage certificate requests) центр сертификации регистрирует ключевые этапы обработки запроса. Интересны следующие события:
- Event ID 4886. Certificate Services received a certificate request — CA получил запрос на сертификат.
- Event ID 4887. Certificate Services issued a certificate — CA одобрил запрос и выдал сертификат.
Появление этих событий не редкость, но требуется проанализировать их содержимое.
В 4886 в разделе Requester будет указан аккаунт, от чьего имени пришел запрос (например, DOMAIN\DC1$), а в Attributes может быть имя шаблона (например, CertificateTemplate: DomainController). Если вы видите, что сертификат запрошен от имени контроллера домена или другого критичного компьютера, особенно в нестандартное время, — это повод для расследования.
Событие 4887 подтвердит, что сертификат действительно выдан. В нем дополнительно фиксируется идентификатор сертификата — Subject Key Identifier. В сочетании с предшествующим 4624 (вход машины по NTLM) это практически однозначно указывает на технику ESC8.
Совет
Настройте оповещение, если в событиях 4886 и 4887 встречаются имена шаблонов, которые используются для компьютеров или DC, или если Requester содержит $. В обычной работе контроллер домена получает сертификат сразу после развертывания, а не произвольно.
Сетевые соединения с сервера CA
Так как события 4886 и 4887 не содержат IP‑адрес источника, полезно сопоставить их с сетевыми логами. Включите аудит брандмауэра Windows для разрешенного трафика (Event ID 5156). Когда поступит запрос в веб‑службу сертификации, появится событие 5156, где SourceAddress = IP CA, DestAddress = IP источника (так в логах Microsoft инвертируются IP‑адреса для входящих соединений). Например, если CA = 172.16.0.10, а атакующий хост 10.10.10.10, то в 5156 будет SourceAddress = 172.16.0.10 и DestAddress = 10.10.10.10 на порте 80/443.
Обратите внимание на временные метки:
- 4624 (вход
DC1$на CA по NTLM); - 4886/4887 (CA выдал сертификат
DC1$); - 5156 (входящее соединение на CA от подозрительного хоста
10.10.10.10).
Соединив их, можно заключить, что сертификат для DC1 запросил не сам DC1, он сделал бы это со своего собственного IP‑адреса. Запрос произошел с другого узла, что свидетельствует о компрометации через NTLM‑релей.
Также стоит проверить логи IIS на CA‑сервере (если ведутся) — там будет запись о запросе к certsrv или CEP/NDES от IP‑адреса атакующего в момент выдачи.
События на контроллере домена
Со стороны DC могут фиксироваться косвенные признаки: при использовании PetitPotam DC сгенерирует событие 4776 (remote NTLM auth) с сообщением о попытке проверить учетные данные NTLM для собственной учетной записи. Если вы видите на DC событие 4776, где Account Name = DC1$ (сам контроллер) и Status = OK, — это странно, ведь DC не должен сам себя проверять. Такое событие может означать, что DC откликнулся на чей‑то запрос по NTLM.
После успешного проведения атаки злоумышленник с сертификатом DC, запросив Kerberos-тикет, может вызвать на контроллере событие 4768 (TGT requested) для учетной записи DC1$ в необычном контексте. Эти сигналы дополняют общую картину.
В совокупности корреляция перечисленных событий позволяет обнаружить факт атаки. Особенно показательна цепочка: 4624 (NTLM‑вход машины на CA) → 4886/4887 (запрос/выдача сертификата машине) с совпадающими временными метками. Это практически прямое указание на ESC8. Без внедрения средств мониторинга такие детали легко пропустить, поэтому рекомендуется на уровне SIEM регулярно отслеживать подобные аномалии.
Еще один подход — проактивный аудит настроек AD CS и связанных компонентов на наличие слабых мест, которые необходимы для ESC8. По сути, это выявление уязвимой конфигурации до ее эксплуатации. Рассмотрим составляющие такого аудита.
Проверка наличия HTTP‑интерфейсов веб‑регистрации
Один из первых шагов для защиты от атаки ESC8 — проверить, есть ли на ваших серверах центров сертификации включенные веб‑службы, принимающие незащищенные HTTP‑соединения. Это можно выяснить через администраторов системы, с помощью простых команд в PowerShell или через утилиту certutil.
Для быстрого анализа веб‑служб можно использовать команду PowerShell Get-Website. На скриншоте ниже показан пример вывода Get-Website, выполненной на CA, где сразу видно состояние веб‑служб и используемые ими привязки.
Видны следующие сайты:
- Default Web Site — включен и работает через HTTP (порт 80). Это потенциальная уязвимость.
- ESC8 — включен и также использует HTTP, еще одна точка риска.
- certsrv — на момент проверки остановлен, но при запуске он также принимает незащищенные соединения HTTP.
Проверка Extended Protection for Authentication
Одно лишь наличие HTTPS не дает полной защиты от атак NTLM‑релея на веб‑службы AD CS. Для этого обязательно должна быть активирована технология Extended Protection for Authentication (EPA), также известная как channel binding tokens (CBT).
Сам файл выглядит примерно так (нас интересует раздел ближе к концу файла):
<location path="Default Web Site">
<system.webServer>
<security>
<authentication>
<windowsAuthentication enabled="true" useKernelMode="true">
<extendedProtection tokenChecking="Require" />
</windowsAuthentication>
<anonymousAuthentication enabled="true" />
</authentication>
</security>
</system.webServer>
</location>
Этот фрагмент конфигурации включает Windows-аутентификацию для сайта Default Web Site, причем в режиме ядра (это быстрее и безопаснее). Ключевой параметр здесь — extendedProtection tokenChecking="Require", который активирует EPA. Простыми словами, это механизм защиты от атак MitM, при которых злоумышленник может попытаться перехватить и повторно использовать чужую NTLM‑аутентификацию.
Также видно, что активирована анонимная аутентификация (anonymousAuthentication enabled="true"), что означает: сайт можно открыть в браузере без ввода логина и пароля.
На скриншоте — пример правильной настройки EPA в интерфейсе IIS.
Помимо анализа конфигурационного файла applicationHost.config, рекомендуется вручную проверить параметры Windows Authentication в интерфейсе IIS Manager.
Администратору следует открыть IIS Manager и для каждого из следующих виртуальных каталогов убедиться, что параметр Extended Protection установлен в значение Required:
- CertSrv — веб‑интерфейс Web Enrollment (если используется).
- DeviceEnrollmentService — служба NDES.
- CertificateEnrollmentService — служба CES.
- CertificateEnrollmentPolicy — служба CEP.
Проверка реестра AD CS
Некоторые признаки наличия уязвимых ролей можно увидеть в реестре сервера:
Ключи в ветке HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ADCS\ указывают на установленные роли. Например, подпуть NDES с параметром ConfigurationStatus, равным 2 (как правило), означает, что служба NDES установлена и настроена. Если ConfigurationStatus равен 1, значит, NDES установлена, но еще не настроена.
Параметр RequestDisposition
Как отмечалось, автоматическая выдача сертификатов — ключевое условие успеха атаки.
Окно настроек модуля политики (Policy Module) центра сертификации в консоли Certification Authority определяет поведение CA при получении запроса на сертификат:
На скриншоте видны следующие настройки:
- Set the certificate request status to pending. The administrator must explicitly issue the certificate — установка запроса в статус ожидания. В этом случае администратор вручную одобряет каждый сертификат.
- Follow the settings in the certificate template, if applicable. Otherwise, automatically issue the certificate — следование настройкам шаблона сертификата. Если шаблон не требует ручного одобрения, то CA автоматически выдаст сертификат.
Если включен второй пункт, как на скриншоте, это создает уязвимость при наличии шаблонов с автоматической выдачей. Такая настройка часто используется по умолчанию в корпоративных CA.
В реестре CA (ветка HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\PolicyModules\...) глобально хранится параметр RequestDisposition, определяющий политику выдачи:
Для Enterprise CA значение параметра RequestDisposition по умолчанию — 1, что означает автоматическую выдачу сертификатов без участия администратора. Однако, если есть возможность, целесообразно изменить это значение на 0×101. Это включает режим, при котором каждый запрос требует одобрения менеджером CA. Такой подход позволяет снизить риск автоматического получения привилегированных сертификатов при компрометации аккаунта.
Также стоит отдельно проверить настройки шаблонов сертификатов в Active Directory: если шаблон критичен (например, позволяет аутентификацию от имени компьютера или пользователя), убедитесь, что у него установлен флаг CA certificate manager approval:
Если требование ручного одобрения включено для всех шаблонов, по которым компьютер может самостоятельно запросить сертификат, то злоумышленник не сможет немедленно получить привилегированный сертификат даже при наличии доступа.
Однако в большинстве корпоративных сетей, особенно с устаревшими шаблонами версии V1 (например, Computer, Web Server и др.), одобрение со стороны администратора не требуется. Это создает окно возможностей для атакующего, позволяя автоматически получить сертификат, пригодный для аутентификации в домене или проведения атак типа ESC1 или ESC8.
В целом обнаружение по конфигурации сводится к выявлению возможности атаки. Если вы увидели, что запущен Web Enrollment и он доступен по HTTP или EPA не настроена, можно с уверенностью сказать, что ваша инфраструктура подвержена ESC8 и вопрос времени, когда кто‑то этим воспользуется.
Идеальная схема выявления хоста, уязвимого к ESC8, основывается на поэтапном, комплексном подходе. Он включает последовательную проверку ключевых параметров в реестре, а также анализ конфигурации IIS и ролей AD CS.
Рассмотрим этот процесс на примере BI.ZONE EDR. В решении проверка реализована в полностью автоматическом режиме: EDR‑агент выполняет инвентаризацию узла, собирая информацию о критичных конфигурационных элементах, и передает данные в систему анализа.
Рассмотрим, какие именно действия выполняет агент на хосте в рамках этой проверки.
Шаг 1. Проверка реестра
Агент проверяет реестр Windows по пути HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ADCS, так как это самый быстрый способ понять, используются ли потенциально уязвимые компоненты:
Здесь он проверяет наличие подпапок:
- WebEnrollment (веб‑служба регистрации сертификатов);
- NDES (Network Device Enrollment Service);
- CES/CEP (Certificate Enrollment Service/Policy).
Далее, если одна из этих папок обнаружена, смотрит параметр ConfigurationStatus. Значение 2 означает, что компонент полностью настроен и активен — это повод продолжать проверку.
Также агент проверяет путь:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<Имя вашего CA>\PolicyModules\CertificateAuthority_MicrosoftDefault
Здесь он смотрит на параметр RequestDisposition. Если значение равно 0×1 (автоматическое утверждение запросов), это прямой признак упрощенной выдачи сертификатов, что облегчает атаку типа ESC8. Значение 0×101 (ручное утверждение) более безопасно.
Почему сначала реестр?
Такой подход позволяет оперативно выявить, стоит ли тратить время на более глубокий анализ конфигурации IIS, так как при отсутствии активных компонентов веб‑регистрации или опасных настроек политики выдачи сертификатов последующие проверки не имеют смысла.
Шаг 2. Проверка IIS
Если обнаружены уязвимые компоненты и упрощенная политика выдачи сертификатов, агент проверяет детальную конфигурацию IIS по пути %SystemRoot%\System32\inetsrv\config\applicationHost.config.
CONFIG-файл содержит следующие параметры:
- windowsAuthentication:
enabled— должен бытьtrue;useKernelMode— предпочтительноtrue;- вложенный параметр:
- extendedProtection tokenChecking="Require" — должно быть именно
Requireдля защиты от NTLM‑релея; - providers — желательно убрать NTLM, оставить только Negotiate;
- extendedProtection tokenChecking="Require" — должно быть именно
- anonymousAuthentication:
enabled. Если анонимная аутентификация включена (enabled="true"), администратору CA необходимо убедиться, что этот параметр включен только для действительно публичных, некритичных ресурсов. Для всех чувствительных ресурсов он должен быть отключен (enabled="false");
- access sslFlags — должен содержать
Ssl,Ssl128илиSslRequireCert, гарантируя использование только HTTPS; - отсутствие HTTP‑привязок — веб‑служба должна быть доступна исключительно по HTTPS;
- requestFiltering allowDoubleEscaping — должен быть установлен в
false, если нет специальной необходимости, поскольку это уменьшает поверхность атаки.
Таким образом, этот подход позволяет:
- Быстро выявить потенциальную уязвимость через реестр.
- Провести точечный глубокий анализ IIS только там, где это реально необходимо.
В дополнение к этому при малейших изменениях в файле %SystemRoot%\System32\inetsrv\config\applicationHost.config и при наличии на сервере настроенной веб‑службы сертификации (CA Web Enrollment) решение автоматически инициирует переоценку конфигурации с последующей инвентаризацией и анализом на наличие потенциальных мисконфигураций.
Такой подход — не просто реактивная мера, а проактивная защита в реальном времени. Он позволяет своевременно выявлять и устранять критические уязвимости конфигурации, снижая риск атак, таких как ESC8.
Защита от ESC8 заключается в правильной настройке и сегментации служб AD CS, а также в ограничении использования NTLM в инфраструктуре. Ниже собрали практические рекомендации.
Лучшая мера — устранить цель атаки. Если ваша организация не пользуется устаревшим веб‑порталом CertSrv или сервисами CEP, CES и NDES, удалите их.
Например, для удаления веб‑портала сертификатов выполните команду PowerShell Uninstall-AdcsWebEnrollment -Force. Аналогично есть команды Uninstall-AdcsEnrollmentWebService и Uninstall-AdcsEnrollmentPolicyWebService для CES и CEP. А удалить роль NDES можно через Remove-WindowsFeature NDES либо соответствующий командлет.
Удаление лишних компонентов значительно сузит поверхность атаки. Если полностью избавиться от них невозможно, рассмотрите хотя бы отключение соответствующих веб‑сайтов в IIS или такую настройку брандмауэра, чтобы эти службы были недоступны из тех сегментов сети, откуда не предполагается легитимных подключений.
Кардинальное решение — полностью отключить NTLM в домене. Правда, это очень сложно и может нарушить работу старых систем. Вот более реалистичные меры:
1. Отключить NTLM на самом CA‑сервере
Чтобы исключить возможность NTLM‑аутентификации на сервере сертификатов (CA), можно использовать Group Policy, в частности параметры в разделе Security Options → Network Security: Restrict NTLM. Эти настройки позволяют либо полностью запретить входящий NTLM, либо гибко его ограничить.
Полный запрет NTLM может сломать работу некоторых веб‑служб AD CS (например, Web Enrollment), особенно если клиенты не умеют работать через Kerberos. Но лучше заранее подготовить инфраструктуру и заставить ее использовать только Kerberos.
Если полностью отключать NTLM нельзя, стоит хотя бы ограничить его — например, запретить на всех серверах прием NTLM‑аутентификации от аккаунтов контроллеров домена. Это не даст атаке PetitPotam использовать NTLM‑релей: даже если DC будет принужден к аутентификации — остальные серверы просто откажутся это принимать.
Что настраивается в GPO
Откройте Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options.
Найдите следующие параметры:
- Network Security: Restrict NTLM: Incoming NTLM traffic. Значение Deny all accounts (2) запрещает любую входящую NTLM‑аутентификацию на сервере.
- Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers. Значение Deny all (2) запрещает серверу инициировать NTLM‑аутентификацию к другим серверам.
- Network Security: Restrict NTLM: Add server exceptions in this domain. Используется, если нужно разрешить отдельные хосты (например, DC) при общем запрете NTLM.
- Network Security: Restrict NTLM: Add remote server exceptions for NTLM authentication. Если запрещен исходящий NTLM‑запрос, можно добавить исключения для критически важных сервисов.
После настройки GPO на сервере CA можно проверить, применились ли политики, через следующие параметры в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0.
Входящий NTLM
| Параметр |
RestrictReceivingNTLMTraffic |
| Тип |
REG_DWORD |
| Значения |
|
Исходящий NTLM
| Параметр |
RestrictReceivingNTLMTraffic |
| Тип |
REG_DWORD |
| Значения |
|
Параметры-исключения:
ClientAllowedToUseNTLMServers(MULTI_SZ) — список серверов, к которым разрешено отправлять NTLM;ServerAllowedToReceiveNTLMClients(MULTI_SZ) — список клиентов, которым разрешен входящий NTLM.
Минимальный набор значений для усиления защиты CA
Если нельзя отключить NTLM полностью, но нужно защититься от атак типа PetitPotam, выполните следующие рекомендации:
- На всех серверах, кроме DC, установите:
RestrictReceivingNTLMTraffic = 2RestrictSendingNTLMTraffic = 2
- На контроллере домена установите:
RestrictReceivingNTLMTraffic = 1;RestrictSendingNTLMTraffic = 1.
- Используйте списки исключений, если нужно разрешить доступ от определенных узлов:
ServerAllowedToReceiveNTLMClients = "DC01.good.local".
Минимальные значения параметров NTLM позволяют заблокировать атаки типа PetitPotam, не ломая инфраструктуру. На всех серверах, кроме DC, включается полный запрет приема и отправки NTLM (RestrictReceivingNTLMTraffic = 2, RestrictSendingNTLMTraffic = 2), а на самих контроллерах домена устанавливается ограничение (1). Оно допускает NTLM только для локальных или доверенных хостов. Все это не даст DC аутентифицироваться по NTLM к уязвимым сервисам.
Но если полностью отключить NTLM невозможно, минимальные настройки — уже хороший шаг. Это не даст контроллеру домена отправить NTLM куда угодно, а другие серверы откажутся его принимать, даже если атака принудит DC аутентифицироваться.
Это не идеальная защита, но практический компромисс, который действительно останавливает PetitPotam и аналогичные техники.
2. Ограничить NTLM в веб‑приложении
В IIS можно настроить директорию так, чтобы из списка провайдеров Windows-аутентификации был удален NTLM, оставив только Negotiate. Это заставит клиента сначала попробовать Kerberos. Но важно понимать: если у сервиса не прописан SPN или клиент не в домене, параметр Negotiate все равно переключится на NTLM, несмотря на то что последний убрали. Поэтому такой подход не дает полной гарантии.
Если необходимо действительно исключить NTLM, включите Extended Protection с параметром tokenChecking="Require", потому что он запрещает использование NTLM в рамках защищенного канала и блокирует релей в принципе.
Для всех веб‑служб AD CS (CertSrv, CEP, CES и т. п.) обязательно включите шифрование и защиту канала. В IIS проверьте, что сайт вообще не принимает соединения на порте 80, — оставьте только HTTPS‑привязку с корректным сертификатом.
Затем в настройках Windows Authentication установите Extended Protection = Required и по необходимости включите Enable Kernel-mode authentication:
Это активирует проверку CBT, и, если кто‑то попытается сделать релей с другого TLS‑соединения, атака не сработает, потому что хеш канала будет отличаться.
Это основной механизм защиты от PetitPotam и ESC8, он официально рекомендован Microsoft.
CNAME и алиасы
Если клиенты обращаются к сайту не по основному имени, а по псевдониму, Kerberos может не сработать — и все развалится. В таких случаях:
- Добавьте отдельный SPN для этого имени.
- Если нужно, временно переведите Extended Protection в режим Allow вместо Require — для совместимости, но с пониманием рисков.
NDES часто устанавливается на отдельный сервер. Удостоверьтесь, что он настроен безопасно: включен только HTTPS. Можно следовать официальной инструкции по включению SSL для NDES, по умолчанию NDES устанавливается без принудительного SSL. Также NDES работает под сервисной учетной записью — убедитесь, что у нее нет лишних привилегий. По возможности разместите NDES‑сервер в изолированной VLAN, недоступной напрямую клиентским хостам, чтобы затруднить к нему релей. Если NDES не нужен, удалите эту роль.
Рассмотрите возможность включения Certificate Manager Approval для чувствительных шаблонов сертификатов. Особенно это касается шаблонов, которые позволяют аутентификацию в домене, например Machine/Computer, Domain Controller, KerberosAuthentication. Если атака произойдет, запрос останется в состоянии Pending и не приведет к немедленной эскалации привилегий, а вы выиграете время на обнаружение.
Реализовать это можно двумя путями:
- Глобально. На уровне CA изменить политику выдачи. Для Enterprise CA это можно сделать через реестр (или certutil, графический интерфейс): установить
RequestDisposition=0×101(вместо0×1) и перезапустить службу CA. Тогда все входящие запросы будут требовать ручного подтверждения. Этот метод радикален и замедлит работу автовыдачи даже по легитимным запросам. - Локально. Изменить свойства конкретных шаблонов через оснастку Certificate Templates. На вкладке Issuance Requirements поставить галочку CA certificate manager approval. Например, можно сделать это для шаблонов версии 2 и выше (их запрашивается не так много) или для шаблонов, которыми вы не пользуетесь регулярно. Оставьте автоматическую выдачу только для самых безобидных сертификатов. Также можно отменить публикацию ненужных опасных шаблонов вовсе.
Включение ручного утверждения через ADSI (для V1‑шаблонов)
- Откройте оснастку ADSI Edit
adsiedit.msc. - Подключитесь к Configuration →
CN=Configuration,DC=yourdomain,DC=local. - Перейдите по ветке
CN=Services→CN=Public Key Services→CN=Certificate Templates. - Найдите нужный шаблон, например User, WebServer, Computer.
- Кликните правой кнопкой мыши и выберите Properties.
- Найдите атрибут
msPKI-Enrollment-Flag. Нажмите Edit и установите флаг CT_FLAG_PEND_ALL_REQUESTS.
Нужно выставить флагу такое значение, чтобы при сравнении побитово с 0×00000002 результат был равен 1.
Чтобы проверить, включен ли определенный флаг, используется побитовое И (битовая операция AND) между текущим значением флагов и интересующим нас флагом.
Пример:
- Текущее значение —
9(в двоичном виде0b00001001). - Проверяем флаг —
2(в двоичном виде0b00000010).
Выполняем побитовую операцию AND:
00001001 & 00000010 = 00000000
Результат — 0, флаг не установлен.
А если бы текущее значение было 11 (0b00001011):
00001011 & 00000010 = 00000010
Результат не равен 0, флаг установлен.
Microsoft советует отключать службу очереди печати на контроллерах домена и серверах, где она не нужна. Эта рекомендация появилась после атаки PrintNightmare/PetitPotam. В контексте ESC8 без запущенной Spooler злоумышленник не сможет использовать метод печати для принуждения DC к NTLM‑аутентификации. На контроллерах домена, начиная с Windows Server 2022, Spooler по умолчанию отключена. Проверьте у себя и, если возможно, отключите Spooler на DC и на самом CA‑сервере (AD CS не требует эту службу). Это устраняет один из простейших векторов принуждения.
Включите детальный аудит на CA: в свойствах CA → Auditing включите все опции (особенно Issue and Manage Certificates) и с помощью auditpol включите категорию Certification Services. Настройте сбор логов событий 488x, 46xx в SIEM и корреляционные правила, как описано в разделе обнаружения.
Также регулярно просматривайте выданные сертификаты. Команда certutil -view -restrict "Disposition=20" -out "RequestID,RequesterName,CommonName,CertificateTemplate,NotBefore,NotAfter" покажет, кто запрашивал сертификаты и какие были выданы за последнее время. Еще с помощью утилит типа Certipy можно получить список недавно выданных сертификатов и удостовериться, что все они легитимны. Если обнаружен неизвестный сертификат на имя контроллера или админа, немедленно отзовите его и расследуйте инцидент.
Следите за рекомендациями Microsoft. Хотя на момент появления PetitPotam прямого исправляющего патча не было (так как это скорее неправильная конфигурация), Microsoft выпустила консультацию ADV210003 и обновление безопасности KB5005413, в которых предписано включить EPA и т. д.
Убедитесь, что ваш CA‑сервер обновлен хотя бы до последних сборок Windows, так как новые версии усиливают безопасные настройки по умолчанию. Например, Windows Server 2022 при установке AD CS может сразу требовать Kerberos для CES и CEP. Также по возможности откажитесь от устаревшего шаблона Web Enrollment. Он был нужен в старых Windows для веб‑доступа, но сейчас практически все задачи можно выполнять через MMC или PowerShell либо через CES/CEP по HTTPS.
Выполнение этих рекомендаций существенно снизит риск успешного проведения атаки ESC8. Ключевыми мерами считаются включение EPA и отключение HTTP на сервисах AD CS. В долгосрочной перспективе полный отказ от NTLM и усиленный мониторинг формируют многоуровневую защиту.
Атака ESC8 на AD CS демонстрирует, как сочетание устаревших протоколов (NTLM) и неочевидных конфигурационных недочетов может привести к критическим последствиям в инфраструктуре Active Directory. Злоумышленники, используя NTLM‑релей-атаку на веб‑интерфейсы центра сертификации, способны получить цифровые сертификаты привилегированных аккаунтов и тем самым обойти традиционные механизмы аутентификации.
Для защиты от подобных атак организации должны проактивно подходить к настройке AD CS: отключать неиспользуемые роли, применять шифрование и расширенную защиту, ограничивать NTLM, контролировать шаблоны и включать аудит. Особое внимание следует уделить веб‑компонентам AD CS (Web Enrollment, CEP, CES, NDES). При неверной настройке они становятся ахиллесовой пятой безопасности домена. Регулярный аудит конфигураций (например, проверка ключей реестра и IIS‑конфигурации), а также мониторинг событий безопасности помогут выявить уязвимости и попытки их эксплуатации на раннем этапе.