ESC5. Невидимая эскалация
AD CS хранит информацию о центрах сертификации и шаблонах сертификатов в контейнере Public Key Services конфигурационного раздела AD. Таким образом, помимо самих шаблонов сертификатов и объекта центра сертификации, есть ряд других объектов AD, связанных с PKI, например:
- Certificate Templates — хранилище всех шаблонов сертификатов леса.
- Enrollment Services — контейнер, содержащий объекты каждого Enterprise CA и их привязку к шаблонам через атрибут
certificateTemplates. - Certification Authorities — список доверенных корневых сертификатов в лесу.
- NTAuthCertificates — список доверенных CA для аутентификации в домене.
- KRA (key recovery agents) — агенты восстановления, получающие доступ к заархивированным ключам.
Их безопасность критически важна для системы AD CS, ведь все они влияют на работу инфраструктуры сертификации. Если низкопривилегированный пользователь получит возможность изменить любой из этих объектов, он сможет скомпрометировать всю систему PKI и получить незаконные привилегии в домене.
Эти критически важные элементы находятся в каталоге по пути CN=Public Key Services,CN=Services,CN=Configuration,DC=Domain,DC=Local:
Для понимания техники ESC5 кратко рассмотрим роли контейнеров Certificate Templates и Enrollment Services:
- Certificate Templates — это база всех шаблонов в лесу, как активных, так и неиспользуемых:
Аналог Certificate Templates — раздел с базой всех шаблонов:
- Enrollment Services — это контейнер, содержащий атрибут
certificateTemplates, в котором перечислены все шаблоны сертификатов, разрешенные к использованию конкретным центром сертификации:
Именно по ним CA выдает сертификаты, и именно здесь определяется, какие шаблоны доступны конечным пользователям и сервисам.Аналог Enrollment Services — шаблоны, которые опубликованы в центре авторизации сертификатов:
Таким образом, один контейнер содержит исходники шаблонов, а другой — список опубликованных для конкретного CA.
Если злоумышленник получает права на запись в оба этих раздела, он может:
- Создать собственный ослабленный шаблон, удовлетворяющий условиям других атак ESC (например, разрешающий подставлять SAN и не требующий утверждения).
- Опубликовать этот шаблон в центре сертификации, добавив его в атрибут
certificateTemplatesобъекта CA в Enrollment Services.
Это и есть базовая логика атаки ESC5 — использование уязвимых ACL объектов PKI в AD для внедрения вредоносной конфигурации и дальнейшей эскалации привилегий. Но это не единственный способ эксплуатации: в следующих разделах рассмотрим и другие варианты, опирающиеся на контроль над объектами инфраструктуры сертификатов.
Иными словами, ESC5 — это атака на логику доверия, основанная не на уязвимости кода, а на неправильно настроенных правах доступа к объектам, управляющим выдачей, доверием и структурой сертификатов в среде Active Directory.
Чтобы атака ESC5 стала возможной, необходимы следующие условия в инфраструктуре:
- Развернутый AD CS с Enterprise CA. В лесу Active Directory должен существовать хотя бы один Enterprise CA, которому домен доверяет для аутентификации (его сертификат присутствует в NTAuthCertificates).
- Неправильная настройка ACL (доступа) на критичных объектах AD CS. Ключевое условие — наличие у злоумышленника достаточных прав на один или несколько объектов в контейнере Public Key Services или связанных с ним:
Для осуществления этой атаки у злоумышленника уже должна быть в домене учетная запись с определенными привилегиями, а из‑за ошибок конфигурации безопасности ему доступны нежелательные права на PKI‑объекты. К опасным правам относят:
- WriteDACL/WriteOwner — право изменять ACL объекта или его владельца (позволяет обрести полный контроль).
- GenericWrite/WriteProperty — право изменять атрибуты объекта.
- GenericAll / Full Control — полный доступ к объекту (включает возможность изменять права и содержимое).
Предоставление подобных прав на PKI‑объекты посторонним пользователям открывает возможность для неправомерных действий. Например, исследователи SpecterOps
В число таких чувствительных компонентов, помимо шаблонов сертификатов, входят:
- учетная запись компьютера CA;
- RPC‑интерфейсы CA;
- все объекты внутри
CN=Public Key Services(Certificate Templates, Certification Authorities, NTAuthCertificates, Enrollment Services и пр.).
Примеры неправильных настроек, делающих ESC5 возможной
- Избыточные делегированные права на объекты AD CS. Например, если встроенная группа Cert Publishers (или другая техническая группа) получила полные права GenericAll на объект центра сертификации или контейнер шаблонов, любой член этой группы сможет использовать сертификаты.
- Сохранение унаследованных ACE в конфигурационном разделе. Бывает, что права, установленные на уровне конфигурации леса или домена, распространяются на контейнер Public Key Services. В междоменных средах Domain Admin дочернего домена может частично влиять на объекты конфигурации. Например, в лабораторной демонстрации SpecterOps администратор дочернего домена имел полный контроль над контейнером Public Key Services своего домена, что реплицировалось на уровень леса. Такие права позволили ему добавлять новые объекты (шаблоны) и менять настройки CA, хотя обычно эти действия зарезервированы за Enterprise Admin.
Таким образом, базовые условия атаки ESC5:
- Наличие у злоумышленника учетной записи в AD с достаточно высокими правами, позволяющими читать или изменять конфигурационный раздел.
- Наличие у этой учетной записи или группы необоснованных прав на объекты PKI AD CS.
Без уязвимых ACL техника ESC5 невозможна, поэтому это атака, обусловленная ошибками конфигурации и контроля доступа.
Конкретные шаги злоумышленника при атаке ESC5 зависят от того, над каким объектом PKI ему удалось получить контроль. Рассмотрим типичные векторы.
Это самый наглядный сценарий для повышения привилегий, который продемонстрировали эксперты SpecterOpspKIEnrollmentService, представляющему Enterprise CA. Последовательность атаки будет следующей:
- Создание уязвимого шаблона сертификата. Имея полный доступ к контейнеру шаблонов, злоумышленник способен через консоль
certtmpl.msc(или с помощью LDAP) создать новый шаблон сертификата — копию существующего, но с ослабленными параметрами безопасности. Например, можно дублировать стандартный шаблон пользовательского сертификата и внести изменения:- разрешить включать в запрос произвольный subject alternative name (SAN);
- добавить в параметры приложения EKU Client Authentication (
1.3.6.1.5.5.7.3.2) для использования сертификата в аутентификации; - отключить требования одобрения со стороны CA или дополнительных подписей (нет флагов
PEND_ALL_REQUESTSиREQUIRE_SIGNATURE).
Также атакующий выдает на новый шаблон права Enroll для учетной записи или группы, которой он владеет, чтобы иметь возможность получить по нему сертификат. Такой шаблон соответствует критериям уязвимости ESC1: любой сертификат, выпущенный по нему, сможет аутентифицировать пользователя с указанным SAN (даже если SAN — это имя учетной записи администратора домена). - Публикация шаблона в целевом CA. После создания шаблона его нужно привязать к центру сертификации, чтобы CA начал выдавать по нему сертификаты. Для Enterprise CA списки разрешенных шаблонов хранятся в LDAP — в объекте
pKIEnrollmentServiceэтого CA, в многозначном атрибутеcertificateTemplates. С доступом Write к объекту CA злоумышленник может добавить имя нового шаблона в такой список, например через ADSI Edit или PowerShell, тем самым опубликовав шаблон в CA. В результате CA начнет считать новый шаблон допустимым и позволит отправлять на него заявки.Альтернативный путь
Если у злоумышленника есть доступ к самому серверу CA, он может использовать утилиту
certutil -setcatemplatesили GUIcertsrv.mscпод SYSTEM для добавления шаблона в CA, как демонстрировали эксперты SpecterOps. - Получение привилегированного сертификата. Теперь злоумышленник, обладая учетной записью в допустимой группе (выданной им правом Enroll на этапе 1), подает запрос на сертификат по новому шаблону. В запросе он указывает в поле SAN имя учетной записи, привилегии которой хочет получить. Благодаря настройке шаблона центр сертификации без дополнительной проверки выпускает сертификат, в котором в качестве альтернативного имени указана учетная запись с высокими привилегиями. Злоумышленник экспортирует полученный сертификат с приватным ключом, например в формате PFX.
- Применение сертификата для эскалации привилегий. Обладатель сгенерированного сертификата может теперь аутентифицироваться в AD под видом другой учетной записи. Например, сертификат с EKU Client Authentication на имя Administrator можно использовать для получения Kerberos TGT этой учетной записи, воспользовавшись утилитами вроде Rubeus (PKINIT Kerberos authentication), или при интерактивном входе, как по смарт-карте. В демонстрации SpecterOps полученный сертификат конвертировали в PFX и перенесли на контроллер дочернего домена. После этого с помощью Rubeus запросили Kerberos-тикет для административной учетной записи. Имея действительный TGT высокопривилегированного пользователя, атакующий фактически становится Enterprise Admin, завершая эскалацию привилегий.
Этот сценарий ESC5 — мощный вариант атаки на инфраструктуру AD CS.
Объект CN=NTAuthCertificates содержит список сертификатов центров сертификации, доверенных для целей аутентификации. Например, при входе в систему с помощью смарт-карты контроллер домена проверяет, был ли предъявленный сертификат подписан одним из CA из этого списка. Таким образом, NTAuthCertificates определяет, каким центрам сертификации доверяет домен при аутентификации пользователей.
Вот как будет развиваться атака по этому сценарию:
- Создание поддельного (rogue) CA. Злоумышленник генерирует собственный самоподписанный сертификат центра сертификации. Этот фиктивный CA существует вне контролируемой инфраструктуры организации, но будет представлен как доверенный.
- Добавление сертификата в NTAuthCertificates. Получив доступ на изменение объекта NTAuthCertificates (например, имея право WriteProperty на него), злоумышленник добавляет в него свой самоподписанный сертификат. Это можно сделать с помощью команды
certutil -dspublish -f <cert.cer> NTAuthCAили напрямую, модифицируя атрибуты объекта через LDAP. - Репликация изменений. После добавления сертификата изменения реплицируются на все контроллеры домена в лесу, так как NTAuthCertificates хранится в разделе конфигурации
CN=Configuration,DC=.... - Доверие к поддельному CA. Теперь контроллеры домена будут доверять сертификатам, выданным злоумышленником через его поддельный CA. При проверке сертификата на вход в систему контроллер домена проверяет, присутствует ли сертификат издателя в списке NTAuthCertificates. Если да — аутентификация будет разрешена.
- Выпуск сертификатов для любых пользователей. Атакующий выпускает сертификаты от имени любого интересующего его пользователя (например, администратора домена). Поскольку его сертификат цепляется к уже доверенному корню, атакующий сможет аутентифицироваться как этот пользователь.
- Результат атаки. Злоумышленник получает возможность легально проходить аутентификацию в домене от имени любого пользователя, для которого он выпустил сертификат. Влияние атаки сопоставимо с получением golden ticket в Kerberos, но на уровне инфраструктуры сертификатов.
Этот способ чрезвычайно опасен, так как практически не требует взаимодействия с самим сервером CA — достаточно прав в AD.
В Active Directory есть еще один важный контейнер — Certification Authorities. В нем хранятся сертификаты доверенных CA для всего леса Active Directory. Такие сертификаты называют enterprise trusted roots. Обычно здесь публикуются:
- сертификаты корневых центров сертификации;
- сертификаты промежуточных центров сертификации, которым должны доверять все компьютеры и пользователи в домене.
По этому сценарию атака развивается следующим образом:
- Добавление поддельного сертификата. Если злоумышленник получит возможность изменять контейнер
CN=Certification Authorities, он может добавить туда собственный самоподписанный сертификат (фальшивый корневой CA). - Репликация доверия. После добавления сертификата все устройства в домене начнут доверять этому фальшивому центру сертификации. Это происходит автоматически, потому что устройства получают список доверенных корней из AD.
- Эксплуатация доверия. Злоумышленник может выпустить сертификаты для любых целей:
- сертификаты для пользователей Active Directory (с подставным UPN);
- TLS-сертификаты для поддельных серверов;
- сертификаты для подписи вредоносных программ как легитимных.
Рассмотрим, чем этот случай отличается от описанного выше добавления доверенного корневого сертификата (NTAuthCertificates).
| NTAuthCertificates | Certification Authorities | |
|---|---|---|
| Основная цель |
Доверие для аутентификации (смарт‑карты, PKINIT) |
Общее доверие к сертификатам (TLS, EFS, подпись кода и др.) |
| Применение |
Вход в систему |
Шифрование, защищенные соединения, подпись кода |
| Последствия атаки |
Подмена учетных записей |
Широкий спектр атак: доступ, перехват трафика, подмена подписей |
Организации настраивают архивирование ключей (key archival), чтобы в случае потери приватного ключа пользователя, например при утере смарт-карты или сбое устройства, можно было восстановить этот ключ из безопасного хранилища.
Чтобы обеспечить безопасность процесса, в системе используются агенты восстановления ключей (key recovery agents, KRA).
У каждого агента восстановления есть публичный и приватный ключ. Публичные ключи агентов хранятся в специальном защищенном месте — контейнере KRA.
Как это работает на практике:
- Когда пользователь запрашивает новый сертификат, создается его приватный ключ, который он будет использовать для подписи или шифрования.
- Если включено архивирование, система делает копию этого приватного ключа.
- Чтобы эта копия была защищена, ее сразу зашифровывают публичным ключом одного из агентов восстановления.
- Зашифрованная копия сохраняется в базе данных CA.
Если во время атаки злоумышленнику удастся добавить в контейнер KRA свой собственный сертификат агента восстановления (при этом приватный ключ будет известен ему) или заменить один из существующих агентов, то атакующий сможет:
- расшифровывать архивированные приватные ключи пользователей;
- получать доступ к зашифрованной информации от их имени;
- захватить контроль над инфраструктурой при наличии архивированных сертификатов высоких привилегий, например администраторов домена.
Эту атаку можно сравнить с ситуацией в банке: каждый клиент кладет копию своего ключа в сейф. Чтобы копии были в безопасности, банк запирает их на специальный замок (шифрует публичным ключом KRA). Но если злоумышленник заменит этот замок на свой, то сможет открывать сейфы других клиентов.
Подытоживая, можно сказать, что атака ESC5 сводится к следующему: злоумышленник, обнаружив уязвимый объект AD CS, над которым у него есть контроль, проводит изменения в инфраструктуре сертификатов. Он создает новые доверенные объекты (сертификаты или шаблоны) либо модифицирует существующие, чтобы выпустить для себя или подставного субъекта сертификат, который даст доступ к привилегированным действиям.
Все операции можно выполнять стандартными средствами:
- ADSI Edit / LDAP для правок в AD;
- утилитой certutil для публикации сертификатов в AD, например
certutil -dspublish; - специализированными инструментами red team, например Certify
или Certipy , для автоматизации поиска и эксплуатации уязвимых настроек AD CS.
В результате атака реализуется на уровне логики AD CS: она не эксплуатирует уязвимости кода, а использует права и доверительные отношения в AD. Это затрудняет ее обнаружение на ранних этапах.
Обнаружить атаку ESC5 возможно двумя путями: с помощью мониторинга событий (корреляция активностей в логах) и проактивного аудита конфигурации AD CS на опасные отклонения.
Чтобы отследить проведение атаки ESC5, настройте аудит важных действий в AD и на серверах сертификатов. Включите аудит изменений в конфигурационном разделе AD для контейнера Public Key Services и всех вложенных объектов. Для этого в Windows Server на соответствующие объекты ACL добавьте SACL (system access control list) с мониторингом нужных операций:
Вот ключевые события Windows, на которые следует обращать внимание:
- Event ID 5136 (A directory service object was modified). Фиксирует, когда успешно изменяется атрибут объекта AD. С помощью этого события можно отследить добавление новых значений или создание новых объектов в контейнерах AD CS. Например, добавление нового сертификата в NTAuthCertificates или нового шаблона сертификата вызовет событие 5136 на объекте NTAuthCertificates или Certificate Templates соответственно.В событии 5136 содержится DN (distinguished name) объекта, имя измененного атрибута и тип операции. Для фильтрации интересующих изменений настройте корреляцию по этим полям. Так, добавление нового сертификата в NTAuthCertificates отразится как
OperationType: Value Addedна объектеCN=NTAuthCertificates,CN=Public Key Services,.... Аналогично создание нового шаблона сертификата — добавление дочернего объекта вCN=Certificate Templates,....Регулярно анализируя события 5136 по ключевым объектам PKI, можно обнаружить факт изменения, который при нормальной работе случается крайне редко. Например, публикация нового корневого сертификата или шаблона обычно производится вручную администраторами и должна быть согласована. - Event ID 4662 (An operation was performed on an object). Низкоуровневое событие аудита доступа к объектам AD. Может генерироваться при попытке изменения ACL или других управляемых атрибутов. Например, злоумышленник пытается изменить разрешения (WriteDACL) на объект Certificate Templates. В этом случае, если есть SACL, это действие вызовет событие 4662, указывающее GUID прав и SID субъекта. Анализ 4662 сложнее (так как связан с сопоставлением GUID прав), но в сочетании с 5136/5141 (создание/удаление объекта) дает полный обзор.
- Event ID 4898/4899 (CA configuration change). События аудита на самом сервере Certificate Authority, если включено ведение лога конфигурации. При добавлении или удалении шаблона сертификатов на сервере CA могут регистрироваться события, например 4898 (Certificate Template added to CA), 4899 (Certificate Template removed from CA). Однако эти события появляются, только если действие совершено через интерфейс CA. При скрытой модификации LDAP (как в случае атаки) CA может не сразу зафиксировать такое изменение как событие. Тем не менее выдача сертификата по новому шаблону, не существовавшему ранее, должна насторожить.
В условиях техники ESC5 наиболее ранними индикаторами будут именно события изменения объектов AD. В охоте за атаками на AD CS рекомендуется отслеживать изменения критичных объектов, в частности изменения атрибутов важных объектов PKI с помощью события 5136. Например, чтобы обнаружить установку мошеннического корневого сертификата, фильтруют события 5136 по ObjectDN = CN=NTAuthCertificates,... и OperationType = %%14674 (добавление значения). По аналогии стоит мониторить:
- ObjectDN =
CN=Certificate Templates,...— создание новых объектов шаблонов, изменение их свойств безопасности, атрибутsecurityDescriptor, событие 5136/5139; - ObjectDN =
CN=Enrollment Services,...— изменения списка шаблонов в объекте CA, атрибутcertificateTemplates; - ObjectDN =
CN=Certification Authorities,...— добавление новых доверенных корней; - ObjectDN =
CN=KRA,...— добавление агентов восстановления; - изменения на объекте
CN=Public Key Services— на случай, если злоумышленник меняет наследуемые права сразу на весь контейнер.
Пример корреляции
- Появилось событие добавления значения в NTAuthCertificates.
- Вскоре после этого — событие 4768 (успешный вход) для привилегированной учетной записи по сертификату.
Представленный метод позволяет выявлять активность злоумышленников в момент проведения атаки, однако наибольшую эффективность демонстрирует проактивный подход к обнаружению — детектирование до наступления инцидента. Предотвращение всегда предпочтительнее реагирования. Далее рассмотрим, как выявлять уязвимые конфигурации и хосты, чтобы устранить потенциальные векторы атаки еще на этапе профилактики.
Крайне важно заранее выявлять и устранять уязвимости конфигурации AD CS, которые делают атаку ESC5 возможной. Проводите аудит, в который входят:
- Проверка ACL критически важных объектов инфраструктуры AD CS. Для защиты инфраструктуры корпоративной PKI регулярно проверяйте списки управления доступом (ACL) следующих объектов в конфигурационном разделе Active Directory:
- Certificate Templates;
- Enrollment Services (объекты
pKIEnrollmentService); - Certification Authorities;
- NTAuthCertificates;
- KRA (key recovery agents);
- объекты выпущенных сертификатов внутри этих контейнеров.
В первую очередь обращайте внимание на опасные права доступа (ACE) у нежелательных субъектов:- WriteOwner — позволяет сменить владельца объекта, а это ключ к дальнейшей эскалации.
- WriteDACL, GenericAll, Full Control, WriteProperty, GenericWrite — все эти права дают возможность изменять поведение объектов PKI.
Особое внимание уделяйте случаям, когда такие права назначены:- Authenticated Users, Domain Users, группам низкого уровня;
- cервисным аккаунтам, не относящимся к PKI;
- владельцам объектов, которые не входят в Enterprise Admins или не являются сервером CA (для специфичных случаев).
Для аудита ACL можно использовать штатные инструменты:- консоль ADSI Edit: подключиться к
CN=Configuration,<ForestDN>и вручную проверить закладки Security нужных объектов; - утилиту командной строки dsacls. Например,
dsacls "CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com"покажет права на объект NTAuthCertificates; - модуль ActiveDirectory PowerShell, командлет
Get-ACL. Пример для контейнера шаблонов:
Import-Module ActiveDirectory $objDN = "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com" Get-ACL -Path ("AD:\" + $objDN) | Select-Object -ExpandProperty Access | Select IdentityReference, ActiveDirectoryRights, AccessControlType
Эта команда выведет список ACE с указанием субъекта, типа доступа и прав. Просканируйте вывод на наличие подозрительных прав, особенно обращая внимание на ActiveDirectoryRights = WriteOwner, WriteDACL, GenericAll, GenericWrite и на то, кто их получатель. - Анализ конфигурации шаблонов сертификатов. Помимо ACL, оцените параметры каждого шаблона на наличие небезопасных настроек, которые могут позволить эскалацию (техники ESC1, ESC2, ESC3 и др.). В контексте ESC5 это важно, чтобы даже при компрометации контейнера злоумышленник не мог сразу найти готовый небезопасный шаблон. Проверьте:
- Какие группы имеют право Enroll на шаблоны. Опасно, если обычные пользователи (Domain Users) могут получить сертификат шаблона с клиентской аутентификацией без контроля.
- Включены ли на шаблонах EKU, позволяющие аутентификацию: Smart Card Logon, Client Authentication, либо установлено Any Purpose (что эквивалентно всем целям). Если да — удостоверьтесь, что такие шаблоны недоступны для выдачи кому угодно.
- Разрешен ли для шаблона флаг
ENROLLEE_SUPPLIES_SUBJECT(заполнение альтернативного имени запросителем). Если да и одновременно шаблон имеет клиентский EKU — это опасная комбинация (ESC1). Лучше отключите SAN или ограничьте круг тех, кто может получать по нему сертификаты. - Требуется ли административное утверждение или подписи для выдачи (флаги
PEND_ALL_REQUESTS,REQUIRE_SIGNATURE). Их отсутствие упрощает задачу злоумышленнику.
Используйтеcerttmpl.msc, чтобы графически проверить каждый шаблон, илиcertutil -v -template, чтобы выгрузить информацию о шаблонах. Также будут полезны скрипты и утилиты, например PowerShell-модуль PSPKI или сторонние аудиты. Они могут автоматизировать поиск шаблонов, удовлетворяющих условиям атаки. - Инвентаризация Enterprise CA и связанных объектов. Убедитесь, что в контейнере Enrollment Services присутствуют только ожидаемые объекты CA и что атрибуты
certificateTemplatesу них содержат лишь разрешенные шаблоны. Любой лишний шаблон в списке должен вызвать вопросы: он мог быть добавлен несанкционированно. Аналогично проверяйте контейнер Certification Authorities: все ли сертификаты корневых центров легитимны, сопоставьте их с известными вам корневыми сертификационными центрами организации. Если находится неизвестный сертификат, расследуйте его происхождение.
Использование специализированных средств
Регулярный аудит конфигурации — лучшая профилактика. Исследование SpecterOps подчеркивает, что методы атаки через ACL PKI очень разнообразны, а у организаций часто нет эффективных средств аудита прав на объекты AD CS. Поэтому сделайте упор на то, чтобы один раз вручную навести порядок и затем внедрить постоянный мониторинг изменений.
Проверку систем в домене можно автоматизировать с помощью EDR. В следующем разделе на примере BI.ZONE EDR покажем, как обнаружить уязвимость еще до начала эксплуатации.
Самая надежная стратегия противодействия атакам ESC5 — это своевременное выявление условий, которые делают атаку возможной. Именно этот проактивный подход реализован в BI.ZONE EDR, а особое внимание уделяется контролю за объектами PKI в Active Directory.
Как работает защита от ESC5 в BI.ZONE EDR
Агенты EDR, установленные на серверах инфраструктуры, регулярно выполняют инвентаризацию критических объектов AD CS. Они анализируют права доступа и владельцев следующих контейнеров в конфигурационном разделе Active Directory:
- Certificate Templates;
- Enrollment Services;
- Certification Authorities;
- NTAuthCertificates;
- KRA;
- Public Key Services.
Каждый из этих объектов проверяется на наличие опасных прав доступа, включая: WriteOwner, WriteDACL, GenericAll, Full Control, WriteProperty, GenericWrite. В рамках аудита выявляются любые случаи, когда доступ имеют низкопривилегированные группы (например, Authenticated Users, Domain Users) или посторонние учетные записи. Также анализируются владельцы объектов: если они не входят в перечень доверенных групп (например, Enterprise Admins), такой случай помечается как потенциально уязвимый.
Как проверяется унаследование прав
В рамках аудита безопасности инфраструктуры AD CS в обязательном порядке проверяется состояние наследования прав у объекта CN=Public Key Services. Помимо анализа владельцев и опасных прав, важно убедиться, что объект не наследует нежелательные ACL от вышестоящих контейнеров:
CN=Public Key Services — это контейнер в конфигурационном разделе AD, который реплицируется на все контроллеры домена во всем лесу. Если в лесу используется структура с дочерними доменами, то каждый DC в дочернем домене содержит копию этого объекта, доступную для записи локально.
Если объект CN=Public Key Services наследует разрешения от родительского контейнера CN=Services, а в нем, в свою очередь, заданы слишком широкие или уязвимые ACE (например, с правами для Domain Admins дочернего домена), то эти права перейдут дальше. В результате их унаследует все содержимое Public Key Services, включая Certificate Templates, Enrollment Services и другие критичные объекты PKI.
Более того, злоумышленник, обладающий доступом к SYSTEM на контроллере дочернего домена, может изменить ACL локальной копии CN=Public Key Services, и эта запись будет реплицирована вверх в корневой домен, распространяя уязвимость на весь лес.
Поэтому отключение унаследованных прав и строгая явная настройка ACL на объекте CN=Public Key Services — обязательная мера защиты от атак, связанных с неправомерной эскалацией привилегий через механизм репликации конфигурационного раздела.
Пример вывода автоматизированного скрипта:
Что происходит при обнаружении отклонений
После каждой инвентаризации агент формирует отчет с выявленными отклонениями и передает его в SIEM. На стороне SIEM реализовано правило предикта, которое:
- выделяет любые изменения прав доступа к объектам PKI;
- отслеживает появление подозрительных владельцев;
- генерирует рекомендации по исправлению мисконфигураций и направляет владельцам уязвимых систем.
Таким образом, BI.ZONE EDR обеспечивает автоматизированный контроль целостности PKI‑объектов AD и своевременно выявляет предпосылки к атаке ESC5 еще до ее реализации.
Результат — непрерывная защита AD CS без необходимости вручную пересматривать каждую настройку.
Регулярный аудит конфигурации — неотъемлемый элемент защиты AD CS. Практика показывает, что уязвимости в правах доступа и конфигурациях инфраструктуры сертификатов возникают не из‑за технических сбоев, а вследствие недосмотра или недостаточного контроля. В исследовании SpecterOps подчеркивается, что логические дыры в ACL и слабые шаблоны сертификатов — одни из самых распространенных векторов эскалации привилегий, и часто они долгое время остаются незамеченными.
Поэтому основная задача специалистов безопасности — заранее выявить и устранить все потенциально опасные настройки, связанные с объектами PKI в каталоге Active Directory. Целенаправленно проверяйте права доступа к контейнерам и объектам AD CS (в том числе скрытые, как NTAuthCertificates), анализируйте владельцев, а также контролируйте параметры шаблонов сертификатов, чтобы минимизировать риски.
Это поможет не просто зафиксировать атаку, а предотвратить ее, устранив саму возможность проведения. Именно такой проактивный подход лежит в основе эффективной защиты от ESC5 и должен стать стандартом при администрировании любой PKI.
Защита сводится к принципу минимальных привилегий для всех объектов PKI и постоянному надзору. Рекомендуем внедрять регулярный аудит AD CS подобно аудиту AD‑политик. Контролируйте настройки CA и шаблонов (defensive IDs PREVENT‑2, PREVENT‑4) и мониторьте их изменения (DETECT‑4). Соблюдение этих мер значительно снижает риск реализации атаки ESC5.
Атака ESC5 на AD CS демонстрирует, насколько важна безопасность инфраструктуры сертификатов в Active Directory. Через уязвимые объекты PKI злоумышленник может преобразовать относительно небольшую компрометацию (учетная запись с доступом к AD) в полный контроль над доменом, фактически обходя традиционные механизмы защиты. В современных гибридных сетях, где распространены смарт-карты и сертификаты для аутентификации, такие атаки представляют особую опасность: они могут долго оставаться незамеченными, ведь злоумышленник действует по правилам PKI, получая вроде бы легитимные сертификаты.
Для специалистов по безопасности важно понимать технику ESC5 и подобные ей. Она не эксплуатирует уязвимость ПО, а пользуется логическими дырами в конфигурации и доверии. Профилактика — тщательная настройка и ограничение прав, а обнаружение — пристальный мониторинг изменений и аномалий в области сертификатов.
Подводя итог, отметим: AD CS — не второстепенная служба, а точка отказа безопасности AD. Успешная атака на сертификаты чревата для домена тем же, чем и атака golden ticket. Поэтому рекомендуем относиться к PKI‑объектам с тем же уровнем строгости, что и к контроллерам домена, регулярно проводить их аудит и следить за отчетами и исследованиями, чтобы вовремя внедрять лучшие практики защиты. Соблюдая эти меры, вы укрепите общий уровень кибербезопасности и значительно затрудните реализацию атаки ESC5 и подобных ей.
