Справочные материалы
В этом разделе мы собрали:
- основные атрибуты шаблонов сертификатов, которые управляют поведением запроса и параметрами выпуска;
- флаги безопасности и поведения CA как на уровне GUI, так и в реестре;
- описание расширений сертификатов (EKU, SAN, Application Policies), влияющих на доверие и аутентификацию;
- специфические OID и EKU, часто встречающиеся в уязвимых шаблонах;
- параметры, которые прямо или косвенно используются в техниках атак ESC1 — ESC16.
Во всех главах исследования, где упоминаются поля Supply in the request, msPKI-RA-Signature, Autoenroll, RequestDisposition и другие, есть ссылки на соответствующие разделы дополнительных материалов. Это поможет глубже разобраться в механике атаки.
Используйте этот раздел как справочник при разборе конкретных техник или проверке на уязвимости существующих шаблонов в инфраструктуре.
Атрибуты шаблонов сертификатов — это параметры, которые хранятся в Active Directory в виде LDAP-атрибутов объектов класса pKICertificateTemplate. Именно они определяют, как работает каждый шаблон: кто может его использовать, какие действия допускаются при запросе, какие EKU добавляются в сертификат и т. д.
Все шаблоны сертификатов хранятся в каталоге конфигурации AD: CN=Certificate Templates, CN=Public Key Services, CN=Services, CN=Configuration, DC=...
Их можно просматривать через:
- оснастку
certtmpl.msc, - ADSI Edit (
adsiedit.msc), - PowerShell:
Get-ADObject -LDAPFilter "(objectClass=pKICertificateTemplate)" -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=..." -Properties *, - сторонние инструменты, например Certipy или PSPKIAudit.
Ниже приводим краткое описание ключевых атрибутов класса pKICertificateTemplate, которые упоминаются в основных материалах исследования и играют важную роль в определении политики выдачи сертификатов и обеспечении безопасности.
| Атрибут | Описание |
|---|---|
| cn (displayName) |
Имя шаблона, которое отображается в пользовательском интерфейсе и используется в утилитах (Certreq, Certipy, Certutil). Это основное идентификационное поле шаблона в Active Directory |
| msPKI-Template-Schema-Version |
Определяет версию схемы шаблона:
|
| msPKI-Certificate-Name-Flag |
Битовая маска, задающая правила формирования поля Subject и расширения SAN в выдаваемом сертификате. Например:
|
| msPKI-Enrollment-Flag |
Битовая маска, определяющая поведение шаблона при регистрации сертификатов. Ключевые флаги включают:
|
| msPKI-RA-Signature |
Указывает, требуется ли подпись агента регистрации. Значение больше 0 означает, что шаблон предназначен для агентских сценариев (например, выдача сертификата по запросу от имени другого пользователя), что используется в атаках типа ESC3. Обычно применяется в сочетании с EKU Certificate Request Agent |
| msPKI-Certificate-Application-Policy |
Содержит список OID, определяющих расширенное назначение (EKU) сертификата. Примеры:
|
| pKIExtendedKeyUsage |
Отражает те же OID, что заданы в msPKI-Certificate-Application-Policy, и отображается в графическом интерфейсе (вкладка Extensions в |
| msPKI-Minimal-Key-Size |
Определяет минимально допустимый размер ключа (в битах), например 2048. Использование ключей меньшего размера (менее 1024 бит) считается небезопасным и снижает криптостойкость сертификата, хотя этот параметр не участвует напрямую в векторах атак ESC |
| msPKI-Cert-Template-OID |
Уникальный идентификатор шаблона (OID), используемый центром сертификации для привязки шаблона к запросам. Этот атрибут полезен для трассировки, аудита и идентификации шаблона в среде CA |
| msDS-OIDToGroupLink |
Связывает шаблон с группой безопасности посредством OID, указанного в Application Policy. Используется для авторизации выдачи сертификатов, где требуется проверка членства пользователя в определенной группе (например, в сценариях, связанных с ESC13) |
| msPKI-Certificate-Policy |
Задает набор OID политик выдачи сертификатов, которые можно использовать для классификации шаблонов. Эти политики помогают ограничивать выдачу сертификатов определенным агентам или категориям, усиливая контроль над процессом выпуска |
| nTSecurityDescriptor |
Дескриптор безопасности (ACL) шаблона, который определяет, кому разрешено выполнять операции с шаблоном (Enroll, Autoenroll, Read, Write и т. д.). Неправильная настройка этого параметра — частая причина уязвимостей, таких как ESC2, ESC5 и ESC7, поскольку позволяет злоумышленникам получить несанкционированный доступ или изменить настройки шаблона |
Эти атрибуты:
- управляют поведением шаблона (например, авторегистрация, требования к имени, допустимые EKU);
- определяют безопасность шаблона: можно ли указать имя вручную, нужен ли агент, какие права доступны;
- участвуют в логике атак ESC, т. к. многие из них напрямую влияют на уязвимость (например, msPKI-Certificate-Name-Flag, msPKI-Enrollment-Flag, msPKI-RA-Signature, flags).
Например:
- если в msPKI-Certificate-Name-Flag выставлен флаг
CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT, то пользователь может сам указать любое имя субъекта — и это ключ к атаке ESC1; - если в msPKI-RA-Signature указано значение >0, то шаблон требует подписи агентом регистрации — и может быть атакован по сценарию ESC3.
В этом разделе подробно рассмотрим ключевые атрибуты объектов шаблонов сертификатов в Active Directory (класс pKICertificateTemplate), от которых напрямую зависят поведение шаблона, политика выдачи и потенциальные уязвимости.
Разберем:
- как работают отдельные флаги и битовые маски (например, в msPKI-Certificate-Name-Flag, msPKI-Enrollment-Flag);
- как интерпретировать их значения и комбинации;
- какие значения считаются безопасными, а какие могут привести к атакам (ESC1 — ESC16);
- где именно эти атрибуты хранятся и как их обнаружить (через ADSI, Certutil, PowerShell);
- как связаны атрибуты с правами доступа и группами (например, через nTSecurityDescriptor, msDS-OIDToGroupLink).
Этот раздел служит техническим справочником, на который мы ссылаемся в других главах нашего исследования при анализе конкретных техник атак. Подробности приведены исключительно для атрибутов, фактически участвующих в эксплуатации уязвимостей AD CS.
Перед тем как описать различные флаги, отдельно отметим, что найти эти атрибуты можно не только в ADSI, но и в реестре. Там они представляют собой отражение того, что хранится в ADSI. Поэтому все, что будет изменено в реестре, не повлияет на их значение, в отличие от того, что изменяется в ADSI. Однако из реестра можно достать полезную информацию о данных атрибутах. В ветке реестра по пути HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\CertificateTemplateCache\ хранится кеш шаблонов сертификатов:
У каждого шаблона сертификата в AD есть свой набор атрибутов, содержащих настройки в виде битовых масок. Такие атрибуты, как msPKI-Enrollment-Flag, msPKI-Certificate-Name-Flag, содержат целочисленные значения, представленные в десятичной или шестнадцатеричной системе. Чтобы понять, какие именно флаги активированы, необходимо уметь интерпретировать эти значения побитово.
- msPKI-Enrollment-Flag = 9 (в десятичной системе);
- это же значение в шестнадцатеричной системе:
0×00000009
Мы хотим понять, включен ли флаг CT_FLAG_PEND_ALL_REQUESTS (этот флаг отвечает за перевод всех запросов в статус Pending, требует ручного одобрения).
Шаг 1: значение флага, который нас интересует. Флаг CT_FLAG_PEND_ALL_REQUESTS имеет значение:
- 0×00000002 в шестнадцатеричной;
- 2 в десятичной.
Шаг 2: побитовая проверка. Чтобы проверить, включен ли нужный флаг, нужно выполнить побитовое И (AND) между текущим значением и значением флага:
9 (значение шаблона): 0b00001001
2 (флаг PEND_ALL_REQUESTS): 0b00000010
--------------------------- AND
0b00000000 → флаг **НЕ установлен**Результат = 0 → флаг не включен.
Шаг 3: пример включенного флага. Если бы msPKI-Enrollment-Flag = 11 (0×0000000B), то бинарное представление:
11 = 0b00001011
AND с 0b00000010 = 0b00000010 → флаг установлен
Результат ≠ 0 → флаг включен.
Как это автоматизировать
$flag = 9
$check = 2
if (($flag -band $check) -ne 0) {
"Флаг CT_FLAG_PEND_ALL_REQUESTS включён"
} else {
"Флаг не включён"
}
Такой способ расшифровки используется для атрибутов:
- msPKI-Enrollment-Flag,
- msPKI-Certificate-Name-Flag,
- flags (в реестре CA),
- других параметров с битовой логикой.
Это базовый навык для аудитора и исследователя инфраструктуры AD CS — без анализа битовых флагов невозможно точно определить, какие функции активны в шаблоне и насколько он уязвим.
Переходим к самим атрибутам. Во многих из них используются одинаковые принципы анализа — значения заданы в виде битовых масок, и проверка нужного флага всегда выполняется через побитовое сравнение (AND) с числовой константой.
Может возникнуть вопрос: зачем мы вообще смотрим значения флагов через ветку реестра, если ту же информацию можно получить и через PowerShell, Certutil или другие средства? Действительно, для разового или ручного анализа — особенно на этапе первичной диагностики — удобнее использовать готовые инструменты, такие как Get-CertificateTemplate, модули PSPKI или ADSI. Это быстрый и простой путь, который легко воспроизвести.
Но если стоит задача масштабной проверки, например при аудите всего леса AD или автоматизации процесса, разумнее копнуть глубже. В таких случаях стоит использовать более низкоуровневые подходы: анализировать содержимое реестра, задействовать групповые политики, обращаться к атрибутам AD напрямую через LDAP. Это позволяет точнее контролировать процесс и легче масштабировать проверку.
Ветка реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\CertificateTemplateCache содержит актуальное состояние шаблонов, с которым реально работает сам CA. Именно сюда подгружается информация из AD, и именно отсюда центр сертификации читает параметры при обработке запроса. Поэтому:
- здесь всегда отражается текущее, применяемое значение, независимо от возможных проблем с репликацией в AD;
- можно отслеживать изменения шаблонов в режиме реального времени;
- можно обнаружить, если кто-то изменил шаблон без публикации новой версии в AD.
Вот почему флаги и параметры мы рассматриваем в том числе через призму реестра — это не просто альтернатива PowerShell, а путь к точной и оперативной информации, особенно при аудите или мониторинге потенциальных атак.
Принадлежит параметру msPKI-Enrollment-Flag (битовая маска). Этот флаг указывает центру сертификации (CA) не включать в сертификат расширение безопасности szOID_NTDS_CA_SECURITY_EXT с OID 1.3.6.1.4.1.311.25.2.
Значение флага: 0×00080000.
В итоге, если включить флаг NO_SECURITY_EXTENSION, отключается другой флаг — szOID_NTDS_CA_SECURITY_EXT.
По умолчанию CA встраивает в сертификат SID объекта (пользователя или компьютера), от имени которого запрашивается сертификат. Это расширение — основа строгого сопоставления сертификата с объектом AD при проверке подлинности (PKINIT, смарт-карта и пр.).
При активном CT_FLAG_NO_SECURITY_EXTENSION (отключенном szOID_NTDS_CA_SECURITY_EXT) CA не добавляет SID в сертификат. В результате:
- контроллер домена не может однозначно связать сертификат с объектом AD;
- проверка аутентичности будет основана на слабых признаках:
Это создает возможность захватить чужую учетную запись даже без компрометации ее SID — только через получение сертификата с совпадающим UPN или DNS.
Данный флаг активно эксплуатируется в техниках:
- ESC9 — слабое сопоставление при входе по сертификату;
- ESC14 — обход SID-связывания через altSecurityIdentities.
Проверить, включен ли флаг CT_FLAG_NO_SECURITY_EXTENSION, можно через ветку реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\CertificateTemplateCache<Имя шаблона>.
Нас интересует параметр msPKI-Enrollment-Flag — его значение необходимо проверить побитово и сравнить с маской 0×00080000. Если результат побитового AND с этим флагом не равен нулю, значит, флаг включен. Подробный алгоритм сравнения уже был рассмотрен ранее.
Однако, если вы захотите изменить значение msPKI-Enrollment-Flag, правкой в реестре это сделать не получится. Ветка HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\CertificateTemplateCache\<Имя шаблона> содержит только кешированные данные, которые CA подгружает из Active Directory. Это «снимок» состояния шаблонов, а не место хранения оригинала.
Чтобы действительно изменить флаг, нужно перейти в ADSI Edit: adsiedit.msc → Configuration → Services → Public Key Services → Certificate Templates. Там надо найти нужный шаблон, открыть его свойства и изменить значение атрибута msPKI-Enrollment-Flag:
После этого:
- изменения будут применены на всех CA после репликации;
- шаблон будет пересчитан в TemplateCache реестра;
- CA начнет использовать обновленную конфигурацию при следующем запросе.
Давайте рассмотрим только следующие параметры:
CT_FLAG_SKIP_AUTO_RENEWAL: автоматический запуск (0×00040000);CT_FLAG_ISSUANCE_POLICIES_FROM_REQUEST: запрос на выдачу (0×00020000);CT_FLAG_USER_INTERACTION_REQUIRED: требуется взаимодействие с пользователем (0×00000100).
Более подробную информацию о данных ключах ищите в документации Microsoft.
В результате мы получим значение 0×00060100, которое при преобразовании в десятичное число становится равным 393472:
После этого устанавливаем нужное число для этого атрибута, сохраняем изменения и перезапускаем центр сертификации, выполнив следующие команды:
net stop certsvc
net start certsvc
Затем нужно перейти в ветку реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\CertificateTemplateCache\ESC9-A(Пример) и найти параметр msPKI-Enrollment-Flag. Мы увидим обновленную информацию. Если окно реестра было открыто, то для обновления реестра необходимо нажать клавишу F5:
Затем мы можем сравнить значение 393472 с 524288 (значение флага CT_FLAG_NO_SECURITY_EXTENSION в шестнадцатеричной системе счисления, которое равно 0×00080000). В результате удостоверимся, что флаг снят:
00011000000000000000 (393472)
AND
00100000000000000000 (524288)
00000000000000000000 (результат: 0)
Выполнение команды .\Certify.exe find /vulnerable /ca:"good-DC-1\CA-1" подтверждает отсутствие этого флага:
Проверить состояние шаблона сертификатов можно также через certutil -dump <путь_к_сертификату>.
Таким образом, есть разные методы для проверки этого флага. Выберите тот, который больше всего подходит для ваших задач.
Ниже описаны две наиболее важные ветки реестра в контексте AD CS, которые обычно проверяют при аудите и отладке: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\CertificateTemplateCache и HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CertSvc\Configuration<Имя_CA>\PolicyModules. Здесь сосредоточены основные механизмы работы центра сертификации и хранения данных о шаблонах.
Хотя в реестре есть и другие разделы, связанные с AD CS, именно эти ветки обычно несут основную «операционную» нагрузку. Здесь отражаются:
- шаблоны, которые CA реально видит и готов выдавать (CertificateTemplateCache);
- настройки, определяющие политику выдачи (PolicyModules).
Регулярный аудит этих веток помогает вовремя выявлять компрометацию, некорректную конфигурацию или злонамеренные изменения, ведущие к уязвимостям ESC.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\CertificateTemplateCacheЧто это такое
Кеш шаблонов сертификатов, которые использует центр сертификации (CA). Для каждого опубликованного в AD шаблона здесь хранится полный набор его атрибутов и текущих значений (msPKI-*):
Особенности
- CA подтягивает информацию из Active Directory и сохраняет ее именно в этом разделе.
- Любое изменение шаблона (по линии AD) после репликации окажется здесь, и CA будет использовать актуальные данные без дополнительных перезапусков (хотя иногда все же нужен
certsrv restart). - Отсюда удобно мониторить появление новых шаблонов, изменения их флагов, а также любые несанкционированные модификации.
Практический смысл
Этот раздел можно считать «оперативной базой» для CA. Если шаблон не отображается в CertificateTemplateCache, значит, CA еще не применяет его. И наоборот, если шаблон там есть, CA готов его выдавать, даже если событие 4898 еще не сработало.
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CertSvc\Configuration<Имя_CA>\PolicyModulesЧто это такое
Настройки самого центра сертификации, в том числе связанные с модулями политики (PolicyModules). К примеру, Windows Default Policy Module может быть настроен на автоматическую выдачу сертификатов или отправку всех запросов в статус Pending:
Особенности
- Здесь определяются правила обработки запросов (PolicyModules).
- В некоторых случаях можно найти флаги, которые влияют на включение SAN из запроса (например,
EDITF_ATTRIBUTESUBJECTALTNAME2), и другие важные параметры, которые могут приводить к атакам ESC6, ESC7. - Именно в этой ветке видна вся глубинная логика, по которой CA принимает решение о выдаче или ожидании (Pending).
Практический смысл
- Контролируя этот раздел, можно оперативно выявлять, не включил ли кто-то опасные флаги, например автоматическую выдачу для критичных шаблонов.
- Если здесь обнаруживаются какие-либо модули, кроме
CertificateAuthority_MicrosoftDefault.Policy, стоит проверить их легитимность.
Рассмотрим ключевые аспекты работы с шаблонами сертификатов в AD CS: их назначение, разновидности, принципы настройки и управления.
Роль шаблонов в AD CS
В AD CS шаблоны сертификатов играют ключевую роль в автоматизации и стандартизации процесса выдачи сертификатов. Они представляют собой преднастроенные конфигурации, которые определяют, какие сертификаты могут быть выданы, кому, с какими правами и на каких условиях.
Без шаблонов каждый запрос на сертификат пришлось бы настраивать вручную, что увеличивает вероятность ошибок, усложняет администрирование и снижает уровень безопасности.
Как шаблоны упрощают выдачу сертификатов
- Автоматизация процесса. Шаблоны позволяют администраторам один раз задать все параметры, а затем пользователи или службы смогут запрашивать сертификаты без необходимости каждый раз указывать детали вручную.
- Гибкость и масштабируемость. С помощью шаблонов можно настроить автоматическое обновление сертификатов, автовыдачу (Auto-Enrollment) и различные политики безопасности.
- Контроль доступа и безопасности. Шаблоны используют разрешения (ACL), чтобы ограничивать, какие пользователи или группы могут запрашивать сертификаты. Например, можно настроить, чтобы только администраторы могли получать определенные типы сертификатов, а обычные пользователи — только сертификаты для шифрования почты.
Определение функциональности сертификатов
Шаблоны задают следующие важные параметры:
- Кто получит сертификат (пользователь, компьютер, служба).
- Можно ли экспортировать закрытый ключ (если разрешено, это может стать уязвимостью).
- Как долго сертификат будет действителен (например, 1 год или 10 лет).
- Для чего используется сертификат (аутентификация, подпись, шифрование и т. д.).
Где хранятся шаблоны и кто их контролирует
Все шаблоны хранятся в Active Directory — в разделе CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=yourdomain,DC=com. Администраторы могут управлять шаблонами через консоль управления шаблонами (certtmpl.msc), редактор Active Directory (adsiedit.msc) или командную строку (Certutil).
При этом:
- Enterprise Admins и CA Admins могут создавать, изменять и удалять шаблоны.
- Domain Admins могут управлять некоторыми настройками безопасности шаблонов.
- Пользователи могут только запрашивать сертификаты, если у них есть разрешение Enroll или Autoenroll на конкретный шаблон.
В AD CS шаблоны сертификатов играют ключевую роль, определяя правила их выдачи, использования и безопасности. Все шаблоны можно разделить на два типа: стандартные (встроенные в систему) и кастомные (созданные администраторами на основе дубликатов стандартных).
Стандартные шаблоны (User, WebServer, DomainController и др.)
Это предустановленные конфигурации, которые включены в Windows Server и предназначены для наиболее распространенных случаев использования. Такие шаблоны нельзя редактировать напрямую, но их можно дублировать и изменять копию.
Примеры стандартных шаблонов:
| Шаблон | Описание |
|---|---|
| User |
Аутентификация пользователей, шифрования данных и подписей |
| WebServer |
Защита веб-сайтов с помощью TLS/SSL |
| DomainController |
Сертификаты для контроллеров домена, поддерживающие Kerberos |
| Computer |
Аутентификация рабочих станций и серверов в домене |
| SmartcardLogon |
Вход с использованием смарт-карт |
Чтобы получить список стандартных шаблонов, выполните команду в PowerShell: certutil -template. Она покажет все доступные шаблоны на сервере.
Вот полный список стандартных шаблонов Windows Server:
| Шаблон | Назначение |
|---|---|
| User |
Сертификаты для пользователей (аутентификация, подпись, шифрование) |
| WebServer |
Сертификаты для веб-серверов (TLS/SSL) |
| DomainController |
Сертификаты для контроллеров домена |
| Computer |
Сертификаты для рабочих станций и серверов |
| SmartcardLogon |
Вход в систему с использованием смарт-карты |
| EFSRecovery |
Восстановление данных, зашифрованных EFS |
| CodeSigning |
Подпись кода и программ |
| EnrollmentAgent |
Регистрация от имени других пользователей |
| ExchangeUser |
Поддержка подписей в Microsoft Exchange |
| IPSecIntermediate |
Сертификаты для IPSec VPN |
| OCSPResponseSigning |
Подпись OCSP-ответов (Online Certificate Status Protocol) |
| RASandIASServer |
Сертификаты для RADIUS-серверов |
| SmartcardUser |
Сертификаты для аутентификации пользователей со смарт-картами |
| WorkstationAuthentication |
Аутентификация рабочих станций |
Проверка шаблонов также возможна через certtmpl.msc (GUI-способ). Нажмите Win + R, введите certtmpl.msc и нажмите Enter. В списке появятся все доступные шаблоны, где также будут видны версии шаблонов.
Стандартные шаблоны нельзя редактировать, можно лишь изменить права выдачи пользователям в разделе Security, так как все стандартные шаблоны — это шаблоны версии 1:
Хотя в certtmpl.msc стандартные шаблоны заблокированы, можно менять их атрибуты напрямую в Active Directory:
- Win + R →
adsiedit.msc→ Enter. - Подключитесь к Configuration Naming Context.
- Перейдите к
CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=GOOD,DC=EXPERT. - Выберите шаблон, например
CN=User. - Откройте свойства и отредактируйте параметры (msPKI-*):
- Перезапустите службу сертификатов:
net stop certsvc && net start certsvc.
Дубликаты (Duplicate Templates): зачем их создают
Официально в AD CS стандартные шаблоны версии 1 (SchemaVersion = 1) нельзя редактировать. Чтобы изменить настройки, администраторы используют дубликаты (Duplicate Templates). Дубликат — это копия стандартного шаблона, которую можно модифицировать. После создания дубликат получает новую версию (SchemaVersion = 2, 3, 4), что дает дополнительные возможности.
Дубликаты шаблонов создают, чтобы изменить параметры, заблокированные в стандартных шаблонах. Стандартные шаблоны не позволяют редактировать такие параметры, как:
- разрешение экспорта закрытого ключа,
- включение архивирования ключей (Key Archival),
- изменение типов использования (Application Policies, EKU),
- увеличение срока действия сертификатов.
Например, стандартный шаблон User не позволяет экспортировать закрытый ключ. Но, если создать дубликат User-Exportable, можно включить опцию Allow private key to be exported.
Шаблоны разных версий: как изменялись с Windows 2000 до Windows Server 2022
У каждого шаблона сертификатов есть версия схемы (SchemaVersion), которая определяет доступные функции и настройки безопасности. Более новые версии позволяют использовать автоназначение сертификатов, ключевое архивирование и дополнительные политики безопасности.
Вот как шла эволюция шаблонов в разных версиях Windows Server:
| Версия | ОС | Функции | Примеры стандартных шаблонов |
|---|---|---|---|
| 1 |
Windows 2000, Windows Server 2003 |
|
User, WebServer, DomainController, Computer, EFSRecovery, SmartcardLogon |
| 2 |
Windows Server 2003 |
|
EnrollmentAgent, SmartcardUser, IPSecIntermediate |
| 3 |
Windows Server 2008 |
|
ExchangeUser, OCSPResponseSigning, RASandIASServer |
| 4 |
Windows Server 2012+ |
|
KerberosAuthentication, NPSRadiusServer, SubCA |
Чтобы определить версию шаблона, выполните следующую команду: certutil -v -template | findstr /i "SchemaVersion TemplatePropCommonName".
Пример вывода:
TemplatePropCommonName = User
TemplatePropSchemaVersion = 1
TemplatePropCommonName = WebServer
TemplatePropSchemaVersion = 1
TemplatePropCommonName = DomainController
TemplatePropSchemaVersion = 1
Идентификация (Subject Name, UPN, SAN и другие параметры)
Идентификация (Subject Name) в сертификате — это один из ключевых параметров, который определяет, кто является владельцем сертификата. В шаблонах AD CS можно настроить, как формируется Subject Name и можно ли его изменять при запросе сертификата:
Основные параметры в шаблоне:
- Supply in the request (указывается при запросе). Позволяет пользователю или процессу самостоятельно указывать Subject Name при запросе сертификата. Может использоваться для настройки сертификатов, где нельзя заранее предугадать CN, например в корпоративных VPN-системах.
- Build from this Active Directory information (формирование из AD). Автоматически формирует CN на основе данных объекта в Active Directory. Обеспечивает соответствие сертификатов реальным пользователям или устройствам в домене.
- Дополнительные параметры Subject Alternative Name (SAN). Эти параметры определяют, какие дополнительные идентификаторы могут быть включены в сертификат:
Вот на что они влияют:
- Include e-mail name in subject name (добавить адрес в Subject Name). Если включено, добавляет почтовый адрес пользователя в CN (если он указан в AD). Используется для сертификатов электронной подписи и шифрования почты (S/MIME).
- E-mail name (добавить адрес почты в SAN). Добавляет адрес почты пользователя в Subject Alternative Name (SAN). Используется в S/MIME, EFS, шифровании почты.
- DNS name (добавить DNS-имя в SAN). Добавляет DNS-имя сервера или устройства в SAN. Используется в SSL/TLS-сертификатах (WebServer, RAS, NPS).
- User principal name (UPN) (добавление UPN в SAN). Добавляет логин пользователя в формате username@domain[.]com. Используется для PKINIT (аутентификация по сертификату в AD), Kerberos, смарт-карт.
- Service principal name (SPN) (добавление SPN в SAN). Добавляет SPN — идентификатор службы в AD. Используется в Kerberos для сервисных аккаунтов (например,
MSSQLSvc/server.example[.]com).
В таблице ниже собрали информацию об основных параметрах:
| Параметр | За что отвечает | Для чего рекомендуется | Риски при включении/отключении |
|---|---|---|---|
| Supply in the request |
Позволяет указывать CN вручную |
VPN, сервисные сертификаты |
Может быть использован для подделки CN (ESC1) |
| Build from AD |
Автоматически формирует CN из AD |
Обычные пользователи, серверы |
Нельзя задать CN вручную |
| E-mail name in subject |
Включает почтовый адрес в CN |
S/MIME, цифровая подпись |
Если адреса нет в AD, может не сработать |
| E-mail name in SAN |
Добавляет почтовый адрес в SAN |
Почтовые сертификаты |
Безопасно |
| DNS name in SAN |
Добавляет DNS-имя сервера |
Серверные сертификаты |
Безопасно |
| UPN in SAN |
Привязывает сертификат к учетной записи AD |
PKINIT, смарт-карты, Kerberos |
Если отключено, сертификат можно использовать без проверки в AD |
| SPN in SAN |
Привязывает сертификат к сервисному аккаунту |
SQL, IIS, RDP |
Может не сработать, если SPN не указан в AD |
В контексте управления сертификатами и инфраструктуры PKI (Public Key Infrastructure) безопасность и доступ к ключам и сертификатам регулируются механизмами ACL (Access Control List), Enrollment и Autoenroll.
ACL
В PKI ACL применяется:
- в шаблонах сертификатов (Certificate Templates в Active Directory).
- сертификатных службах (CA) (разрешения на выдачу и управление сертификатами).
- реестре Windows (управление доступом к хранилищам ключей).
- файловой системе (управление доступом к хранилищу сертификатов и ключей).
Пример ACL в шаблоне сертификата в Windows
Запустите certtmpl.msc, выберите шаблон, откройте вкладку Security и настройте разрешения:
- Domain Users → Read.
- Domain Admins → Full Control.
- Authenticated Users → Read, Autoenroll (если требуется автоматическая выдача сертификатов).
На скриншоте пример настройки разрешений для пользователя hacker:
Основные права ACL в PKI
- Read — просмотр настроек шаблона.
- Enroll — возможность запрашивать сертификат.
- Autoenroll — автоматическая выдача сертификата.
- Full Control — полный доступ к объекту (изменение, удаление).
- Manage CA — администрирование центра сертификации.
- Issue and Manage Certificates — разрешение на выдачу и управление сертификатами.
Можно проверять права шаблонов разными способами, но один из самых интересных — просмотр событий Windows после перезагрузки CA. При этом в журнале событий Windows появляется событие 4898, связанное с обновлением базы сертификатов CA.
Во время этого процесса центр сертификации загружает актуальную информацию о каждом шаблоне и фиксирует ее в событиях Windows. Это позволяет получить полные данные обо всех шаблонах, включая их настройки и права доступа.
Например, данные об ACL в SDDL:
Security Descriptor: O:S-1-5-21-3912521324-1417072855-2443496624-519G:S-1-5-21-3912521324-1417072855-2443496624-519D:PAI(OA;;RPCR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;S-1-5-21-3912521324-1417072855-2443496624-498)(OA;;RPCR;a05b8cc2-17bc-4802-a710-e7c15ab866a2;;S-1-5-21-3912521324-1417072855-2443496624-498)(OA;;RPWPCR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;DA)(OA;;RPWPCR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;DD)(OA;;RPWPCR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;S-1-5-21-3912521324-1417072855-2443496624-519)(OA;;RPWPCR;a05b8cc2-17bc-4802-a710-e7c15ab866a2;;DD)(OA;;RPWPCR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;ED)(OA;;RPWPCR;a05b8cc2-17bc-4802-a710-e7c15ab866a2;;ED)(A;;CCDCLCSWRPWPDTLOSDRCWDWO;;;DA)(A;;CCDCLCSWRPWPDTLOSDRCWDWO;;;S-1-5-21-3912521324-1417072855-2443496624-519)(A;;LCRPLORC;;;AU)
Allow GOOD\Enterprise Read-only Domain Controllers
Enroll
Allow GOOD\Enterprise Read-only Domain Controllers
Auto-Enroll
Allow GOOD\Domain Admins
Enroll
Allow GOOD\Domain Controllers
Enroll
Allow GOOD\Enterprise Admins
Enroll
Allow GOOD\Domain Controllers
Auto-Enroll
Allow NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS
Enroll
Allow NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS
Auto-Enroll
Allow(0x000f00ff) GOOD\Domain Admins
Full Control
Allow(0x000f00ff) GOOD\Enterprise Admins
Full Control
Allow(0x00020094) NT AUTHORITY\Authenticated Users
Read
Общий разбор структуры
- O:S-1-5-21-...-519 → владелец объекта (Enterprise Admins / Domain Admins).
- G:S-1-5-21-...-519 → группа владельца (Enterprise Admins / Domain Admins).
- D:PAI → DACL (список разрешений), объект защищен.
| Элемент | Значение | Расшифровка |
|---|---|---|
| O: |
S-1-5-21-…-519 |
Владелец объекта — Enterprise Admins |
| G: |
S-1-5-21-…-519 |
Основная группа — та же группа |
| D:PAI |
DACL |
Список разрешений, объект защищен от унаследованных ACL |
Разбор разрешений (DACL)
Эти записи представляют собой доступ по расширенным правам (Object Access), где указано, кто может выполнять действия, связанные с управлением шаблоном, в частности Enroll и Autoenroll.
| Компонент SDDL | Расшифровка |
|---|---|
| (OA;;RPCR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;S-1-5-21-…-498) |
Разрешение на Enroll (запрос сертификата) для группы GPCO |
| (OA;;RPCR;a05b8cc2-17bc-4802-a710-e7c15ab866a2;;S-1-5-21-…-498) |
Разрешение на Autoenroll (автоматическую выдачу) для группы GPCO |
| Поле | Значение |
|---|---|
| OA |
Object Access (расширенный тип доступа) |
| RPCR |
ReadProperty + ControlAccess Rights — чтение свойств и применение GUID |
| GUID (Enroll) |
0e10c968-78fb-11d2-90d4-00c04f79dc55 → право на Enroll |
| GUID (Autoenroll) |
a05b8cc2-17bc-4802-a710-e7c15ab866a2 → право на Autoenroll |
| SID |
S-1-5-21-...-498 → группа Group Policy Creator Owners (GPCO) |
ACL: что стоит подчеркнуть
- Domain Admins / Enterprise Admins — полный контроль и возможность запрашивать и автоматически получать сертификаты.
- Authenticated Users — только Read, не могут инициировать выпуск сертификатов.
- Чтобы разрешить Enroll для группы, добавьте ACE с GUID
0e10c968-78fb-11d2-90d4-00c04f79dc55(Enroll). - Чтобы разрешить Autoenroll, используйте GUID
a05b8cc2-17bc-4802-a710-e7c15ab866a2(Autoenroll).
(OA;;RPWPCR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;DA)
(OA;;RPWPCR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;DD)
(OA;;RPWPCR;a05b8cc2-17bc-4802-a710-e7c15ab866a2;;DD)
(OA;;RPWPCR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;ED)
(OA;;RPWPCR;a05b8cc2-17bc-4802-a710-e7c15ab866a2;;ED)
DA — Domain Admins, DD — Domain Controllers, ED — Enterprise Admins.
RPWPCR → Чтение (RP), запись (WP), управление (CR)
Могут управлять сертификатами, а параметры 0e10c968-78fb-11d2-90d4-00c04f79dc55 и a05b8cc2-17bc-4802-a710-e7c15ab866a2 говорят нам о том, что также могут запрашивать сертификаты.
Enrollment (запрос сертификатов)
Enrollment — это процесс запроса, выдачи и установки сертификатов пользователями или устройствами. У него есть два типа:
- Ручной (Manual Enrollment). Пользователь вручную запрашивает сертификат через
certmgr.mscили веб-интерфейс CA. Администратор вручную одобряет (если требуется) и выдает сертификат. - Автоматический (Auto-Enrollment). Сертификаты выдаются автоматически без взаимодействия с пользователем. Используется в корпоративных средах с AD + GPO.
Вот как происходит процесс Enrollment через Windows CA:
- Пользователь отправляет запрос (CSR) на сертификат.
- CA проверяет права пользователя (ACL, Enrollment):
- CA подписывает и выдает сертификат (если одобрено).
- Сертификат устанавливается в хранилище пользователя или устройства.
Настройка Certificate Enrollment Policy через GPO
Эта политика определяет, откуда клиент получает политику регистрации сертификатов, например из Active Directory или через URL. Она обязательно должна быть включена, если вы хотите использовать Autoenroll или централизованную регистрацию сертификатов в домене.
Вот как включить Certificate Enrollment Policy:
- Откройте редактор групповых политик
gpedit.msc(или Group Policy Management Console — GPMC, если это доменная политика). - Перейдите в Computer Configuration → Windows Settings → Security Settings → Public Key Policies → Certificate Services Client — Certificate Enrollment Policy.
- Дважды кликните по политике, чтобы открыть свойства.
- Убедитесь, что
-Configuration Model = Enabled, в списке политик есть строкиName: Active Directory Enrollment Policy,Automatic Enrollment: Enabledи установлен флагDefault. - При необходимости добавьте другую политику через кнопку Add..., но для стандартной работы в AD-домене достаточно встроенной AD Enrollment Policy.
- Убедитесь, что не установлен флаг Disable user configured enrollment policy servers, если не хотите ограничивать возможность ручной настройки на клиенте.
- Нажмите OK или Apply, чтобы сохранить изменения.
Способ включения Certificate Enrollment Policy также показан на скриншоте:
Эта политика сама по себе не инициирует выдачу сертификатов, но она:
- определяет, откуда клиент узнает о шаблонах сертификатов;
- необходима для корректной работы Auto-Enrollment;
- может использоваться совместно с веб-службами сертификатов, если вы добавляете внешние политики регистрации.
Также не забудьте включить и Auto-Enrollment, если нужна автоматическая выдача.
Autoenroll (автоматическая выдача сертификатов)
Autoenroll — это механизм автоматической регистрации и обновления сертификатов в Active Directory.
Настройка Autoenroll через GPO
- Откройте
gpedit.msc. - Перейдите в Computer Configuration → Windows Settings → Security Settings → Public Key Policies.
- Выберите Certificate Services Client → Auto-Enrollment.
- Включите Enable Automatic Enrollment of Certificates.
- Выберите:
- Renew expired certificates, update pending certificates, and remove revoked certificates
- Update certificates that use certificate templates
- Примените GPO к нужным группам пользователей/устройств.
Требования для Autoenroll
- Включена групповая политика Auto-Enrollment:
- В шаблоне сертификата установлены права Read, Enroll, Autoenroll:
- CA настроен на автоматическую выдачу (не требует ручного одобрения):
- Follow the settings in the certificate template (следовать настройкам шаблона) → сертификаты выдаются автоматически, если шаблон это поддерживает.
Как работает Autoenroll
- Групповая политика (GPO) включает поддержку Auto-Enrollment.
- Компьютер или пользователь при входе в систему автоматически отправляет запрос на сертификат.
- CA проверяет права и, если разрешено, автоматически выдает и устанавливает сертификат.
Выводы
Контроль выпуска сертификатов подразумевает 4 уровня проверки. Чтобы сертификат был успешно выдан, должны одновременно сработать все 4 уровня контроля:
- Шаблон сертификата (Certificate Template).
- У пользователя или устройства должны быть права Enroll.
- Настроены параметры: Subject Name, EKU, RA Signature и др.
- Групповая политика (GPO).
- Включает поддержку автоматической регистрации.
- Применена к нужным пользователям/компьютерам.
- Задано: Autoenroll, Update certificates that use certificate templates.
- Центр сертификации (CA).
- CA должен быть опубликован в AD и доступен для запроса.
- Шаблон должен быть добавлен на сервер CA и находиться в рабочем состоянии.
- Проверяются флаги, права и подписи.
- Механизм подтверждения (Approval Logic).
- Включен флаг Pend all requests → требуется ручное подтверждение.
- Настроен msPKI-RA-Signature → нужна подпись агента.
- Включена опция Authorized Signatures → требуется несколько подписей.
Чтобы получить возможность выпускать сертификаты, недостаточно иметь права Enroll/Autoenroll в шаблоне. Необходимо также, чтобы политики групп (GPO) и настройки центра сертификации (CA) разрешали их выдачу, а в некоторых случаях — чтобы запрос был подтвержден ответственными лицами.
Это событие — один из ключевых индикаторов при выявлении уязвимых шаблонов сертификатов. Важно не просто знать, что представляет собой это событие, а понимать его особенности и структуру, чтобы при создании правил корреляции и настройке систем обнаружения учитывать все технические нюансы и контекст. Мы не просто формально описали событие, а раскрыли логику его генерации, порядок появления и то, какие поля несут наибольшую ценность для аналитика кибербезопасности и систем мониторинга.
Windows Event ID 4898 («Служба сертификации загрузила шаблон сертификата») фиксируется в журнале безопасности Windows, когда CA загружает в память шаблон сертификата. По умолчанию такое событие возникает редко — обычно только в момент первого обращения к конкретному шаблону после запуска или перезапуска службы CA либо после внесения изменений в настройки шаблона.
Для более эффективного и оперативного мониторинга рекомендуется включить специальный параметр аудита — флаг EDITF_AUDITCERTTEMPLATELOAD. Этот параметр заставляет службу сертификации регистрировать событие 4898 значительно чаще, а именно — при каждом перезапуске службы CA для всех имеющихся шаблонов, независимо от их изменений или фактического использования. Благодаря этому аналитики получают более своевременный доступ к информации о потенциально уязвимых шаблонах сертификатов, что особенно критично в рамках реагирования на угрозы безопасности.
На скриншоте ниже представлено событие 4898:
Оно регистрируется в журнале безопасности Windows (Security Log) только при условии, что заранее включен соответствующий аудит.
Как включить аудит события 4898
- Открыть редактор локальной групповой политики командой —
gpedit.msc. - Перейти по следующему пути: Конфигурация компьютера → Конфигурация Windows → Параметры безопасности → Локальные политики → Политика аудита (или в расширенные настройки аудита, в зависимости от версии ОС).
- Если используется расширенный аудит (это рекомендуется), пройти по следующему пути: Security Settings → Advanced Audit Policy Configuration → System Audit Policies → Certification Services → Certification Services.
- Включить опцию Audit Certification Services → Success.
- Перезапустить службу сертификатов:
net stop certsvc && net start certsvc.
Когда появляется событие 4898 и почему важно это учитывать
Техническая особенность события 4898 — в том, что оно появляется не сразу после публикации шаблона, а в момент его использования. Типичные случаи регистрации события:
- перезапуск службы сертификации, когда заново загружаются база данных и кеш шаблонов;
- запрос сертификата пользователем или системой по данному шаблону (даже если шаблон ранее уже был опубликован, но еще не использовался).
Такая логика несет риски: шаблон с опасными настройками может быть опубликован и оставаться неиспользованным длительное время, из-за чего событие 4898 не появляется своевременно. В худшем случае аналитик увидит событие уже после того, как злоумышленник воспользовался уязвимым шаблоном.
Однако важно отметить, что событие 4898 появляется не просто при публикации шаблона. Оно генерируется в случаях, когда CA действительно обращается к шаблону, например:
- при перезапуске CA, когда происходят обновление базы данных и кеширование шаблонов;
- когда запрашивается сертификат по данному шаблону (даже если шаблон опубликован, но сам CA не был перезапущен).
Это создает опасный прецедент: шаблон с уязвимыми настройками может быть опубликован, но событие 4898 не появится до тех пор, пока CA не выполнит обращение к нему. В некоторых случаях такое событие может появиться, когда атакующий уже запросил уязвимый сертификат. В таких сценариях команда реагирования будет отставать от атакующего.
На практике событие 4898 обычно появляется не чаще раза в сутки, в зависимости от частоты обращения к шаблонам. Поэтому необходимо контролировать и другие источники, например реестр.
Событие 4898 фиксирует только момент обращения к шаблону, а само наличие опубликованного шаблона можно отследить через кеш шаблонов в реестре (ветка HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\CertificateTemplateCache).
Таким образом, для полноценного мониторинга уязвимых шаблонов необходимо использовать не только события аудита, но и данные из реестра. Это позволит оперативно получать актуальную информацию о состоянии опубликованных шаблонов.
Какую информацию можно получить из события 4898
В этом событии есть вся необходимая информация о шаблонах: атрибуты, флаги, дескрипторы безопасности и пр. На скриншоте ниже показан пример события 4898 (Windows Security Auditing):
Из его содержимого можно достать:
- Основные сведения о шаблоне: его версия (SchemaVersion), имя (Common Name), назначение (Intended Purpose), срок действия (Validity) и т. д.
- Ключевые флаги: msPKI-Certificate-Name-Flag, msPKI-Enrollment-Flag, msPKI-PrivateKeyFlag и др. Здесь же отражены их шестнадцатеричные значения, позволяющие судить о том, включено ли, к примеру, право экспортирования закрытого ключа или опция Supply in the request.
- Расширения и EKU: pKICriticalExtensions, Key Usage, Subject Alternative Name — все, что влияет на возможности сертификата и вектор атаки.
- Права доступа и SID групп (Security Descriptors): полные сведения о том, у кого есть право на выпуск сертификата (Enroll), максимальный уровень разрешений (Full Control) и какие группы добавлены в ACL. Для атак ESC, связанных с неверной настройкой прав, это особенно важно.
- Другие параметры: срок действия сертификата, имя сервера CA, учетная запись, от имени которой центр сертификации получил доступ к шаблону и начал его использовать (например, GOOD\hacker — если вдруг это делал злоумышленник). В событии также фиксируется точное время обращения CA к шаблону, что помогает в расследованиях и отслеживании потенциально вредоносной активности.
Проще говоря, событие 4898 содержит полноценный «снимок» всех критичных параметров шаблона, который CA загрузил в данный момент. Это делает 4898 одним из самых информативных событий для аудита и поиска уязвимых шаблонов. Вы можете выявить, к примеру, что msPKI-Certificate-Name-Flag указывает на разрешенный Supply in the request (ESC1) или что msPKI-PrivateKeyFlag разрешает экспорт закрытого ключа (ESC2), а также увидеть, не выданы ли широкие права Enroll всем пользователям домена. Именно поэтому рекомендуется регулярно анализировать событие 4898 в дополнение к проверкам кеша шаблонов в реестре.
Также важно учитывать дополнительное событие 4899 (A Certificate Services template was updated). Оно появляется в случаях, когда параметры шаблона, хранящиеся в кеше CA, отличаются от параметров, указанных в запросе сертификата. Это событие помогает своевременно выявлять изменения конфигурации уже используемых шаблонов, что также полезно для оперативного мониторинга.
Официальная документация и отчеты Microsoft
- KB5014754: Certificate-based authentication changes on Windows domain controllers
- [MS-PKCA]: Public Key Cryptography for Initial Authentication (PKINIT) in Kerberos Protocol
- KB5005413: Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS)
- 3.1.4.9 Document Printing Methods // [MS-RPRN]: Print System Remote Protocol
- Security and Identity // Autorization
Исследования и отчеты компаний
- Certified Pre-Owned // SpecterOps
- ADCS Attack Paths in BloodHound — Part 1 // SpecterOps Blog
- EKUwu: Not just another AD CS ESC // TrustedSec Blog
- Investigating Active Directory Certificate Services Abuse: ESC1 // CrowdStrike
- Хеирхабаров Т., Соколин Д. Hunting for Active Directory Certificate Services Abuse
- SDDL Demystified Mind Map // Splunk
Инструменты и утилиты
- Certipy — AD CS Exploitation Toolkit
- Certify — AD CS Abuse Tool by GhostPack
- Rubeus — Kerberos Abuse Toolkit
- PowerView — PowerShell Reconnaissance Toolkit
- PSPKIAudit — PowerShell PKI Audit Tool
- PetitPotam — NTLM Relay Attack Toolkit
- Impacket — Network Protocol Attack Toolkit
- DFSCoerce — Coerce NTLM Authentication via DFS
- ntlmrelayx.py — NTLM Relay Tool (Impacket)
Авторитетные блоги и статьи
- Active Directory Certificate Services (ADCS) Exploitation Techniques: In-Depth Offensive and Defensive Guide // Medium / Esra Kayhan
- Admin’s Nightmare: Combining HiveNightmare/SeriousSAM and AD CS Attack Path’s for Profit // Black Hills Information Security
- Certificates and Pwnage and Patches, Oh My! // Medium / Will Schroeder
- AD CS Attack Guide // The Hacker Recipes