Привет, Хабр! По горячим следам нашей большой статьи про векторы атак ESC1-ESC15 мы — команда PT Cyber Analytics — решили подробно разобрать относительно новый вектор атаки ESC16. Возможность обнаружения и эксплуатации этого вектора была добавлена в майском обновлении ПО Certipy.

С предпосылками, историей возникновения подобных атак и основной терминологией вы можете ознакомиться в нашей предыдущей публикации. В этой же статье мы сразу перейдем к рассмотрению вектора атаки ESC16, обсудим условия для его возникновения, детали его эксплуатации, а также дадим превентивные рекомендации и рекомендации для его обнаружения.

Статья носит исключительно информационный характер и не является инструкцией или призывом к совершению противоправных деяний. Наша цель — рассказать о существующих уязвимостях, которыми могут воспользоваться злоумышленники, предостеречь пользователей и дать рекомендации по защите своей личной информации в Интернете. Авторы не несут ответственности за использование информации. Помните, что не стоит забывать о безопасности своих личных данных.

Технические детали

Для реализации данного вектора необходимо выполнение следующих условий:

• На центре сертификации отключено расширение безопасности szOID_NTDS_CA_SECURITY_EXT (в раздел реестра центра сертификации в параметр DisableExtensionList добавлен OID 1.3.6.1.4.1.311.25.2).

• Ключ реестра StrongCertificateBindingEnforcement на контроллере домена не принимает значение 2.

• Шаблон сертификата позволяет использовать сертификат для аутентификации.

• Наличие права GenericWrite по отношению к учетной записи, от имени которой запрашивается сертификат.

Расширение szOID_NTDS_CA_SECURITY_EXT появилось в обновлениях для системы безопасности в мае 2022 года (KB5014754) и используется для реализации сильного маппинга сертификатов (strong certificate mapping), позволяя контроллерам домена надежно сопоставлять выданный сертификат с SID пользователя или учетной записи рабочей станции (machine account) для проверки подлинности.

Когда в центре сертификации добавлено расширение с OID 1.3.6.1.4.1.311.25.2 в параметре реестра policy\DisableExtensionList в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA-Name>\PolicyModules\<PolicyModuleName>, каждый выданный сертификат будет выпущен без расширения безопасности szOID_NTDS_CA_SECURITY_EXT. Это фактически приводит к тому, что все шаблоны, опубликованные этим центром сертификации, ведут себя так, как если бы они были индивидуально настроены с флагом CT_FLAG_NO_SECURITY_EXTENSION (как это происходит в векторе атаки ESC9).

Настройки реестра сервера центра сертификации при отключенном расширении безопасности szOID_NTDS_CA_SECURITY_EXT

В свою очередь, если контроллеры домена не обеспечивают сильный маппинг сертификатов — значение ключа реестра StrongCertificateBindingEnforcement не принимает значение 2 (режим полного применения) — они возвращаются к старым, менее безопасным методам маппинга. Эти методы часто полагаются на такие значения, как UPN (userPrincipalName) для пользователя или DNS (dNSHostName) для учетной записи рабочей станции, находящиеся в поле альтернативного имени субъекта (SAN) сертификата. К небезопасным значениям ключа реестра StrongCertificateBindingEnforcement относятся значение 0 (сильный маппинг не реализован) и значение 1 (режим совместимости, если используется явный маппинг, аутентификация разрешена). По информации от компании Microsoft, 10 сентября 2025 года режим совместимости будет полностью отменен, раздел реестра StrongCertificateBindingEnforcement больше не будет поддерживаться.

Такие небезопасные настройки могут появиться в результате попыток администраторов устранить проблемы совместимости после майских исправлений 2022 года. Вместо устранения проблем в конкретных шаблонах или клиентских системах многие администраторы решают использовать обходной путь и глобально отключить новое расширение безопасности, что и приводит к возможности эксплуатации вектора атаки ESC16. Также такая небезопасная настройка возможна, если сам сервер центра сертификации и контроллеры домена не обновлялись с мая 2022 года, когда вышло обновление безопасности (KB5014754). Последующие накопительные обновления после мая 2022 года также содержат необходимые исправления. В случае, если сервер центра сертификации не обновлялся до версий, содержащих эти исправления, он вообще не может использовать расширение безопасности szOID_NTDS_CA_SECURITY_EXT.

Условия, описанные выше, позволяют пользователям с низким уровнем привилегий запросить сертификат, выдавая себя за привилегированную учетную запись, и с помощью полученного сертификата успешно аутентифицироваться на необходимом узле или на контроллере домена, обходя проверку на основе SID. Таким образом, злоумышленник может повысить свои привилегии в среде Active Directory и получить полный контроль над инфраструктурой.

Эксплуатация

Механизмы эксплуатации вектора атаки ESC16 в целом схожи с механизмами вектора атаки ESC9, поскольку результат эксплуатации вектора атаки ESC16 такой же — сертификат без расширения безопасности szOID_NTDS_CA_SECURITY_EXT. Однако между данными векторами есть одно важное отличие: как мы уже упоминали ранее, в случае с вектором атаки ESC9 уязвимым будет только тот шаблон, который содержит флаг CT_FLAG_NO_SECURITY_EXTENSION (расширение безопасности szOID_NTDS_CA_SECURITY_EXT не будет добавлено в выпущенный по этому шаблону сертификат), в случае же с вектором атаки ESC16 любой шаблон сертификата для аутентификации, выпущенный небезопасно настроенным центром сертификации, будет являться уязвимым и может быть использован для атаки с манипуляцией UPN. 

Давайте перейдем к разбору того, как это работает.

Для начала атакующему необходимо определить, имеет ли центр сертификации небезопасные настройки, а именно – настроен ли центр сертификации на глобальное отключение расширения безопасности szOID_NTDS_CA_SECURITY_EXT. Это можно сделать с помощью команды find ПО Certipy, обновленной в мае этого года.

Далее для эксплуатации ESC16 атакующему необходимо наличие права GenericWrite по отношению к атакуемой учетной записи, то есть у атакующего должно быть разрешение на изменение userPrincipalName (UPN) другого доменного пользователя. Кроме того, необходимо выбирать такого атакуемого пользователя, который имеет разрешение на выпуск сертификата с использованием шаблонов сертификата для аутентификации (например, User). Целью для имперсонации может быть выбран любой произвольный привилегированный пользователь, например, administrator. Также атакующий должен знать логин и пароль атакуемой учетной записи. Для получения учетных данных пользователя может быть проведена, например, атака Shadow Credentials.

Далее атакующий, в нашем примере user, меняет UPN пользователя test16 на UPN другого пользователя, например, привилегированного пользователя administrator. Это необходимо, чтобы при запросе сертификата выдать себя за более привилегированного пользователя или пользователя, чьи права интересны атакующему, то есть имперсонировать пользователя administrator.

Далее атакующий запрашивает сертификат от имени пользователя test16 на имя пользователя, указанного в UPN. В выпущенном сертификате автоматически не будет расширения безопасности SID из-за уязвимой к вектору атаки ESC16 конфигурации центра сертификации.

Затем атакующий меняет оригинальное значение UPN, чтобы минимизировать риски обнаружения и избежать потенциальных проблем при аутентификации.

Всё, теперь атакующий может аутентифицироваться на контроллере домена с использованием сертификата и получить TGT привилегированного пользователя. Атака успешно проведена.

Эксплуатация ESC16 в сочетании с ESC6

Данный метод атаки работает, даже если контроллеры домена находятся в режиме полного применения (ключ реестра StrongCertificateBindingEnforcement = 2).

При проведении данной цепочки атак хакер запрашивает сертификат с использованием любого шаблона, подходящего для аутентификации клиента (допустим, User, как показано в примере команды для запроса сертификата ниже), в уязвимом для вектора атаки ESC16 центре сертификации. Наличие настроек, приводящих к вектору атаки ESC16, гарантирует, что центр сертификации не будет добавлять расширения безопасности SID в сертификаты. Одновременно используется вектор атаки ESC6 в том же центре сертификации, который позволяет атакующему внедрить SID цели в SAN, используя специальный формат URL.

certipy req \
    -u 'attacker@corp.local' -p 'Passw0rd!' \
    -dc-ip '10.0.0.100' -target 'CA.CORP.LOCAL' \
    -ca 'CORP-CA' -template 'User' \
    -upn 'administrator@corp.local' -sid 'S-1-5-21-...-500'

Key Distribution Center (KDC), не обнаружив расширения безопасности SID (из-за ESC16), но увидев URL-адрес с SID в SAN (из-за ESC6), будет использовать SID из SAN. В результате нарушитель может получить сертификат на имя произвольного привилегированного пользователя и с помощью него повысить свои привилегии в домене.

Превентивные меры защиты

Включить расширение безопасности SID в центре сертификации. Для этого необходимо удалить OID 1.3.6.1.4.1.311.25.2 из параметра DisableExtensionList раздела реестра. Здесь может быть использована следующая команда:

certutil -setreg policy\DisableExtensionList -1.3.6.1.4.1.311.25.2

Префикс «-» перед OID удаляет его из списка. Проверить успешное удаление OID можно с помощью команды

certutil -getreg policy\DisableExtensionList).

После выполнения данной команды необходимо перезапустить центр сертификации, чтобы внесенные изменения применились.

net stop certsvc
net start certsvc

Обновить все серверы, на которых запущены службы сертификатов Active Directory, и контроллеры домена Windows, обслуживающие проверку подлинности на основе сертификатов, до актуальной версии, содержащей необходимые исправления (KB5014754). После установки обновлений сервер сможет создать и включить расширение безопасности szOID_NTDS_CA_SECURITY_EXT.

Включить полное принудительное применение сильного маппинга сертификатов на контроллерах домена: ключ реестра StrongCertificateBindingEnforcement должен принимать значение 2 (подробнее см. в статье Microsoft KB5014754). Этот режим имеет решающее значение, так как для него требуется расширение SID (или действительный URL-адрес SID SAN в определенных сценариях) для маппинга сертификатов, что снижает вероятность манипуляций на основе UPN, когда расширение SID просто отсутствует.

Рекомендации по мониторингу

Для обнаружения данной атаки необходимо осуществлять отслеживание изменений объектов пользователей и рабочих станций в AD с помощью мониторинга событий:

• Windows Event ID 5136 (A directory service object was modified), которое генерируется при изменении объекта Active Directory, в том числе при изменении учетной записи и присвоении ей UPN, отличного от ее имени.

• Windows Event ID 4738 (A user account was changed), которое также генерируется при изменении учетной записи.

Для выявления подозрительных запросов на получение сертификата следует мониторить события Windows Event ID 4886 (Certificate Services received a certificate request) и Windows Event ID 4887 (Certificate Services approved a certificate request and issued a certificate), в которых содержатся сведения о пользователе, запросившем сертификат, о пользователе, на имя которого запрашивается сертификат, а также времени создания запроса.

Заключение

Как мы писали ранее, новые методы атак на службу сертификации Active Directory продолжат появляться уже «завтра» и подтверждение наших слов не заставило себя ждать: «завтра» наступило в конце мая 2025 года. Вектор атаки ESC16 — стал прекрасным примером того, как исследователи безопасности продолжают изучать среду AD CS и обнаруживать новые небезопасные конфигурации, приводящие к уязвимостям. И по нашим ощущениям это далеко не последний вектор атаки на AD CS в ближайшем будущем.

Отсутствие должной защиты службы сертификации, в том числе использование «обходных» настроек администраторами и несвоевременное обновление серверов, наглядно демонстрирует, как легко нарушитель может использовать все это для повышения своих привилегий и получения возможности делать все, что ему угодно в локальной сети.

Анастасия Коротеева
Аналитик

@Направление проектов по кибербезопасности, Positive Technologies