ESC1. Сертификат без границ
ESC1 — это атака, при которой злоумышленник самостоятельно указывает имя владельца сертификата и таким образом может пройти аутентификацию от имени любого пользователя, включая администратора.
Ключевое отличие ESC1 от остальных ESC-атак состоит именно в том, что атакующий может напрямую получить сертификат на чужое имя, воспользовавшись правом самостоятельно задавать владельца сертификата (Subject Alternative Name, SAN). В других, например ESC2 или ESC3, злоумышленник либо получает сертификат только на свое имя, но с расширенными возможностями (ESC2), либо сначала становится доверенным агентом регистрации и уже затем запрашивает сертификат от имени другого пользователя (ESC3).
Иными словами, ESC1 — это прямой и самый простой путь аутентифицироваться от чьего угодно имени, сразу перепрыгнув через промежуточные этапы.
Допустим, обычный пользователь с учетной записью hacker хочет получить сертификат от имени высокопривилегированной учетной записи testeradm. Для этого он использует уязвимый шаблон сертификата под названием ESC1.
Успешная реализация атаки возможна, только если шаблон ESC1 соответствует следующим условиям:
-
Разрешено указывать Subject Alternative Name.
Критически важное условие для ESC1. Шаблон сконфигурирован с флагом Supply in the request (информация предоставляется в запросе) для имени субъекта. Это означает, что запросивший сертификат может самостоятельно задать поля SAN в CSR. При таком сценарии Active Directory при проверке сертификата будет доверять имени из поля SAN. Таким образом, злоумышленник способен запросить сертификат на имя любого пользователя домена, указав его UPN/имя в SAN. Флаг
CT_FLAG_ENROLLEE_SUPPLIES_SUBJECTв атрибутеmspki-certificate-name-flagобъекта шаблона установлен, что и соответствует опции Supply in the request в консолиcerttmpl.msc.
-
Непривилегированный пользователь имеет право регистрации сертификатов.
Шаблон сертификата настроен так, что группа вроде Domain Users или Authenticated Users имеет разрешение Enroll (регистрация) на выдачу по этому шаблону. Это подразумевает, что корпоративный удостоверяющий центр (Enterprise CA) не ограничивает обращение к этому шаблону — им могут пользоваться не только администраторы.
-
Не требуется одобрение менеджера.
Для шаблона отключено подтверждение запроса менеджером сертификатов перед выдачей. Флаг CA certificate manager approval не установлен.
-
Не нужны авторизованные подписи.
Шаблон не требует дополнительной подписи запроса другим доверенным сертификатом.
-
Опасные EKU (extended key usage).
Шаблон определяет расширенные назначения ключа, позволяющие аутентификацию. В частности, либо EKU отсутствуют вовсе (шаблон SubCA), либо есть хотя бы один из следующих EKU:
- Client Authentication (OID 1.3.6.1.5.5.7.3.2),
- PKINIT Client Authentication (OID 1.3.6.1.5.2.3.4),
- Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2),
- Any Purpose (OID 2.5.29.37.0) — универсальный EKU.
Такие EKU позволяют впоследствии использовать выданный сертификат для удостоверения в системе (например, для Kerberos-/LDAP-аутентификации в качестве пользователя).
Если все эти условия выполняются, злоумышленник с обычной доменной учетной записью может обмануть AD CS и получить сертификат на имя другого пользователя с высокими правами, например Domain Admin.
Если есть уязвимый шаблон сертификата, атака проводится в несколько шагов. Злоумышленники обычно используют инструменты вроде Certify
-
Поиск уязвимого шаблона. На первом этапе атакующий ищет шаблоны, уязвимые к сценарию ESC1. Для этого он использует инструменты, такие как Certify или Certipy. Например, команда
Certify.exe find /vulnerableищет потенциально уязвимые шаблоны. Аналогичная команда в Certipy выглядит так:certipy find -u <user>@<domain> -p <password> -dc-ip <DC_IP> -vulnerable.
Обе команды выводят список шаблонов, у которых:
- отключено требование одобрения запроса,
- нет подписей,
- разрешен SAN и т. д.
Затем злоумышленник открывает созданный файл и ищет условия для уязвимого шаблона ESC1, на рисунке ниже они выделены красным.
-
Запрос сертификата с поддельным SAN. Обнаружив подходящий шаблон, атакующий запрашивает новый сертификат, выдаваемый CA, но указывает в запросе SAN с именем привилегированной цели.
Если все условия шаблона выполнены, центр сертификации успешно выпускает сертификат. Злоумышленник получает файл сертификата (и закрытый ключ), например
.pfx.Вот как выглядит запрос сертификата от пользователя hacker на имя testeradm c административными правами с использованием Certipy (уязвимый шаблон ESC1):
-
Аутентификация с полученным сертификатом. Это финальный этап: используя выданный сертификат, злоумышленник аутентифицируется в домене. Сертификат (с приватным ключом) можно импортировать и применять для PKINIT-аутентификации в Kerberos либо для прямого входа через Schannel (LDAPS, RDP со смарт-картой и т. п.). На практике это реализуют с помощью утилит вроде Rubeus (для получения TGT по сертификату) или Certipy.
ПримерЧтобы получить Kerberos TGT и немедленно передать его в текущую сессию, используется следующая команда:Rubeus.exe asktgt /user:Administrator /certificate:adminCert.pfx /password:<pfx_password> /ptt.Для Certipy команда выглядит так:certipy auth -pfx enterpriseadmin.pfx -username Administrator -domain domain.local -ptt.
Результат:- Получен TGT для
testeradm@good.expert. - Сохранен Kerberos-билет в формате
.ccache(testeradm.ccache). - Извлечен NT-хеш пользователя:
aad3b435b51404eeaad3b435b51404ee:e21b1d9764cb0044f5f9dcfdc1670f1a
- Получен TGT для
Важное преимущество такой атаки — она не зависит от компрометации паролей или хешей. Злоумышленник получает легитимный, хотя и ненадлежащим образом выданный аутентификационный сертификат. Более того, срок действия такого сертификата может быть длительным (в соответствии с настройками шаблона), что обеспечивает долгосрочный скрытный доступ, пока сертификат не отзовут или не истечет срок его действия.
Выявить атаку ESC1 непросто, потому что она задействует штатные механизмы AD CS. Тем не менее есть характерные признаки, по которым можно обнаружить как уязвимость в конфигурации, так и факт ее эксплуатации. Есть два подхода к выявлению атаки:
- Использование телеметрии Windows для событий корреляции и запуск скриптов/утилит для сбора дополнительной информации об уязвимых настройках.
- Обнаружение с помощью EDR. Этот подход устраняет такие недостатки штатной телеметрии и запуска скриптов, как необходимость настройки сбора логов в SIEM, ручной запуск скриптов или утилит, строгие условия регистрации событий штатного аудита и другие.
Анализ журналов AD CS (события)
Если в Windows включен аудит службы сертификации, система регистрирует события безопасности, связанные с запросами и выдачей сертификатов. Ключевые Event ID — 4886 и 4887 в журнале Microsoft-Windows-CertificateServices%4Operational (или Security при определенных настройках).
- Event ID 4886 фиксируется, когда CA получает запрос на сертификат. Событие указывает, какая учетная запись запросила сертификат и по какому шаблону. Если заявка не требует одобрения, следующим событием будет сразу выдача.
- Event ID 4887 означает, что удостоверяющий центр успешно выдал сертификат. В данных события 4887 содержится информация о выданном сертификате: серийный номер, шаблон, имя субъекта и, что особенно важно, поле SAN (если оно есть).
Дополнительно во время обращения к шаблону центр сертификации может логировать Event ID 4898 с деталями шаблона. Это происходит, когда обновляется база сертификатов или когда пользователь запрашивает сертификат.
Например, событие 4898 содержит экспорт шаблона в текстовом виде. В нем можно искать потенциально уязвимые настройки, например строку CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT или указание OID 2.5.29.37.0 (Any Purpose), если при этом в разделе Security Descriptor выданы права Domain Users.
На основе вышесказанного можно подойти к корреляционному правилу двумя разными способами:
-
Проактивный подход (по событию 4898). Самый простой и надежный способ — регулярно проверять событие 4898. Оно регистрируется каждый раз при загрузке шаблонов сертификатов и содержит важные детали:
- права пользователей и групп на регистрацию сертификатов;
- настройки безопасности шаблона (например, наличие опасных флагов типа
ENROLLEE_SUPPLIES_SUBJECT, отключение проверки одобрения менеджером).
- Корреляционный подход (по событиям 4886, 4887 и 4898). Более сложный, но также эффективный подход — корреляция нескольких событий:
- 4886 — при поступлении запроса сертификата;
- 4887 — при успешной выдаче сертификата;
- 4898 — при загрузке шаблонов сертификатов с их настройками.
В SIEM-системе можно реализовать корреляционное правило для выявления атаки ESC1. Для этого в течение заданного времени (например, 10 минут) система должна:
- собирать события 4886 и 4887, чтобы выявить случаи, когда запрос отправил один пользователь, а сертификат выдан на другого;
- анализировать событие 4898 с тем же именем шаблона, чтобы проверить наличие опасных конфигураций (например, разрешение указывать SAN вручную, отсутствие одобрения запроса).
Срабатывание правила происходит, если одновременно выполняются следующие условия:
- Совпадают имя шаблона сертификата и имя хоста, с которого поступил запрос.
- Обнаружено несовпадение между Requester и Subject (запросил один, сертификат выдан на другого).
- В шаблоне присутствуют уязвимые настройки, такие как:
- Supply in the request включен;
- отключено подтверждение запроса менеджером;
- разрешена регистрация для обычных пользователей;
- EKU позволяют аутентификацию (например, Client Authentication, Smart Card Logon и др.).
Такое правило позволяет выявлять факт эксплуатации ESC1 в режиме, близком к реальному времени.
Больше о событии 4898 — в дополнительных материалах.
Сложность обнаружения с помощью событий 4898, 4886 и 4887 — в том, что они появляются только при фактическом обращении к шаблону. А если шаблон уязвим, но им никто не пользуется, событий не будет. То есть корреляция будет работать уже по факту атаки, что полезно, но недостаточно.
Эффективнее выявлять уязвимые шаблоны заранее через предиктивный анализ конфигурации, то есть еще до того, как злоумышленник их проэксплуатирует.
Шаблон создается и добавляется в раздел центра сертификации, как показано на скриншоте:
Сразу после этого сертификат добавляется в кеш сертификатов, который находится в реестре по пути: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\CertificateTemplateCache.
В реестре Windows хранится вся конфигурационная информация о шаблонах сертификатов, за исключением дескрипторов безопасности (SDDL), которые представлены в зашифрованном виде. На примере шаблона ESC1 дескрипторы безопасности можно узнать следующей командой:
Get-ADObject -LDAPFilter "(cn=ESC1)"
-SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,$((Get-ADRootDSE).configurationNamingContext)"
-Properties nTSecurityDescriptor |
Select-Object -ExpandProperty nTSecurityDescriptor |
Select-Object -ExpandProperty Sddl
В результате команда выведет строку SDDL:
Для предиктивного выявления уязвимостей необходимо использовать поэтапный подход:
- Отфильтровать шаблоны по признакам потенциальной опасности: отсутствию требования одобрения менеджером, разрешению на указание SAN вручную, наличию EKU для аутентификации (например, Client Authentication).
- Расшифровать SDDL-дескрипторы с помощью PowerShell или другого инструмента, чтобы определить, выданы ли права Enroll непривилегированным пользователям или группам (например, Domain Users, Authenticated Users).
- Сопоставить обнаруженные риски с событиями аудита безопасности и скорректировать уязвимые шаблоны, устранив избыточные или неправомерные права.
Такой подход позволяет не только выявлять текущие ошибки конфигурации, но и предупреждать будущие атаки, основываясь на поведенческих и структурных индикаторах. Однако он требует ручной работы аналитиков или специалистов по кибербезопасности, чтобы собирать информацию на регулярной основе.
BI.ZONE EDR устраняет недочеты предыдущих способов, одновременно реализуя как детектирование самой атаки, так и обнаружение уязвимых настроек. Решение позволяет обнаружить атаку или намеренное ослабление настроек сертификата на более раннем этапе, чем штатная телеметрия Windows. Это достигается за счет того, что BI.ZONE EDR регистрирует любые изменения шаблона сертификатов и отражает это в телеметрии (штатные события аудита Windows генерируются лишь в ограниченных случаях, например при самом запросе сертификата атакующим). Данные же, необходимые для поиска мисконфигураций, собираются автоматически, не задействуя ресурсы аналитиков или специалистов по кибербезопасности.
BI.ZONE EDR проактивно выявляет уязвимые шаблоны сертификатов следующим образом:
- Агенты EDR, установленные на хостах с ролью AD CS, сразу после развертывания и затем с заданной периодичностью проводят полную инвентаризацию шаблонов сертификатов, собирая все их параметры из ветки реестра
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\CertificateTemplateCache. - Для каждого собранного шаблона дополнительно извлекаются и расшифровываются дескрипторы безопасности (SDDL).
- Также агенты постоянно мониторят ветку реестра на любые изменения шаблонов сертификатов. Если появляются любые изменения, информация о них мгновенно собирается и отправляется на оперативный анализ.
Рассмотрим, как выявляются мисконфигурации, на примере правила обнаружения:
sddl:(";0e10c968-78fb-11d2-90d4-00c04f79dc55;;DU" OR
";0e10c968-78fb-11d2-90d4-00c04f79dc55;;AU" OR
";0e10c968-78fb-11d2-90d4-00c04f79dc55;;WD")
-"CT_FLAG_PEND_ALL_REQUESTS" AND
("CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT" AND
"msPKI-RA-Signature = 0") AND
("1.3.6.1.4.1.311.20.2.2" OR "1.3.6.1.5.2.3.4" OR "1.3.6.1.5.5.7.3.2")
Это правило в режиме реального времени выявляет любые шаблоны сертификатов, которые одновременно удовлетворяют следующим условиям:
- Разрешают пользователю самостоятельно указывать имя субъекта (флаг
CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT). - Не требуют авторизованной подписи (
msPKI-RA-Signature = 0). - Не требуют подтверждения менеджером (
CT_FLAG_PEND_ALL_REQUESTSотсутствует). - Имеют расширенные возможности аутентификации в домене (EKU типа Client Authentication — 1.3.6.1.5.5.7.3.2, Smart Card Logon — 1.3.6.1.4.1.311.20.2.2 или PKINIT — 1.3.6.1.5.2.3.4).
- Доступны для регистрации широкому кругу пользователей или привилегированным группам (Domain Users, Authenticated Users, Everyone), что проверяется по расшифрованным SDDL.
Одновременное выполнение этих условий означает, что любой непривилегированный пользователь теоретически может запросить и получить сертификат от имени другого пользователя, в том числе администратора домена, что является классическим сценарием атаки ESC1.
Подробная информация о флагах и дескрипторах — в дополнительных материалах.
Для защиты от атаки ESC1 необходимо исправить конфигурацию шаблонов и укрепить процессы, связанные с выдачей сертификатов:
-
Отключить Supply in the request для имени субъекта. Во всех пользовательских шаблонах снимите флажок Supply in the request (информация будет предоставлена в запросе) на вкладке Subject Name. Используйте вариант Build from this Active Directory information (формировать из данных AD) — это не даст указать чужой SAN в запросе. Если по каким-то причинам необходимы альтернативные имена (например, для веб-сертификатов), убедитесь, что шаблон с такими правами недоступен для обычных пользователей.
- Ограничить EKU-аутентификацию. Пересмотрите EKU в шаблонах. Шаблоны, предназначенные не для аутентификации пользователей, не должны содержать Client Authentication, Smart Card Logon или тем более Any Purpose. Удалите лишние EKU: например, сертификат для шифрования файлов (EFS) не должен иметь возможность использоваться для входа в систему.
- Включить подтверждение выдачи. Для особо критичных шаблонов имеет смысл задействовать менеджерскую проверку (certificate manager approval). На вкладке Issuance Requirements у шаблона установите флажок CA certificate manager approval, чтобы любой запрос требовал ручного одобрения администратором CA. Хотя это неудобно для массовых сценариев, для редких и привилегированных шаблонов такая мера добавит дополнительный уровень защиты: даже если злоумышленник сможет отправить запрос, сертификат не выпустится автоматически.
- Требовать дополнительные подписи (authorized signatures). Альтернативно предыдущему пункту или совместно с ним можно настроить требование, чтобы запрос на сертификат был подписан действующим сертификатом определенного типа. Например, можно установить Number of authorized signatures = 1 и указать шаблон, сертификаты по которому могут выступать в роли подписанта (скажем, требовать подпись корпоративного PKI-офицера). В контексте ESC1 это избыточно, проще отключить SAN, но общая практика может повысить безопасность.
- Ограничить права на шаблоны. Пересмотрите ACL шаблонов. Как правило, для пользовательских шаблонов не требуется предоставлять права Enroll всем пользователям домена. Достаточно выдавать их группам, которым реально нужны эти сертификаты. Уберите группы Domain Users / Authenticated Users из списка Enrollment. Оставьте только конкретные группы или учетные записи. Желательно, чтобы учетные записи с высокими привилегиями (администраторы) вообще не присутствовали в SAN других сертификатов. Поэтому не давайте возможность кому-либо запрашивать сертификаты на их имя.
- Обновить шаблоны и CA до современных версий. Некоторые устаревшие схемы шаблонов (v1) имеют меньше настроек безопасности. Обновление до схемы v3/v4 может включать больше возможностей контроля. Также убедитесь, что сам CA работает на поддерживаемой версии Windows Server с последними обновлениями.
- Настроить мониторинг и оповещение. Настройте оповещения об описанных выше событиях (4887 SAN mismatch, попытки выдачи на административные SAN). Контролируйте журнал выдачи сертификатов (Certification Authority → Issued Certificates) на предмет подозрительных записей. Регулярно просматривайте отчеты аудита PKI.
- Обучить администраторов. Часто уязвимые настройки появляются из-за незнания. Удостоверьтесь, что ответственные за шаблоны сертификатов понимают последствия включения опции Supply in the request. Например, при включении этого флага консоль
Certtmpl.mscпредупреждает: «If subject name is supplied in request, CA will not verify it», — это явный сигнал опасности. Администраторы должны относиться к таким предупреждениям серьезно и понимать, как реализуются атаки вроде ESC1, чтобы не допускать подобной конфигурации. - Включить подтверждение заявок на уровне CA. Тогда перед выдачей всех сертификатов будет требоваться ручное одобрение администратора.
Атака ESC1 на AD CS — один из самых прямых и опасных сценариев злоупотребления инфраструктурой сертификатов. Без взлома паролей или эксплуатации традиционных уязвимостей злоумышленник фактически получает возможность стать любым пользователем в домене, включая доменных администраторов.
Эксперты по безопасности отмечают, что уязвимость ESC1 — одна из наиболее часто встречающихся проблем в конфигурациях AD CS. Например, исследование SpecterOps
