ESC4. Права решают всё
ESC4 — это эскалация привилегий в домене за счет уязвимой настройки прав доступа (ACL) на объекте шаблона сертификата в AD CS. Если в списке управления доступом шаблона есть записи, позволяющие непривилегированным пользователям изменять свойства этого шаблона, злоумышленник может модифицировать шаблон сертификата и тем самым привнести в него опасные настройки. После этого измененный шаблон становится уязвимым для других атак (например, для техники ESC1).
Таким образом, ESC4 — это использование права на шаблон сертификата (Certificate Template ACL abuse). Злоумышленник может превратить обычный шаблон в уязвимый и выпустить с его помощью привилегированный сертификат. Эта техника дополняет другие векторы атак на AD CS.
Давайте кратко сравним техники с ESC1 по ESC4, чтобы лучше понять, в чем отличие ESC4.
| Техника | Условия | Результат |
|---|---|---|
| ESC1 (Modifiable SAN) |
Шаблон сертификата изначально уязвим, поскольку позволяет указать произвольное альтернативное имя субъекта (Subject Alternative Name, SAN) в запросе |
Низкопривилегированный пользователь с правом на выпуск такого сертификата может вписать в SAN имя учетной записи администратора и получить сертификат, с которым можно аутентифицироваться как этот администратор |
| ESC2 (EKU Any Purpose или нет EKU) |
У шаблона есть небезопасные расширения: либо не указаны допустимые назначения (EKU), либо стоит универсальное назначение Any Purpose |
Сертификат, выпущенный по такому шаблону, по умолчанию доверяется для целей аутентификации (и других). Злоумышленник может получить сертификат без специфичных ограничений и использовать его для входа в систему (даже без SAN, так как доверяется учетная запись владельца сертификата) |
| ESC3 (Enrollment Agent) |
Шаблон агентa регистрации (Certificate Request Agent) неправильно настроен, например позволяет любому пользователю получить сертификат агента |
Обладатель сертификата Enrollment Agent может выступать доверенным посредником и от имени других пользователей выпускать новые сертификаты (в том числе для администраторов) |
| ESC4 (ACL на шаблон) |
Проблема возникает не из‑за шаблона, а из‑за неправильно настроенных прав доступа к нему |
Атакующий с некорректно выданными правами на шаблон сам делает его уязвимым, внося изменения, а затем эксплуатирует их (через механизм ESC1, ESC2 или ESC3) |
ESC4 выделяется на фоне всех остальных тем, что требует, чтобы у злоумышленника были определенные права на шаблон сертификата: без этого он не сможет осуществить атаку.
Для выполнения атаки по сценарию ESC4 должны совпасть несколько условий:
- Неправильный ACL шаблона сертификата.
- Возможность выпуска сертификата.
- Аутентификация в домене.
Разберем каждое подробнее.
В системе должен существовать хотя бы один шаблон сертификата с избыточными правами для низкопривилегированных групп или пользователей. В контексте ESC4 опасны следующие права доступа к объекту шаблона:
- Owner — владелец объекта (имеет неявный полный контроль).
- Full Control — полный контроль (аналогично владельцу разрешает изменение всех свойств и прав).
- WriteOwner (WO) — право изменять владельца объекта на другого субъекта.
- WriteDACL (WD) — право изменять Discretionary ACL, то есть давать другим учетным записям дополнительные привилегии вплоть до Full Control.
- WriteProperty (WP) — право редактировать свойства объекта (в случае шаблона — всех параметров сертификата).
Шаблон считается уязвимым, если хотя бы одно из этих прав есть у неподходящего субъекта, например Domain Users, Authenticated Users или аналогичной группы. На практике наиболее частый сценарий — это когда группе Domain Users или всем, прошедшим проверку, выданы права Write (изменение свойств) или даже Full Control на шаблон. Такое может произойти, например, из-за копирования настроек шаблона или ошибок делегации.
Разберем ключевые опасные права на примере скриншота ниже.
На изображении у шаблона сертификата ESC4 выявлен ряд грубых ошибок конфигурации, которые создают условия для атаки ESC4:
- Владельцем (Owner) установлена группа Authenticated Users. Это означает, что любой прошедший аутентификацию пользователь домена обладает неявными правами на полный контроль и может переназначать владельца шаблона.
- Пользователь с именем hacker явно получил права Full Control и Write. Это позволяет ему изменять любые свойства шаблона, в том числе потенциально опасные параметры, например получение возможности задавать альтернативное имя субъекта, что соответствует технике ESC1.
- Кроме того, у учетной записи пользователя mgoev также есть право Full Control. Даже если эта учетная запись не принадлежит непосредственно злоумышленнику, ее компрометация даст ему аналогичные возможности.
В итоге атакующий с таким набором прав может выполнить следующую цепочку действий:
- Изменить шаблон так, чтобы снять все ограничения на выпуск сертификатов.
- Самостоятельно добавить себе или другим пользователям права Enroll, если их еще не было.
- Выпустить сертификат, указав произвольное альтернативное имя (например, администратора домена) либо получив сертификат от имени других учетных записей.
- Используя полученный сертификат, злоумышленник легитимно авторизуется в домене под именем привилегированной учетной записи (например, администратора домена), полностью скомпрометировав доменную инфраструктуру.
Такая конфигурация — классический пример техники ESC4, которая может привести к полной потере контроля над инфраструктурой Active Directory. Подобные ошибки в настройках нужно незамедлительно устранять, тщательно проверяя и ограничивая права доступа к объектам шаблонов сертификатов.
Даже получив права на изменение шаблона, атакующему нужно выпустить по нему сертификат. Обычно для этого у злоумышленника либо уже есть право Enroll/Autoenroll, либо он может его добавить.
В ряде случаев у групп вроде Domain Users по умолчанию есть право Enroll для некоторых шаблонов (например, User Certificate), и это сочетается с ошибочно выданным правом Write / Full Control. Такая комбинация сразу открывает дорогу для ESC4.
Если же права на запись есть, а на запрос сертификата — нет, злоумышленник может сперва добавить себе или нужной группе право Enroll, используя права на запись WriteDACL, и таким образом обеспечить возможность запросить сертификат.
В итоге это условие сводится к тому, что злоумышленник способен изменить шаблон (отмечено 1 на скриншоте) и затем запросить по нему сертификат (отмечено 2 на скриншоте):
Это условие скорее неявное: шаблон, который атакующий делает уязвимым, должен быть приведен к такому состоянию, чтобы выпущенный по нему сертификат мог использоваться для входа в домен. В большинстве случаев это означает, что у шаблона есть (или появятся после изменения) подходящие расширения EKU, например Client Authentication или Smart Card Logon (OID для входа в AD).
Многие шаблоны пользователей уже содержат Client Authentication. Если нет, злоумышленник с правом WriteProperty может добавить нужный EKU, например Certificate Request Agent или Any Purpose, в случае реализации ESC2 или ESC3 через ESC4.
То есть необходимое условие — чтобы у шаблона был потенциал для доменной аутентификации. Чаще всего атакующий выбирает шаблон пользователя, у которого есть Client Authentication, либо добавляет этот EKU вручную.
Таким образом, исходные условия для ESC4:
- В AD есть шаблоны сертификатов с избыточными правами доступа (Owner, Full Control, WP, WD, WO) у широких групп.
- У атакующего есть учетная запись, подпадающая под эти права.
- Злоумышленник способен выпускать сертификаты по этому шаблону — напрямую или после изменения ACL.
При выполнении этих условий он может перейти к атаке.
Злоумышленник с правами на изменение шаблона редактирует его, делая шаблон уязвимым (обычно к ESC1, ESC2 или ESC3). Затем он запрашивает сертификат с привилегиями и использует его для получения доступа. Рассмотрим шаги атаки с примерами команд и инструментов.
Сначала атакующий сканирует конфигурацию AD CS на предмет шаблонов со слабыми ACL. Для этого можно использовать специальные утилиты (Certipy, Certify) или PowerShell-скрипты.
Например, скрипт PowerShell выполняет инвентаризацию всех шаблонов сертификатов в Active Directory и выводит список пользователей и групп, обладающих опасными правами доступа к каждому шаблону:
- WriteProperty — изменение параметров шаблона.
- WriteDACL — изменение прав доступа.
- WriteOwner — смена владельца.
- GenericAll, GenericWrite, Full Control — полный или почти полный контроль.
$root = [ADSI]"LDAP://RootDSE"
$config = $root.configurationNamingContext
$templatesDN = "LDAP://CN=Certificate Templates,CN=Public Key Services,CN=Services,$config"
$templates = [ADSI]$templatesDN
$templates.Children | ForEach-Object {
$acl = $_.psbase.ObjectSecurity
$entries = $acl.Access | Where-Object {
$_.ActiveDirectoryRights -match "WriteDacl|WriteOwner|WriteProperty|GenericAll|GenericWrite|FullControl"
}
if ($entries) {
Write-Host "`nШаблон: $($_.Name)"
foreach ($entry in $entries) {
Write-Host "`t$($entry.IdentityReference): $($entry.ActiveDirectoryRights)"
}
}
}
На скриншоте ниже показаны права шаблона ESC4, который отображается в списке всех уязвимых шаблонов.
Здесь видно то же самое, что и на скриншотах выше. У некоторых пользователей и групп есть критичные права, напрямую создающие условия для эксплуатации техники ESC4:
- NT AUTHORITY\Authenticated Users имеет право GenericAll, что эквивалентно полному контролю.
- Пользователи GOOD\mgoev и GOOD\hacker также имеют право GenericAll, то есть полный контроль над шаблоном.
- У групп Domain Admins и Enterprise Admins дополнительно есть права WriteDACL и WriteOwner, что позволяет им изменять списки доступа и владельца шаблона. Эти действия допустимы для администраторов, но, когда такие же права есть у неконтролируемых аккаунтов, это представляет угрозу.
- Domain Users имеют права WriteProperty, что уже позволяет им изменять параметры шаблона, включая флаги, EKU и другие свойства, влияющие на выпуск сертификатов.
Такая конфигурация делает шаблон максимально уязвимым для злоумышленника с учетной записью обычного пользователя: он может изменить шаблон, выпустить сертификат с повышенными привилегиями и использовать его для компрометации домена.
Альтернативно можно применить Python-инструмент Certipy: certipy find -vulnerable -u USER -p PASS -dc-ip DC_IP. Он автоматически покажет уязвимые к ESC4 шаблоны и даже укажет, какой именно тип прав делает их уязвимыми.
Далее злоумышленник редактирует свойства шаблона ESC4, чтобы сделать его небезопасным. Например, самое частое действие — включить в шаблоне флаг CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT, что соответствует уязвимости ESC1. Этот флаг (бит в атрибуте msPKI-Certificate-Name-Flag) позволяет субъекту запроса самостоятельно указать имя в сертификате:
На скриншоте видно, что этот параметр выключен. Злоумышленник выполняет следующую команду:
$template = [ADSI]"LDAP://CN=ESC4,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=GOOD,DC=EXPERT"
$template.Put("msPKI-Certificate-Name-Flag", 1)
$template.SetInfo()И включает параметр Supply in the request:
Атакующий может также отключить флаг требуемого одобрения менеджера (msPKI-Enrollment-Flag), убрав бит «проверка менеджером», или отключить требование авторизованной подписи. Эти меры нужны, если шаблон изначально требовал подтверждения или подписывался особым сертификатом. Проще говоря, конфигурация шаблона становится такой же, как при техниках ESC1, ESC2 и ESC3.
Инструменты вроде Certipy могут автоматизировать этот шаг. Например, команда certipy template -template "ESC4" -save-old -u USER -p PASS автоматически вносит изменения в шаблон, делая его уязвимым (по умолчанию подготавливает к ESC1). При этом -save-old сохраняет старые настройки на случай отката.
Дальнейшие действия злоумышленника зависят от того, какой вектор атаки он выберет для завершения эскалации привилегий: подделку SAN (ESC1), добавление универсальных EKU (ESC2) или получение сертификата агента (ESC3).
На этом этапе техника ESC4 выполняет свою ключевую функцию — предоставляет контроль над шаблоном сертификата и открывает путь к дальнейшей компрометации инфраструктуры. Здесь сценарий ESC4 завершается, уступая место реализации других атак.
Выявить атаки типа ESC4 может быть трудно, так как изменения происходят на уровне конфигурации AD (шаблон — объект в AD), а механизмы выпуска сертификатов затем используются стандартные. Однако есть несколько подходов к детектированию — от корреляции событий Windows до проактивного поиска неправильных настроек. Рассмотрим три основных направления обнаружения.
При правильно настроенном аудите AD CS ряд ключевых событий безопасности могут указать на атаку ESC4. Рассмотрим основные события на стороне CA и контроллеров домена.
Event ID 4899. A Certificate Services template was updated
Служба сертификатов регистрирует это событие, если при обработке запроса обнаружилось, что свойства шаблона изменились по сравнению с кешем в CA. Иными словами, 4899 появляется, когда CA загружает шаблон, а его параметры не совпадают с предыдущими (то есть шаблон недавно был модифицирован в AD). В событии содержатся измененные атрибуты шаблона, например будет отражен включенный флаг ENROLLEE_SUPPLIES_SUBJECT.
Однако есть важное ограничение: 4899 генерируется только при выпуске сертификата по измененному шаблону. То есть, если шаблон изменили, но никто не запрашивал по нему сертификат, 4899 не появится. Тем не менее в случае реальной атаки злоумышленник, скорее всего, сразу запросит сертификат, и событие возникнет.
Event ID 4900. A Certificate Services template security was updated
Это похожее событие, указывающее, что были изменены права доступа (ACL) шаблона. Логика та же: при попытке выпуска сертификата, если ACL в кеше CA отличается от текущего ACL шаблона в AD, появляется 4900. Это может произойти, например если злоумышленник добавил себе право Enroll или изменил владельца шаблона перед запросом.
В событии 4900 есть поле NewSecurityDescriptor, содержащее новый ACL (в SDDL). Оно позволяет проанализировать, какие права добавились или кому. Событие 4900 так же возникает только при попытке использования шаблона после изменения его ACL (вне контекста выпуска — нет).
Event ID 4898. Certificate Services loaded a template
Это событие возникает каждый раз, когда CA загружает шаблон для оценки поступившего запроса. Примечательно, что 4898 содержит полный дамп параметров шаблона:
На скриншоте события 4898 видны поля, которые позволяют сразу определить наличие уязвимости ESC4 по правам доступа на шаблон сертификата.
Поле Security Descriptor содержит полную информацию о правах и владельце шаблона. Здесь наиболее важны следующие параметры:
- Full Control (CCDCLCSWRPWPDTLOCRSDRCWDWO) — полное управление объектом шаблона, включая возможность менять его параметры и списки доступа (ACL).
- WriteProperty (WP), WriteDACL (WD), WriteOwner (WO) — дают злоумышленнику возможность изменять владельца, права доступа и свойства шаблона, делая его уязвимым.
Также на этом примере видно, что у групп Domain Admins и Enterprise Admins есть полные права (Full Control) — и это нормально. Но наличие этих же критичных прав (например, записи с WP, WD, WO) у любых других субъектов (например, Domain Users, Authenticated Users или любых обычных пользователей по их SID) указывает на технику ESC4.
Таким образом, просто анализируя поле Security Descriptor события 4898, можно легко идентифицировать опасные конфигурации шаблонов и заранее обнаружить потенциальную возможность проведения атаки ESC4.
Если рассматривать только ESC4, то ключевой признак уязвимости — это наличие опасных прав (WriteOwner, WriteDACL, WriteProperty, Full Control) у непривилегированных пользователей. Само по себе это уже достаточный индикатор риска. Но если в инфраструктуре используется много шаблонов с подобными правами, а задача — зафиксировать факт эксплуатации, а не просто наличие уязвимости, стоит расширить правила анализа. Например, можно учитывать:
- наличие Enroll для непривилегированных групп;
- возможность выпуска сертификата от имени доменных субъектов;
- наличие ограничения на одобрение шаблона.
Это позволит выявить именно начало эксплуатации, а не просто потенциально уязвимую конфигурацию. Тем не менее для ESC4 достаточно сосредоточиться на анализе прав доступа к шаблону, не углубляясь в его поведение при выдаче сертификатов.
Однако у события 4898 есть важное ограничение, о котором можно прочитать в справочных материалах.
Event ID 4662 и 5136 на контроллере домена
Это события аудита Directory Service Access/Changes. Если настроить SACL на объект Certificate Templates в контейнере AD CN=Public Key Services,CN=Services,CN=Configuration,<DN> на операции Write, как показано на скриншоте ниже, то при любом изменении шаблона в AD будет логироваться событие 4662 (а в Windows Server 2016+ — более информативное 5136).
В этих событиях сразу видно, какой аккаунт изменил конкретные атрибуты. Например, добавим пользователю BloodUser права на выпуск сертификата:
Проверим SID пользователя BloodUser командой:
(New-Object System.Security.Principal.NTAccount("GOOD\BloodUser")).Translate([System.Security.Principal.SecurityIdentifier]).Value
Узнаем, что SID = S-1-5-21-3912521324-1417072855-2443496624-1117.
Проверим событие 5136:
На представленном дескрипторе безопасности (SDDL) можно увидеть ряд важных ACE‑записей (Access Control Entries), которые указывают, какие именно права и каким пользователям были назначены для конкретного шаблона сертификата.
Например, запись OA;;CR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;S-1-5-21-3912521324-1417072855-2443496624-1117 означает, что указанный пользователь (SID с RID 1117) получил конкретное право на выпуск сертификата (Enroll). Это следует из комбинации:
- OA (Object Access) — расширенное разрешение, привязанное к объекту.
- CR (Control Access) — специальный доступ, в этом случае право на Enroll.
- GUID 0e10c968-78fb-11d2-90d4-00c04f79dc55 — уникальный идентификатор права на выпуск сертификата.
Подобные записи позволяют детектировать ситуации, когда непривилегированным пользователям выдаются права Enroll. Для поиска таких событий подходит мониторинг события 5136 (Directory Service Changes).
Однако сами по себе права Enroll выходят за рамки техники ESC4. Если задача — отслеживать исключительно ESC4, то ключевой фактор — именно наличие опасных прав на изменение самого шаблона:
- WP (WriteProperty);
- WD (WriteDACL);
- WO (WriteOwner);
- Full Control (CCDCLCSWRPWPDTLOCRSDRCWDWO).
Таким образом, если необходимо обнаруживать именно эксплуатацию техники ESC4, акцентируйте внимание на новых ACE‑записях, предоставляющих перечисленные опасные права изменения шаблонов, а не только права на выдачу сертификатов (Enroll).
Чтобы получать событие 5136 по изменению в конфигурации AD, необходимо включить его командой auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable. Также это можно сделать через расширенные групповые политики, как показано на скриншоте.
Анализируя перечисленные выше события, можно построить корреляционное правило, которое позволит выявлять попытки эксплуатации ESC4. Однако у каждого из этих событий есть свои ограничения:
- 4899 и 4900 появляются только после запроса на использование шаблона, то есть на этапе, когда злоумышленник уже начал действовать.
- 4898 срабатывает в момент загрузки шаблона CA, что происходит либо при первом обращении к шаблону, либо после перезапуска службы. Это также указывает на активную фазу атаки.
- 5136 фиксирует изменения в объекте шаблона в AD, но тоже относится к уже происходящей активности (например, модификации прав), а не к факту наличия уязвимости как таковой.
Именно поэтому наиболее эффективной стратегией остается проактивный подход — выявление уязвимых шаблонов до того, как начнется атака.
Далее подробно поговорим о том, как выявлять такие уязвимые шаблоны на этапе их конфигурации — без опоры на события.
Лучший способ защититься от атак, связанных с ESC4, — это заранее выявлять уязвимые шаблоны сертификатов, не дожидаясь их эксплуатации. Такой подход называют обнаружением на основе конфигурации. Фактически это аудит настроек AD CS, направленный на выявление потенциально опасных конфигураций.
Регулярно проверяйте ACL шаблонов сертификатов. Особое внимание уделяйте группам и пользователям, которые по умолчанию не должны иметь повышенных привилегий, например Domain Users, Authenticated Users, Everyone. У таких групп или пользователей не должно быть опасных прав, таких как Full Control, WriteProperty (WP), WriteDACL (WD) или WriteOwner (WO).
Проверку можно автоматизировать с помощью специализированных модулей, например PowerView, либо провести вручную, используя встроенные средства Windows. Например, вот простой способ проверки через PowerShell без сторонних инструментов:
$root = [ADSI]"LDAP://RootDSE"
$config = $root.configurationNamingContext
$templatesDN = "LDAP://CN=Certificate Templates,CN=Public Key Services,CN=Services,$config"
$templates = [ADSI]$templatesDN
$templates.Children | ForEach-Object {
$acl = $_.psbase.ObjectSecurity
$entries = $acl.Access | Where-Object {
$_.ActiveDirectoryRights -match "WriteDacl|WriteOwner|WriteProperty|GenericAll|GenericWrite|FullControl"
}
if ($entries) {
Write-Host "`nШаблон: $($_.Name)"
foreach ($entry in $entries) {
Write-Host "`t$($entry.IdentityReference): $($entry.ActiveDirectoryRights)"
}
}
}После этого вы получите результат с уязвимым шаблоном, останется исправить неправильные настройки:
Но как быть, если требуется контроль в реальном времени и проверка уже созданных уязвимых сертификатов? Ответ рассмотрим на примере BI.ZONE EDR.
Самый эффективный подход — это мониторинг состояния шаблонов не только периодически, но и в режиме реального времени. Рассмотрим, как такую защиту можно реализовать на основе BI.ZONE EDR.
В Windows при любом изменении или создании шаблона сертификата (даже без его непосредственного использования или перезапуска службы CA) информация об этом автоматически сохраняется в реестре по пути HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\CertificateTemplateCache\<Имя шаблона>:
Здесь находится вся необходимая информация о шаблонах. Однако дескрипторы безопасности (SDDL) хранятся в закодированном виде и напрямую не читаются.
BI.ZONE EDR решает эту проблему следующим образом:
- Агенты EDR, установленные на хостах, собирают данные об изменениях в шаблонах сертификатов в реальном времени.
- При обнаружении изменений по указанному пути автоматически извлекаются и расшифровываются дескрипторы безопасности. После этого данные отправляются на анализ.
- На основе полученных данных (об ошибках конфигураций) формируется правило предикта. Оно выделяет события, где непривилегированные пользователи или группы получают критичные права на изменение шаблонов (например, Full Control, WriteDACL, WriteOwner, WriteProperty).
Таким образом получается эффективное комбинированное правило, которое контролирует состояние шаблонов сертификатов как в реальном времени, так и ретроспективно — включая шаблоны, созданные или измененные ранее.
Если в инфраструктуре нет уязвимых шаблонов, то нет и риска атаки. Но даже в ситуации, когда злоумышленник пытается скрыть следы, назначая опасные права не самому себе, а низкопривилегированным пользователям для последующего незаметного использования, агент BI.ZONE EDR сразу же обнаружит такие изменения и предотвратит атаку еще до того, как она начнется.
Подобный проактивный подход обеспечивает гораздо более высокую степень защищенности, чем простое реагирование на уже произошедшие события.
Как видно, ESC4 — это прежде всего проблема неправильной конфигурации. Значит, основными мерами защиты будут приведение настроек AD CS в порядок и ограничение возможностей, которыми злоумышленник может воспользоваться. Вот практические рекомендации.
Проведите полную ревизию ACL всех шаблонов, особенно кастомных и скопированных. Убедитесь, что низкопривилегированные группы (например, Domain Users, Authenticated Users, Users, Everyone) не обладают следующими правами:
- Full Control;
- Write;
- WriteDACL;
- WriteOwner;
- Owner.
Строго ограничьте редактирование шаблонов:
- Только Enterprise Admins или специально делегированные администраторы PKI должны иметь права на управление.
- Даже группы вроде Account Operators или Backup Operators не должны иметь доступа к шаблонам.
Если необходимо делегировать управление, создайте отдельную группу с минимальными правами, например только на дублирование шаблонов без права изменять существующие. Удалите все лишние ACE из ACL шаблонов.
Удалите из публикации устаревшие и неиспользуемые шаблоны или измените их, особенно те, которые:
- дают право Enroll всем пользователям;
- включают такие опции, как SAN и UPN, без контроля.
Чтобы удалить шаблон из публикации:
- Запустите
certsrv.msc. - Откройте Certificate Templates.
- Кликните правой кнопкой мыши и выберите Unpublish.
Оставьте только необходимые бизнесу шаблоны и настройте их по принципу минимально необходимых прав.
Ошибка, приводящая к ESC4, часто возникает, когда одни и те же пользователи имеют и право Enroll, и право редактирования шаблона. Это создает условия для атаки.
Разделите права:
- Если у группы есть право Enroll, убедитесь, что она не может редактировать шаблон.
- Если кому‑то делегировано редактирование, отключите для него право Enroll.
Такой контроль разрушает потенциальную цепочку атаки еще на стадии подготовки.
Для чувствительных шаблонов активируйте:
- Manager Approval — заявка требует подтверждения администратором CA перед выпуском. Это снижает риск ESC1 и ESC2, но не защищает от ESC4, если злоумышленник может изменить шаблон.
- Authorized Signature — выпуск сертификата возможен только при наличии подписи определенного сертификата, например сертификата агента. Это добавляет барьер: даже при уязвимом шаблоне злоумышленнику понадобится получить дополнительный уровень доступа.
Тем не менее и эти механизмы могут быть отключены, если есть доступ к WriteDACL. Поэтому приоритет всегда остается за контролем ACL.
Обязательно проверяйте установку обновлений безопасности.
Настройте аудит критически важных событий, как было описано выше в этой главе.
Техника ESC4 показывает, насколько критичны правильные настройки доступа в инфраструктуре AD CS. Если шаблоны сертификатов попадают под контроль злоумышленника, он, начав с обычной учетной записи, способен в несколько шагов получить сертификат доменного администратора и скомпрометировать весь домен.
Для специалистов по безопасности ESC4 служит напоминанием: AD CS нужно защищать так же тщательно, как контроллеры домена. Часто CA и шаблоны остаются без должного внимания, в то время как доменные политики и AD‑объекты контролируются. Эта техника демонстрирует, что через уязвимый шаблон можно обойти защиту и проникнуть в домен.
Противодействие ESC4 достигается комбинацией мер: превентивной конфигурацией и детектированием. Если строго ограничить права на шаблоны и включить контроль за их изменениями, вероятность успешной атаки упадет до минимума. Ведь злоумышленнику просто не удастся получить нужные права незаметно, а если он попытается — система мониторинга сразу подаст сигнал.
Важно помнить, что, помимо ESC4, существуют и другие векторы (ESC1 — ESC16), которые также используют ошибки конфигурации. Поэтому соблюдение принципов минимальных привилегий, аудит и обновления обеспечат защиту не только от ESC4, но и от аналогичных методов.
В итоге ESC4 — грозный, но предсказуемый враг: его успешность зависит от человеческой ошибки в настройках. Осведомленность о технике и внедрение соответствующих мер значительно повышают безопасность PKI и помогают закрыть один из ключевых путей к компрометации домена.