ESC7. Manage CA как ключ к Active Directory
ESC7 — это атака на Active Directory Certificate Services (AD CS), при которой злоумышленник с низкими привилегиями может получить полный контроль над центром сертификации за счет неправильно настроенных прав доступа. Ключевую роль в этой технике играют два специальных разрешения в безопасности AD CS:
- Manage CA (управление CA). Обладатель этого права получает возможность выполнять административные действия в CA: менять настройки центра сертификации, запускать или останавливать службу и т. д. Например, злоумышленник может включить флаг User Specified SAN (
EDITF_ATTRIBUTESUBJECTALTNAME2) и разрешить указание альтернативного имени субъекта (SAN) в запросах на сертификат. Это изменение позволяет запросить сертификат, удостоверяющий любую учетную запись, что фактически ведет к полной компрометации домена (именно так реализуется атака ESC6). Таким образом, Manage CA позволяет включить уязвимые настройки, эксплуатируемые в атаках через подделку SAN: ESC1 и ESC6. - Manage Certificates (управление сертификатами). Это право менее опасно само по себе. Его обладателя называют Certificate Manager, он может одобрять или отклонять запросы на сертификат, находящиеся в ожидании (Pending Requests). По умолчанию такие запросы требуют действия от администратора, но злоумышленник с правом Manage Certificates способен обойти требование ручного утверждения и выпустить сертификаты по своему усмотрению. Само по себе это не даст ему прав администратора домена, однако в комбинации с другими действиями, например созданием запроса от имени привилегированного пользователя, разрешение Manage Certificates позволяет завершить атаку.
Иными словами, техника ESC7 эксплуатирует ситуацию, когда у злоумышленника появляются административные полномочия в службах сертификации без полноценного статуса администратора домена. В результате атакующий способен выпускать поддельные сертификаты от имени любого пользователя (включая администратора), отменять механизмы проверки, компрометировать цепочку доверия и тем самым нарушать безопасность всей среды Active Directory. Такая атака часто остается незамеченной, ведь злоумышленник использует легитимную функцию инфраструктуры, а не запускает вредоносный код на контроллере домена.
Для эксплуатации техники ESC7 необходим ряд условий:
- Права Manage CA и Manage Certificates у атакующего.
- Конфигурация AD CS, допускающая удаленное администрирование.
- Доступность шаблонов сертификатов для использования прав.
- Отсутствие мониторинга в реальном времени.
Это главное условие для реализации ESC7. Атакующему недостаточно быть обычным доменным пользователем: необходимы разрешения Manage CA и Manage Certificates или хотя бы Manage CA с возможностью эскалации до Manage Certificates.
В безопасной конфигурации эти права есть только у администраторов PKI, например у группы Enterprise Admins, Domain Admins или выделенных операторов центра сертификации. Однако на практике встречаются опасные отклонения от нормы, например когда учетная запись или группа включена в ACL CA с этими правами.
Пример
В ходе red team — оценки специалисты Tarlogic обнаружили
Используя такие права, злоумышленник мог бы включить расширение SAN для всех шаблонов сертификатов, управляемых этим CA. Это позволяло запрашивать сертификаты, связанные с дополнительными идентификационными данными, что критически важно для атаки ESC1. Включение этой функции на уровне CA делало расширение доступным для всех шаблонов, даже если они не использовали его по отдельности, что позволяло проводить атаку ESC6.
Этот случай подчеркнул, как важно строго контролировать права доступа в AD CS и проводить регулярный аудит настроек безопасности, чтобы предотвращать подобные уязвимости. Если бы это оказались не специалисты red team, а злоумышленники, последствия были бы тяжелыми.
Такая конфигурация состоит в следующем:
- В организации развернут Enterprise CA (удостоверяющий центр, интегрированный с AD). Именно в таких системах действуют упомянутые разрешения и шаблоны сертификатов.
- ACL на объекте CA или в его реестре сконфигурирован неправильно и допускает лишних пользователей. Обычно компрометирующие права появляются либо из‑за человеческой ошибки (неверно выданные полномочия на уровне свойств CA), либо при использовании слишком широких групп в местных группах безопасности CA. Например, если локальная группа сервера CA Certificate Services DCOM Access включает в себя Authenticated Users или Domain Users, любая прошедшая аутентификацию учетная запись может удаленно подключаться к интерфейсу DCOM (Distributed COM) службы сертификации. В сочетании с неправильным ACL на самом CA это довольно опасно, поскольку злоумышленник сможет установить связь с CA и выполнить административные вызовы удаленно.
- Удаленный интерфейс управления AD CS доступен через DCOM. AD CS предоставляет этот интерфейс «из коробки» (по умолчанию) через RPC/DCOM, и он не всегда блокируется в организациях. Это означает, что злоумышленнику не нужно иметь интерактивный доступ к серверу сертификации (например, через RDP). Достаточно, чтобы сервер CA был доступен по сети и не фильтровал RPC‑порты. Используя DCOM‑интерфейс, такой как ICertAdmin, злоумышленник может удаленно вызывать методы управления CA, например изменять шаблоны сертификатов или подписывать запросы.
Вот настройки по умолчанию, облегчающие атаку ESC7:
- DCOM в Windows включен;
- серверы CA не изолированы на сетевом уровне;
- RPC‑трафик, используемый DCOM, часто разрешен внутри корпоративных сетей.
Поэтому в типичной среде, если у злоумышленника есть права Manage CA, а сетевые фильтры не мешают, он может провести атаку полностью удаленно, без заметного присутствия на сервере. В стандартной установке Enterprise CA это происходит так: служба сертификации регистрирует DCOM‑класс и локальную группу CertSVC_DCOM_ACCESS. Если эта группа содержит пользователей домена (например, Authenticated Users), они могут удаленно вызывать COM‑интерфейсы CA.
Должен существовать хотя бы один шаблон, который можно использовать для эскалации привилегий.
Обычно нужен опубликованный шаблон, позволяющий аутентификацию (Client Authentication) и доступный для регистрации (Enrollment) низкопривилегированному пользователю. Без такого шаблона, даже обладая правами на управление CA, злоумышленник не сможет выдать для себя сертификат.
В большинстве доменов шаблоны пользовательских сертификатов (например, User) доступны для регистрации всем доменным пользователям. Если такой шаблон позволяет аутентификацию (например, имеет флаг Client Authentication), злоумышленник сможет использовать его для выпуска сертификата от имени любого пользователя. Этого достаточно для выполнения атаки даже без дополнительных привилегий.
Хотя это не строгое техническое условие, но успех атаки зависит от того, заметят ли администраторы подозрительные изменения. Если аудит отключен или никто не следит за журналами, шанс незаметно провести ESC7 существенно возрастает.
Если все условия сходятся, злоумышленник получает идеальную точку опоры: у него есть инструменты (права на CA) и возможности (доступ через DCOM) для тихой подрывной активности внутри AD CS.
Рассмотрим пошагово, как злоумышленник может эксплуатировать технику ESC7. Предположим, что он уже получил учетную запись, входящую в группу с правами Manage CA и Manage Certificates в интересующем его удостоверяющем центре, — например, через перебор паролей, фишинг или ранее выполненную атаку.
Атакующий убеждается, что у него действительно есть нужные права в CA. Для этого он может использовать утилиту certutil или специализированные инструменты (например, Certifycertutil -getreg CA\Security он может локально (или удаленно с параметром -config <CA>) прочитать ACL центра сертификации из реестра.
Вывод покажет список учетных записей и групп с их разрешениями. В норме там должны быть только администраторы. Если же в списке присутствует, допустим, NT AUTHORITY\Authenticated Users с дополнительными правами, помимо Enroll, — это явный индикатор уязвимости.
Вот результат выполнения команды certutil -getreg CA\Security, которая извлекает список прав доступа (ACL) к центру сертификации:
Видно, что, кроме групп Domain Admins, Enterprise Admins и Administrators, разрешения уровня CA Administrator Certificate Manager и Certificate Manager есть также у обычных пользователей, например GOOD\testeradm и Authenticated Users. Это указывает на потенциальную уязвимость к ESC7: злоумышленник с такими правами может управлять запросами или изменить конфигурацию CA, открыв путь к другим атакам.
Кроме certutil, существуют PowerShell-скрипты для инвентаризации прав. Например, модуль PSPKI предоставляет командлет Get-CertificationAuthorityAcl, который выводит разрешения на указанный CA в читабельном виде. Инструменты вроде Certify от SpecterOps также автоматически сканируют известные векторы атаки на AD CS. В отчете Certify уязвимость ESC7 обычно помечается, если обнаружены лишние права Manage CA и Manage Certificates.
Убедившись, что у него есть нужные полномочия, злоумышленник переходит к активной фазе атаки.
Атакующий может изменить настройки CA в своих целях, если у него есть права Manage CA:
Типичный подход заключается в активации опции, разрешающей использовать SAN для любых сертификатов, выдаваемых этим центром сертификации.
Обычно параметр EDITF_ATTRIBUTESUBJECTALTNAME2 (в реестре это значение EditFlags) отключен или равен 0, если администратор явно не разрешил SAN. Злоумышленник устанавливает этот параметр в активное состояние, равное 1. Теперь можно запрашивать сертификаты
Технически это можно сделать через интерфейс ICertAdmin2 с помощью метода SetConfigEntry. Вот как это упрощенно выглядит в коде:
objCertAdmin.SetConfigEntry(
"GOODEX-SERVER.GOOD.EXPERT\\GOOD-GOODEX-SERVER-CA-1",
@"PolicyModules\CertificateAuthority_MicrosoftDefault.Policy",
"EditFlags",
новое_значение); // новое_значение
Новое_значение — это текущее значение параметра EditFlags с добавленным битом 0×00040000, который разрешает SAN. Благодаря этому при побитовом сравнении результат будет истинным.
Также процесс активации этой опции можно легко автоматизировать с помощью популярного инструмента Certify.
Таким образом, злоумышленнику даже не нужен прямой доступ к серверу CA: достаточно удаленного доступа через DCOM и наличия соответствующих прав.
Альтернативный вариант использования Manage CA
Злоумышленник также может изменить настройки безопасности самого CA, например добавить себе еще больше прав.
Если у атакующего есть только право Manage CA, этого достаточно, чтобы получить и разрешение Manage Certificates.
С правом Manage CA он может изменить настройки центра сертификации, включая список тех, кто считается менеджером сертификатов (Certificate Manager).
Технически это делается так:
- Атакующий редактирует ACL центра сертификации, например, через утилиту certutil, Certify или ADSI Editor.
- В конфигурацию CA добавляется нужный SID пользователя (или группы) с разрешением Issue and Manage Certificates.
- Эти изменения сохраняются в реестре в разделе
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration<Имя_CA>\Security.
Таким образом, даже если у злоумышленника не было нужных прав изначально, он назначает их себе сам. Это и есть одна из ключевых опасностей ESC7: обладатель разрешения Manage CA может эскалировать себе остальные критичные права, открывая путь к полной компрометации CA. Например, на скриншоте ниже показаны права пользователя GOODUSER в центре сертификации.
Здесь:
- Read — право чтения информации о CA.
- Issue and Manage Certificates — право на выдачу и управление сертификатами (подтверждение и отклонение запросов на сертификаты других пользователей).
- Manage CA — право управления настройками самого центра сертификации, позволяющее изменять конфигурацию и политики CA. Это наиболее критичное право с точки зрения безопасности, так как позволяет проводить атаку ESC7.
- Request Certificates — право запрашивать сертификаты для собственной учетной записи.
После изменения настроек CA наступает ключевой момент: злоумышленник получает привилегированный сертификат. В зависимости от ситуации, он может сделать это разными путями. Рассмотрим два наиболее распространенных сценария:
- Атака через пользовательский сертификат с SAN.
- Атака через привилегированный шаблон (SubCA, Domain Controller).
Сценарий 1. Атака через пользовательский сертификат с SAN
Этот сценарий прямо следует из включения флага SAN. Атакующий ищет в каталоге опубликованных шаблонов сертификатов шаблон, который:
- имеет назначение для аутентификации пользователей (EKU содержит Client Authentication или смежные цели);
- не требует одобрения менеджера (то есть запросы по нему автоматически выпускает CA);
- доступен для регистрации низкопривилегированным пользователям.
В домене по умолчанию часто есть пользовательский шаблон User или User Authentication, для которого у группы Domain Users есть право Auto‑enroll. Обычно, когда пользователь запрашивает по нему сертификат, CA сам подставляет в сертификат имя этого пользователя (субъекта) и его UPN, не позволяя указывать чужие данные.
Однако благодаря включенному флагу SAN злоумышленник может при запросе подменить UPN на учетную запись жертвы. Например, он формирует запрос на сертификат, где в поле Subject Alternative Name прописан UPN администратора домена Admin@domain.local.
Проверить, включен ли SAN на хосте, можно командой:
certutil -getreg "CA\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditFlags"
А командой certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 можно добавить или удалить (-) этот флаг.
После включения поддержки SAN атакующий может отправить специально сформированный запрос на сертификат, в котором укажет чужой UPN, например UPN администратора домена.
Сделать это можно разными способами. Один из самых простых — использовать certreq. Для этого можно создать INF‑файл с нужными параметрами либо сразу выполнить команду:
certreq -submit -attrib "CertificateTemplate:ESC7 SAN:upn=Administrator@domain.local" -config "<CA_Server>\<CA_Name>" request.inf
Здесь:
CertificateTemplate:ESC7— пример имени шаблона сертификата, который доступен обычным пользователям.SAN:upn=Administrator@domain.local— альтернативное имя, подставляемое в расширение SAN сертификата.
Такой запрос будет принят и обработан, потому что злоумышленник включил возможность указывать SAN на уровне центра сертификации (через EditFlags). CA не проверит, чей это UPN, и просто впишет его в сертификат.
Если шаблон не требует ручного одобрения (то есть работает в режиме автовыдачи), сертификат будет выпущен сразу.
В результате атакующий получит действительный сертификат, в котором фигурирует UPN администратора. С точки зрения контроллера домена это легитимный сертификат для входа в AD.
Этот сертификат можно затем экспортировать с закрытым ключом, например, в PFX‑формате и использовать для аутентификации от имени администратора.
Сценарий 2. Атака через привилегированный шаблон (SubCA, Domain Controller)
Перед тем как перейти к описанию этой атаки, важно разобрать, что такое подчиненный управляющий центр (Subordinate CA).
Кратко о Subordinate CA
Подчиненный CA, или Subordinate CA, — это центр сертификации, чей сертификат подписан доверенным корневым CA (Root CA).
Root CA доверяет Subordinate CA. И если злоумышленнику удается завладеть сертификатом такого подчиненного CA, он может самостоятельно выпускать сертификаты с любыми атрибутами, например:
CN=AdministratorилиSAN=admin@domain.local— для входа в домен от имени любого пользователя;CN=DC01$(DC‑auth) — для Kerberos-аутентификации и имитации контроллера домена.
Вся инфраструктура Active Directory будет принимать эти сертификаты как доверенные, так как цепочка подписей ведет к Root CA.
Это все равно что выдать злоумышленнику удостоверение личности администратора, в подлинности которого никто не усомнится, ведь оно подписано настоящей организацией.
Получив сертификат Subordinate CA, злоумышленник становится внештатным администратором PKI. Он выходит за рамки обычной учетной записи и получает полный контроль над доверием внутри AD.
В некоторых случаях злоумышленник может использовать права Manage Certificates, чтобы принудительно выдать себе сертификат по шаблону, который обычно ему недоступен. Например, шаблон Subordinate CA по умолчанию разрешен только Enterprise Admins, а выпуск по нему обычно требует ручного утверждения:
У атакующего, конечно, нет таких прав, но он может пойти по следующему пути:
- Включить или опубликовать через Manage CA шаблон, если он был неактивен, или снять флаг, требующий одобрения менеджера, на шаблоне, если такой стоит. Например, он может проверить, есть ли у учетной записи
testeradmтакие права, с помощью командыcertify.exe cas /ca:"CA_SERVER\CA_NAME" /showAllPermissions.В выводе атакующий ищет свою учетную запись, например:Identity: DOMAIN\username Rights : ManageCertificates, Enroll
- Сформировать запрос на сертификат по этому шаблону. Например, злоумышленник создает INF‑файл
subca.inf, чтобы описать параметры сертификата.Атакующий генерирует запрос:[Version] Signature="$Windows NT$" [NewRequest] Subject = "CN=MaliciousSubCA" KeyLength = 2048 KeySpec = 2 Exportable = TRUE MachineKeySet = TRUE RequestType = PKCS10 ProviderName = "Microsoft Strong Cryptographic Provider" [Extensions] 2.5.29.19 = AwIB/w== ; BasicConstraints: CA=TRUE
И отправляет его:certreq -new subca.inf subca.req
Здесь используется право Enroll — без него нельзя отправить запрос: он уходит в статус Pending, так как шаблон требует одобрения вручную (CA не выдаст его автоматически обычному пользователю). С разрешением Manage Certificates злоумышленник видит этот pending request и одобряет его вручную.certreq -submit -attrib "CertificateTemplate:SubCA" -config "CA_SERVER\CA_NAME" subca.req subca.cer
- Вручную одобрить pending request благодаря Manage Certificates. Это можно сделать с помощью утилит либо стандартно через консоль
certsrv.msc(в случае интерактивного входа). Например, в Certipy есть команда для выпуска по ID заявки:certipy ca issue -target <CA_FQDN> -id <RequestID> -u <DOMAIN\username> -p <PASSWORD>.
После одобрения запроса корпоративный CA выпускает привилегированный сертификат, например:
- по пользовательскому шаблону с SAN:
Administrator@domain.local— сертификат для логина от имени администратора; - по шаблону SubCA — сертификат подчиненного центра сертификации;
- по шаблону DomainControllerAuthentication — сертификат, дающий Kerberos-доступ от имени контроллера домена.
Во всех случаях результат один — злоумышленник получает сертификат, который позволяет ему:
- аутентифицироваться в AD;
- эскалировать привилегии до уровня Domain Admin;
- действовать незаметно, без ввода пароля, без вызова подозрительных логов входа.
Вот чего достигает злоумышленник, используя разные сценарии и шаблоны:
| Сценарий | Тип шаблона | Результат |
|---|---|---|
| Kerberos через SAN |
Пользовательский шаблон с |
Самый тихий путь. Через PKINIT можно аутентифицироваться в AD как любой пользователь, в том числе Domain Admin, просто зная его имя |
| Subordinate CA |
SubCA |
Злоумышленник разворачивает фальшивый центр сертификации, подписанный доверенным корневым CA. Он может выдавать любые сертификаты кому угодно, в том числе себе самому или другому злоумышленнику. Это оружие массового поражения |
| DC-auth |
DomainControllerAuthentication |
Атакующий может получить сертификат, позволяющий аутентифицироваться в AD (через SAN/PKINIT), выдавать себе TGT от имени контроллера домена (через шаблон DomainControllerAuthentication) или даже развернуть фальшивый подчиненный CA, подписанный доверенным корнем, тем самым создавая любые сертификаты по своему усмотрению |
Комбинирование атак
Оба пути (через SubCA или через обычный шаблон) могут объединяться в более сложные сценарии.
Например, сначала злоумышленник получает SubCA, а затем сам себе выпускает сертификаты по нужным шаблонам в обход всей инфраструктуры безопасности. Или наоборот — сразу подает запрос с нужным SAN и получает доступ «в лоб», если шаблон позволяет.
Чаще всего в реальности фиксируются именно простые SAN‑атаки (ESC1, ESC6), поскольку они тихие, не требуют развертывания фальшивого CA и быстро приводят к компрометации.
Но когда в руках злоумышленника оказывается SubCA, у него буквально появляется собственная PKI‑фабрика внутри AD — и последствия этого трудно переоценить.
Получив на руки файл с выданным сертификатом и приватным ключом, атакующий переходит к завершающему действию — использует сертификат для получения полного доступа.
Пользовательский сертификат
Если был выдан пользовательский сертификат администратора, атакующий может применить его для аутентификации в домене от имени этого администратора. Active Directory поддерживает смарт-карты и Kerberos PKINIT, что позволяет предъявить сертификат вместо пароля.
Злоумышленник импортирует сертификат в свое хранилище и либо осуществляет RDP‑вход как Admin (если инфраструктура допускает вход по смарт-картам), либо запрашивает Kerberos TGT у KDC с помощью этого сертификата (более универсальный метод). Существуют инструменты (например, Rubeus или модуль Get‑TGT в Certipy), позволяющие отправить на контроллер домена запрос на тикет Kerberos с использованием сертификата вместо пароля. Контроллер проверяет подпись сертификата, удостоверяется, что он выпущен доверенным центром и содержит UPN admin@domain, и выдает TGT на имя администратора. Таким образом, злоумышленник получает полноценный Kerberos-тикет привилегированной учетной записи и может выполнять любые действия в домене с правами администратора.
Сертификат Subordinate CA
Если же был получен сертификат подчиненного CA, атакующий фактически становится PKI‑администратором: он может самостоятельно выпустить себе сертификат на администратора (уже своим CA) или на контроллер домена, а затем импортировать его в AD или использовать аналогично для Kerberos. Здесь вариантов множество: имея свой доверенный центр, злоумышленник выходит за рамки одной учетной записи — это компрометация всего доверенного хранилища.
Резюмируем ход атаки ESC7:
- Злоумышленник находит уязвимый CA и убеждается в наличии прав Manage CA и Manage Certificates.
- С помощью этих прав он удаленно меняет критичные настройки CA, например включает глобальный SAN.
- Использует полученные возможности для запроса и выпуска сертификата на чужое имя (администратора или сервисное), обходя ограничения шаблонов и политики выдачи.
- Завладевает выпущенным сертификатом и применяет его для входа в систему от имени привилегированного пользователя, захватывая контроллер домена или другие критичные узлы.
- Добивается полной компрометации AD или сохраняет бэкдор-доступ через выданные сертификаты.
Поскольку злоумышленник не использует явный эксплоит и его действия маскируются под легитимную активность администратора AD CS, обнаружить атаку ESC7 непросто. Однако внимательный анализ журналов безопасности и конфигурации может выявить признаки атаки. Рассмотрим, какие маркеры могут указывать на попытку или факт компрометации центра сертификации.
AD CS при включенном аудите генерирует ряд событий в журнале Security.
Event ID 4882. The security permissions for Certificate Services changed
Это самый важный индикатор — событие с сообщением The security permissions for Certificate Services changed («Изменены разрешения безопасности службы сертификации»). Появление такого события означает, что ACL CA был изменен (например, добавлен новый администратор CA или выданы права Certificate Manager). В штатной работе это происходит крайне редко.
Когда внезапно фиксируется 4882 — это повод немедленно проверить, кто и какие права изменил. А если в списке появился обычный пользователь с высокопривилегированными правами, это должно насторожить.
Например, на скриншоте видно, что у всех авторизованных пользователей в домене есть:
- CA Administrator — административные права над центром сертификации;
- Certificate Manager — права менеджера центра сертификации;
- Enroll — права, которые позволяют выпускать сертификаты.
Event ID 4890. Certificate manager settings changed
Изменение настроек менеджеров сертификатов. Событие может свидетельствовать, что кто‑то отключил требование одобрения или изменил список ответственных за определенные шаблоны (злоумышленник мог сделать это для упрощения атаки).
На скриншоте видно, что поле Enable принимает значение Yes. Это значит, ограничение менеджеров сертификатов (Restrict certificate managers) включено. Но в списке есть группа Everyone (значение поля Allow), и это:
- аннулирует саму идею ограничения;
- позволяет любому пользователю в домене (включая обычных) участвовать в процессе одобрения и отклонения заявок.
При этом также присутствует пользователь GOOD\testeradm, и, судя по повторяющимся строкам, настройки вносились вручную или программно несколько раз.
Если шаблон требует ручного утверждения (например, SubCA, Domain Controller Auth), то любой член группы Everyone сможет подтвердить заявку. Это типичный обход защиты через слабую настройку, он часто используется в реальных атаках (например, комбинируется с ESC1 или ESC13).
Event ID 4891. A configuration entry changed in Certificate Services
Изменение конфигурационного параметра CA. Это событие вызывает включение флага SAN или других параметров через Manage CA. В тексте события обычно указывается, какой именно узел и параметр изменены (например, EditFlags).
На скриншоте видно следующие данные:
| Поле | Значение |
|---|---|
| Node |
PolicyModules\CertificateAuthority_MicrosoftDefault.Policy |
| Entry |
RequestDisposition |
| Value |
1 |
| Компьютер |
GOODEX-SERVER.GOOD.EXPERT |
Параметр RequestDisposition равен 1 — это говорит об автоматической выдаче сертификатов без проверки. То есть любые заявки, поступившие в CA (в том числе с подставленным Subject, SAN, EKU и т. п.), будут одобряться и выдаваться автоматически.
Вот какие значения может принимать RequestDisposition:
| Значение | Что означает (битовая маска) |
|---|---|
| 0x00000001 (1) |
Автоматически одобрить заявку |
| 0x00000002 (2) |
Автоматически отклонить заявку |
| 0x00000101 (257) |
Заявка принимает статус Pending, требуется одобрение вручную |
| 0x00000100 (256) |
Не выдавать заявку автоматически, но можно после утверждения |
Event ID 4886. Certificate Services received a certificate request
Поступил запрос на сертификат. Это распространенное событие, но по нему одному мало что можно понять — лучше смотреть в сочетании с другими.
На скриншоте видно следующие данные:
| Поле | Значение |
|---|---|
| Event ID |
4886 |
| Описание |
CA получил запрос на сертификат |
| Request ID |
71 — уникальный номер заявки |
| Requester |
|
| Template |
ESC7 — используемый шаблон |
| CA Server |
|
Event ID 4887. Certificate Services issued a certificate (approved a request)
Сертификат выдан по запросу. Если в таком событии видно, что Requester — одна учетная запись, а в поле Subject или Attributes значится другая (например, администратор), это тревожный звонок. Также стоит насторожиться, если вдруг сертификат выдан на имя учетной записи, которая обычно сертификатов не запрашивает (скажем, внезапно появился сертификат на Domain Admins или на контроллер домена).
На скриншоте видно следующие данные:
| Поле | Значение |
|---|---|
| Event ID |
4887 (успешная выдача сертификата) |
| Requester |
|
| Subject |
|
| Computer |
GOODEX-SERVER.GOOD.EXPERT |
| Request ID |
63 — номер заявки |
| Disposition |
3 — значение, говорящее, что сертификат выдан |
Здесь подозрение вызывает значение поля Subject: CN=Administrator, CN=Users, DC=GOOD, DC=local.
Это значит, что пользователь testeradm подал заявку на сертификат, но в поле Subject указал Administrator, то есть сертификат был выдан от имени администратора домена.
Event ID 4885. The audit filter for Certificate Services changed
Фильтр аудита изменен. Это событие предупреждает, что злоумышленник мог попытаться отключить аудит на время атаки (через реестр или GUI).
На скриншоте видно следующие данные:
| Поле | Значение |
|---|---|
| Event ID |
4885 |
| Описание |
The audit filter for Certificate Services changed |
| Filter |
127 |
| Источник |
Microsoft Windows security |
| Компьютер |
GOODEX-SERVER.GOOD.EXPERT |
| Уровень |
|
Это событие регистрирует изменение параметра аудита AD CS, а значение поля Filter, равное 127, говорит о включении максимального уровня аудита. То есть все возможные категории событий AD CS теперь логируются.
Что отслеживает флаг AuditFilter
AuditFilter — это параметр в реестре HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA_NAME>\AuditFilter.
Он управляет тем, какие типы действий журналируются:
| Значение | Действие |
|---|---|
| 1 |
Startup/Shutdown |
| 2 |
Backup and Restore |
| 4 |
Configuration Changes |
| 8 |
Security Changes |
| 16 |
Enrollment Agent |
| 32 |
Certificate Request (4886) |
| 64 |
Certificate Issuance (4887, 4888) |
| 127 |
Включает все вышеперечисленное |
Другие события
Также есть менее специфичные события, которые могут появиться в контексте атаки ESC7:
- 4870 — отзыв сертификата;
- 4871 и 4872 — публикация CRL;
- 4888 — отказ в выдаче, например если атакующий сперва получил отказ по шаблону SubCA перед последующим одобрением.
Чтобы эти события появлялись, нужно включить аудит AD CS. В свойствах удостоверяющего центра (certsrv.msc → свойства CA → вкладка Auditing) включаются опции аудита: Change CA security settings, Issue and Manage Certificate Requests и др. Для события 4882 обязательно должен быть активен аудит изменения безопасности CA. Кроме того, на уровне групповой политики нужно включить категорию Audit Object Access → Certification Services (Success) для сервера CA.
Обычно включение аудита через GPO или локально с помощью auditpol требует перезагрузки службы сертификатов. Без настроенного аудита указанные события не будут писаться вовсе, и атака может пройти в полной тишине.
Если в организации внедрен контроль целостности, стоит отдельно мониторить ключевые изменения в конфигурации центра сертификации. Они хранятся в реестре: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA_NAME>\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy
Вот что видно на скриншоте:
- EditFlags управляет возможностью указания SAN. Изменение этого флага может позволить злоумышленнику подставить UPN администратора.
- SubjectAltName и SubjectAltName2 отключены (DISABLED). Но их активация делает шаблон уязвимым (ESC1).
Такие изменения стоит отслеживать: они могут указывать на попытку подготовки к атаке через подделку сертификатов.
После атаки при анализе можно обнаружить нехарактерные сертификаты в хранилищах. Например, внезапно появившийся у учетной записи администратора пользовательский сертификат — обычно такие сертификаты администраторам не выдаются. Или сертификаты с необычным SAN, указывающим на другое имя, у обычных пользователей (не сервисных и не системных).
Еще один тревожный сигнал — внезапно выпущенный сертификат подчиненного центра. Он будет виден в списке выданных корневым CA. Если администратор просматривает журнал выдачи, он заметит заявку и выпуск SubCA‑сертификата — это редкое событие и должно происходить только в контролируемых условиях. Кстати, в событии 4887 поле Disposition подскажет, был ли запрос утвержден вручную, что может указать на вмешательство злоумышленника.
Ключ к обнаружению ESC7 — корреляция событий и изменений, которые не встречаются в обычной работе AD CS.
Далее подробно рассмотрим, как выстраивать такие корреляции.
Чтобы повысить вероятность своевременного выявления атаки ESC7, настройте в системе мониторинга или SIEM корреляционные правила, объединяющие несколько сигналов в единую картину инцидента. Приводим несколько примеров подобной логики.
Корреляция «Изменение прав + выдача сертификата»
Если в течение короткого времени с одного и того же сервера CA приходят два события: изменение ACL (событие 4882) и сразу за ним выдача сертификата (4887) — это крайне необычно и заслуживает немедленного расследования.
В обычной практике сначала должны идти плановые изменения. Событие 4882 может возникнуть при добавлении нового операторa CA, но обычно за этим не следует немедленная выдача сертификата на имя администратора.
Правило может выглядеть так: ALERT, если происходит EventID=4882 (Change CA permissions) и в течение, скажем, 1 часа за ним — EventID=4887 (Cert issued) в том же CA. Еще точнее: если учетная запись, которая фигурирует в 4882 как изменившая права, затем выступает в роли Requester или Approver в событиях 4887 или 4890.
Корреляция по необычному субъекту сертификата
SIEM может отслеживать шаблоны и назначения сертификатов. Например, если по шаблону User внезапно выпущен сертификат, у которого в Subject или SAN указан Domain Admin, событие 4887 будет содержать атрибуты запроса, где видно несоответствие Requester и Subject. Такое сочетание должно триггерить алерт: «Обнаружен выпуск сертификата (4887), где запрашивающий — обычный пользователь, а Subject содержит привилегированный аккаунт». Это явный признак атаки типа ESC6 или ESC7.
Корреляция с данными Directory Services
При изменении ACL на объекте удостоверяющего центра в AD (CN=Enrollment Services, CN=Public Key Services, CN=Services, CN=Configuration, DC=domain, DC=com) контроллер домена может сгенерировать событие изменения конфигурации (Event ID 5136 в логе Directory Service). Это значит, кто‑то изменил атрибут securityDescriptor объекта pKIEnrollmentService. Если организация ведет аудит изменений конфигурации AD, можно сопоставить событие 5136 (ACL CA changed) и событие 4882 на самом CA. Это двойное подтверждение нелегитимного изменения прав.
Мониторинг групп и привилегий
Еще одна корреляция — добавление пользователя в локальную группу CertSVC_DCOM_ACCESS на сервере CA + последующие странные события. Например, злоумышленник мог сперва добавить свою учетную запись в группу DCOM‑доступа (Event ID 4732 на сервере CA в Security-логе), а затем провел атаку. Если известно время, можно связать эти события. Также хороший индикатор — это отслеживание изменения локальных групп на сервере CA: эти группы не должны меняться часто.
Повторяющиеся отказ и последующее одобрение запроса
Если наблюдается последовательность «событие 4888 (запрос отклонен) с определенным Request ID, а затем через короткое время 4887 (запрос с тем же ID одобрен и выдан)», это говорит о том, что кто‑то сначала запросил недопустимый сертификат, получил отказ, а затем воспользовался правами, чтобы выдать его.
В нормальной работе такое сочетание маловероятно: администратор не будет дважды пытаться выполнить один и тот же запрос. По этому индикатору удалось бы выявить сценарий с SubCA: сначала заявка отклонена, затем через Manage Certificates та же заявка переведена в статус выданных.
Анализ успешных входов после изменений
Коррелируя события на CA и входы на DC, можно заметить, что сразу после подозрительной активности на CA, некий пользователь-администратор начинает выполнять действия (вход, получение доступа к DC) с компьютера, откуда эти действия ранее не выполнялись. Это может говорить о том, что злоумышленник получил тикет Kerberos и пошел дальше. Такая корреляция сложнее и требует поведенческой аналитики.
При настройке корреляций важно задать контекст: кто обычно обладает правами Manage CA или Manage Certificates и работает с CA. Действия от имени учетной записи, которая не принадлежит к известным администраторам PKI, — это красный флаг. Например, если User123 вдруг вызывает события, характерные для управления CA, немедленно проверьте, почему у него вообще были такие возможности.
Отдельно взятые события могут затеряться в общем потоке логов, но вместе четко укажут на атаку. Грамотно выстроенные правила в SIEM помогут обнаружить ESC7 на раннем этапе, например при попытке изменения конфигурации CA до выпуска сертификатов. Конечно, важно регулярно актуализировать такие правила с учетом новых техник атак. Но ESC7 уже достаточно хорошо изучена, чтобы ее паттерны можно было описать в системе мониторинга.
Помимо анализа событий, крайне полезно периодически проверять саму конфигурацию AD CS на уязвимости. Это позволяет выявить предпосылки для ESC7.
А если ваша SIEM-/EDR-система собирает инвентаризационные данные реестра по определенному пути по мере их изменения, тогда у вас получится выявить уязвимые хосты в реальном времени еще до атаки злоумышленника.
Рассмотрим проверки, которые нужно выполнить в ходе аудита настроек безопасности центра сертификации.
Проверка ACL центра сертификации
Проверить ACL можно вручную через GUI или с помощью команды certutil -getreg CA\Security:
Убедитесь, что в свойствах центра сертификации (вкладка Security) отсутствуют лишние аккаунты с расширенными правами, такими как Manage CA или Issue and Manage Certificates.
В идеале доступ к этим функциям должен быть ограничен только административными группами, такими как Enterprise Admins или Domain Admins, либо специально созданными группами операторов, если это предусмотрено вашей политикой безопасности.
Широкие группы вроде Authenticated Users или Domain Users ни в коем случае не должны иметь административные права на CA. В крайнем случае, если этого требует процесс автоматической регистрации, им может быть предоставлено только право Enroll — и то с учетом контроля над шаблонами.
Анализ конфигурации доступа DCOM
AD CS предоставляет DCOM‑интерфейс CertSrv Request для обработки удаленных запросов на сертификаты. Если этот доступ неправильно сконфигурирован, любой доменный пользователь может удаленно подключиться к CA и воспользоваться уязвимыми шаблонами (ESC1, ESC6 и др.).
На сервере CA есть встроенная локальная группа Certificate Service DCOM Access (SID: S-1-5-32-574). Она управляет тем, кому разрешено удаленно обращаться к CA через DCOM.
Для проверки состава группы используйте команду net localgroup "Certificate Service DCOM Access":
В этом примере:
- в группу включены Authenticated Users (все доменные пользователи) — это избыточный уровень доступа;
- также добавлен пользователь
testeradm.
Вот что можно сделать в таком случае для повышения безопасности:
- Удалите Authenticated Users, если группа добавлена вручную.
- Оставьте только те группы или учетные записи, которым действительно необходим удаленный доступ к CA:
- Domain Computers — если в организации используется AutoEnrollment (автоматическая выдача сертификатов компьютерам);
- служебные аккаунты — например, для ролей NDES, Intune Connector, SCCM и т. п.;
- специальные группы безопасности, которым делегированы задачи администрирования или обслуживания PKI.
Чем меньше участников в группе Certificate Service DCOM Access, тем меньше риск несанкционированного запроса сертификатов с использованием уязвимых шаблонов.
Чтобы проверить или изменить разрешения DCOM, зайдите в настройки:
- Нажмите Win + R, введите
dcomcnfg. - Перейдите: Component Services → Computers → My Computer → DCOM Config → CertSrv Request.
- Кликните правой кнопкой и выберите: Properties → вкладка Security.
По умолчанию все три раздела (Launch and Activation Permissions, Access Permissions, Configuration Permissions) используют Use Default, то есть наследуют глобальные разрешения, которые могут включать Everyone, INTERACTIVE и др.
Чтобы увидеть точный список, отметьте Customize и нажмите Edit. Вот что отображается в разделе Access Permissions:
На скриншоте видно, что присутствует SELF с Remote Access. Это значит, что любой пользователь, от имени которого выполняется процесс, может обращаться к CA по DCOM, что опасно.
В настройке раздела Launch and Activation Permissions есть группа INTERACTIVE:
Это дает право всем пользователям, вошедшим в систему (в том числе по RDP), удаленно активировать компонент, а значит, получить доступ к CA.
Вот каким группам можно выдавать разрешения для безопасной настройки:
| Раздел | Группы |
|---|---|
| Access Permissions |
Administrators, Certificate Service DCOM Access |
| Launch and Activation Permissions |
SYSTEM, Administrators |
| Configuration Permissions |
По необходимости |
Слишком широкий DCOM‑доступ позволяет:
- удаленно обращаться к интерфейсу CertSrv;
- отправлять запросы на сертификаты, в том числе по шаблонам, требующим ручного одобрения;
- использовать Certipy, certreq или Rubeus
для обхода контроля доступа.
Проверка списка менеджеров сертификатов
В консоли certsrv.msc есть отдельный раздел Certificate Managers. Убедитесь, что там указаны только уполномоченные лица. Иногда в больших организациях создают группы Certificate Operators и делегируют им право выдачи или отзыва. В любом случае там не должно быть посторонних учетных записей. Если обнаружились лишние, разберитесь, кто и зачем их добавил.
Проверка настроек аудита на CA
Чтобы обеспечить надежный контроль за действиями в PKI, убедитесь, что на сервере центра сертификации корректно включен аудит всех критических событий.
Проверка и настройка происходит на вкладке certsrv.msc → Properties → Auditing:
Проследите, чтобы обязательно были включены следующие флаги:
| Флаг | Какие события логирует |
|---|---|
| Start and stop AD CS |
Запуск и остановка службы CA |
| Issue and manage certificate request |
Выпуск сертификатов и управление ими |
| Revoke certificates and publish CRLs |
Отзыв сертификатов и публикация CRL: кто и когда это делает |
| Change CA configuration |
Изменения в параметрах CA |
| Change CA security settings |
Изменения прав и разрешений (вкладка Security, |
| Back up and restore the CA database |
Создание резервных копий и восстановление базы сертификатов |
Эти флаги — ключевые точки для расследования атак через шаблоны (ESC1 — ESC16), эскалации прав и установки бэкдора через CA.
В реестре флаг аудита находится по пути HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA-Name>\AuditFilter:
Флаг аудита — это числовое значение (битовая маска), где каждый бит соответствует определенному аудируемому действию
| Значение | Флаг |
|---|---|
| 0x1 |
Start and stop AD CS |
| 0x2 |
Back up and restore the CA database |
| 0x4 |
Issue and manage certificate requests |
Если значение AuditFilter было изменено вручную, например злоумышленник пытался скрыть свои действия, то это зафиксируется в системном журнале безопасности. Его изменение (событие 4885) тоже нужно мониторить в рамках любой SIEM‑системы или средствами контроля целостности.
Выполнение такого аудита настроек CA раз в квартал или хотя бы при изменениях политики — отличная профилактика. Многие организации, проводя аудит AD, забывают про AD CS, а зря. Выявление и устранение конфигурационных дыр не даст злоумышленнику даже попытаться реализовать ESC7, потому что не будет точки входа.
При анализе атак типа ESC7 становится понятно: однократный снимок состояния системы — это не защита. Важно видеть динамику, фиксировать изменения в правах, составе групп, конфигурации центра сертификации. Именно на этом и построен подход, реализованный в BI.ZONE EDR.
Система не просто находит факты атаки — она в реальном времени отслеживает и фиксирует условия, при которых атака становится возможной.
Вот что конкретно мониторит BI.ZONE EDR:
- права доступа к CA — выполняется сбор, хеширование и сравнение с предыдущим состоянием;
- изменения в ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Security — как только параметр
Securityменяется, запускается автоматический анализ нового ACL;
- группу Certificate Service DCOM Access — любое изменение состава автоматически логируется и отправляется на проверку.
При этом применяются правила предикта, которые фиксируют наличие неадминистративных пользователей с потенциально опасными правами (Manage CA, Issue and Manage Certificates, Read / Write Template и т. д.).
За счет этого система не просто детектирует атаку — она строит профиль риска, выявляя слабые места до их эксплуатации. Такой подход позволяет эффективно выявлять подготовку к ESC7 или аналогичной атаке, даже если сама эксплуатация еще не началась. Это и есть настоящая проактивная защита.
Защита от атаки ESC7 сводится к минимизации прав, надлежащему аудиту и сегментации. Вот список мер защиты, которые помогут обезопасить вашу инфраструктуру AD CS.
Проведите ревизию ACL каждого удостоверяющего центра. Удалите любые группы или учетные записи, которым не критично быть администраторами CA или менеджерами сертификатов. В идеале только члены группы Enterprise Admins (для Enterprise CA) или специально назначенные Certificate Administrators должны иметь права Manage CA.
Выдавайте разрешение Manage Certificates, только если ваша модель предполагает разделение ролей. Например, для операторов, которые занимаются сугубо выпуском и отклонением сертификатов.
Не используйте здесь широкие группы (Domain Users, Authenticated Users). Windows не добавляет их по умолчанию, а уязвимые ACL появляются от ручной ошибки.
AD CS поддерживает разграничение ролей: администратор CA, офицер по регистрации (Certificate Manager), оператор архива ключей, аудитор и т. д. Включите настройку Require role separation в свойствах CA, если это отвечает вашим процессам.
Эта опция предотвращает случаи, когда один и тот же пользователь — одновременно и администратор CA, и менеджер сертификатов. Таким образом, даже если кто‑то с правами Manage CA попробует использовать Manage Certificates, система такого не позволит. Правда, злоумышленник может обойти это, создав второго пользователя, поэтому разграничение ролей не панацея, но усложняет атаку.
Проверьте группу Certificate Service DCOM Access и политику DCOM, как описано выше. Исключите из нее всех, кроме необходимых.
Если возможно, ограничьте сетевой доступ к RPC‑интерфейсу CA. Например, через файрвол на самом сервере разрешите RPC‑трафик только от известных хостов: администраторских рабочих станций, серверов, где запускаются сервисы вроде NDES.
Многие организации размещают Enterprise CA на изолированных серверах, куда обычные пользователи не могут подключиться напрямую. Это хорошая практика: даже если злоумышленник получит права, он не сможет ими воспользоваться удаленно без доступа к сети CA.
Убедитесь, что на всех серверах AD CS настроен Audit Object Access: Certification Services (Success/Failure) через GPO. В свойствах каждого CA включите аудит по нужным категориям, минимум следующим: изменение конфигурации, безопасности, выпуск/отклонение запросов, старт/остановка службы.
Собирайте эти логи в SIEM или хотя бы централизованно на сервере. Настройте оповещения на критические события: 4882, 4890, 4891, 4887 и др. Регулярно просматривайте журнал на предмет неизвестных изменений.
Протестируйте аудит: вручную измените, к примеру, разрешения на тестовом CA и убедитесь, что событие 4882 пришло и содержит понятные вам сведения.
Настройте систему так, чтобы о выпуске сертификата для особо чувствительных шаблонов или аккаунтов узнавали ответственные лица. Нужно немедленно среагировать, если, например, был выдан сертификат по шаблону Domain Controller, SubCA, Enrollment Agent или на учетную запись из группы Administrators. Это можно реализовать, используя скрипт, который периодически парсит выданные сертификаты (через certutil -view или с помощью WMI/CSP), или анализируя поля Subject и Requester в событии 4887.
Помимо разовых проверок, внедрите периодический скриптовый аудит. Используйте инструменты вроде PSPKIAudit
Результаты аудита разбирайте и приводите настройки в порядок. Например, для этого можно использовать утилиту Certipy: у нее есть режим certipy find, который сканирует AD CS на уязвимости и прямо указывает, если CA уязвим к ESC7 и почему.
Удостоверьтесь, что администраторы Active Directory и PKI в вашей организации осведомлены об этой угрозе. Часто уязвимые настройки появляются из‑за незнания. Например, добавили Domain Users, «чтобы все получали сертификаты без проблем». Проводите тренинги, объясняйте риски.
Включите проверку AD CS в регулярные сканирования кибербезопасности. Если у вас проводят тестирование на проникновение, попросите специалистов отдельно оценить безопасность AD CS. Чем раньше вы узнаете о проблеме, тем легче будет ее устранить проактивно — и не придется делать это во время инцидента.
Разработайте план ликвидации инцидента на случай, если обнаружилось неладное, например вы заподозрили, что скомпрометирован CA или выдан фальшивый сертификат. Обычно план содержит следующие шаги:
- Немедленно отозвать подозрительные сертификаты через консоль Certificate Authority (или
certutil -revoke). - Сгенерировать и распространить новые списки отзыва (CRL).
- Убрать злоумышленника из ACL.
- Сменить пароли администраторов на случай, если они были скомпрометированы через сертификат.
В крайнем случае может потребоваться отключить на время службу CA, если она скомпрометирована, до полного расследования. Заранее пропишите, кто и как это будет делать, чтобы в спешке не потерять время.
Следите за обновлениями безопасности Windows Server, касающимися AD CS. Хотя ESC7 — это скорее конфигурационная проблема, а не изъян кода, бывают обновления, улучшающие аудит или вводящие дополнительные проверки. Например, после громких историй Microsoft выпустила рекомендации и обновления по ужесточению картирования сертификатов (Cert Mapping).
Держите CA на поддерживаемых версиях, применяйте свежие патчи. Это не устранит ESC7 само по себе, но исключит другие векторы компрометации и может добавить средства детектирования.
Если выяснится, что Enterprise CA установлен по наследству и мало используется, возможно, проще его выключить, чем держать ради пары сертификатов, постоянно рискуя его компрометацией. Лишние услуги — лишние уязвимости.
Атака ESC7 — яркий пример того, как один неправильный доступ к центру сертификации может дать злоумышленнику права администратора домена без взлома паролей и эксплоитов. Атакующий просто использует доверенную PKI против нее самой.
Исторически службы AD CS редко проверяются после внедрения. В результате появляется множество спящих уязвимостей, которые могут использовать в любой момент.
Основной риск: если пользователь или группа получают права Manage CA или Manage Certificates, они могут выпустить любой сертификат от имени любого субъекта, включая администратора.
ESC7 показывает: PKI — не второстепенная роль, а критическая часть инфраструктуры AD. Без жесткого контроля за правами и шаблонами CA может стать входной точкой для незаметного захвата домена.