ESC9. Эксплоит No Security Extension в корпоративной PKI
ESC9 заключается в использовании шаблонов сертификатов, у которых отключено расширение безопасности szOID_NTDS_CA_SECURITY_EX (CT_FLAG_NO_SECURITY_EXTENSION). В результате сертификат не содержит SID владельца, что позволяет злоумышленнику аутентифицироваться в домене от имени чужой учетной записи, используя слабое (неявное) сопоставление сертификатов по user principal name (UPN) или DNS‑имени.
Коротко о szOID_NTDS_CA_SECURITY_EX
Это расширение обычно связывает сертификат с конкретной учетной записью пользователя или компьютера через ее уникальный идентификатор (SID). Без этого расширения сертификаты не содержат информации о SID, а контроллер домена вынужден использовать слабые механизмы сопоставления, например по UPN или DNS‑имени.
Именно наличие флага CT_FLAG_NO_SECURITY_EXTENSION в шаблоне делает возможной ESC9 и другие атаки, связанные с обходом строгого сопоставления сертификатов. Подробнее о szOID_NTDS_CA_SECURITY_EX читайте в справочных материалах.
В рамках ESC9 различают два сценария в зависимости от типа используемого сопоставления:
- ESC9a — через UPN (для пользовательских сертификатов).
- ESC9b — через DNS‑имя (для компьютерных сертификатов).
Оба варианта приводят к эскалации привилегий, но нацелены на разные типы целевых учетных записей (пользователи или компьютеры).
Для успешной реализации атаки ESC9 должно совпасть несколько условий:
- Уязвимый шаблон сертификата. Должен существовать шаблон с установленным флагом
CT_FLAG_NO_SECURITY_EXTENSION(значение флага в параметреmsPKI-Enrollment-Flagравно0x00080000). Именно такой шаблон позволит выпустить сертификат без SID‑связки. Кроме того, шаблон должен быть опубликован в корпоративном центре сертификации (CA) и доступен для регистрации (Enrollment). Шаблон не должен требовать одобрения со стороны администратора CA или дополнительных подписей, то есть должна быть прямая выдача. - Соответствующие EKU / Application Policies. Шаблон сертификата должен поддерживать аутентификацию, иначе даже выданный сертификат не сможет использоваться для входа в систему. В частности, сертификат может применяться в атаках, чтобы:
- Получить Kerberos TGT через PKINIT (чаще всего в случае с ESC9a). Для этого в шаблоне должны быть OID для аутентификации, такие как Client Authentication или Smart Card Logon. Эти EKU позволяют использовать сертификат при входе в Active Directory.
- Использовать TLS‑аутентификацию по протоколу Schannel (например, в случае с ESC9b). В этом случае достаточно наличия EKU TLS Web Client Authentication: он позволяет проходить проверку при подключении к защищенным службам через TLS (например, RDP или HTTPS с клиентскими сертификатами).
-
Конфигурация контроллеров домена, допускающая слабое сопоставление. На контроллерах домена должна быть активна возможность сопоставления сертификата по UPN или DNS. В идеале администраторы домена должны установить
StrongCertificateBindingEnforcement=2(полное требование SID) и отключить сопоставление по UPN. Это сделает атаку невозможной.Техника ESC9 нацелена на ситуации, когда используется режим совместимости (значение1, установленное по умолчанию в современных системах) или даже устаревший режим0.Также атаку упрощает наличие флага UPN в реестровом параметреCertificateMappingMethods(значение0x4), позволяющего сопоставление по UPN. После патча 2022 года по умолчанию сопоставление по UPN отключено (значение по умолчанию0x18вместо старого0x4), однако администраторы могут включить его обратно для совместимости.То есть для успеха ESC9 должна быть возможна неявная привязка сертификата к учетной записи — либо через один из слабых режимовStrongCertificateBindingEnforcement(0или1), либо при включенной поддержке UPN‑маппинга через параметрCertificateMappingMethods.Если же у контроллера доменаStrongCertificateBindingEnforcement=2(жесткая привязка) и отключена привязка по UPN, то такой сертификат (без SID) просто не будет принят. Даже если его удалось получить, атака провалится. -
Права на регистрацию у контролируемой учетной записи. Злоумышленник должен контролировать учетную запись, которой разрешено зарегистрировать сертификат по уязвимому шаблону.Обычно в AD CS права на шаблон сертификата назначаются группам или пользователям через Access Control Entry (например, разрешение Enroll). Во многих организациях шаблоны доступны всем аутентифицированным пользователям, группе Domain Users или выделенным отделам. В контексте атаки любая учетная запись, у которой есть право Enroll и которую злоумышленник может использовать для отправки запроса на сертификат, называется жертвой.Получить такой контроль можно разными способами: с помощью перехвата учетных данных, сброса пароля при наличии соответствующих разрешений, использования техники shadow credentials (добавление альтернативного ключа для входа) и т. д. Главное — в момент запроса сертификата злоумышленник должен быть способен аутентифицироваться как эта учетная запись.
- Доверие к центру сертификации. Эксплуатация имеет смысл, только если целевой Enterprise CA — доверенный для аутентификации в домене. В большинстве случаев Enterprise CA автоматически доверен доменом (его корневой сертификат находится в хранилище Trusted Root на контроллерах) и выпущенные им сертификаты принимаются для NT‑аутентификации. Если же атакуемый CA не интегрирован с AD или не доверен для входа (например, standalone CA без публикации сертификата в NTAuthStore), то даже выпущенный сертификат не даст привилегий.
- Подходящая целевая учетная запись. Злоумышленник должен определить конечную цель: от чьего имени он хочет получить доступ. В случае атаки через UPN (ESC9a) обычно это член группы Domain Admins (например, встроенная учетная запись
Administrator). Если же эксплуатируется вариант через DNS (ESC9b) — учетная запись компьютера (например, контроллера домена). Необходимое условие — знать имя целевой учетной записи, и желательно домен (если в среде их несколько).В рамках ESC9 не требуется прямая компрометация целевой учетной записи — ее имя будет использовано при подмене поля сертификата.
Если все перечисленные условия соблюдены, инфраструктура уязвима для атаки ESC9. Отметим, что режим StrongCertificateBindingEnforcement = 0/1 не поддерживается в обновлениях безопасности Windows (KB5014754) с февраля 2025 года.
Разберем, как именно проходит атака в обоих возможных вариантах (ESC9a и ESC9b) в необновленных системах.
В ходе ESC9a атакующий стремится выдать себя за привилегированного пользователя домена. Злоумышленник использует уязвимый шаблон сертификата и подмену UPN. Предположим, на CA опубликован уязвимый шаблон UserTemplate с No Security Extension и EKU для клиентской аутентификации или аутентификации по смарт-карте. А атакующий контролирует учетную запись, у которой есть право Enroll на этот шаблон. Цель — получить доступ от имени привилегированной учетной записи, например администратора домена.
В ходе атаки злоумышленник выполняет следующие шаги:
Шаг 1. Получает доступ к учетной записи жертвы — пользователя, у которого есть право регистрации сертификатов по уязвимому шаблону. Это право выражается в наличии параметра Enroll (0e10c968-78fb-11d2-90d4-00c04f79dc55) в шаблонах сертификации:
Шаг 2. Изменяет UPN жертвы на sAMAccountName цели (Admin). Залог успеха — убедить центр сертификации выдать сертификат, в котором указано имя целевой учетной записи в поле User principal name.
Обычно при выпуске сертификата поле UPN заполняется автоматически на основе атрибута userPrincipalName учетной записи заявителя. Поэтому злоумышленник изменяет атрибут userPrincipalName у учетной записи, установив значение равным имени цели.
Например, злоумышленник хочет выдать себя за встроенного Administrator@corp.local. Но у настоящей учетной записи администратора UPN может быть пустым либо заданным как Administrator@corp.local.
Если атакующий попытается напрямую задать UPN как Administrator@corp.local, произойдет конфликт, ведь такой UPN уже существует в системе. Это может вызвать ошибку при создании объекта или изменении атрибута, и в логах будет видно, что кто‑то пытался задать дублирующее имя. Администратор может это заметить.
Чтобы избежать конфликта и остаться незамеченным, атакующий делает одно из двух:
- устанавливает UPN просто как
Administrator(без домена); - указывает фейковый домен, например
Administrator@fake.local.
Таким образом, получается UPN, который технически не конфликтует с Administrator@corp.local, но может использоваться для маскировки в некоторых атаках.
Для успешной атаки шаблон сертификата необходимо настроить так, чтобы UPN попадал не в основное поле Subject, а в расширение SAN. С этой целью злоумышленник выбирает опцию Build from this Active Directory information и включает флажок User principal name (UPN), как показано на скрине ниже. При этом можно выбрать и SPN, поскольку туда включен UPN — так описывает Microsoft.
Шаг 3. Запрашивает сертификат по уязвимому шаблону (без SID). Теперь злоумышленник, выступая от имени жертвы (например, администратора), отправляет запрос на выпуск сертификата по уязвимому шаблону, например UserTemplate. Это становится возможным, потому что в запросе указывается измененный UPN, то есть имя жертвы, под которое подделывается сертификат.
Запрос можно отправить с помощью инструментов Certify
certipy req -u "<UserName>@<Domain>" -p "<Password>" -ca "<CAName>" -template "UserTemplate" -target "<CAHost>"
Если шаблон не требует строгой проверки SID (как это часто бывает с устаревшими шаблонами), CA примет запрос и выдаст сертификат, не проверяя, совпадает ли UPN с реальной учетной записью отправителя.
Шаг 4. Получает сертификат с UPN целевой учетной записи. В результате злоумышленник получает файл сертификата (в формате PFX или CER с приватным ключом), у которого:
- в поле UPN указано имя администратора;
- отсутствует расширение с SID, что позволяет использовать сертификат для аутентификации от имени жертвы.
Шаг 5. Восстанавливает исходные параметры учетной записи. Получив сертификат, злоумышленник возвращает атрибут UPN учетной записи в исходное состояние (например, обратно UserA@<Domain>). Это нужно, чтобы не оставлять на виду нелогичное значение UPN и избежать возможного обнаружения слишком долгого несоответствия.
Шаг 6. Использует сертификат для аутентификации на DC. Это ключевой шаг — злоумышленник использует выданный сертификат, содержащий UPN администратора, для входа в систему.
Поскольку сертификат выпущен доверенным CA и у контроллеров домена включено слабое сопоставление, при попытке входа контроллер попытается сопоставить UPN из сертификата с учетной записью в AD.
В сертификате UPN = <TargetUser(Administrator)>, и контроллер находит соответствующую учетную запись в домене. Отсутствие SID в сертификате уже не играет роли: DC воспринимает это как сертификат, выданный на учетную запись Administrator. Злоумышленник может, к примеру, запросить Kerberos TGT от имени администратора с помощью этого сертификата (PKINIT). Инструменты вроде Rubeus или Certipy позволяют выполнить вход по смарт-карте. Вот пример с Rubeus для получения TGT:
Rubeus.exe asktgt /user:<TargetUser> /certificate:cert.pfx /password:<PfxPassword> /domain:<Domain> /dc:<DC>
Шаг 7. Получает доступ от имени целевой учетной записи (Admin). В результате успешной аутентификации злоумышленник получает учетные данные домена — по сути, полный доступ с привилегиями цели. В случае администратора домена это означает компрометацию всего домена.
Также при подобной атаке можно извлечь хеш NTLM целевого пользователя. NTLM‑хеш можно получить через дальнейшую атаку с помощью TGT, выданного PKINIT. Однако в любом случае злоумышленник уже обладает правами цели.
В ходе ESC9b злоумышленник фокусируется на эскалации привилегий через имперсонацию учетной записи компьютера (machine account) с использованием сопоставления по DNS‑именам.
Наиболее опасный сценарий — когда атакующий выдает себя за контроллер домена. Предпосылки схожи с ESC9a, но жертвой выступает учетная запись компьютера с правом на шаблон с No Security Extension, где требуется включение DNS в сертификат. Например, шаблон WorkstationTemplate требует наличия DNS‑имени заявителя в SAN и также не встраивает SID. Группа Domain Computers имеет право Enroll по этому шаблону.
Атакующий контролирует учетную запись компьютера (возможно, ранее созданную через MachineAccountQuota или захваченную), которая может получить сертификат по этому шаблону. Цель — сымитировать учетную запись, например контроллер DC01$.
В ходе атаки злоумышленник выполняет следующие шаги:
Шаг 1. Получает доступ к учетной записи компьютера-жертвы. Злоумышленник может пойти двумя путями:
- Создать новый компьютер в домене, если политика
ms-DS-MachineAccountQuotaэто позволяет (по умолчанию 10 машин на пользователя), задав известный пароль. - Получить права GenericWrite на существующий компьютер и установить ему пароль.
В итоге у атакующего есть имя учетной записи компьютера и ее пароль, что позволяет аутентифицироваться от имени этой машины.
Шаг 2. Изменяет dNSHostName компьютера-жертвы на dNSHostName цели (например, DC). Атакующий подготавливает атрибуты, чтобы шаблон WorkstationTemplate требовал DNS‑имя в сертификате:
И после этого обычно CA автоматически подставляет в сертификат значение из атрибута dNSHostName учетной записи компьютера, поэтому злоумышленник меняет dNSHostName на имя целевой машины.
Шаг 3. Запрашивает сертификат по уязвимому шаблону (без SID). В запросе на сертификат указано поддельное имя машины.
Шаг 4. Получает сертификат с dNSHostName целевого компьютера. В сертификате поддельное имя прописано как основное. Например, если указать в измененном dNSHostName значение DC01, то выданный сертификат будет ассоциирован с учетной записью контроллера домена — и даст такие же права.
Шаг 5. Восстанавливает исходный dNSHostName компьютера-жертвы. После получения сертификата злоумышленник возвращает исходной учетной записи ее настоящее имя, чтобы не вызывать лишнего внимания или сбоев в работе.
Шаг 6. Использует сертификат для аутентификации на контроллере домена (DC). После получения сертификата злоумышленник может использовать его для аутентификации в домене от имени целевой машины, в том числе контроллера домена. В таком случае становится возможным выполнение чувствительных действий от имени контроллера, включая, например, DCSync — репликацию NTDS.dit с хешами паролей всех пользователей домена.
Шаг 7. Получает доступ от имени целевого компьютера (например, DC). На этом этапе атака завершена, и злоумышленник может использовать полученные полномочия для скрытного доступа в течение длительного времени. Именно поэтому так важно вовремя заметить признаки ее выполнения.
Обнаружить реализацию атаки ESC9 по косвенным признакам сложно, так как злоумышленник использует штатные функции AD CS и корректные сертификаты. Однако существуют характерные артефакты, по которым можно выявить либо подготовку, либо сам факт атаки.
Мониторинг изменений в атрибутах учетных записей
Поскольку в ходе атаки злоумышленник изменяет ключевые атрибуты, например userPrincipalName у пользователя или dNSHostName у компьютера, эти изменения можно и нужно отслеживать.
Для этого:
- Включите аудит изменений свойств объектов AD — это категория Directory Service Changes в групповой политике. При этом на контроллерах домена будет фиксироваться событие 5136 в журнале Security, указывающее, какой атрибут изменен, кем и когда.
- Настройте SACL (system access control list) на интересующие объекты или контейнеры. Без этого события 5136 не будут записываться даже при включенной политике. Убедитесь, что аудит установлен, например, на действия Write Property по атрибутам
userPrincipalNameиdNSHostName.
Пример тревожного признака
Если у обычного пользователя внезапно появляется UPN = Administrator (особенно без домена) или у рядового компьютера dNSHostName неожиданно меняется на имя контроллера — это явный индикатор возможной компрометации и попытки атаки через сертификаты.
Логи центра сертификации о выдаче сертификатов
На сервере AD CS рекомендуем включить аудит управления сертификатами. В журнале Certificate Services появляются события:
- Event ID 4886 — получен запрос на сертификат.
- Event ID 4887 — запрос одобрен и сертификат выдан.
Каждая выдача содержит информацию о том, кто запрашивал (имя учетной записи) и по какому шаблону. Аналитик может сопоставить: если пользователь запросил сертификат, а в деталях (Subject/SAN) значится имя другого субъекта — это аномалия. Также обращайте внимание на выдачу сертификатов по шаблонам, которые редко используются, особенно если сразу за этим следует вход.
Логи безопасности на контроллерах (аутентификация по сертификату)
При использовании сертификата для входа в Kerberos на контроллере домена появляются события:
- Event ID 4768 — фиксируется при первичной аутентификации клиента (пользователя или компьютера) в Kerberos. Важное поле — Pre-Authentication Type, которое указывает способ аутентификации:
0x2или0x8используются при аутентификации по смарт-карте или сертификату (PKINIT). Если после события 4887 (выдача сертификата) сразу появляется 4768 с необычным UPN — это может указывать на попытку входа с поддельным сертификатом. - Event ID 4769 — фиксируется, когда клиент запрашивает билет на доступ к конкретному сервису (CIFS, LDAP, HTTP и т. д.), используя ранее полученный TGT. Это не первичная аутентификация, а ее продолжение.
При анализе этого события обращайте внимание на следующие поля:
| Поле | Значение |
|---|---|
| Service Name |
SPN целевого сервиса, например |
| Service ID |
Учетная запись сервиса (например, |
| Client Name |
Имя клиента, запрашивающего билет |
| Client Address |
IP-адрес клиента |
| Ticket Encryption Type |
|
Вот какие аномалии можно заметить:
- Ticket Encryption Type =
0x12, но у вас не используются PKI или смарт-карты. Использование сертификата без легитимной инфраструктуры подозрительно. - Client Name =
Administrator, но Client Address = обычная рабочая станция. В норме администратор работает с терминального сервера или своей машины. - Массовые запросы TGS по разным SPN за короткое время могут говорить о горизонтальном перемещении или service enumeration с использованием скомпрометированного TGT.
- Множество событий 4769 с одного IP‑адреса, но от разных учетных записей говорит о возможной автоматизации атаки или массовом использовании сертификатов.
Например, если злоумышленник провел атаку ESC9 и получил сертификат на имя контроллера домена, он может использовать этот сертификат для аутентификации через PKINIT. Это приведет к событию 4769 с такими параметрами:
- Client Name =
DC01$. - Client Address = рабочая станция злоумышленника.
- Encryption Type =
0x12.
Так вы видите, что якобы контроллер домена получил сервисный билет, но с чужого IP‑адреса и по сертификату, чего быть не должно.
Корреляция событий
Совпадение по времени событий 4886/4887 (выдача сертификата на CA) и 4768 (запрос TGT на контроллере домена) — сильный индикатор потенциальной атаки.
Если эти события происходят в течение нескольких секунд или минут, это может означать, что сертификат был немедленно использован для Kerberos-аутентификации.
Мы рекомендуем включить такую корреляцию в систему мониторинга — это эффективный способ выявить использование сертификатов в рамках атак ESC9.
Можно обнаружить уязвимые настройки еще до того, как злоумышленник проведет атаку. Если своевременно исправить критические конфигурации, ESC9 можно полностью предотвратить. Для этого:
- Проверьте параметр
StrongCertificateBindingEnforcement, который отвечает за строгое сопоставление сертификатов, он должен иметь значение2. - Убедитесь, что в системе отсутствуют шаблоны сертификатов, допускающие слабое сопоставление по UPN или DNS.
- Проверьте права пользователей на выдачу и автовыдачу сертификатов, особенно если это пользователи без административных привилегий.
Однако самый важный параметр — это NO_SECURITY_EXTENSION. Если он включен, сервер становится потенциально уязвимым. Подробнее о нем читайте в справочных материалах. Таким образом, если заранее проверить состояние параметра NO_SECURITY_EXTENSION и убедиться, что он отключен, атака ESC9 станет невозможной.
Для оценки безопасности шаблонов сертификатов важно проверить, установлен ли флаг CT_FLAG_NO_SECURITY_EXTENSION (значение 0x80000, или 524288 в десятичной форме). Этот флаг отключает привязку сертификата к SID, что позволяет злоумышленнику использовать сертификат от чужого имени.
Проверка флага CT_FLAG_NO_SECURITY_EXTENSION
На сервере, где установлен центр сертификации, значения флагов шаблонов можно найти в реестре по пути HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\CertificateTemplateCache\. В каждом шаблоне ищите параметр msPKI-Enrollment-Flag:
Чтобы определить, установлен ли нужный флаг, выполните побитовую операцию AND между значением msPKI-Enrollment-Flag и числом 524288. Например, если флаг шаблона равен 60100, то:
$flag = 60100 ($flag -band 524288) -ne 0 # Результат будет False — флаг не установлен
Если результат не равен нулю (True), это значит, что флаг установлен и шаблон потенциально уязвим: можно подставить произвольный UPN или DNS в поле SAN без привязки к конкретной учетной записи.
Такую проверку стоит проводить для всех шаблонов, особенно если на них есть права Enroll у обычных пользователей или групп Domain Users, Authenticated Users и т. п.
Но если по каким‑то причинам CT_FLAG_NO_SECURITY_EXTENSION необходим, то в шаблоне, где был выявлен этот флаг, найдите параметр ms-PKI-Certificate-Application-Policy и проверьте, какие политики OID разрешены этому шаблону:
Вот самые опасные политики из всех, которые могут быть:
| EKU | Kerberos Authentication | Schannel Authentication |
|---|---|---|
| Client Authentication (1.3.6.1.5.5.7.3.2) |
True |
True |
| Any Purpose (2.5.29.37) |
True |
True |
| SubCA (нет EKU) |
True |
True |
| PKINIT Client Authentication (1.3.6.1.5.2.3.4) |
True |
False |
| Smart Card Logon (1.3.6.1.4.1.311.20.2.2) |
True |
False |
Таблица помогает понять, какие EKU позволяют использовать сертификат для аутентификации в AD по Kerberos или Schannel. Например:
- Для ESC9a (Kerberos через UPN) подойдут:
1.3.6.1.5.5.7.3.2,2.5.29.37,1.3.6.1.5.2.3.4,1.3.6.1.4.1.311.20.2.2, а также сертификаты без EKU. - Для ESC9b (TLS/Schannel через DNS) подойдут:
1.3.6.1.5.5.7.3.2,2.5.29.37и сертификаты без EKU.
Проверка дескрипторов безопасности
Проверьте, какие непривилегированные пользователи имеют право на выдачу или автоматическую выдачу сертификатов. Для этого проанализируйте дескрипторы безопасности шаблонов, в частности наличие разрешений Enroll (0e10c968-78fb-11d2-90d4-00c04f79dc55) для следующих групп:
- Domain Users (
DU). - Authenticated Users (
AU). - Everyone (
WD).
Такие права позволяют широкому кругу пользователей получать сертификаты, что в сочетании с уязвимыми шаблонами создает поверхность атаки.
Проверка параметра CertificateMappingMethods
Дополнительно проверьте параметр CertificateMappingMethods, отвечающий за способы сопоставления сертификатов с учетными записями в домене. Он находится в реестре по пути HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel.
Значение CertificateMappingMethods по умолчанию — 0x18 (битовая маска 0x10 + 0x08). Это означает, что контроллер домена будет выполнять сопоставление по полям Subject и Issuer. В этом режиме сертификаты без SID, даже если они выданы злоумышленником, не будут ассоциироваться с учетной записью по UPN.
Однако, если установлен флаг 0x01, включается сопоставление по UPN, что делает возможной атаку ESC9: злоумышленник может указать UPN жертвы в SAN и пройти аутентификацию от ее имени.
Проверка SAN‑полей
Также проверьте, какие SAN‑поля обязаны присутствовать в сертификате. Эти требования задаются в параметре msPKI-Certificate-Name-Flag шаблона сертификата. Критичны следующие флаги:
| Название флага | HEX | DEC | Назначение |
|---|---|---|---|
| CT_FLAG_SUBJECT_ALT_REQUIRE_SPN |
0x00800000 |
8388608 |
Требует наличия SPN в SAN |
| CT_FLAG_SUBJECT_ALT_REQUIRE_UPN |
0x02000000 |
33554432 |
Требует наличия UPN в SAN |
| CT_FLAG_SUBJECT_ALT_REQUIRE_DNS |
0x08000000 |
134217728 |
Требует наличия DNS‑имени в SAN |
Если установлен один из этих флагов и одновременно шаблон уязвим (например, разрешает ручное указание Subject или SAN), это делает атаку еще более вероятной, особенно при включенном UPN‑сопоставлении на контроллерах.
Проверка ошибок конфигурации в событии 4898
Добавьте флаг CT_FLAG_NO_SECURITY_EXTENSION в шаблон ADCSESC9:
Подробно весь процесс добавления смотрите в справочных материалах.
После перезапустите центр сертификации и найдите свежие события 4898 с шаблоном ADCSESC9:
В описании события есть вся нужная информация. Но флаг CT_FLAG_NO_SECURITY_EXTENSION здесь учитывается в числовом значении, а точнее в шестнадцатеричной и десятичной системе — учитывайте это для будущих правил:
Тут также можно отследить включенные параметры SPN, UPN и DNS:
Подробный разбор события 4898 — в справочных материалах. Там мы описали, что есть риск не зафиксировать факт добавления уязвимого шаблона: событие можно легко пропустить либо оно вообще не появится, если перезапуск службы CA не был выполнен. Именно поэтому критически важно обеспечить непрерывный мониторинг конфигурации — как в реальном времени, так и с возможностью ретроспективного анализа изменений.
Такой подход реализован в BI.ZONE EDR, где за счет глубокой инвентаризации и анализа данных из реестра и конфигурационных файлов система позволяет выявлять критические мисконфигурации независимо от наличия событий в журналах Windows, обеспечивая полный охват даже тихих изменений.
Традиционные решения полагаются на событие 4898 в журнале безопасности, появляющееся только после обращения к самим шаблонам сертификатов. В отличие от них агент BI.ZONE EDR реализует проактивный подход: он извлекает данные напрямую из реестра и конфигурационных файлов центра сертификации в режиме реального времени. Таким образом, любые потенциально опасные шаблоны (в том числе добавленные до перезапуска службы и уже действующие) обнаруживаются немедленно, а не постфактум.
В BI.ZONE EDR реализован механизм активного мониторинга CT_FLAG_NO_SECURITY_EXTENSION — именно этот флаг делает шаблон потенциально опасным. Агент регулярно проверяет значение атрибута msPKI-Enrollment-Flag для всех шаблонов, расположенных в реестре по пути HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\CertificateTemplateCache\. При обнаружении флага CT_FLAG_NO_SECURITY_EXTENSION информация немедленно собирается для последующего анализа.
Более того, агент ведет непрерывный мониторинг изменений этого атрибута — это позволяет зафиксировать попытки злоумышленников активировать флаг даже в уже существующих шаблонах.
Этот подход обеспечивает максимально актуальную и независимую от событий журналов Windows картину состояния шаблонов. Главное условие — наличие EDR‑агента на ключевых узлах инфраструктуры, особенно на серверах с установленной ролью центра сертификации.
Такая архитектура позволяет выявить уязвимую конфигурацию немедленно, устраняя окно возможностей между моментом внесения изменений и перезагрузкой службы — именно этот промежуток и используют атакующие в реальных сценариях.
Защита от атаки ESC9 сводится к устранению условий, делающих ее возможной, и внедрению надзорных мер.
Проведите инвентаризацию всех шаблонов сертификатов в AD CS и проверьте атрибут msPKI-Enrollment-Flag на наличие флага 0x80000 (CT_FLAG_NO_SECURITY_EXTENSION). Любые обнаруженные шаблоны с этой настройкой стоит пересмотреть. В идеале отключите этот флаг (включите обратно добавление object SID в сертификаты) либо вовсе аннулируйте такой шаблон, если он не критичен. В корпоративной среде редко необходимо выдавать сертификаты без привязки к учетной записи, поэтому наличие такого шаблона — серьезная уязвимость.
Убедитесь, что все контроллеры домена обновлены и настроены на максимально безопасный режим.
В реестре на каждом DC в ветке HKLM\SYSTEM\CurrentControlSet\Services\Kdc задайте StrongCertificateBindingEnforcement = 2 (или установите обновление безопасности KB5014754 от 2022 года). Тогда для Kerberos-аутентификации обязательно будет необходим SID в сертификате.
Аналогично в ветке HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel проверьте CertificateMappingMethods. По умолчанию его значение должно быть 0x18, что не включает флаг UPN. Не выставляйте 0x1F или другие значения, возвращающие слабое сопоставление, если только этого не требуют старые приложения.
Эти настройки предотвратят использование сертификатов без SID для входа в домен (они просто будут отвергнуты).
Примените принцип минимальных привилегий:
- Проверьте ACL шаблонов: кого добавили в Enroll. Исключите из прав шаблонов с клиентской аутентификацией группы типа Domain Users или Authenticated Users, если это не необходимо. Вместо этого делегируйте права узким группам или отдельным сервисным аккаунтам, которые действительно должны получать сертификаты.
- Ограничьте право Enroll на самом CA. В AD каждый Enterprise CA представлен объектом
pKIEnrollmentService. Убедитесь, что в его ACL нет лишних записей. Пользователь с правом Enroll на шаблон все еще не сможет получить сертификат, если у него нет права Enroll на CA (двойной контроль). - Проверьте, что права Manage CA и Manage Certificates на CA не делегированы посторонним. Эти права могли бы позволить злоумышленнику настроить флаги шаблонов или одобрять запросы вручную.
В описанных сценариях злоумышленник часто начинает с получения права GenericWrite на учетную запись. Проведите аудит ACL критичных учетных записей и групп в AD: администраторских, сервисных, имеющих доступ к сертификатам. Убедитесь, что никакие посторонние пользователи и группы не обладают правами изменения (Write/FullControl) на них. Это снизит вероятность, что злоумышленник сможет воспользоваться даже существующим уязвимым шаблоном.
Следите за обновлениями безопасности Microsoft, связанными с AD CS. Хотя ESC9 — это скорее конфигурационная проблема, установка обновления KB5014754 автоматически переведет статус проверки сертификатов на строгое сопоставление.
Введите практику регулярного аудита AD CS:
- Используйте скрипты (например, модуль PowerShell PSPKI) или сторонние утилиты для выгрузки параметров всех шаблонов и CA. Ищите признаки уязвимостей: флаги вроде
EDITF_ATTRIBUTESUBJECTALTNAME2(ESC6) или No Security Extension (ESC9), шаблоны v1 с опасными настройками (ESC15) и т. д. - Следите за членством группы Cert Publishers и защитой ее членов: обычно в нее входят серверы CA.
- Убедитесь, что Root CA (если есть) и подчиненные CA хранят приватные ключи безопасно, чтобы атакующий не мог скомпрометировать всю PKI.
- Включите расширенное логирование, описанное в разделе «Обнаружение атаки», чтобы иметь историю запросов сертификатов и попыток входа по ним.
Если обнаружено, что по какому‑то шаблону были выданы сертификаты злоумышленнику (например, вы нашли в журнале подозрительный выпуск), незамедлительно их отзовите. Добавьте их в CRL на CA, чтобы они больше не принимались для аутентификации. Конечно, при ESC9 атакующий мог уже получить тикет или хеш пароля, но отзыв сертификата предотвратит его дальнейшее использование.
ESC9 показывает, что даже «мелкие» настройки шаблонов в AD CS могут превращаться в критические уязвимости. Если организация не контролирует, какие расширения включены и кто имеет права на выпуск сертификатов, злоумышленник получает возможность выдавать себе чужие учетные данные. Защита требует системного подхода, который включает аудит шаблонов и прав, применение обновлений, строгую привязку сертификатов и мониторинг событий. Иначе PKI становится удобным инструментом для скрытой эскалации прав.