ESC2. Подписываю что хочу
ESC2 — распространенный сценарий опасной конфигурации в AD CS. Его иногда называют уязвимостью Any Purpose EKU или SubCA-шаблона. По сути, ESC2 — вариация ESC1, но без необходимости подделки SAN.
В качестве примера рассмотрим шаблон сертификата с именем ESC2. Пользователь с низкими привилегиями — hacker — запрашивает сертификат на свое имя с помощью уязвимого шаблона, содержащего расширение Any Purpose. Затем злоумышленник использует выданный сертификат для получения Kerberos TGT, что открывает путь к дальнейшим атакам внутри домена.
Вот условия, необходимые для успешного выполнения атаки:
-
Шаблон определяет EKU Any Purpose или не содержит EKU вовсе. Это главное условие для реализации ESC2. В поле назначений сертификата (Extended Key Usage) шаблона указан универсальный OID Any Purpose (
2.5.29.37.0) либо EKU отсутствуют:
Отсутствие EKU обычно характерно для шаблонов Subordinate CA (подчиненный CA) — такие сертификаты по умолчанию не ограничены в применении. В некоторых случаях шаблон может комбинировать Any Purpose с другими EKU, но суть в том, что сертификат, выпускаемый по этому шаблону, может использоваться практически для любых целей. В частности, сертификат Any Purpose подходит для аутентификации клиента или сервера, для подписи кода, для шифрования и т. д.
А у сертификата без EKU (SubCA) вообще есть полномочия для подписи других сертификатов: включен флаг The subject is a certification authority, как показано на скриншоте ниже. Когда EKU не задан, это делает сертификат универсальным в применении. Отсутствие ограничения Do not allow subject to issue certificates to other CAs позволяет выпускать и свои подчиненные центры авторизации.
Такой шаблон дает злоумышленнику возможность создать собственный доверенный CA и обойти все ограничения AD CS. Пользователь получает сертификат с правами полного доверия без ограничений — именно это лежит в основе атаки ESC2.
-
У низкоуровневого пользователя есть право Enroll на шаблон. Как и в случае с ESC1, обычный доменный пользователь (или группа типа Authenticated Users) наделен правом регистрации по рассматриваемому шаблону. То есть шаблон доступен не только администраторам. В нашем случае это пользователь
hacker:
-
Отключено требование одобрения менеджера. Параметр CA certificate manager approval отключен, заявки автоматически обрабатываются центром сертификации без ручного контроля.
-
Не требуются авторизованные подписи. Шаблон не требует дополнительных подписей запроса (
msPKI-RA-Signatureравен 0 или не задан). Это значит, что запрос может исходить напрямую от пользователя, без совместной подписи каким‑либо агентом или другим сертификатом.
Обратите внимание: чтобы шаблон считался уязвимым по ESC2, не нужен флаг Supply in the request (SAN).
Даже если SAN нельзя указать вручную, сам факт выдачи широкопрофильного сертификата низкопривилегированному лицу — серьезная брешь. Если же шаблон ESC2 тоже позволяет SAN в запросе, то это комбинация ESC1 и ESC2. В таком случае атака будет проходить по сценарию ESC1, позволяя выдачу сертификата на чужое имя.
Таким образом, вот типичный сценарий ESC2: в организации есть шаблон сертификата (например, для внутреннего универсального удостоверения или для выдачи SubCA), который доступен всем и не требует одобрения. Злоумышленник, скомпрометировав обычную учетную запись, может запросить такой сертификат для себя. По сравнению с ESC1 он не может сразу выдать сертификат на администратора (если SAN запрещен), но полученный им сертификат все равно открывает возможности для дальнейшей эскалации и атаки на инфраструктуру. Далее рассмотрим, как именно злоумышленник может это использовать.
Атака по сценарию ESC2 может развиваться несколькими путями в зависимости от того, какой тип сертификата злоумышленник получает: с EKU Any Purpose или подчиненного CA. Общие шаги поиска уязвимого шаблона аналогичны ESC1.
Утилиты Certifyfind /vulnerable помечают шаблоны, подходящие под ESC2. Также атакующий может вручную отфильтровать в AD все шаблоны, у которых pKIExtendedKeyUsage равен 2.5.29.37.0 (Any Purpose) или отсутствует, вместе с отключенными approval и RA signature.
Так как шаблон ESC2 ранее уже был настроен с уязвимыми параметрами и доступен пользователю hacker, теперь необходимо аналогичным образом настроить шаблон SubCA.
Для этого злоумышленнику нужно предоставить пользователю hacker расширенные права на выпуск сертификатов по этому шаблону — как показано на скриншоте ниже. Это позволит использовать SubCA по сценарию, описанному в разделе об атаке ESC1.
Далее атакующий проверяет уязвимые шаблоны через Certipy:
И получает информацию о шаблоне ESC2:
Шаблон ESC2 уязвим, поскольку включены флаги Any Purpose и Enrollment Agent, что дает злоумышленнику возможность запрашивать сертификаты от имени других пользователей. Кроме того, пользователь hacker имеет права на выпуск сертификатов без одобрения администратора.
Еще атакующий получает информацию о шаблоне SubCA:
В шаблоне SubCA тоже включены флаги Any Purpose и Enrollment Agent, отсутствует требование ручного одобрения, а в списке прав на выпуск сертификатов находятся низкопривилегированные пользователи, что указывает на уязвимость по ESC2.
Обычный сертификат
С помощью найденного уязвимого шаблона атакующий запрашивает сертификат на свою учетную запись. Для разнообразия представим, что SAN изменить нельзя. Выдача происходит при использовании шаблона с настройкой Build from this Active Directory information: имя в сертификате автоматически подставляется из атрибутов текущего пользователя.
Вот как выпустить сертификат на себя вручную:
-
Создать INF‑файл с текстом:
[Version] Signature="$Windows NT$" [NewRequest] Subject = "CN=GOODUSER, OU=DCAdministrators, OU=Expert, DC=GOOD, DC=EXPERT" KeySpec = 1 KeyLength = 2048 Exportable = TRUE MachineKeySet = FALSE SMIME = FALSE PrivateKeyArchive = FALSE UserProtected = FALSE UseExistingKeySet = FALSE RequestType = PKCS10 KeyUsage = 0xa0 [Extensions] 2.5.29.17 = "{text}" _continue_ = "upn=hacker@good.expert" [RequestAttributes] CertificateTemplate = ESC2v3 Командой
certreq -new .\esc2.inf esc2.reqсоздать запрос на сертификат ESC2 из файлаesc2.inf:
Отправить запрос на подпись с помощью команды
certreq -submit -attrib “CertificateTemplate:ESC2” esc2.req esc2.cer:
Теперь можно использовать этот сертификат в Windows с помощью команды certreq -accept esc2.cer.
Сертификат с форматом PFX
Если нужен сертификат с форматом PFX, помогут следующие команды:
$cert = Get-ChildItem Cert:\CurrentUser\My | Where-Object { $_.Subject -like "*GoodUser*" }
$cert | Export-PfxCertificate -FilePath.\esc2v3.pfx -Password (ConvertTo-SecureString -AsPlainText "P@ssw0rd!" -Force)
Здесь GoodUser — CN пользователя hacker в тестовой лаборатории, а P@ssw0rd! — пароль, который потребуется во время экспорта сертификата.
Если в системе много сертификатов с данными CN, тогда можно найти самый последний выданный сертификат командой:
$cert = Get-ChildItem Cert:\CurrentUser\My | Where-Object { $_.Subject -like "*GoodUser*" } |
Sort-Object NotBefore -Descending |
Select-Object -First 1
Или вручную проверить и выбрать по отпечатку:
Get-ChildItem Cert:\CurrentUser\My | Where-Object { $_.Subject -like "*GoodUser*" } |
Format-List Subject, Thumbprint, NotBefore, NotAfter
А после экспортировать командой:
$cert = Get-ChildItem Cert:\CurrentUser\My | Where-Object { $_.Thumbprint -eq "DA7413AC0D7FC336968B279EF3DAE4B234E5B336" }
$cert | Export-PfxCertificate -FilePath.\esc2pfx -Password (ConvertTo-SecureString -AsPlainText "1234" -Force)
Дополнительно можно выполнить поиск по UPN (user principal name) — уникальному идентификатору пользователя в формате «имя@домен». Например, hacker@good.expert может быть подставным UPN, указанным злоумышленником при ручной подаче запроса на сертификат:
Get-ChildItem Cert:\CurrentUser\My | Where-Object { $_.Extensions | Where-Object { $_.Format(1) -like "*hacker@good.expert*" } }
После мы получаем отпечаток (thumbprint) и можем экспортировать сертификат в формат PFX.
Все действия проиллюстрированы на скриншоте ниже.
PFX-формат содержит и сам сертификат, и приватный ключ, а значит, может использоваться для аутентификации.
Вот примеры, где нужен PFX:
| Инструмент/цель | Использование PFX |
|---|---|
| Certipy |
Аутентификация с |
| Rubeus |
Получение TGT через |
| Mimikatz |
Импорт в токен с |
| Cobalt Strike / Empire |
Импорт в Beacon для скрытой аутентификации |
| Установка в Windows |
Импорт для использования системой |
| LDAPS, HTTPS auth |
Сертификат-клиент для TLS |
Например, чтобы получить свой же TGT‑билет в Rubeus, используется команда:
.\Rubeus.exe asktgt /user:hacker /certificate:esc2.pfx /password:1234 /domain:good.expert /dc:10.3.132.172 /ptt
В итоге эксплуатируется сертификат с EKU Any Purpose для пользовательской учетной записи. Злоумышленник может сразу использовать его для аутентификации в домене (так же как в ESC1, но только от имени своей учетной записи). Эксплуатация такого сертификата не дает новых прав, однако он может служить средством обхода некоторых средств защиты. Например, если в организации настроена многофакторная аутентификация или блокировка входа по паролю, сертификат может предоставить альтернативный способ входа — как по сертификату, так и по TGT. Кроме того, сертификат можно использовать для подписания и шифрования с высоким доверием: Any Purpose включает серверную аутентификацию и ему доверяет широкий круг приложений.
Если проэксплуатировать шаблон SubCA, потенциал такой атаки еще серьезнее. С приватным ключом подчиненного CA злоумышленник может развернуть собственный удостоверяющий центр (например, программно установить на скомпрометированной машине) и начать выдавать от имени корпоративной цепочки любые сертификаты. По сути, атакующий получает возможность создавать доверенные сертификаты для любых целей:
Выпускать себе сертификат на администратора домена (аналог ESC1, но «в обход» — теперь он сам себе CA). Правда, контроллер домена не примет такой сертификат по умолчанию для аутентификации, потому что Windows проверяет, включен ли издатель сертификата в контейнер
NTAuthCertificates. Подчиненные CA не добавляются туда автоматически. То есть, просто выпустив фальшивый сертификат администратора через свой суб‑CA, злоумышленник не сможет войти в домен — DC отклонит его, не доверяя цепочке для целей смарт-карты. Однако отсутствие доверия для входа не исключает остальные возможности.Генерировать сертификаты с любым EKU и любыми полями. Такие сертификаты подписаны ключом, который, в свою очередь, отправляется к доверенному корневому CA компании.
Например, атакующий может выдать себе сертификат с EKU Code Signing и выпустить им цифровую подпись вредоносного кода. Для рабочих станций в домене такая подпись будет выглядеть как пришедшая от доверенного издателя (корневой корпоративный CA обычно находится в доверенных корневых центрах на всех машинах домена). Это облегчит внедрение вредоносного ПО, обход SmartScreen и других механизмов, проверяющих подписи кода.
Другой пример — выпуск сертификата с EKU Server Authentication для любого имени сервера (скажем,
mail.corp.local) и проведение MitM‑атаки на сервис, шифрующий трафик. Пользователи не увидят предупреждений, так как сертификат «подписан» доверенным CA.Издать сертификаты для протоколов IPsec, S/MIME, SSL VPN, WPA‑Enterprise. Все они опираются на доверие к корпоративному корневому центру. Таким образом, компрометация SubCA эквивалентна компрометации всей PKI организации за исключением непосредственной аутентификации в AD, которая защищена NTAuth‑списком. Но даже в AD можно найти обходные пути, например скомпрометировав сервис ADFS. Если ADFS доверяет сертификатам определенного CA для выдачи токенов, атакующий может воспользоваться этим и выпустить токен доступа.
Добиться доверия к своему сертификату для последующего входа в домен. Один из способов — добавить сертификат поддельного SubCA в контейнер
NTAuthCertificates, который используется для определения доверенных центров при Kerberos-аутентификации с сертификатами. Для этого требуются административные привилегии в Active Directory, в частности права Write или Full Control на объект:CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=....Другой способ — использовать шаблон конечного сертификата, у которого нет строгих ограничений по EKU и которому не требуется наличие специфического расширения Certificate Request Agent. В таком случае атакующий может получить агентский сертификат без проверки и использовать его, чтобы запрашивать сертификаты от имени других пользователей, как в атаке ESC3.
Оба этих вектора, позволяющие добиться доверия к сертификату, выходят за рамки базового сценария ESC2, так как требуют либо прямого доступа к конфигурации AD, либо заведомо небезопасной конфигурации шаблонов.
При ESC2 злоумышленник обычно не имперсонирует какого‑либо пользователя в момент запроса. Он получает сертификат на себя, но этот сертификат сам по себе настолько сильный, что его использование приводит к серьезным последствиям. В этом отличие от ESC1 в плане выполнения атаки. В отчете SpecterOps
Иногда злоумышленник с сертификатом ESC2 может попытаться разыграть сценарий ESC3. То есть, используя, скажем, сертификат Any Purpose, попробовать выступить в роли Enrollment Agent и запросить сертификат на другого пользователя. Однако для этого нужна вторая уязвимость — шаблон, позволяющий запрос on behalf of без строгой проверки EKU‑агента. Если такой шаблон есть, то даже без EKU Certificate Request Agent злоумышленник может подписать им CSR как агент (Any Purpose может трактоваться как допустимый для этой операции). Тогда комбинация двух шаблонов приведет к тому же результату — выпуску сертификата на администратора. Фактически это будет уже не совсем техника ESC2, а совмещение с ESC3. Тем не менее этот вариант маловероятен, если шаблон принимающей стороны нормально настроен (обычно он требует именно OID агента в сертификате агента).
Рассмотрим, как обнаружить шаблоны, уязвимые к ESC2, и эксплуатацию этой техники.
Прямая эксплуатация ESC2 может не вызывать таких явных аномалий, как в случае с ESC1, но все же может быть заметна. Например, по следующим событиям:
Событие 4887 (выдача сертификата) для шаблона Subordinate CA, инициированное от учетной записи, не являющейся администратором. Это крайне подозрительно. В обычной работе только PKI‑администратор инициирует выдачу подчиненного CA (и то не через авторегистрацию, а вручную, часто офлайн). Поэтому обнаружение 4887, когда Template = Subordinate CA, а Requester — это пользователь без высоких прав, сигнализирует о проблеме. Даже если SAN совпадает (то есть пользователь запросил на свое имя), сам факт того, что обычный пользователь получил сертификат подчиненного CA, — уже инцидент.
Событие 4887 для шаблона с Any Purpose EKU. Здесь заметить аномалию сложнее, так как Any Purpose может фигурировать и в других шаблонах. Но можно отфильтровать случаи, когда у Template есть EKU Any Purpose и при этом нет EKU аутентификации клиента. Комбинация Any Purpose и Server Authentication встречается редко. Если такой сертификат получил обычный пользователь, возможно, у него слишком много прав.
Событие 4898 (загрузка шаблонов) и поиск шаблонов. Как и для ESC1, можно использовать события 4898 для поиска присутствия Any Purpose. В тексте события шаблона Any Purpose будет OID
2.5.29.37.0без указания других EKU. А для шаблона SubCA поле EKU вообще отсутствует. Если у таких шаблонов есть открытые разрешения, событие 4898, которое содержит Security Descriptor шаблона, покажет SIDS-1-1-0(Everyone) илиS-1-5-11(Authenticated Users) с правами Enroll. Фильтр по событию 4898 может быть таким: Any Purpose и присутствие в Security Descriptor строк;;DU/;;AU/;;WD(Domain Users / Auth Users / Everyone). Это прямо указывает на технику ESC2 в конфигурации:
Подробный разбор события 4898 смотрите в справочных материалах.
Выявить технику ESC2 сложнее, чем ESC1, потому что злоумышленник явно ничего не нарушает: он получает сертификат как бы для себя. Поэтому делайте упор на предварительный аудит и мониторинг конфигурации.
Хотя многие превентивные меры перекликаются с мерами против ESC1, в случае ESC2 важно сосредоточиться на специфике техники. Полагаться исключительно на события безопасности — неэффективно, так как они могут отсутствовать вовсе или появляться только в момент обращения к уже уязвимым шаблонам. Надежнее заранее выявлять и устранять опасные конфигурации шаблонов, не дожидаясь, пока ими воспользуется злоумышленник.
В этом поможет следующее:
Инвентаризация EKU шаблонов. Администраторы должны знать, какие EKU заданы в каждом шаблоне и для чего он предназначен. Любые шаблоны с EKU = Any Purpose должны вызывать вопросы. Чаще всего такая установка — ленивое решение на все случаи жизни, которое не требуется, если можно явно перечислить нужные назначения. Проверьте через ADSI Edit или PowerShell все объекты
pKICertificateTemplateна наличие2.5.29.37.0в атрибутеpKIExtendedKeyUsage.Проверка прав на шаблоны CA. Шаблон Subordinate CA по умолчанию хранится в
CN=Certificate Templates. Убедитесь, что у него нет разрешения Enroll для широких групп. Обычно там должны быть перечислены только Enterprise Admins или аналогичные права. Если выявлено отклонение — это серьезный инцидент безопасности (возможно, специально оставленный бэкдор или грубая ошибка настройки).Скрипты аудита. Как упоминалось, инструменты вроде PSPKIAudit имеют проверки для подобных случаев. Например, они могут показать предупреждение, если шаблон без EKU доступен всем. Также вы можете написать собственный скрипт: пробежаться по всем шаблонам, вывести Name, EKU и группы с правами Enroll, а затем вручную проанализировать, нет ли опасных сочетаний.
Консоль Certification Authority. Откройте оснастку CA
certsrv.mscи проверьте, какие шаблоны доступны этому CA (в ветке Certificate Templates). Бывает, что шаблон существует, но не разрешен на конкретном CA — тогда его эксплуатация невозможна. Если же уязвимый шаблон опубликован на сервере CA, исправьте его. Помните, что в ветке реестра по путиHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\CertificateTemplateCacheесть все актуальные шаблоны. Проверив, например, параметрExtKeyUsageSyntaxшаблона ESC2, можно заметить атрибут2.5.29.37.0(Any Purpose):
Затем найдите, какие дескрипторы безопасности у этого шаблона:
Get-ADObject -LDAPFilter "(cn=ESC2)" -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" -Properties nTSecurityDescriptor | Select-Object -ExpandProperty nTSecurityDescriptor | Select-Object -ExpandProperty SddlРезультат может быть таким:
На следующем этапе проанализируйте дескрипторы безопасности, чтобы выявить пользователей с правами на выпуск сертификатов, но при этом не входящих в административные группы.
Более детальный разбор прав доступа (ACL) — включая их структуру, типы и примеры интерпретации — ищите в справочных материалах.
Таким образом, обнаружение уязвимости ESC2 в конфигурации сводится к проактивному поиску широко доступных шаблонов со слишком универсальными сертификатами.
Лучшей практикой считается использование автоматизированных систем для поиска уязвимых шаблонов в режиме реального времени, например BI.ZONE EDR.
BI.ZONE EDR позволяет выявлять атаки ESC2 на основе правил корреляции, точно так же как и ESC1, а еще обеспечивает регулярный аудит сертификатов на предмет небезопасных настроек. Рассмотрим механизм работы подробнее.
Как говорилось выше, при любом изменении или создании шаблона сертификата в Windows вся информация об этом автоматически сохраняется в реестре по пути: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\CertificateTemplateCache.
Здесь хранятся ключевые параметры шаблонов сертификатов, однако дескрипторы безопасности (SDDL) представлены в закодированном виде — их нельзя прочитать напрямую.
BI.ZONE EDR решает эту задачу следующим образом:
- Агенты EDR на контролируемых хостах проводят полную инвентаризацию всех шаблонов сертификатов с их параметрами из указанного раздела реестра.
- Для каждого шаблона при сборе данных дополнительно извлекаются и расшифровываются дескрипторы безопасности (SDDL).
- Также осуществляется мониторинг всех изменений в шаблонах сертификатов. При изменении любого параметра шаблона (например, атрибута безопасности —
Security) агент мгновенно собирает обновленные данные и отправляет их на анализ.
В BI.ZONE EDR на основе полученных данных формируется правило предикта.
Вот пример такого правила для выявления уязвимых шаблонов, способных привести к атаке ESC2:
sddl:(";0e10c968-78fb-11d2-90d4-00c04f79dc55;;DU"
OR ";0e10c968-78fb-11d2-90d4-00c04f79dc55;;AU"
OR ";0e10c968-78fb-11d2-90d4-00c04f79dc55;;WD")
AND NOT "CT_FLAG_PEND_ALL_REQUESTS"
AND "msPKI-RA-Signature = 0"
AND "2.5.29.37.0"
Это правило в постоянном режиме мониторинга выявляет шаблоны сертификатов, удовлетворяющие следующим условиям:
- Шаблон не требует одобрения менеджером (
CT_FLAG_PEND_ALL_REQUESTSотсутствует). - Нет требований дополнительной подписи агента (
msPKI-RA-Signature = 0). - Шаблон содержит EKU Any Purpose (
2.5.29.37.0), что дает сертификату право на любое использование без ограничений. - Права на регистрацию сертификатов (Enroll) предоставлены широкому кругу пользователей или группам (Domain Users, Authenticated Users или Everyone). Это значит, что любой непривилегированный пользователь может получить сертификат с неограниченными правами, что является прямым путем к реализации атаки ESC2.
Кроме того, если у шаблона сертификата типа SubCA изменяется дескриптор безопасности (параметр Security), агент также мгновенно запускает скрипт, извлекает и расшифровывает актуальный SDDL. После этого на основе полученных данных дополнительно проверяется следующее условие: права регистрации (Enroll) предоставлены любой группе или пользователю, кроме стандартно допустимых (Domain Admins и Enterprise Admins):
(";0e10c968-78fb-11d2-90d4-00c04f79dc55;;DU"
OR ";0e10c968-78fb-11d2-90d4-00c04f79dc55;;AU"
OR ";0e10c968-78fb-11d2-90d4-00c04f79dc55;;WD"
OR любые другие пользователи и группы с правами ";0e10c968-78fb-11d2-90d4-00c04f79dc55;;")
Таким образом, BI.ZONE EDR в сочетании с SIEM позволяет заранее, еще до фактического использования злоумышленниками, выявить уязвимые шаблоны сертификатов и оперативно уведомить ответственных сотрудников для принятия мер по устранению угроз.
Чтобы устранить уязвимость к технике ESC2, примите следующие меры на уровне политики управления сертификатами:
Избегайте EKU Any Purpose. Пересмотрите необходимость использования универсального EKU. В большинстве случаев лучше указать конкретные OID, соответствующие предполагаемому использованию сертификата. Например, если сертификат предназначен для аутентификации пользователей и шифрования почты, укажите именно эти EKU вместо Any Purpose. Исключение можно сделать для очень специфичных сценариев, но тогда тщательно ограничьте доступ к такому шаблону. Microsoft прямо рекомендует удалять EKU Any Purpose из шаблонов, доступных непроверенным пользователям, так как он позволяет использовать сертификат для аутентификации и других целей.
Ограничьте или отключите выдачу подчиненных CA. В большинстве организаций внутренние промежуточные CA выпускаются редко. Обычно это разовая операция, которую админ PKI выполняет вручную. Нет причин держать шаблон Subordinate CA с включенными правами Enroll для кого‑либо постоянно. Рекомендуем убрать все разрешения Enroll из шаблона Subordinate CA (можно оставить только Read для Authenticated Users, чтобы его видели, но не более). Если понадобится выпустить новый CA, временно выдайте нужной учетной записи права или воспользуйтесь другим контролируемым методом.
Включите дополнительный контроль для Any Purpose — шаблонов. Если по каким‑то причинам существует шаблон, где Any Purpose нужен, убедитесь, что установлен флаг CA certificate manager approval или требование подписи. Это предотвратит автоматическую выдачу. Также стоит ограничить количество выдаваемых сертификатов по нему (через настройки серийных номеров или периодов выдачи).
Сократите срок действия сертификатов. В контексте ESC2 сертификаты SubCA обычно имеют длительный срок, например 5–10 лет. Если злоумышленник получил такой сертификат, долгая продолжительность действия играет на руку атакующему. Пересмотрите политики: действительно ли нужен столь большой срок? Может, внутренние суб‑CA могут переиздаваться чаще? То же касается и шаблонов Any Purpose: ограничение срока действия сертификата (например, 1 год вместо 5) уменьшит промежуток, в течение которого скомпрометированный сертификат опасен.
Отзовите выданные подозрительные сертификаты. Если обнаружилось, что по шаблону ESC2 уже были выданы сертификаты (особенно SubCA), немедленно отзовите (revoke) их на сервере CA и опубликуйте CRL. Более того, если инфраструктура позволяет, есть смысл добавить сертификат подчиненного CA в CTL (certificate trust list) как нелегитимный, чтобы в клиентах он сразу отвергался.
Мониторьте цепочки сертификации. Используйте инструменты мониторинга PKI, чтобы отслеживать, какие промежуточные центры существуют. Например, скрипт, проходящий по AD‑контейнеру Public Key Services → Enrollment Services, покажет все зарегистрированные CA. Там не должно появиться неожиданного нового объекта (злоумышленник с правами Enterprise Admin мог бы попытаться зарегистрировать свой SubCA в AD, хотя это уже другой уровень компрометации).
Проводите обучение и выстраивайте процессы. Аналогично ESC1 в этом случае важно донести до ответственных лиц опасность широких EKU. Настройка шаблона — это всегда баланс между удобством и безопасностью. Администраторы должны задавать себе вопросы: «А что, если обычный пользователь получит сертификат по этому шаблону? Чем он сможет злоупотребить?» В случае с Any Purpose / SubCA он сможет злоупотребить почти всем. Если риск неприемлем, ограничьте шаблон или не используйте вовсе.
ESC2 — это скрытая и крайне опасная проблема. Если ESC1 можно назвать ошибкой, сразу дающей корону (сертификат на администратора), то ESC2 — ошибка, дающая злоумышленнику запечатанный артефакт силы. Его еще нужно активировать и использовать, но потенциал огромен. Сертификат с Any Purpose EKU дает атакующему универсальный ключ ко многим дверям в инфраструктуре. А сертификат подчиненного CA — вообще контроль над самой системой доверия сертификатам (PKI) в организации, кроме ограничения NTAuth на вход в систему (которое, к счастью, сдерживает мгновенный захват домена).
