ESC16. SID тут больше не живет: глобальное отключение как уязвимость
Этот вектор атаки связан с отключением в центре сертификации (CA) специального расширения безопасности — сертификата szOID_NTDS_CA_SECURITY_EXT, введенного в Windows в 2022 году. Оно содержит SID учетной записи заявителя и служит для строгого сопоставления сертификата при аутентификации в AD.
При наличии SID-расширения контроллер домена (DC) может выполнить строгую проверку соответствия и однозначно сопоставить предъявленный сертификат с конкретным объектом AD по SID. Однако, если CA не встраивает это расширение, DC вынужден использовать устаревший слабый способ сопоставления по полям UPN (userPrincipalName) или DNS-имени из SAN (Subject Alternative Name).
Флаг шаблона сертификата CT_FLAG_NO_SECURITY_EXTENSION как раз предотвращает включение SID-расширения в выдаваемый сертификат. Если этот флаг установлен в атрибутах шаблона (msPKI-Enrollment-Flag) или глобально отключен на уровне CA, то SID владельца не добавляется в сертификат при выпуске. В результате, даже если контроллеры домена настроены на стандартный режим строгого сопоставления (значение StrongCertificateBindingEnforcement = 0 или 1), они не будут применять строгое сопоставление при проверке такого сертификата.
По сути, удостоверяющий центр возвращается к поведению, эквивалентному полностью отключенному строгому сопоставлению (режим совместимости). Это открывает уязвимость: злоумышленник может запросить сертификат на имя другой учетной записи, обойдя механизмы проверки SID, и затем предъявить этот сертификат для входа в домен от лица жертвы. Иными словами, отключение Security Extension позволяет атакующему скомпрометировать чужую учетную запись посредством выдачи «непривязанного» сертификата и последующей аутентификации с ним. На уровне содержимого в таком сертификате будут поля субъекта или альтернативного имени (например, UPN целевой жертвы) без расширения с SID. Поэтому с точки зрения AD он будет выглядеть как обычный сертификат старого образца.
Чтобы лучше понять ESC16, разберем отличия с техникой ESC9:
| ESC9 (No Security Extension per template) | ESC16 (Security Extension Disabled on CA) | |
|---|---|---|
| Отключение SID-расширения |
Производится на уровне конкретного шаблона сертификата путем установки флага CT_FLAG_NO_SECURITY_EXTENSION |
Производится глобально для всего удостоверяющего центра путем добавления OID-расширения SID (1.3.6.1.4.1.311.25.2) в реестр DisableExtensionList CA |
| Выдача сертификатов |
Лишь отдельные шаблоны выдают сертификаты без расширения SID |
Независимо от настроек шаблонов сертификаты выпускаются без SID-расширения вообще для всех шаблонов этого CA |
| Устранение уязвимости |
Простое: достаточно снять флаг с шаблона или обновить шаблон после установки обновлений безопасности |
Сложное: требуется не только удалить OID из реестра, но и проверить, нет ли условий для реализации ESC6 |
Таким образом, ESC16 — это глобальная и более опасная версия ESC9, затрагивающая весь удостоверяющий центр, а не отдельные шаблоны. Важно понимать эту разницу при аудите безопасности инфраструктуры AD CS.
Главная опасность состоит в том, что при отсутствии SID-расширения домен доверяет данным, которые относительно легко сфальсифицировать (UPN, имя субъекта, DNS-имя), и не проверяет принадлежность сертификата конкретному объекту AD.
Злоумышленник, имеющий возможность повлиять на содержимое запроса или атрибуты учетных записей, способен выпустить сертификат, который выдает атакующего за привилегированного пользователя, например администратора домена. Так злоумышленник сможет получить доступ с соответствующими правами. Фактически такой сертификат становится аналогом легитимного удостоверения личности жертвы, но без встроенной привязки к ней, что и позволяет обойти стандартные меры защиты. С помощью этого возможно незаметно выполнить атаку Pass the Certificate и получить Kerberos-тикет (TGT) от имени жертвы, даже если в системе после обновлений включен режим строгого сопоставления сертификатов, который в норме предотвращает подобные имперсонации.
Для эксплуатации техники ESC16 необходим ряд условий:
- Отключение SID-расширения на стороне CA.
- Шаблон с клиентской аутентификацией.
- Права на запрос сертификата.
- Возможность влиять на атрибуты учетной записи или содержимое запроса.
А теперь разберем каждое подробнее.
Должна существовать уязвимая конфигурация AD CS, при которой CA не добавляет szOID_NTDS_CA_SECURITY_EXT в выпускаемые сертификаты. Это возможно в двух случаях:
- На уровне конкретного шаблона сертификата установлен флаг CT_FLAG_NO_SECURITY_EXTENSION в атрибуте msPKI-Enrollment-Flag. Шаблон с таким флагом по сути выпустит сертификат без SID даже на обновленном CA (такой случай классифицируется как ESC9).
- На уровне всего сервера сертификации глобально отключено добавление такого расширения через реестр CA (ключ DisableExtensionList содержит OID: 1.3.6.1.4.1.311.25.2). В этом случае все сертификаты, выдаваемые CA, не будут содержать SID-расширения (как если бы у всех шаблонов был проставлен флаг NO_SECURITY_EXTENSION). Подобную настройку администраторы могли применить после майских патчей 2022 года для совместимости со старыми клиентами, однако она создает серьезную брешь в безопасности. Аналогичная ситуация с отсутствием расширения возникнет, если сам сервер CA не был обновлен патчем KB5014754 или более новыми — неподдерживаемый CA не умеет выдавать SID-расширение вовсе.
Понять, что изменилось после майских обновлений безопасности 2022 года (патч KB5014754), помогает официальное описание. Из него становится ясно, что если система — как контроллеры домена, так и центр сертификации — была обновлена этим патчем, то после установки:
- центр сертификации начинает автоматически встраивать расширение безопасности с SID (szOID_NTDS_CA_SECURITY_EXT, OID: 1.3.6.1.4.1.311.25.2) в каждый сертификат, если такое поведение явно не отключено;
- контроллеры домена получают поддержку строгого сопоставления (strong binding) сертификата с объектом AD по SID и начинают учитывать это поведение в зависимости от значения ключа реестра StrongCertificateBindingEnforcement.
Поведение DC теперь регулируется этим параметром:
- 0 — отключено (слабое поведение по умолчанию, до патча).
- 1 — режим совместимости: если есть SID, используется он, если нет — fallback на UPN/DNS.
- 2 — строгий режим: вход возможен только при наличии SID в сертификате.
Таким образом, если CA обновлен, но администратор вручную отключает добавление расширения SID (через ключ DisableExtensionList), а DC при этом работает в режиме 0 или 1, то защита, введенная в патче, фактически отключается. Так инфраструктура становится уязвимой к техникам ESC9 или ESC16 — в зависимости от того, отключен ли SID на уровне шаблона или глобально на CA.
Если же CA обновлен, SID не отключен, а DC переведен в режим 2, то аутентификация работает в безопасном режиме и атаки через непривязанные сертификаты (без SID) невозможны.
Теперь возникает два интересных сценария атаки, связанных с новым поведением.
Сценарий 1. Конфликт настроек
Например, после февраля 2025 года параметр принудительно выставлен в значение 2, как показано на скриншоте:
Но администратор, столкнувшись с проблемами совместимости (допустим, из‑за старых клиентов или сервисов), глобально отключает расширение безопасности SID (szOID_NTDS_CA_SECURITY_EXT, OID: 1.3.6.1.4.1.311.25.2) на уровне центра сертификации:
Получается парадокс, конфликт конфигураций:
- С одной стороны, DC требует наличия SID-расширения для строгой проверки сертификата, так как режим именно строгий.
- С другой стороны, центр сертификации больше не добавляет это расширение ни в один сертификат, так как оно глобально отключено.
Что произойдет в такой ситуации — отдельный важный вопрос для детального изучения.
Сценарий 2. Отсутствие обновлений
Если же обновление, устанавливающее автоматический строгий режим после февраля 2025 года, вообще не установлено (а практика показывает, что многие компании не очень охотно ставят обновления), то DC остается в слабом режиме сопоставления сертификатов (StrongCertificateBindingEnforcement = 0 или 1).
При этом администратор глобально отключает расширение SID на CA для решения проблем совместимости или просто по незнанию. Такая ситуация весьма вероятна в реальной жизни — это второй серьезный вектор атаки.
Если контроллеры домена не работают в режиме строгого сопоставления сертификатов (StrongCertificateBindingEnforcement = 2), это значительно упрощает реализацию техники ESC16, хотя и не является строго необходимым условием.
Оба сценария, их последствия и реалистичность эксплуатации мы подробно рассматриваем в разделе о выполнении атаки.
Атакуемый шаблон сертификата обязательно должен допускать использование сертификата для аутентификации в домене. В расширенных назначениях ключа (EKU) уязвимого шаблона должна присутствовать, к примеру, Client Authentication (1.3.6.1.5.5.7.3.2) или аналогичная цель (Smart Card Logon и т. п.):
Иначе полученный сертификат не позволит войти в систему. Без этого даже сертификат на чужое имя не даст привилегий.
Злоумышленник (или подконтрольная ему учетная запись) должен обладать правом Enroll на соответствующий шаблон. Чаще всего уязвимость возникает, если шаблон опубликован для широкой группы, например Authenticated Users или пользователей домена. В таком случае любой доменный пользователь может инициировать запрос на сертификат по этому шаблону.
Если же шаблон доступен лишь ограниченному кругу, атакующему потребуется предварительно получить учетные данные пользователя из разрешенной группы или скомпрометировать учетную запись с правами Enroll:
Чтобы подменить идентичность в сертификате, злоумышленник может внедрить в запрос желаемые данные жертвы (например, UPN администратора) одним из способов:
Указать UPN при генерации запроса. Если шаблон позволяет задавать альтернативное имя субъекта (SAN) вручную, то есть у него включена опция Supply in the request (техника ESC6), то атакующий может сразу указать UPN жертвы при генерации запроса:
В контексте ESC16 это опасно даже при самом строгом режиме DC, поскольку можно передать и SID жертвы как специальный SAN-параметр, обходя проверку. Однако наличие одновременно ESC6 и отключенного расширения безопасности — более редкий и тяжелый случай (комбинированная атака). Подробнее рассмотрим его в разделе «Выполнение атаки».
Изменить UPN существующей учетной записи. В базовом сценарии (DC в режиме совместимости) достаточно, чтобы атакующий мог изменить UPN существующей учетной записи, с которой он будет запрашивать сертификат. Обычно для этого требуется иметь права GenericWrite (изменение атрибутов) или эквивалентные права на атрибут userPrincipalName. Например, скомпрометировав учетную запись пользователя и получив возможность изменить ее UPN, злоумышленник может вписать туда имя администратора домена. Тогда при выпуске сертификата по уязвимому шаблону CA возьмет UPN из AD (уже подмененный) и вставит в сертификат. В результате сертификат будет содержать UPN привилегированной жертвы, хотя запрошен от лица другого пользователя.
Использовать явное сопоставление. Альтернативно при наличии прав на изменение других атрибутов AD атакующий мог бы использовать явное сопоставление сертификатов (например, добавить хеш сертификата или altSecurityIdentities в атрибут учетной записи жертвы как в ESC14). Однако в случае отсутствия SID-расширения достаточно и неявного сопоставления по UPN, поэтому внесение сертификата в altSecurityIdentities не требуется. Более того, явное сопоставление при отключенном SID тоже будет обрабатываться по старым правилам.
Рассмотрим пошагово реализацию атаки в тестовой среде с Enterprise CA на Windows Server 2016 (CA и контроллер домена развернуты на одном хосте). Предположим, в домене есть заранее сконфигурированный и уязвимый шаблон сертификата ESC16 с разрешением Enroll для пользователей домена:
Благодаря полученным правам GenericWrite на учетную запись ESC16User атакующий может внести изменения в критически важные атрибуты объекта, такие как UPN. Это позволяет ему временно подменить идентификатор ESC16User на UPN администратора домена, например Administrator@good.expert.
На скриншоте из BloodHound ниже видно, что пользователь HACKER@GOOD.EXPERT (hacker) обладает правами GenericWrite по отношению к ESC16USER@GOOD.EXPERT:
Это дает возможность провести атаку ESC16, особенно если центр сертификации уязвим и не добавляет SID в выдаваемые сертификаты. Атака по этому сценарию развивается так:
Шаг 1. Сбор сведений и подготовка
Атакующий убеждается, что шаблон ESC16 в CA уязвим: флаг отключения расширения безопасности установлен. Это можно сделать с помощью утилиты Certipy (certipy find) или PowerShell-скриптов, проверив атрибуты шаблона. Кроме того, для последующего восстановления важно узнать текущий UPN учетной записи ESC16User. Например, инструментом Certipy или командой PowerShell можно прочитать атрибут userPrincipalName пользователя ESC16User.
Вот как это выглядит в Certipy:
Шаг 2. Подмена UPN жертвы
Используя полученные права GenericWrite, атакующий пользователь hacker заменяет атрибут userPrincipalName у учетной записи ESC16User на значение, совпадающее с UPN целевой учетной записи администратора домена. В нашем примере подмена выполняется на Administrator@good.expert. Это позволяет ESC16User запрашивать сертификат от имени администратора, поскольку контроллер домена интерпретирует UPN как Administrator.
Изменение атрибута выполняется через PowerShell следующей командой:
Set-ADUser -Identity ESC16User -UserPrincipalName "Administrator@good.expert"
Результат можно подтвердить с помощью:
Get-ADUser ESC16User -Properties userPrincipalName | Select-Object Name, userPrincipalName
Как видно на скриншоте, атрибут userPrincipalName успешно подменен — теперь он указывает на Administrator@good.expert, что открывает путь к получению сертификата с правами доменного администратора в рамках атаки ESC16.
Шаг 3. Получение доступа для запроса сертификата
Атакующий не знает пароль от учетной записи ESC16User, но у него есть определенные права на нее, например GenericWrite или WriteKeyCredentialLink. Поэтому он может воспользоваться техникой Shadow Credentials (или аналогичной), чтобы получить возможность аутентифицироваться от имени этой учетной записи.
Для упрощения в лабораторных условиях можно предположить один из следующих сценариев, когда атакующий:
- Скомпрометировал учетные данные ESC16User, например получил NTLM-хеш или пароль.
- Использовал функцию certipy shadow для установки альтернативного ключа (KeyCredential) и извлечения соответствующего приватного ключа.
В результате у атакующего оказывается на руках пароль / NT‑хеш пароля или Kerberos TGT / ccache-файл, которые позволяют ему выполнять аутентификацию от имени ESC16User.
Так атакующий может отправить запрос на сертификат от имени ESC16User, чей UPN уже был ранее подменен на Administrator@good.expert. В условиях уязвимого шаблона и отключенной проверки security extensions (ESC16) это приводит к получению валидного сертификата администратора.
Шаг 4. Запрос сертификата на уязвимом CA
Подмена UPN у учетной записи ESC16User на Administrator@good.expert — это подготовка к атаке. Затем злоумышленник выполняет запрос на получение сертификата от ее имени. Он использует уязвимый шаблон ESC16 с помощью утилиты Certipy: certipy.exe req -u ESC16User -p ’Пароль’ -target good.expert -dc-ip 10.3.132.172 -ca GOOD-GOODEX-SERVER-CA-1 -template ESC16 -pfx administrator.pfx.
В результате выдается сертификат:
- с расширением SAN, содержащим UPN Administrator@good.expert;
- без встроенного SID, что подтверждает эксплуатацию уязвимой конфигурации, допускающей атаку ESC16;
- от имени легитимного CA, что гарантирует доверие со стороны контроллера домена.
Согласно выводу Certipy:
Got certificate with UPN 'Administrator@good.expert'
Certificate has no object SID
И как видно на скриншоте, поле Subject Alternative Name сертификата содержит имя администратора, то есть атака удалась:
Это позволяет использовать сертификат для Kerberos-аутентификации от имени администратора, даже если используется защита StrongCertificateBindingEnforcement = 0 или 1.
Шаг 5. Восстановление изменений
Перед следующим шагом атакующий может вернуть в исходное состояние атрибуты учетной записи жертвы (ESC16User), чтобы минимизировать следы атаки в Active Directory и не нарушать уникальность UPN в домене. Для этого он выполняет обратное действие — восстанавливает оригинальный UPN, например: Set-ADUser -Identity "ESC16User" -UserPrincipalName "ESC16User@good.expert".
После изменения атрибута userPrincipalName у ESC16User атака ESC16 считается завершенной, а учетная запись возвращается к своему изначальному виду. Это предотвращает конфликты, если администраторы позже попытаются использовать Administrator@good.expert.
Шаг 6. Аутентификация с полученным сертификатом
Теперь атакующий переходит к завершающему этапу: аутентификации от имени Administrator с помощью ранее полученного сертификата. В нашем случае используется сертификат в формате PFX, в котором:
- прописан SAN UPN = Administrator@good.expert;
- отсутствует SID (по причине глобально отключенного расширения безопасности — техника ESC16).
Для выполнения Kerberos-аутентификации с использованием сертификата запускается команда: certipy.exe auth -pfx administrator.pfx -dc-ip 10.3.132.172.
В результате, как видно на скриншоте, Certipy:
- определяет SAN UPN как
'Administrator@good.expert'; - успешно получает TGT (
[*] Got TGT); - сохраняет Kerberos-билет в файл
administrator.ccache; - извлекает NTLM-хеш от имени администратора домена:
aad3b435b51404eeaad3b435b51404ee:e21b1d9764cb0044f5f9dcfdc1670f1a.
Таким образом, атакующий получает полный доступ от имени domain administrator, не зная пароля и не обладая изначально его учетными данными.
Как говорилось выше, с момента внедрения механизма Strong Certificate Binding Enforcement (режимы сопоставления SID) Windows Domain Controllers начинают полагаться не только на UPN, но прежде всего на SID, встроенный в сертификат, чтобы достоверно связать его с конкретной учетной записью. Это защищает от атаки с подменой UPN, которую мы описали выше.
Но что, если в сертификате вообще нет SID? Такое бывает, например, когда:
- CA не добавляет расширение SID в сертификаты (ESC16 — отключенный szOID_NTDS_CA_SECURITY_EXT);
- одновременно с этим включен строгий режим сопоставления SID на контроллерах домена (StrongCertificateBindingEnforcement = 2).
На первый взгляд кажется, что аутентификация невозможна, ведь SID отсутствует. Однако существует обходной путь, связанный с техникой ESC6.
Суть комбинированной техники ESC6 + ESC16
| Компонент | Что происходит |
|---|---|
| ESC16 |
Центр сертификации не включает расширение SID в выдаваемый сертификат. Оно может быть отключено вручную (через DisableExtensionList) или в результате ошибки |
| ESC6 |
CA сконфигурирован с флагом EDITF_ATTRIBUTESUBJECTALTNAME2, который позволяет пользователю самому указывать поле SAN в теле запроса. Это позволяет внедрить любой UPN или SID, включая UPN администратора и SID его учетной записи |
В итоге:
- Сертификат не содержит встроенного SID (это требование для KDC в режиме Enforcement = 2).
- Поле SAN в сертификате содержит специально подставленный URL в формате:
URL=tag:microsoft.com,2022-09-14:sid:S-1-5-21-...-500.
KDC при проверке обнаруживает SID в SAN и принимает его как валидный, несмотря на отсутствие настоящего расширения SID.
Почему комбинация работает
Microsoft, начиная с Windows Server 2016, реализовала поддержку обработки SAN URL SID, который читается из поля otherName внутри SAN. Если нет основного SID-расширения (из‑за ESC16), а DC работает в режиме полного контроля (Enforcement = 2), он будет использовать SID, если тот присутствует в SAN URL.
Таким образом, атакующий получает TGT на доменного администратора, просто указав его UPN и SID в сертификатной заявке, без знания пароля или компрометации учетной записи.
Как проверить уязвимость CA к технике ESC6
CA уязвим, если установлен флаг EDITF_ATTRIBUTESUBJECTALTNAME2, который разрешает принимать SAN из запроса от клиента. Проверить это можно через certutil: certutil -getreg policy\EditFlags.
Если в выводе есть строка EDITF_ATTRIBUTESUBJECTALTNAME2, то CA уязвим к ESC6 — разрешено указывать произвольный SAN.
Далее разберем, как именно этот сертификат можно использовать для получения Kerberos TGT и доступа к контроллеру домена, а также как с этим бороться.
Шаг 1. Получение SID администратора
С помощью Certipy атакующий формирует сертификатный запрос, подставляя вручную UPN Administrator@good.expert и SID администратора в SAN.
Сначала он получает точный SID целевого пользователя (в этом случае — Administrator): Get-ADUser Administrator | Select-Object -ExpandProperty SID.
Вывод: S-1-5-21-3912521324-1417072855-2443496624-500.
Шаг 2. Запрос сертификата
В выводе Certipy подтверждается, что:
- выданный сертификат содержит нужный UPN;
- SID внедрен в SAN в виде URL-расширения;
- SID-расширение отсутствует (техника ESC16 активна).
.\certipy.exe req `
-u ESC16User -p 'Ryryququn95' `
-dc-ip 10.3.132.172 `
-target GOODEX-SERVER.GOOD.EXPERT `
-ca GOOD-GOODEX-SERVER-CA-1 `
-template ESC16 `
-upn Administrator@good.expert `
-sid S-1-5-21-3912521324-1417072855-2443496624-500 `
-pfx administrator.pfx
Шаг 3. Аутентификация с полученным сертификатом
Для этого используется Certipy: .\certipy.exe auth -pfx administrator.pfx -dc-ip 10.3.132.172.
Certipy сообщает, что:
- сертификат содержит SAN UPN и SAN URL SID;
- получен TGT от имени администратора;
- извлечен NTLM-хеш администратора.
На скриншоте выше видно, что:
- в сертификате указано:
Got certificate with UPN 'Administrator@good.expert; - Certipy отразил внедренный SAN URL SID:
'S-1-5-21-3912521324-1417072855-2443496624-500'; - был успешно получен TGT и хеш от имени администратора.
Комбинация техник ESC6 и ESC16 — это мощный метод обхода всех современных механизмов защиты PKINIT и Kerberos в домене Active Directory. Даже при StrongCertificateBindingEnforcement = 2, контроллер домена доверяет SID, внедренному в SAN, если SID-расширение отсутствует. Это позволяет получить полный доступ к домену без знания пароля.
Для обнаружения атаки ESC16 существует несколько методов:
- На основе корреляций. Этот подход предполагает построение детектирующей логики поверх штатных механизмов логирования Windows. Чтобы такая логика работала, убедитесь, что логирование настроено корректно и необходимые события поступают в SIEM. В некоторых случаях для настройки логирования достаточно выставить опцию в расширенном аудите, в других же — необходимо выставить SACL на интересующие объекты.
- На основе ошибок конфигурации. Этот подход основан на регулярном мониторинге состояния компонентов AD CS. Нужно искать нарушения политик кибербезопасности и уязвимые настройки в шаблонах сертификатов, параметрах реестра, выпускаемых сертификатах и т. д. Такой мониторинг возможен с помощью утилит (Certipy, Certify и т. д.), самописных скриптов или других решений.
- С помощью EDR. Эффективного обнаружения атаки можно добиться, объединив два подхода, как это реализовано, например, в BI.ZONE EDR. Только своевременное детектирование атаки вкупе с постоянным мониторингом состояния инфраструктуры и выявлением мисконфигураций позволяет добиться оптимального уровня защиты.
При попытке эксплуатации ESC16 злоумышленник, как правило, вносит изменения в учетные записи (или шаблоны) перед запросом сертификата. Эти изменения можно отследить с помощью журналов AD.
Event ID 5136 и 4738
Следите за событиями 5136 (Directory Service Object Modified) и 4738 (User Account Changed) в журнале контроллера домена. Они позволяют увидеть модификации объектов AD. В частности, при смене UPN у учетной записи генерируется событие 4738:
Событие 5136 указывает, какой атрибут изменен:
Event ID 4886 и 4887
На скриншоте события 4886 ниже видно, что доменная учетная запись GOOD\ESC16User отправила запрос на выпуск сертификата, используя шаблон ESC16:
Особое внимание следует обратить на поле SAN, где указано:
SAN: upn=Administrator@good.expert
&url=tag:microsoft.com,2022-09-14:sid:S-1-5-21-...-500
Это означает, что в заявке вручную были внедрены:
- UPN администратора (для имперсонации);
- SID администратора в виде SAN:URL — это признак атаки ESC6.
Сам CA не добавил поле SID, поскольку он уязвим к ESC16 (расширение отключено). Таким образом, атакующий подставил SID через SAN, и сервер примет его при проверке, несмотря на отключенное расширение SID.
В событии 4887 зафиксирован факт успешной выдачи сертификата:
Ключевые поля:
- Requester: GOOD\ESC16User.
- Template: ESC16.
- SAN: содержит UPN администратора и его SID, внедренный через URL.
Несмотря на то что ESC16User — это низкопривилегированный пользователь, ему удалось получить сертификат, привязанный к UPN и SID администратора. Это возможно только в случае, если CA уязвим к ESC16 и одновременно разрешает использовать поля SAN (ESC6).
Такая активность не обязательно сразу вызовет срабатывание сигнала, но может быть выявлена при корреляции следующих событий:
- Событие 4887 (кому выдан сертификат и с какими полями).
- Событие 4768 (кто аутентифицировался с этим сертификатом).
- Сопоставление серийного номера и UPN между двумя журналами.
Если между Requester и UPN в SAN нет совпадения, особенно если UPN указывает на администратора, это важный индикатор возможной атаки.
Выявление техники ESC16 возможно как на этапе превентивного аудита конфигурации AD CS, так и по событиям, генерируемым в процессе атаки. Рекомендуются два подхода.
Подход 1. Аудит конфигурации CA и шаблонов
До того как атака произошла, администраторы могут обнаружить уязвимость, проверив настройки AD CS. Необходимо проанализировать опубликованные шаблоны сертификатов на наличие флага CT_FLAG_NO_SECURITY_EXTENSION в их атрибуте msPKI-Enrollment-Flag. Эту информацию можно получить с помощью утилиты certutil (-v -template <TemplateName>) или LDAP-запросов по контейнеру шаблонов в AD. Кроме того, следует проверить реестр CA на предмет глобального отключения расширения по пути: HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA-Name>\PolicyModules\...\DisableExtensionList.
Для проверки, зафиксированной на скриншоте выше, использовалась версия Certipy 5.0.2.
Если в упомянутой ветке реестра присутствует OID 1.3.6.1.4.1.311.25.2, это сигнализирует об отключении SID-расширения для всех сертификатов этого CA. Инструменты вроде Certipy способны автоматически выявлять такую конфигурацию. Например, как показано на скриншоте, в выводе certipy find у CA будет указан отключенный OID и пометка ESC16: Security Extension is disabled и Disabled Extensions: 1.3.6.1.4.1.311.25.2. Регулярный аудит подобных настроек (вручную или с помощью сканеров уязвимостей AD вроде PingCastle) позволяет обнаружить проблему до того, как ею воспользуются злоумышленники.
Подход 2. Исправление уязвимой конфигурации, допускающей атаку ESC16 в Microsoft Intune
Для устранения уязвимости, связанной с отсутствием SID-расширения в сертификатах, выдаваемых через Intune, сделайте следующее:
- Измените значение в реестре Windows на сервере, где установлен Intune Certificate Connector:
[HKEY_LOCAL_MACHINE\Software\Microsoft\MicrosoftIntune\PFXCertificateConnector]
"EnableSidSecurityExtension"=dword:00000001Это включает добавление SID-расширения (OID 1.3.6.1.4.1.311.25.2) в сертификаты, что необходимо для поддержки Strong Certificate Mapping. До октября 2024 года Intune не добавлял SID-расширение в PKCS-/SCEP-сертификаты, так как использовал офлайн-шаблоны через коннектор. Без SID-аутентификации Kerberos PKINIT и Schannel может использовать уязвимые методы сопоставления (например, по UPN).
- Дополнительно убедитесь, что контроллеры домена работают на Windows Server 2019 или новее, так как только они умеют распознавать SID в офлайн-сертификатах, выданных через Intune.
Как показывает практика, эффективная защита от подобных техник невозможна без системного подхода. Недостаточно просто разово проверить шаблоны сертификатов или настройки центра сертификации — требуется выстроенная архитектура постоянного контроля и защиты.
Обнаружение с помощью BI.ZONE EDR: информация из алертаКлючевые элементы такой защиты:
- Контроль шаблонов. Особенно тех, которые позволяют выпуск сертификатов пользователям без административных привилегий. Если шаблон содержит EKU Client Authentication и не ограничивает подстановку UPN, его можно использовать для получения сертификатов от имени других пользователей.
- Подтверждение заявок. Обязательное утверждение запросов ответственными лицами (как минимум на уровне шаблона или вручную в CA) минимизирует риск автоматического выпуска сертификатов с подменой идентичности.
- Мониторинг параметра StrongCertificateBindingEnforcement. Критически важен в условиях атак через подмену UPN или отсутствия SID в сертификате (ESC16). Однако есть нюансы:
- Без обновления безопасности (май 2022 года, KB5014754) этот параметр может отсутствовать вовсе, и DC будет работать в нестрогом режиме.
- При установленном патче, даже если ключ не задан явно, домен автоматически перейдет в строгий режим (уровень 2). Но и это не спасет, если CA по‑прежнему не добавляет SID в сертификаты, например через реестр отключено расширение 1.3.6.1.4.1.311.25.2.
Cтрогая проверка SID на контроллерах домена оказывается бесполезна, если CA вообще не добавляет SID в сертификаты. Именно на этой уязвимости строится атака ESC16. Причем, если CA также позволяет указывать SAN вручную (техника ESC6, активируемая через EDITF_ATTRIBUTESUBJECTALTNAME2), атакующий может вручную подставить чужой SID в SAN. В комбинации с ESC16 это обходит даже полное сопоставление.
BI.ZONE EDR позволяет не просто разово проверить настройки, а постоянно мониторить следующие критичные параметры:
- Фактическое значение StrongCertificateBindingEnforcement на каждом DC.
- Присутствие или отсутствие DisableExtensionList с OID SID-расширения на CA.
- Наличие включенного EDITF_ATTRIBUTESUBJECTALTNAME2, указывающего на риск ESC6.
- Наличие подтверждения заявок.
- Факт установки патча KB5014754 (или его отсутствие).
- Изменения веток реестра, даже если на хосте не включен аудит.
Для анализа атак ESC6 и ESC16 важно видеть не только текущую конфигурацию, но и момент ее изменения. BI.ZONE EDR решает эту задачу: фиксирует модификации параметров в реальном времени, что позволяет реагировать на атаку до того, как атакующий сможет нанести ощутимый ущерб.
Событие с уязвимым шаблоном сертификата, зафиксированное BI.ZONE EDRПроверка параметров CA и DC — это не одноразовое действие из чек-листа аудитора. Это непрерывный процесс, который должен быть встроен в вашу инфраструктуру. Только так можно выстроить реальную защиту от атак с использованием уязвимых сертификатов.
Для предотвращения атак типа ESC16 необходимо последовательно усилить конфигурацию инфраструктуры AD CS и связанных компонентов безопасности. Меры должны затрагивать как контроллеры домена, так и серверы центра сертификации.
На всех DC установите значение StrongCertificateBindingEnforcement = 2 в реестре по пути HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc.
Это активирует режим Full Enforcement, при котором контроллер домена требует обязательное наличие SID-расширения в каждом предъявляемом сертификате. Сертификаты без этого расширения будут автоматически отвергаться, даже если содержат UPN или SAN. Такая конфигурация блокирует не только ESC16, но и ряд других техник, связанных с подменой UPN.
Рекомендуем централизованно задать параметр через групповую политику и обязательно перезапустить службу KDC (kdcsvc) на всех контроллерах домена для применения изменений.
Проверьте, что на каждом Enterprise CA отсутствует глобальное отключение расширения SID. Это делается через реестр: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA_Name>\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy.
Параметр DisableExtensionList не должен содержать строку 1.3.6.1.4.1.311.25.2.
Также можно использовать команду: certutil -getreg policy\DisableExtensionList.
Если OID присутствует, удалите его: certutil -setreg policy\DisableExtensionList −1.3.6.1.4.1.311.25.2, net stop certsvc, net start certsvc.
В 2025 году глобальное отключение SID-расширения уже не оправдано: подавляющее большинство клиентов и сервисов корректно обрабатывают сертификаты с этим расширением. Если проблемы совместимости все же возникают, решайте их индивидуально, например через выпуск отдельных сертификатов для устаревших систем вручную, а не путем ослабления глобальных настроек безопасности центра сертификации.
Убедитесь, что CA работает на системе с установленным обновлением безопасности KB5014754 (или более поздними cumulative updates). Без этого обновления сервер CA не умеет встраивать SID в сертификаты вообще, независимо от настроек шаблонов. Проверка должна быть как на уровне наличия патча, так и на уровне поведения CA (фактически встроен ли SID в выдаваемые сертификаты).
Проведите ревизию всех шаблонов сертификатов:
- Удалите флаг CT_FLAG_NO_SECURITY_EXTENSION из всех опубликованных шаблонов, где он может быть установлен. Обычно у встроенных шаблонов нет этого флага по умолчанию. Он может появиться, только если администратор вручную включил Do not include security extension, например клонируя шаблон в старом совместимом режиме. Если такой флаг нужен для специализированных сертификатов, лучше изолируйте их на отдельном CA, не добавленном в NTAuth (чтобы они не могли использоваться для входа в AD).
- Ограничьте набор зарегистрированных шаблонов. Удалите или отзовите публикацию неиспользуемых шаблонов, особенно тех, что позволяют клиентскую аутентификацию. Чем меньше шаблонов доступно, тем меньше поверхность атаки.
- Пересмотрите права Enroll. На каждом шаблоне проверьте ACL. Как минимум уберите группу Authenticated Users из списка тех, кто может запрашивать сертификат, если шаблон поддерживает аутентификацию. Дайте права только тем группам или пользователям, кому это действительно нужно по работе. Практика показывает, что многие организации по умолчанию оставляют слишком широкие права на шаблоны. Существенно сократив круг субъектов, допускаемых к выдаче сертификатов (особенно по чувствительным шаблонам), вы затрудните действия злоумышленника.
- Добавьте требование одобрения выдачи. Для особо привилегированных или потенциально опасных шаблонов (например, шаблонов, которые дают права на клиентскую аутентификацию широкой группе), рассмотрите включение опции CA certificate manager approval — ручного подтверждения со стороны администратора CA для каждого запроса. Это добавляет нагрузку администраторам, но предотвращает автоматическую выдачу сертификата злоумышленнику. Даже если он сможет подать запрос, сертификат застрянет в ожидании подтверждения и не будет выдан без вмешательства ответственного лица.
Минимизируйте ситуации, когда пользователи могут изменять чужие учетные записи:
- Проведите аудит делегирования прав в домене. Ограничьте выдачу прав на изменение свойств учетных записей (GenericWrite/GenericAll) только административными аккаунтами. Рядовые пользователи не должны иметь возможность менять UPN или другие критичные атрибуты ни у себя, ни тем более у других. Если где‑то настроены нестандартные ACL, дающие такие права (например, через неправильное делегирование OU), исправьте их.
- Следите, чтобы у административных учетных записей (Domain Admins и т. п.) не было лишних делегированных прав от других объектов. В частности, учетные записи сервисов не должны иметь возможность модифицировать администраторов домена. Также не давайте привилегии на администрирование сертификатов или CA неподготовленным пользователям.
- Разделите роли. Администраторам PKI не обязательно быть Domain Admin, можно ограничить их права только CA. Так, риск неправильной настройки AD снижается. Но при этом мониторьте действия даже PKI-администраторов: компрометация CA тоже ведет к тяжелым последствиям.
Настройте постоянный мониторинг событий, упомянутых в разделе «Обнаружение атаки». Внедрите правила корреляции в SIEM для автоматического оповещения при подозрительных комбинациях (смена UPN + выдача сертификата + вход с сертификатом). Рассмотрите использование специализированных инструментов обнаружения атак на AD CS. Также существуют открытые проекты, сканирующие уязвимости AD CS (Certipy, PSPKI-модули) — администраторы могут использовать их для проактивного поиска неправильных настроек.
Атака типа ESC16 — критическая угроза для инфраструктуры Active Directory. Отключение Security Extension фактически отменяет важное защитное улучшение в Kerberos-аутентификации, возвращая систему к уязвимому состоянию, существовавшему до 2022 года.
В случае успешной эксплуатации злоумышленник получает возможность выдавать себя за любого пользователя домена, включая администраторов и даже аккаунты контроллеров, в зависимости от сценария. Это почти наверняка приводит к полной компрометации домена: с учетными данными Domain Admin в руках атакующего безопасность всей среды оказывается под угрозой. Более того, использование легитимно выданных сертификатов затрудняет обнаружение: такая аутентификация может не вызвать срабатывания классических средств защиты, а полученные сертификаты могут использоваться для длительного скрытого доступа (до истечения их срока действия, а при необходимости злоумышленник способен выпустить новые).
Таким образом, опасность атаки ESC16 трудно переоценить. Администраторам AD CS следует отнестись к проверке и укреплению настройки SID-расширения с самым высоким приоритетом. При надлежащей конфигурации (строгое сопоставление SID, отсутствие флага на шаблонах, актуальные патчи) риск будет минимальным. Однако при ненадлежащей конфигурации последствия могут быть разрушительными: вплоть до полного захвата контроллеров домена и всех ресурсов AD. Практика показывает, что превентивные меры и мониторинг жизненно необходимы. Следуя описанным рекомендациям, организации могут существенно снизить риск и предотвратить реализацию сценария ESC16 в своей сети.
