ESC15. Уязвимость шаблонов
ESC15 — это техника повышения привилегий в AD CS, при которой злоумышленник использует уязвимый шаблон сертификата версии 1 (v1), чтобы запросить сертификат с поддельным Subject и произвольными application policies (OID). В результате атакующий получает сертификат, подходящий для аутентификации от имени любого пользователя (вплоть до администратора), даже если шаблон изначально не предназначен для этого.
Причина уязвимости в том, что v1‑шаблоны не фильтруют содержимое запроса. Так, злоумышленник может внедрить нужные OID (объектные идентификаторы), превращая обычный шаблон (например, Web Server) в инструмент для захвата AD.
Чтобы злоумышленник смог реализовать атаку ESC15, в инфраструктуре должны одновременно выполняться следующие пять условий:
-
Используется шаблон сертификата версии 1
Уязвимость затрагивает только шаблоны первого поколения (Schema Version 1). Они поставляются «из коробки» в Windows 2000/2003, и их нельзя отредактировать (кроме списков доступа). Примеры: User, Web Server, Basic EFS, Code Signing, Enrollment Agent (Offline) и др. Если администратор дублировал (скопировал) шаблон, копия будет уже версии 2+ и неуязвима к ESC15.
-
Разрешен ручной ввод имени субъекта (Subject)
Для успешного проведения атаки в свойствах шаблона должна быть включена опция Subject Name = Supplied in the request (в консоли
certtmpl.msc). В атрибутеmsPKI-Certificate-Name-Flagв AD при этом появляется соответствующий флаг. Это означает, что заявителю позволено самостоятельно указывать поля Subject/SubjectAltName.Если же шаблон настроен на автогенерацию имени из AD (например, для пользовательского шаблона по умолчанию), атака ESC15 через него невозможна, так как злоумышленник не сможет подменить имя запрашиваемого субъекта.
-
Не требуется ручное одобрение заявки администратором CA и подпись регистрационного агента
Шаблон должен быть доступен для автоматической выдачи. Это подразумевает, что отключено требование одобрения оператора CA (флаг
PEND_ALL_REQUESTSне установлен в атрибутеmsPKI-Enrollment-Flag) и не требуется предварительная подпись регистрационного агента (msPKI-RA-Signature = 0). Иными словами, любой обладатель права Enroll может сразу получить сертификат без дополнительных препятствий. В шаблонах первой версии нет таких настроек, но технически можно добавить такие ограничения через ADSI. -
Нет ограничения через одобрение выпуска сертификатов на стороне CA
Выбранная настройка не отправляет запрос сертификата на одобрение, что позволяет получить сертификат сразу.
-
Злоумышленник имеет право на выпуск сертификатов (Enroll)
В ACL шаблона в AD (вкладка Security) право Enroll есть у пользователей без высоких привилегий. Например, шаблон уязвим, если доступен Domain Users, Authenticated Users или иной общей группе. Если регистрироваться по шаблону могут только администраторы PKI или аналогичные высокопривилегированные группы, даже будучи потенциально уязвимым по настройкам, шаблон не представляет непосредственной угрозы эскалации, пока злоумышленник не получит соответствующие привилегии доступа к нему.
Злоумышленник сканирует конфигурацию AD CS на наличие шаблонов версии 1, которые позволяют задавать имя субъекта вручную. Как правило, такие шаблоны — унаследованные v1‑шаблоны (созданные еще в Windows 2000) с опцией Supplied in the request и опубликованные на сервере CA. К числу типичных уязвимых шаблонов относятся, например: Web Server, Enrollment Agent (Offline), Exchange User, Offline Router, CEP Encryption.
Атакующий убеждается, что у его учетной записи есть право Enroll на такой шаблон (например, шаблон с таким правом доступен для Domain Users или другой группы, куда входит злоумышленник).
Обнаружив подходящий шаблон, злоумышленник генерирует запрос на выпуск сертификата (CSR), подменяя в нем поля, чтобы выдать сертификат на чужую привилегированную личность.
В частности, он указывает:
- Subject/SubjectAltName — имя учетной записи с высокими правами, которую атакующий хочет имперсонировать (например, UPN администратора домена). Шаблон v1 с Supplied in the request позволяет это сделать.
- Дополнительные OID в application policies. Злоумышленник добавляет в запрос OID политики приложения, соответствующий требуемому использованию сертификата. Например, чтобы использовать сертификат для аутентификации в AD, он добавляет OID Client Authentication (
1.3.6.1.5.5.7.3.2) или Smart Card Logon. Эти OID указываются как application policies в расширениях запроса, даже если исходный шаблон их не содержит.
Приведем пример создания запроса на сертификат, для этого необходимо сформировать INF‑файл.
Что такое INF‑файл и зачем он нужен
INF‑файл — это конфигурационный файл, который используется вместе с утилитой certreq для генерации запроса на сертификат (CSR).
Внутри этого файла можно указать:
- какой Subject (имя пользователя) необходимо получить в сертификате;
- какие OID (application policies) вставить в запрос (например, для аутентификации в AD);
- параметры ключа, криптопровайдера и т. д.
В контексте атаки ESC15 злоумышленник вручную подменяет в этом файле имя на учетную запись жертвы (например, Administrator) и добавляет нужные OID, чтобы обойти ограничения шаблона.
Вот как может выглядеть INF‑файл для атаки ESC15:
[Version]
Signature="$Windows NT$"
[NewRequest]
Subject = "CN=Administrator,CN=Users,DC=corp,DC=local"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = FALSE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
[Extensions]
2.5.29.17 = "{text}"
_continue_ = "upn=Administrator@corp.local"
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.2 ; Client Authentication
| Параметр | Назначение |
|---|---|
| Subject |
Указывает, от чьего имени будет выдан сертификат (жертва — |
| 2.5.29.17 → upn= |
Альтернативное имя (UPN) — подставляется имя жертвы |
| OID=1.3.6.1.5.5.7.3.2 |
Добавляет политику Client Authentication — позволяет использовать сертификат для входа в AD |
| Exportable = TRUE |
Указывает на то, что ключ можно экспортировать — это нужно злоумышленнику |
| KeyLength, ProviderName и др. |
Технические параметры генерации ключа |
Чтобы использовать INF‑файл, необходимо:
- Сохранить файл как
admin_request.inf. - Сгенерировать запрос на сертификат:
certreq -new admin_request.inf admin_request.req.
Это означает, что, даже если шаблон изначально был предназначен, например, только для веб‑серверов, злоумышленник может превратить его в сертификат, который Windows признает подходящим для входа в домен (Client Authentication).
Такой эффект достигается за счет ручного указания нужных OID в запросе на сертификат. В частности, в INF‑файле, с помощью которого формируется CSR, атакующий добавляет в секцию [EnhancedKeyUsageExtension] строку вида: OID=1.3.6.1.5.5.7.3.2 ; Client Authentication.
Это значение (OID=1.3.6.1.5.5.7.3.2) соответствует политике использования сертификата для клиентской аутентификации, в том числе для Kerberos-аутентификации в Active Directory. Именно такой OID должен присутствовать в сертификате, чтобы он считался пригодным, например, для входа в систему через PKINIT или подключения по TLS к сервисам, доверяющим этому OID.
В нормальной, безопасной ситуации OID, включенные в сертификат, определяются на уровне шаблона сертификата и жестко контролируются администратором. То есть, если шаблон предназначен только для шифрования данных, в нем не будет OID, связанных с аутентификацией, — и злоумышленник не сможет это изменить.
Однако в случае шаблонов версии 1 ситуация иная. Такие шаблоны:
- не содержат раздела Application Policies в интерфейсе
certtmpl.msc;
- не фильтруют OID, указанные в запросе, на стороне центра сертификации. Это самое главное.
Это означает, что если злоумышленник вручную добавит нужные OID (например, Client Authentication) в свой запрос (CSR), то центр сертификации включит эти значения в выданный сертификат, даже если шаблон изначально не предназначался для таких целей.
В шаблонах версии 2 и выше все OID, указанные в запросе, сравниваются с теми, что разрешены в шаблоне, и любые лишние OID просто игнорируются. В отличие от них v1‑шаблон не делает такого сопоставления. Центр сертификации доверяет всему, что находится в CSR.
Таким образом, если атакующий использует шаблон версии 1 (например, Web Server) и вручную в запросе указывает, что сертификат должен быть пригоден для Client Authentication, он получит сертификат с этим правом, даже если исходный шаблон таких прав не предусматривал.
После подготовки INF‑файла злоумышленник использует встроенную утилиту Windows certreq для генерации и отправки запроса на сертификат.
Сначала формируется CSR‑файл на основе подготовленного INF‑файла:
certreq -new admin_request.inf admin_request.req
На этом этапе создается файл запроса admin_request.req, в который уже включены все поддельные данные: имя администратора, UPN и OID для клиентской аутентификации.
Затем этот запрос отправляется в уязвимый центр сертификации:
certreq -submit -attrib "CertificateTemplate:WebServer" admin_request.req admin_received.cer
Обратите внимание, что здесь явно указывается шаблон WebServer (версии 1), который содержит необходимые уязвимости: разрешает Supply in the request, не требует одобрения, не фильтрует OID.
Если все условия соблюдены, центр сертификации автоматически выпускает сертификат и сохраняет его в admin_received.cer.
Далее атакующий объединяет сертификат с приватным ключом в формат PFX. Таким образом, злоумышленник получает готовый PFX‑файл, который можно использовать для аутентификации от имени жертвы.
Чтобы выявить эксплуатацию ESC15, отслеживайте несколько ключевых событий на сервере центра сертификации.
Event ID 4887. Certificate Services approved a certificate request and issued a certificate
Это событие фиксирует факт выдачи сертификата. Важно сравнивать следующие поля:
- Requestor — кто отправил запрос;
- Issued To — на чье имя был выдан сертификат.
Если сертификат выдан, например, на CN=Administrator, а запрашивал его user@corp.local — это сигнал потенциальной атаки ESC15.
Event ID 4898. Certificate Services loaded a template
Система создает это событие при обращении к сертификату. Оно содержит полный список параметров каждого шаблона и может использоваться для инвентаризации и предиктивного обнаружения уязвимых конфигураций — иногда еще до начала атаки, а иногда уже в момент ее выполнения. Это возможно, потому что к шаблону может обратиться не только злоумышленник, но и легитимные службы, использующие его в работе.
Вот какие данные можно извлечь из этого события:
| Признак | Значение |
|---|---|
| msPKI-Template-Schema-Version |
=  |
| msPKI-Certificate-Name-Flag |
Содержит флаг  |
| msPKI-RA-Signature |
= |
| msPKI-Enrollment-Flag |
Не содержит |
| pKIExtendedKeyUsage |
Содержит OID  |
| Security Descriptor |
Содержит Enroll для Domain Users / Authenticated Users и т. п.  |
Может возникнуть вопрос: зачем смотреть в шаблоне 4898 на атрибут pKIExtendedKeyUsage вместо того, чтобы посмотреть на msPKI-Certificate-Application-Policy? Параметр msPKI-Certificate-Application-Policy отвечает за список OID, определяющих допустимое использование сертификата. Например, если в нем указано значение 1.3.6.1.5.5.7.3.2 (Client Authentication), то сертификат можно использовать для входа в AD.
Как же внести такой OID в шаблон, если через консоль шаблонов сертификатов (certtmpl.msc) этого параметра вообще не видно? Ответ — в версии шаблона. В шаблонах версии 1 (v1) действительно отсутствует вкладка Application Policies, и кажется, что задать такие значения невозможно. Однако, если открыть шаблон через ADSI Edit, нужное поле (msPKI-Certificate-Application-Policy) там есть. Именно отсюда и можно вручную добавить OID, даже если в GUI этого не видно.
Таким образом, несмотря на то что шаблон выглядит «чистым» в интерфейсе, он может содержать разрешенные политики на стороне Active Directory. Это позволяет сертификату, выданному по такому шаблону, получить EKU для клиентской аутентификации — и быть использованным в атаках вроде ESC15.
Через ADSI Edit найдите этот шаблон, в нем — атрибут msPKI-Certificate-Application-Policy и добавьте OID 1.3.6.1.5.5.7.3.2. Сохраните, перезапустите центр сертификации, чтобы во время обновления базы он обратился к вашему шаблону и это событие было зафиксировано в журнале безопасности под номером 4898.
Перед тем как проверить событие 4898, посмотрите на содержимое в консоли шаблона сертификатов:
Как видно, OID был добавлен в раздел с EKU.
А теперь посмотрите на событие 4898:
Кратко разберем дескрипторы безопасности, подробнее о них читайте в справочных материалах.
Проверьте, у кого, кроме администраторов, есть права Enroll (0e10c968-78fb-11d2-90d4-00c04f79dc55).
Затем выявите потенциально опасные группы. К ним относятся DU — Domain Users (все пользователи домена), AU — Authenticated Users (все аутентифицированные пользователи, включая пользователей из доверенных доменов), WD — Everyone (абсолютно все пользователи, в том числе неаутентифицированные и анонимные).
Под это требование подходит следующее условие:
";0e10c968-78fb-11d2-90d4-00c04f79dc55;;DU" OR ";0e10c968-78fb-11d2-90d4-00c04f79dc55;;AU" OR ";0e10c968-78fb-11d2-90d4-00c04f79dc55;;WD"
В этом разборе важно учитывать, что шаблон может изначально не содержать OID 1.3.6.1.5.5.7.3.2 (Client Authentication) в EKU. Злоумышленник все равно может запросить сертификат по такому шаблону, вручную указав нужный OID в запросе. Центр сертификации обращается к шаблону WebServer, в это время создается событие 4898, где и будет информация об этом шаблоне. Если используется шаблон версии 1, CA не сверяет запрошенные OID с теми, что прописаны в шаблоне, — и включит их в сертификат, даже если в шаблоне нет этого OID.
В итоге вы получите событие 4898 без OID 1.3.6.1.5.5.7.3.2 (Client Authentication) в EKU.
Тем не менее нельзя исключать и обратную ситуацию — когда кто‑то заранее вручную добавил OID в шаблон. Именно для того, чтобы лучше понять этот механизм, мы привели пример ручного добавления 1.3.6.1.5.5.7.3.2 в поле msPKI-Certificate-Application-Policy через ADSI Edit.
Таким образом, при анализе события 4898, чтобы найти потенциально уязвимые шаблоны, не стоит полагаться только на наличие или отсутствие конкретного OID. Лучше ориентироваться на структурные признаки, а именно:
- Шаблон версии 1 (
Schema-Version = 1). - Установлен флаг
CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT, то есть разрешен ручной ввод Subject. - Право Enroll есть у одной из небезопасных групп, например Domain Users (
DU), Authenticated Users (AU), Everyone (WD).
При этом условия про одобрение менеджера или подпись регистрационного агента можно не учитывать, так как в шаблонах v1 их попросту нет по своей структуре.
Итоговое условие фильтрации события 4898 будет выглядеть так:
EventID 4898 CONTAIN (
msPKI-Template-Schema-Version = 1 AND CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT AND
(";0e10c968-78fb-11d2-90d4-00c04f79dc55;;DU" OR
";0e10c968-78fb-11d2-90d4-00c04f79dc55;;AU" OR
";0e10c968-78fb-11d2-90d4-00c04f79dc55;;WD"))
Такой подход позволит выявить все потенциально уязвимые шаблоны, независимо от того, была ли Client Authentication указана в них изначально или будет внедрена в момент запроса.
Рассмотрим ситуацию, когда нет доступа к событиям аудита либо они отсутствуют в логах. Например, потому что на хосте не включены политики журналирования или шаблон был добавлен, но служба центра сертификации (CertSvc) не была перезапущена, из‑за чего событие 4898 не сработало. В таком случае на помощь приходят инвентаризационные данные, собранные с хоста.
Все активные шаблоны, с которыми работает CA, хранятся в реестре Windows по пути HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\CertificateTemplateCache. Независимо от того, был ли перезапущен центр сертификации, в этом разделе реестра уже будут перечислены все опубликованные шаблоны и их параметры. Это позволяет проводить ретроспективный и офлайн-анализ конфигурации шаблонов.
Например:
- Версия шаблона —
msPKI-Template-Schema-Version.
- Имя Subject из запроса —
msPKI-Certificate-Name-Flag, где наличие флага0x00000001означаетCT_FLAG_ENROLLEE_SUPPLIES_SUBJECT.
Если обратиться к официальной документации Microsoft по шаблонам сертификатов (MS‑CRTD), можно увидеть, что флаг
CT_FLAG_ENROLLEE_SUPPLIES_SUBJECTимеет значение0x00000001. Это означает, что при анализе параметраmsPKI-Certificate-Name-Flagв шаблоне (в том числе в реестре) достаточно выполнить побитовую проверку. Если результат выражения ($msPKI_Certificate_Name_Flag -band 0x1) равен0x1, то флаг активен и шаблон позволяет пользователю вручную указывать Subject/SubjectAltName при запросе сертификата. - Политики использования —
msPKI-Certificate-Application-Policy, где можно проверить наличие1.3.6.1.5.5.7.3.2.
ACL (Enroll-права) — в зашифрованном виде в параметре Security. Может быть извлечен и расшифрован PowerShell-скриптом.
Последним шагом необходимо извлечь у шаблона дескрипторы безопасности, находящиеся в параметре Security, однако они хранятся в зашифрованном виде.
Тогда нужные данные можно получить командой в PowerShell. Например, так выглядит информация о шаблоне WebServer:
Get-ADObject -LDAPFilter "(cn=WebServer)" ` -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" ` -Properties nTSecurityDescriptor | Select-Object -ExpandProperty nTSecurityDescriptor | Format-List Sddl
Вывод:
С помощью EDR‑решений, например BI.ZONE EDR, уязвимые шаблоны сертификатов выявляются заранее, до момента возможной эксплуатации. Для этого используется механизм инвентаризации конфигураций, который собирает данные обо всех шаблонах, хранящихся в реестре по пути HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\CertificateTemplateCache.
После первичного анализа шаблоны, относящиеся к версии 1 и содержащие потенциально опасные параметры (например, Supply in the request, широкие права Enroll и отсутствие фильтрации OID), ставятся на постоянный мониторинг.
Если в этой ветке появляются новые шаблоны или происходят изменения существующих, система автоматически фиксирует это и направляет шаблон на повторный анализ.
Таким образом, в BI.ZONE EDR реализован подход, при котором все уязвимые или неправильно сконфигурированные шаблоны могут быть выявлены как в ретроспективе, так и в режиме реального времени, еще до начала атаки.
Атака ESC15 использует слабости шаблонов сертификатов версии 1, позволяющие запрашивать сертификаты с поддельным Subject и внедренными OID. Чтобы надежно защититься от этой техники, примите комплекс мер на уровне конфигурации AD CS и общего управления безопасностью.
Шаблоны версии 1 не позволяют настроить ограничения на уровне интерфейса и не фильтруют OID, передаваемые в запросах. Рекомендуем:
- Удалить все v1‑шаблоны, которые не используются.
- Если шаблон необходим, создать его дубликат (версия 2 или выше) и настроить его безопасно.
- Никогда не публиковать шаблоны v1 для широких групп пользователей.
Атака становится возможной только при включенной опции Supply in the request. Вот что мы советуем сделать:
- В свойствах шаблона (в
certtmpl.msc), на вкладке Subject Name, установите флаг Build from information in Active Directory. - Убедитесь, что флаг
CT_FLAG_ENROLLEE_SUPPLIES_SUBJECTне используется.
В шаблонах v1 это невозможно сделать через GUI — либо замените шаблон, либо вручную отредактируйте через ADSI Edit.
Поменяйте значение так, чтобы CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT не входил в этот атрибут. Подробнее о том, как это сделать, читайте в справочных материалах.
Сохраните изменения и перезапустите службу сертификации: net stop certsvc && net start certsvc.
В результате шаблон сертификата должен выглядеть так:
Проверьте, кто имеет право Enroll на шаблоны:
- Удалите доступ к Enroll для групп Domain Users, Authenticated Users, Everyone.
- Разрешите Enroll только тем группам, которые действительно должны запрашивать сертификаты (например, IT или PKI Admins).
В ноябре 2024 года Microsoft выпустила патч, который напрямую блокирует возможность добавления произвольных OID в шаблонах v1, — KB5046616.
Установите это обновление — патч полностью закрывает вектор атаки ESC15. После инсталляции центр сертификации блокирует внедрение лишних OID в раздел Application Policies, даже если шаблон v1 не настроен жестко.
Включите аудит шаблонов сертификатов (Event ID 4898) и событий выдачи сертификатов (Event ID 4887).
Так как шаблоны первой версии не позволяют настраивать ручное одобрение, настройте это на уровне CA. Подробнее о том, как это сделать, читайте в справочных материалах.
Если шаблон v1 позволяет Supply in the request, не фильтрует OID и доступен для обычных пользователей, его можно использовать для захвата привилегий. Удаление таких шаблонов, установка обновлений и настройка ограничений по правам — надежный способ защититься от атаки ESC15.