ESC3. Один шаблон — хорошо, а два — путь к домену
ESC3 — это техника, при которой злоумышленник может получить сертификат от имени другого пользователя с помощью неправильно настроенного механизма Enrollment Agent (агент регистрации). Такая атака позволяет эскалировать привилегии вплоть до администратора домена.
Чтобы лучше понять место ESC3 в цепочке атак на AD CS, сравним ее с двумя другими сценариями эскалации привилегий — ESC1 и ESC2. Все они связаны с неправильной конфигурацией шаблонов сертификатов, однако механизм и условия эксплуатации отличаются.
| Атака | Механизм эксплуатации | Условия для успешного выполнения | Результат для атакующего |
|---|---|---|---|
| ESC1 |
Имперсонация через альтернативный субъект. Злоумышленник запрашивает сертификат, указывая в поле Subject Alternative Name (SAN) идентификатор другого пользователя, например UPN администратора. CA выпускает сертификат с чужим именем |
|
|
| ESC2 |
Выдача универсального сертификата (Any Purpose). Атакующий получает сертификат на свое имя, но у шаблона EKU равен Any Purpose (OID 2.5.29.37.0) или вообще не указан (что эквивалентно subordinate CA). Такой сертификат фактически действителен для любых целей |
|
Прямой захват DA через такой сертификат неочевиден, если он не доверен в NTAuth, но можно, например, подписать токены для ADFS, подделывать сертификаты служб и т. д. |
| ESC3 |
Использование Enrollment Agent. Атака в два шага:
В итоге выпускается сертификат на чужое имя, как при делегированном выпуске |
|
|
Для эксплуатации ESC3 требуются две уязвимые конфигурации шаблонов сертификатов и определенные условия в настройках CA и AD CS.
Первый шаблон ESC3 должен соответствовать следующим условиям:
Шаблон с EKU агента регистрации. Опубликованный шаблон сертификата должен содержать EKU Certificate Request Agent (OID: 1.3.6.1.4.1.311.20.2.1). Этот EKU, известный как Enrollment Agent в терминологии Microsoft, дает владельцу выданного по шаблону сертификата право запрашивать сертификаты от имени других субъектов. Иными словами, сертификат агента регистрации позволяет его обладателю выступать доверенным посредником при выдаче сертификата другой учетной записи.
Отсутствие требований к дополнительной подписи (Authorized Signatures). Шаблону агента регистрации не должна требоваться подпись другого агента (атрибут msPKI‑RA‑Signature = 0). Проще говоря, This number of authorized signatures = 0 — никакие дополнительные подписи не нужны. Если бы требовалась хотя бы одна подпись (msPKI‑RA‑Signature ≥ 1), то получить такой сертификат без уже существующего доверенного агента было бы невозможно, что ломало бы цепочку атаки.
Утверждение менеджером отключено. Шаблон не должен требовать одобрения со стороны администратора CA: флаг CT_FLAG_PEND_ALL_REQUESTS отключен. В AD CS это отражается в атрибуте msPKI-Enrollment-Flag, у которого не установлен бит Pend all requests. Иначе все запросы по такому шаблону переходили бы в статус Pending, а автоматическая выдача сертификата без ручного утверждения была бы невозможна.
Центр сертификации настроен на автоматическую выдачу сертификатов. В параметрах модуля политики CA (вкладка Policy Module → Properties) выбрана опция Follow the settings in the certificate template... Это означает, что, если шаблон не требует одобрения администратора (флаг CT_FLAG_PEND_ALL_REQUESTS отключен), CA автоматически выпускает сертификат. В таком случае злоумышленник может завершить атаку ESC3 без участия администратора.
Права на запрос шаблона у пользователя с низкими привилегиями. Шаблон сертификата должен быть доступен для регистрации низкопривилегированному пользователю. Часто у уязвимых шаблонов слишком широкий Security Descriptor, дающий группе Domain Users или Authenticated Users право Enroll (или даже Autoenroll). Такие права у обычного пользователя — обязательное условие всех ESC‑атак. Кроме того, в ряде случаев слишком широкие права ACL могут позволить атакующему самому изменить свойства шаблона (техника ESC4), однако для ESC3 достаточно прав на регистрацию.
Отсутствие ограничений Enrollment Agent в CA. На стороне центра сертификации не должны применяться ограничения для агентов регистрации. В настройках CA (консоль
certsrv.msc→ свойства CA → вкладка Enrollment Agents) по умолчанию стоит Do not restrict enrollment agents. Если администратор не включил и не настроил ограничения, любой выданный сертификат с EKU агента регистрации может использоваться для запросов по любым шаблонам и для любых учетных записей. Это означает, что злоумышленник с сертификатом агента не ограничен в выборе цели атаки.
Второй шаблон сертификата используется агентом регистрации для запроса сертификата от имени жертвы. Он должен быть настроен аналогично первому шаблону, но при этом соответствовать следующим условиям:
EKU аутентификации. Например, Client Authentication (1.3.6.1.5.5.7.3.2) без включения EKU Certificate Request Agent.
Требование запроса от агента сертификата EKU. Во втором шаблоне эта опция должна быть включена.
Атака ESC3 развивается в два этапа. Цель пользователя hacker — выпустить себе сертификат с правами агента регистрации ESC 3:
А затем с помощью этого сертификата выпустить новый с названием ESC 3 - 2, но на имя testeradm. Рассмотрим шаги и инструменты, которые злоумышленник может применять в ходе атаки.
Злоумышленник, обладающий учетной записью в домене даже с минимальными правами, сначала регистрирует на себя сертификат ESC 3 по уязвимому шаблону. Поскольку шаблон удовлетворяет перечисленным выше условиям (нет требуемых подписей, нет одобрения, открыт для учетной записи злоумышленника), запрос выполняется автоматически — выдается сертификат с EKU 1.3.6.1.4.1.311.20.2.1, привязанный к аккаунту атакующего. Этот сертификат делает его доверенным агентом регистрации.
С помощью утилит Certify (набор GhostPack) или Certipy можно найти уязвимый шаблон с EKU Certificate Request Agent и запросить по нему сертификат.
Например, через Certify, используя команду: Certify.exe request /ca:<CA_NAME> /template:<EA_Template> /agent, <EA_Template> — имя шаблона агента.
В выводе Certify будет видно, что сертификат успешно выдан и сохранен в формате PEM с закрытым ключом:
Аналогично Certipy (Python‑реализация) позволяет выполнить команду certipy req -u <user> -p <password> -ca <CA_NAME> -template "<EA_Template>" и получить сертификат агента на текущего пользователя.
Затем злоумышленник формирует PFX‑файл (сертификат и приватный ключ):
После этого он может запросить новый сертификат ESC 3 - 2 на другого пользователя.
Получив на руки сертификат агента регистрации (PFX‑файл), атакующий использует его для подписания нового запроса от имени привилегированного пользователя. Обычно цель — учетная запись с высокими правами, например Domain Admin. Злоумышленник формирует CSR на имя этой учетной записи и совместно подписывает его своим агентским сертификатом, после чего отправляет в CA запрос по уязвимому шаблону ESC 3 - 2.
Certify.exe request /ca:<CA_NAME> /template:<User_Template>
/onbehalfof:"DOMAIN\Administrator"
/enrollmentcert:"AgentCert.pfx" /enrollmentcertpw:<pass>
Здесь с помощью /onbehalfof указывается целевая учетная запись (доменный админ), а параметры /enrollmentcert и /enrollmentcertpw задают файл и пароль ранее полученного агентского сертификата.
Certify подписывает CSR сертификатом агента и отправляет его в CA. Если настройка уязвима, CA возвращает готовый сертификат, выданный на имя администратора домена (Subject = testeradm, Issuer = корпоративный CA).
Аналогичные действия можно сделать через Certipy:
certipy req... -template "<User_Template>" -on-behalf-of 'DOMAIN\Administrator' -pfx agent.pfx
Также можно использовать штатные средства Windows, например команду certreq -submit с указанием атрибута CertificateTemplate и опцией подписания запроса с помощью Enrollment Agent сертификата. Однако этот метод сложнее автоматизировать.
Чтобы продемонстрированный метод успешно сработал, необходимо в шаблоне ESC 3 - 2 включить флаг Build from this Active Directory information, тогда информация о пользователе будет автоматически получена из AD:
Однако атаку возможно провести и при включенной опции Supply in the request. В этом случае при выполнении атаки по сценарию ESC 3 - 2 нужно указать точный UPN пользователя testeradm в запросе на сертификат, чтобы центр сертификации смог корректно сформировать subject.
На втором шаге злоумышленник фактически получает действующий аутентификационный сертификат на учетную запись жертвы. Такой сертификат (с EKU, позволяющим аутентификацию, например Client Authentication или Smart Card Logon) вместе с соответствующим закрытым ключом позволяет войти в систему от имени жертвы.
Атакующий импортирует полученный сертификат и использует его для аутентификации в домене. Практически это можно выполнить с помощью инструмента Rubeus (для Kerberos PKINIT):
Rubeus.exe asktgt /user:DOMAIN\Administrator /certificate:adminCert.pfx /password:<pfx-password>
Эта команда инициирует PKINIT‑аутентификацию в AD с предъявлением сертификата администратора. В результате этого возвращается TGT на имя администратора. Получив TGT привилегированной учетной записи, злоумышленник может действовать в сети с полными правами этой учетной записи, например выполнять DCsync. Иными словами, происходит компрометация учетной записи доменного администратора.
После второго этапа CA считает запрос легитимным, так как он подписан доверенным агентом. В журнале CA фиксируется выдача сертификата для Admin, запрошенного от имени агента. В процессе атаки ESC3 злоумышленник проходит путь: обычный пользователь → агент регистрации → сертификат администратора домена → полные права администратора домена. Несмотря на то что часто двухэтапные атаки работают только в теории, ESC3 остается практически выполнимой и открывает все двери при наличии уязвимых шаблонов.
Обнаружить использование техники ESC3 можно, коррелируя события аудита службы сертификации и анализируя несоответствия между субъектом сертификата и инициатором запроса. В Windows Server при включенном аудите AD CS регистрируются следующие ключевые события безопасности:
Event ID 4898 — Certificate Services loaded a template. Событие, которое логирует, какой шаблон загрузил CA для обработки нового запросa. В поле Template Information содержатся детали: флаги шаблона, EKU, требуемые подписи и т. п. При эксплуатации техники ESC3 обычно фиксируется загрузка сначала шаблона агента регистрации (этап 1), а затем — шаблона пользовательского сертификата (этап 2), так как это событие появляется, только когда происходит обращение к шаблонам.
Вот пример с шаблоном ESC 3. Видно, что у него нет никаких ограничений и есть права на агента регистрации:
На примере с шаблоном ESC 3 - 2 можно увидеть, что в системе есть шаблон, который требует согласия агента сертификатов и доступен для аутентификации всем клиентам в домене:
Дополнительно можно проверить, какие права и у кого есть в этих шаблонах. Если там окажутся непривилегированные пользователи, это должно насторожить:
Подробнее о событии 4898 читайте в справочных материалах.
Event ID 4899 — Certificate Services template was updated. Это событие срабатывает, когда изменяются свойства шаблона сертификата (в AD‑хранилище) и CA их подгружает. Само по себе 4899 не указывает на атаку, но важно для обнаружения изменения конфигураций. Например, злоумышленник мог изменить шаблон перед атакой (техника ESC4).
В контексте ESC3 4899 поможет, если администраторы будут отслеживать включение и выключение флагов шаблонов, добавление EKU, изменение ACL и т. п. Например, изменение атрибута msPKI‑RA‑Signature или EKU шаблона, как и изменение прав доступа (WriteACL) на шаблон, вызовет событие 4899. Однако есть проблемы: Windows не всегда генерирует 4899 корректно при каждом изменении, поэтому надежнее параллельно включить аудит изменения объектов AD.
Event ID 5136 — Directory Service Changes. Аудит изменений в AD. Шаблоны сертификатов хранятся в контейнере
CN=Certificate Templates,CN=Public Key Services,...в AD, поэтому событие 5136 с CN шаблона покажут, какие атрибуты менялись и кем. Например, если кто‑то отключил флаг CT_FLAG_PEND_ALL_REQUESTS или добавил EKU 1.3.6.1.4.1.311.20.2.1 в шаблон, это будет видно в деталях 5136. Это событие полезно для превентивного выявления опасных изменений, особенно если внезапно Domain Users получили право Enroll на чувствительный шаблон или ограничения снялись. Рекомендуется на уровне SIEM‑аналитики настроить оповещения об изменении критичных атрибутов шаблонов (msPKI-*, flags, nTSecurityDescriptor) и о появлении в DACL определенных групп.
- Найти событие 4887 выпуска сертификата, где Subject DN не содержит имя учетной записи Requester. Зафиксировать Request ID и имена.
- Проверить, были ли незадолго до этого события 4898 или 4886 с тем же Request ID или тем же Requester, указывающие на шаблон с Certificate Request Agent EKU.
- Убедиться, что целевой шаблон (из 4887 — поле Certificate Template) требует подписи агента или содержит RA EKU (это можно увидеть в сообщении 4898, предшествующем выдаче).
- Проверить, сходятся ли эти условия. Если да, то с большой вероятностью имела место атака ESC3.
Атаку ESC3 можно попытаться предотвратить, найдя и устранив опасные шаблоны сертификатов еще до того, как ими воспользуются.
В отличие от события 4898, когда шаблон сертификатов добавляется в центр сертификации, информация о созданном шаблоне хранится в ветке реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\CertificateTemplateCache. В этом разделе находятся все шаблоны, подробно о нем читайте в справочных материалах.
На следующем скриншоте — раздел реестра, содержащий шаблон ESC 3:
Нас интересуют следующие критические параметры:
- msPKI‑Enrollment‑Flag = 0x00000009. Флаг CT_FLAG_PEND_ALL_REQUESTS не установлен — это означает, что шаблону не требуется одобрение администратора CA. Это обязательное условие для автоматического выпуска сертификата.
- msPKI‑RA‑Signature = 0. Подпись другого агента не требуется.
- msPKI‑Certificate‑Application‑Policy содержит EKU 1.3.6.1.4.1.311.20.2.1. Это EKU для агента регистрации.
- Установлен флаг CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT = 1. В сертификате можно указать произвольный субъект.
Таким образом, можно считать, что этот шаблон удовлетворяет первому условию атаки ESC3: злоумышленник может получить сертификат агента регистрации без участия администратора или другого агента.
Однако в реестре нет информации о том, кто именно имеет права на регистрацию по этому шаблону. Эти данные есть в Active Directory, и получить их можно через PowerShell командой:
Get-ADObject -LDAPFilter "(cn=ESC3)" ` -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" ` -Properties nTSecurityDescriptor | Select-Object -ExpandProperty nTSecurityDescriptor | Select-Object -ExpandProperty Sddl
На выходе мы получаем список SID и GUID, которым предоставлены права. Вот пример вывода:
Обращайте внимание на строки, содержащие GUID 0e10c968-78fb-11d2-90d4-00c04f79dc55, — это разрешение Enroll. Если, например, в этих строках указаны группы Domain Users или Authenticated Users, это означает, что широкий круг пользователей может запрашивать сертификаты по этому шаблону.
Такие группы в списке прав — признак потенциальной уязвимости. Хотя подобная конфигурация может использоваться по умолчанию, ее следует считать небезопасной практикой.
Подробный разбор дескриптора безопасности читайте в справочных материалах.
Этот способ выявления можно автоматизировать, например, с помощью BI.ZONE EDR.
В Windows при любом изменении или создании шаблона сертификата (даже без его непосредственного использования или перезапуска службы CA) информация об этом автоматически сохраняется в реестре по пути HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\CertificateTemplateCache\<CertificateTemplateName>\:
Здесь хранится вся необходимая информация о шаблонах. Однако дескрипторы безопасности (SDDL) хранятся в закодированном виде и напрямую не читаются.
BI.ZONE EDR решает эту проблему следующим образом:
- Агенты EDR, установленные на хостах, собирают данные об изменениях в шаблонах сертификатов в реальном времени.
- При обнаружении изменений по указанному пути BI.ZONE EDR автоматически извлекает и расшифровывает дескрипторы безопасности, после чего эти данные собираются на анализ предикт‑правилом.
Вот как в интерфейсе BI.ZONE EDR выглядит срабатывание предикт‑правила обнаружения уязвимых шаблонов сертификатов (техника ESC3) по событию обращения к шаблону:
А это пример предикт‑правила для обнаружения уязвимых шаблонов сертификатов (ESC3):
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 "1.3.6.1.4.1.311.20.2.1"Это правило позволяет в режиме постоянного мониторинга обнаруживать все сертификатные шаблоны, которые одновременно:
- содержат EKU агента регистрации — 1.3.6.1.4.1.311.20.2.1 (Enrollment Agent);
- не требуют авторизованной подписи — msPKI‑RA‑Signature = 0;
- не требуют одобрения менеджером — флаг CT_FLAG_PEND_ALL_REQUESTS не установлен;
- доступны для регистрации группам Domain Users, Authenticated Users или всем (WD) — проверяется по SDDL с правами на Enroll (0e10c968-78fb‑11d2‑90d4‑00c04f79dc55).
То есть любой низкопривилегированный пользователь может запросить сертификат агента регистрации, а затем от его имени выпустить сертификат на любую цель в домене. Это путь к полноценной реализации атаки ESC3.
В дополнение к предиктивному подходу BI.ZONE EDR детектирует ESC3 и другие атаки на основе корреляционной логики. Таким образом решение обеспечивает комплексную защиту от атак на центр сертификации Active Directory.
Для предотвращения атак типа ESC3 усильте настройки AD CS с помощью следующих мер:
- Ограничьте права на уязвимые шаблоны. Шаблоны сертификатов, содержащие EKU Certificate Request Agent или иные высокорисковые комбинации, не должны быть доступны всем пользователям. Выдайте права Enroll только строго ограниченному списку администраторов или сервисных учетных записей, которым действительно нужна функциональность Enrollment Agent. Например, дефолтный шаблон Enrollment Agent (User) после установки CA не публикуется. Если вы дублируете его для использования, убедитесь, что доступ к нему есть лишь у специальной группы (и, возможно, включено ручное утверждение). Удалите из ACL шаблона группы Domain Users и Authenticated Users, если они там присутствуют, либо смените права Enroll на Deny для этих групп. Практика показывает: если администраторы по неосторожности дали Domain Users право Enroll для шаблона агента, можно считать, что игра проиграна — такая конфигурация однозначно ведет к компрометации с минимальными усилиями для атакующего.
- Включите CT_FLAG_PEND_ALL_REQUESTS для чувствительных шаблонов. Настройте в свойствах шаблона во вкладке Issuance Requirements опцию CA certificate manager approval для всех шаблонов, выдача по которым может повлечь эскалацию привилегий. Это добавляет ручной этап: даже если злоумышленник инициирует запрос, сертификат не будет выдан автоматически, пока администратор CA не проверит и не одобрит его. Конечно, для всего без исключения включать одобрение неудобно, но для шаблонов Enrollment Agent и любых, где возможна выдача сертификата, эквивалентного доменному входу (Smart Card, User с ClientAuth), менеджерское одобрение — это мощная защита. Если же такие шаблоны не нужны, их лучше вовсе не публиковать.
- Включите ограничение Enrollment Agents на CA. На уровне CA включите режим Restrict Enrollment Agents и задайте допустимые сочетания: агент → шаблон → заявитель. В настройках CA (вкладка Enrollment Agents) можно указать, какие пользователи или группы имеют право быть агентами, для каких шаблонов они могут подавать запросы и на каких пользователей. По умолчанию эта функция отключена (всем агентам все разрешено), а при включении без настройки действует крайне либеральная политика (Everyone на All Templates). Поэтому включите и настройте функцию, например добавьте конкретную учетную запись или группу в Enrollment Agents, ограничьте Certificate Templates списком конкретных разрешенных шаблонов, а поле Permitted accounts — перечнем OU или групп, для пользователей из которых можно выпускать сертификаты. Это предотвратит использование агента вне регламентированных случаев.
- Проведите аудит и мониторинг событий AD CS. Настройте аудит, как было описано в разделе «Обнаружение атаки»: собирайте события 4898, 4887, 4886, 4899 и другие в SIEM. В случае с ESC3 атакующий, как правило, оставляет следы, которые легко заметить задним числом: сертификат на имя администратора, выданный по пользовательскому шаблону, но с другим Requester, или аномалии в запросах.
- Используйте специализированные инструменты аудита. Компания SpecterOps выпустила PowerShell‑модуль PSPKIAudit
для проактивного поиска уязвимостей AD CS. Он базируется на библиотеке PSPKI от PKI Solutions и способен выявлять все известные сценарии ESC, включая ESC3. Запустив команду аудита (например, Invoke-PKIAudit), администратор получит отчет о шаблонах с опасными настройками. Рекомендуется включить такие проверки в регулярные процедуры безопасности. Также полезны утилиты Certipy (certipy find) и скрипты от сторонних разработчиков (например, ADCSExplorer от PKISolutions) для проверки PKI‑инфраструктуры на неправильные конфигурации.
Обобщая вышесказанное: уберите ненужное, ограничьте нужное, контролируйте остальное. Лучше предотвратить атаку, не допуская ситуаций, при которых обычный пользователь может получить сертификат на чужое имя. Это достигается комбинацией настроек шаблонов и политики CA.
Техника ESC3 демонстрирует, как несколько, казалось бы, несерьезных упущений в настройке PKI (неограниченный шаблон агента + открытые права + отсутствие ограничений) приводят к полной компрометации домена. По сути, атакующий получает возможность сделать то, на что способен только администратор CA или уполномоченный регистратор: выпускать от имени других лиц сертификаты, признаваемые доменом. Такой вектор атаки делает неэффективными многие традиционные средства защиты: он эксплуатирует доверенную инфраструктуру безопасности (PKI) для вредоносных целей.
Чтобы отличить ESC3 от ESC2, нужно ориентироваться на Extended Key Usage. При ESC3 фигурирует EKU Certificate Request Agent (OID 1.3.6.1.4.1.311.20.2.1) и связанная с ним логика on behalf of. Техника ESC2 же связана с EKU Any Purpose (OID 2.5.29.37.0) или отсутствием EKU (субъект — подчиненный CA). Проще говоря, ESC2 — это когда шаблон выдает сертификат на все случаи жизни, а ESC3 — когда шаблон позволяет выдать себя за кого‑то другого. Также атака ESC3 всегда состоит из двух шагов (сначала агент, потом цель), тогда как ESC1/ESC2 — из одного. В логах ESC3 заметно участие политики Certificate Request Agent (например, Authorized Signatures Required = 1), чего нет в ESC2.
Атака ESC3 подчеркивает необходимость внимательного отношения к настройкам AD CS. Реализуйте принцип минимальных привилегий и для PKI: права выдачи сертификатов — минимально необходимые, опасные функции — под контролем. Соблюдение этих правил и мониторинг аномалий (например, выпуск сертификата одним пользователем на имя другого) позволят защититься от ESC3 и подобных ей атак.