ESC6. Как чужое имя в сертификате становится вашим кошмаром
Основная причина атаки ESC6 — небезопасная настройка обработки поля Subject Alternative Name (SAN) на уровне центра сертификации (CA).
SAN — это расширение в сертификате, куда можно добавить дополнительные идентификаторы: UPN, DNS, SPN и т. д. Обычно это делают для удобства: один SSL‑сертификат может использоваться для защиты сразу несколько доменов. Но если пользователь может сам указывать SAN в аутентификационных сертификатах (с EKU типа Client Authentication) — это серьезная проблема.
Если CA настроен с флагом EDITF_ATTRIBUTESUBJECTALTNAME2, центр сертификации доверяет полю SAN из запроса независимо от настроек шаблона. Это означает, что любой пользователь может подставить в SAN чужой UPN, например имя администратора, и получить сертификат, который система будет считать принадлежащим администратору.
Такая атака — не активное вторжение, а результат опасной конфигурации, и, в свою очередь, она дает возможность запустить другие техники из семейства ESC. Поэтому ESC6 — важный шаг в цепочке небезопасных действий, и его нельзя игнорировать.
Вот пример того, как развивается техника ESC6:
- Злоумышленник генерирует CSR (запрос сертификата) с чужим UPN в поле SAN, например
administrator@domain.com. - Центр сертификации, настроенный с флагом
EDITF_ATTRIBUTESUBJECTALTNAME2, доверяет содержимому поля SAN, но не проверяет, соответствует ли UPN отправителю запроса. - CA выдает сертификат с UPN =
administrator@domain.com. - Атакующий аутентифицируется с этим сертификатом от имени администратора.
- AD признает злоумышленника администратором.
Чтобы атака ESC6 стала возможна, в среде должны совпасть несколько условий:
- Центр сертификации уязвим (включен флаг SAN).
- Есть шаблон сертификата, доступный злоумышленнику.
- Нет дополнительных барьеров для выдачи.
- Выданный сертификат доверяется в домене.
Главный фактор — в CA установлен флаг EDITF_ATTRIBUTESUBJECTALTNAME2. Узнать, включен ли он, можно из ветки реестра или через консоль. К примеру, в реестре сервера CA по пути HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA>\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy, в параметре EditFlags (тип DWORD):
Значение флага EDITF_ATTRIBUTESUBJECTALTNAME2 — 0×40000 в шестнадцатеричном формате или 262144 в десятичном, а результат параметра EditFlags — 4278173695 (в десятичном формате).
Чтобы понять, включен ли флаг, сравните вхождение побитово. Например, есть два десятичных числа:
4278173695 262144
В двоичном формате это соответственно:
11111111000010100001011111111111 00000000000001000000000000000000 (0x40000)
Выполните побитовую операцию И (AND):
11111111000010100001011111111111 & 00000000000001000000000000000000 ----------------------------------- 00000000000001000000000000000000
Результат операции — это и есть 262144.
Поскольку результат не нулевой, значит, флаг установлен. То есть CA будет принимать альтернативные имена из запроса сертификата. Если же флаг выключен (а по умолчанию он выключен), CA игнорирует SAN, когда шаблон не разрешает его явно.
Проверить наличие уязвимости можно и с помощью команды certutil или через regedit: certutil -getreg policy\EditFlags.
Вывод показывает текущее значение EditFlags:
Администратор мог включить этот флаг намеренно, например с помощью показанных далее команд. А если флаг уже включен, то важно выявить это.
Этот флаг нельзя изменять через графический интерфейс, можно — только через командную строку:
certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
Или если включить, то тогда:
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
В выводе показаны старые и новые значения:
Для применения настроек требуется перезагрузка управляющего центра сертификации:
net stop certsvc net start certsvc
Даже если CA допускает произвольный SAN, злоумышленнику нужно иметь возможность запросить хотя бы какой‑то сертификат.
Атаке способствует наличие опубликованного шаблона, удовлетворяющего двум условиям:
-
Злоумышленник (обычный пользователь домена) имеет право Enroll по нему.
-
Выданный по этому шаблону сертификат подходит для аутентификации в домене: EKU включает Client Authentication, что делает сертификат пригодным для входа в AD.
Для развития атаки выбранный шаблон не должен требовать ручного одобрения или нескольких подписей. Например, если шаблон требует одобрения запросов администратором CA (manager approval) или настроен так, что authorized signatures > 0, злоумышленнику сложнее получить сертификат незаметно. Ниже — пример отсутствия дополнительных барьеров для выдачи.
В большинстве уязвимых сценариев используются стандартные шаблоны без требований (manager approval = False и required signatures = 0). К счастью для злоумышленника, типовые User или Domain Controller Authentication не требуют дополнительных утверждений, так как в шаблонах версии 1 таких параметров просто нет.
Но специально для таких сертификатов есть и второй барьер защиты — настройка ручного подтверждения сертификатов на уровне CA:
Например, когда выбрано Follow the settings in the certificate template, if applicable. Otherwise, automatically issue the certificate, это означает:
- Если шаблон сертификата содержит инструкции об утверждении (например, ручное подтверждение), CA будет их учитывать.
- Если таких инструкций нет, CA выдает сертификат автоматически, без участия администратора.
Обычно Enterprise CA, как часть AD CS, автоматически доверяется контроллерами домена для аутентификации пользователей. Сертификаты, которые он выдает, размещаются в хранилище NTAuth и могут использоваться для входа в домен (например, через Kerberos PKINIT или смарт-карту). Таким образом, если CA — Enterprise (а не Standalone вне домена) и интегрирован с AD, то сертификат с клиентским EKU мгновенно действует как удостоверение для AD. Это условие обычно выполняется по умолчанию для внутренних CA в инфраструктуре Active Directory.
В реальных атаках самый распространенный сценарий — когда администратор включил флаг по незнанию, а атакующий использует уязвимый шаблон.
Рассмотрим шаги выполнения атаки ESC6 с точки зрения злоумышленника, имеющего учетную запись в компрометируемом домене (но без прав администратора). Эта техника наглядно демонстрирует, как при слабой конфигурации шаблона можно получить доступ с привилегиями, которых изначально не было.
Сначала атакующий выявляет, настроен ли в организации уязвимый CA. Это можно сделать red team — утилитами для AD CS вроде Certifycertutil -getreg policy\EditFlags проверяет наличие флага SAN в доступных центрах сертификации.
Кроме того, атакующий перебирает опубликованные шаблоны сертификатов и их DACL, чтобы найти подходящий для запроса. Предположим, он обнаружил, что CA имеет включенный EditFlags/SAN и опубликован шаблон ESC1, доступный Authenticated Users. Это идеальный сценарий для атаки ESC6.
Злоумышленник генерирует запрос на сертификат, добавляя в него атрибут Subject Alternative Name со значением UPN жертвы. Целью, например, может быть учетная запись администратора домена Administrator@good.expert.
Атакующий может воспользоваться утилитой certreq, чтобы оформить запрос. Например, есть шаблон ESC6, который можно использовать. Злоумышленник создает INF‑файл запроса для этого шаблона:
[Version] Signature="$Windows NT$" [NewRequest] Subject = "CN=User" KeySpec = 1 KeyLength = 2048 Exportable = TRUE FriendlyName = "ESC6_Attack" MachineKeySet = FALSE ProviderName = "Microsoft RSA SChannel Cryptographic Provider" RequestType = PKCS10 KeyUsage = 0xa0 [EnhancedKeyUsageExtension] OID=1.3.6.1.5.5.7.3.2 ; Client Authentication
Атакующий сохраняет файл под именем esc6.inf. Если, к примеру, злоумышленник выполнит последовательность certreq -new.\esc6.inf.\esc6.req, команда создаст файл запроса сертификата esc6.req.
После подготовки CSR (certificate signing request) злоумышленник отправляет запрос на выпуск сертификата в центр сертификации с помощью различных инструментов: certreq, Certipy, Certify — или через интерфейс Web Enrollment, если он доступен.
В примере выше используется certreq и задействован шаблон ESC6, который содержит опасную конфигурацию:
- разрешает Enroll обычным пользователям;
- позволяет указывать поле SAN вручную.
Центр сертификации, в свою очередь, доверяет значениям SAN из запроса благодаря включенному флагу EDITF_ATTRIBUTESUBJECTALTNAME2.
В CA отправляется запрос с подмененным UPN. В параметре SAN:UPN=Administrator@good.expert злоумышленник вручную подставляет имя администратора:
certreq -submit -attrib "CertificateTemplate:ESC6\nSAN:UPN=Administrator@good.expert" esc6.req esc6.cer
Вывод:
RequestId: 85 Certificate retrieved(Issued) Issued
Сертификат успешно выдан. Он подписан доверенным CA и выглядит валидным для домена.
Злоумышленник получает сертификат, который в системе ассоциируется с администратором домена, несмотря на то что запрос был отправлен от имени обычного пользователя. С помощью такого сертификата атакующий может получить Kerberos TGT (через certipy auth, Rubeus, PKINITtools и т. п.). Это дает полный доступ от имени Administrator.
После успешной отправки запроса в CA и получения сертификата (RequestID = 85) можно выяснить: кто запрашивал, какой шаблон использовался и какие значения содержатся в выданном сертификате. Это особенно важно для фиксации признаков атаки ESC6 и дальнейшего построения правил корреляции.
Просмотр информации
Для просмотра информации из базы CA используется команда:
certutil -config "GOODEX-SERVER.GOOD.EXPERT\GOOD-GOODEX-SERVER-CA-1" -view -restrict "RequestID=85" -out RequesterName,CertificateTemplate,SerialNumber
Результат:
Анализ содержимого сертификата
Чтобы проанализировать содержимое самого сертификата, используйте команду:
certutil -dump esc6.cer | findstr /C:"Subject:" /C:"Principal Name" /C:"Template=" /C:"Client Authentication" /C:"Issuer:" /C:"NotBefore:" /C:"NotAfter:"
Эта команда разбирает структуру файла сертификата esc6.cer, отбирая только ключевые строки:
Subject:— фактический субъект (обычно имя злоумышленника, напримерhacker);Principal Name:— значение UPN из SAN (например,Administrator@good.expert);Template=— имя шаблона, по которому выдан сертификат;Client Authentication— наличие EKU для аутентификации;Issuer:— кто выдал сертификат;NotBefore:/NotAfter:— срок действия сертификата.
Ожидаемый результат:
- RequesterName: GOOD\hacker
- SAN (UPN): Administrator@good.expert
- Template: ESC6
- EKU: Client Authentication
Дополнительно через графический интерфейс можно посмотреть настройки выданного сертификата:
Таким образом, в результате выпуска сертификата с подмененным UPN создается формально легитимный сертификат. Система распознает его как принадлежащий учетной записи администратора. Такой сертификат может быть использован для получения Kerberos TGT и последующей аутентификации в домене от имени администратора.
Это практическая реализация атаки ESC6, которая наглядно демонстрирует, насколько критичной может быть доверительная обработка поля SAN на уровне центра сертификации при некорректной конфигурации.
Действия злоумышленника не ограничиваются компрометацией учетных данных администратора домена. В дальнейшем атакующий может установить бэкдоры, добавить себя в группы и захватить полный контроль над доменом. Все это — следствие одного неправильно настроенного параметра в CA.
Есть смежная атака — ESC7, при которой злоумышленник сначала получает права ManageCA на уязвимом CA и самостоятельно включает флаг EDITF_ATTRIBUTESUBJECTALTNAME2, то есть создает условия для ESC6.
В сценарии выше предполагается, что администратор уже включил флаг. Если ACL CA позволяют постороннему управлять настройками, атакующий может сначала намеренно включить SAN‑флаг (это легко сделать с помощью одной команды certutil), а затем эксплуатировать технику ESC6. Поэтому защита должна охватывать оба аспекта: контроль прав на CA и настройку флага.
Важно на раннем этапе выявить ошибки конфигурации и факты их эксплуатации. Для обнаружения используются два основных подхода: на основе анализа событий (корреляций) и на основе аудита конфигурации CA. Также можно выделить комплексный подход к обнаружению с помощью EDR.
Один из способов выявления атаки ESC6 — это анализ событий аудита центра сертификации (AD CS), в частности события Event ID 4887 из журнала Microsoft-Windows-Security-Auditing. Оно возникает, когда центр сертификации одобряет запрос и выдает сертификат:
Обратите внимание на ключевые поля:
- Requester: GOOD\hacker — имя пользователя, от которого был подан запрос на сертификат;
- CertificateTemplate: ESC6 — шаблон, по которому был выдан сертификат;
- SAN:UPN=Administrator@good.expert — альтернативное имя, указанное в запросе;
- Subject: CN=User — отображаемое в сертификате имя (не используется при аутентификации).
Аномалия, когда имя (hacker) в поле Requester не соответствует UPN в SAN (Administrator@good.expert), — это явный признак попытки эксплуатации ESC‑атак: пользователь запрашивает сертификат, указывая в SAN чужую, высокопривилегированную учетную запись.
Конечно, событие связано с эксплуатацией уязвимости ESC6 лишь косвенно, однако его наличие — важный индикатор. Если в журналах появилось Event ID 4887, значит, пора проверить конфигурацию CA. В частности, нужно определить, включен ли флаг EDITF_ATTRIBUTESUBJECTALTNAME2, позволяющий передавать произвольный UPN через атрибут SAN. Если этот флаг активен, он открывает возможность для атак и требует немедленных мер.
Регулярный аудит конфигурации Enterprise CA на предмет активации потенциально опасного флага EDITF_ATTRIBUTESUBJECTALTNAME2 помогает выявить атаку ESC6 еще до эксплуатации. Такую проверку можно делать вручную или автоматизировать.
Проверка состояния флага вручную
Самый простой способ проверить флаг — выполнить на сервере CA команду:
certutil -getreg policy\EditFlags
Если в выводе присутствует флаг EDITF_ATTRIBUTESUBJECTALTNAME2 или установлен бит 0×40000 в шестнадцатеричном формате, значит, центр сертификации уязвим.
Автоматизация аудита и реагирования
Чтобы контролировать конфигурацию CA регулярно и автоматизированно, рекомендуем использовать системы мониторинга, инвентаризации и средства EDR. Реализовать автоматизацию можно двумя способами:
-
Регулярный запуск команды на хостах с агентами EDR:
certutil -getreg policy\EditFlags
Или:certutil -config "<CA>" -getreg "policy\EditFlags"
Если в результате обнаруживается активный флаг, агент может автоматически отключать флаг командойcertutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2или направить отдельную рекомендацию по отключению данного флага, если в нем нет необходимости. -
Постоянный мониторинг ветки реестра:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CertSvc\Configuration\<CA>\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy
Нужно извлекать значение параметраEditFlagsи выполнять побитовое сравнение с флагомEDITF_ATTRIBUTESUBJECTALTNAME2(значение0×40000в шестнадцатеричном формате или262144в десятичном формате).Рекомендуется настроить SIEM‑системы так, чтобы при изменении параметраEditFlagsи активации этого флага немедленно генерировалось предупреждение и служба безопасности автоматически получала уведомление. Это позволит отслеживать текущие изменения и проводить ретроспективный анализ событий безопасности в инфраструктуре.
Разберем, как реализовать эффективную многоуровневую защиту, на примере BI.ZONE EDR.
Метод предиктивного анализа
Для обнаружения атаки ESC6 используется метод предиктивного анализа: отслеживаются текущие конфигурации и потенциально опасные изменения в них. Это позволяет выявлять не только атаку, но и условия, которые могут к ней привести, еще до компрометации. Такой подход особенно эффективен, если на целевом сервере есть агент мониторинга.
Ключевой элемент атаки ESC6 — уязвимая конфигурация параметра EditFlags в реестре центра сертификации. Именно EDITF_ATTRIBUTESUBJECTALTNAME2 позволяет CA безусловно принимать значения поля SAN, указанные в самом запросе. Это создает возможность подмены критически важных идентификаторов, таких как UPN, DNS или SPN, что напрямую приводит к выпуску сертификатов от имени другого пользователя вплоть до администратора домена.
BI.ZONE EDR может просто проверить значение этого параметра и сообщить о наличии флага. Однако следующий комбинированный подход гораздо надежнее:
- Агент EDR в реальном времени отслеживает любые изменения параметра
EditFlagsв ветке реестра policy:HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\CertSvc\Configuration\<CA>\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy. - Если изменение зафиксировано, автоматически получаются актуальные значения всех флагов.
- BI.ZONE EDR анализирует полученные данные, и срабатывает предикт-правило, которое оценивает конфигурацию CA с учетом известных и потенциальных угроз.
Такой механизм позволяет не просто среагировать на атаку, а предотвратить ее, если вовремя обнаружить появление критичных флагов (например, в параметре EditFlags) и оперативно принять меры.
Проактивный контроль за изменениями в шаблонах сертификатов — ключ к сдерживанию атак до того, как они приведут к эскалации привилегий.
Полный анализ всех флагов
Флаг EDITF_ATTRIBUTESUBJECTALTNAME2 ключевой в контексте атаки ESC6, но он далеко не единственный. Зацикливаться только на нем — стратегическая ошибка. Центр сертификации управляется целым набором флагов (EditFlags), каждый из которых может по‑своему повлиять на безопасность выдачи сертификатов. Некоторые могут незаметно ослабить контроль, допуская подмену, обход ручного утверждения или обработку нестандартных запросов.
Эти аспекты выходят за рамки классической техники ESC6, но разумный подход к защите требует учитывать более широкую картину. По этой причине продвинутые решения, такие как EDR‑агенты (в частности, BI.ZONE EDR), отслеживают изменения всех критичных флагов CA и шаблонов сертификатов, чтобы зафиксировать даже малейшее отклонение от безопасной конфигурации.
Это не просто расширение анализа, а превентивная стратегия: выявить и остановить потенциальную уязвимость до того, как она будет использована в реальной атаке.
Вот список наиболее значимых флагов и их назначение.
| Флаг | Значение (hex и dec) | Описание | Уровень риска | Рекомендации | |
|---|---|---|---|---|---|
| 1 |
EDITF_ATTRIBUTESUBJECTALTNAME2 |
|
Позволяет использовать поле SAN из запроса на сертификат. Может применяться для выдачи сертификатов с поддельной идентичностью |
Критический |
Отключить, если нет жестко контролируемой необходимости |
| 2 |
EDITF_IGNORESIGNATURECHECK |
|
Отключает проверку цифровой подписи в запросах. Позволяет злоумышленникам отправлять поддельные запросы |
Критический |
Использовать только в тестовой среде. Отключить в рабочей |
| 3 |
EDITF_ENABLEOCSPREVNOCHECK |
|
Отключает проверку статуса OCSP для продлеваемых сертификатов. Может привести к использованию отозванных сертификатов |
Критический |
Отключить, если требуется строгая проверка статуса |
| 4 |
EDITF_ENABLELDAPREFERRALS |
|
Включает использование LDAP referrals. Может позволить обход ограничений безопасности |
Высокий |
Отключить, если нет конкретной бизнес‑необходимости |
| 5 |
EDITF_ENABLEUPNMAP |
|
Сопоставляет UPN с SAN. Может использоваться для подделки идентичности в шаблонах |
Высокий |
Контролировать использование. Не применять в шаблонах для машин |
| 6 |
EDITF_ENABLERENEWONBEHALFOF |
|
Позволяет одному пользователю обновлять сертификат от имени другого. Создает уязвимость при слабом контроле прав |
Высокий |
Запретить, если не нужна делегированная выдача |
| 7 |
EDITF_AUDITCERTTEMPLATELOAD |
|
Включает аудит загрузки шаблонов. Позволяет отслеживать изменения шаблонов сертификатов |
Нет риска |
Включить для мониторинга активности |
| 8 |
EDITF_ENABLEAKIKEYID |
|
Добавляет расширение Authority Key Identifier. Упрощает проверку цепочек доверия |
Средний |
Включить для большей надежности валидации |
| 9 |
EDITF_REQUESTEXTENSIONLIST |
|
Позволяет CA запрашивать список расширений, которые нужно включить |
Низкий |
Безопасен при корректной настройке |
| 10 |
EDITF_DISABLEEXTENSIONLIST |
|
Отключает определенные расширения, даже если они указаны в запросе |
Низкий |
Использовать, если нужна жесткая политика |
| 11 |
EDITF_ADDOLDKEYUSAGE |
|
Добавляет устаревшее расширение Key Usage. Обеспечивает совместимость со старыми системами |
Низкий |
Использовать, только если требуется для совместимости |
| 12 |
EDITF_BASICCONSTRAINTSCRITICAL |
|
Помечает Basic Constraints как критическое. Обеспечивает строгость проверки |
Нет риска |
Включить для надежности доверия |
| 13 |
EDITF_ENABLEDEFAULTSMIME |
|
Разрешает выпуск S/MIME‑сертификатов по умолчанию (шифрование email) |
Средний |
Применять в средах с электронной подписью и шифрованием |
| 14 |
EDITF_ENABLECHASECLIENTDC |
|
Проверяет DC‑клиентов при выдаче сертификатов |
Нет риска |
Применять в инфраструктурах с автообслуживанием DC |
| 15 |
EDITF_ENABLECROSSCERTPLACEHOLDER |
|
Включает поддержку плейсхолдеров для кросс‑сертификатов |
Средний |
Использовать под контролем только в сложных PKI‑структурах |
Каждый из этих флагов может повлиять на безопасность цепочки доверия в PKI. Поэтому их анализ должен быть не разовой проверкой, а частью постоянного мониторинга и предиктивной аналитики — это и реализовано в BI.ZONE EDR.
Лучший способ защиты от ESC6 — не допускать появления условий для этой атаки.
Если вы обнаружили, что в каком‑либо центре сертификации включен флаг EDITF_ATTRIBUTESUBJECTALTNAME2, незамедлительно отключите его. Сделать это можно через certutil с последующим перезапуском службы сертификатов:
certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2 net stop certsvc && net start certsvc
Первая команда убирает флаг SAN из EditFlags (обратите внимание, используется префикс - перед именем флага для его выключения). Вторая перезапускает службу AD CS для применения нового значения. После этого центр сертификации перестает принимать произвольные SAN из запросов (кроме случаев, когда сам шаблон позволяет Supply in the request, что нужно контролировать отдельно).
Помимо непосредственного отключения уязвимого флага, рекомендуем принять следующие меры защиты:
- Аудит и исправление шаблонов. Проверьте опубликованные шаблоны сертификатов в AD CS. Убедитесь, что у шаблонов, позволяющих аутентификацию (Client Authentication, Smartcard Logon и т. п.), отключена опция Supply in the request (если она не нужна) и ограничены права на выдачу всем пользователям, кроме администраторов. Шаблоны вроде User по умолчанию относительно безопасны при выключенном SAN‑флаге, но их публикация может быть не нужна во всех CA. Оцените необходимость каждого опубликованного шаблона. Удалите или запретите лишние — это сократит поверхность атаки.
- Ограничение прав в самом CA. Убедитесь, что только администраторы (Enterprise Admins, CA Admins) имеют привилегии ManageCA и ManageCertificates в вашем центре сертификации. Не давайте широким группам (например, Authenticated Users) административных прав. Это предотвратит ситуацию, когда злоумышленник сам включает опасный флаг через изменение настроек CA. Правильный ACL на объекте CA в AD (в контейнере PKI) — важный элемент защиты. Эта мера направлена скорее против ESC7, но она же не даст реализовать и преднамеренную ESC6.
- Обновление и усиление защиты аутентификации. Microsoft, осознав опасность атак через сертификаты (включая ESC6), выпустила обновления, усиливающие проверку сертификатов на контроллерах домена. В частности, патч KB5014754 вводит режимы Strong Certificate Mapping Enforcement. Начиная с определенных обновлений, AD может требовать, чтобы в сертификате присутствовала привязка к учетной записи (например, SID пользователя или запись в
altSecurityIdentities), иначе аутентификация отклоняется. - Мониторинг и обучение. Настройте постоянный мониторинг журнальных событий, чтобы отслеживать подозрительные выдачи сертификатов и случаи их использования для входа. Кроме того, проведите работу с администраторами, ответственными за PKI: объясните риск установки флага
EDITF_ATTRIBUTESUBJECTALTNAME2. Часто его включают автоматически, чтобы разрешить дополнительные DNS‑имена для веб‑сертификатов, не осознавая, что вместе с DNS он открывает возможность указывать UPN. Вместо включения глобального флага может быть безопаснее создать отдельный шаблон для веб‑сертификатов, где разрешено указывать SAN, и ограничить его использование нужной группой. Тогда потребность в глобальной настройке отпадает. В целом минимизируйте необходимостьEDITF_ATTRIBUTESUBJECTALTNAME2. В современных версиях Windows Server его включение практически не требуется: большинство сценариев можно решить другими способами.
В итоге рекомендации по защите сводятся к следующему:
- отключите опасный флаг;
- наведите порядок в шаблонах и правах;
- установите обновления и актуальные патчи безопасности.
Эти шаги как устранят саму уязвимость к технике ESC6, так и затруднят злоумышленникам эксплуатацию подобных схем.
Атака ESC6 на AD CS — наглядный пример того, как маленькая настройка в инфраструктуре безопасности может привести к катастрофическим последствиям. Включенный флаг, разрешающий устанавливать произвольный Subject Alternative Name, фактически сводит на нет модель доверия сертификатов: любой доменный пользователь может получить сертификат от имени другого пользователя. Злоумышленники активно пользуются этим, ведь такую атаку сложно обнаружить и она дает прямой доступ к привилегированным аккаунтам без взлома паролей или применения эксплоитов.
Специалистам по кибербезопасности важно знать об этой технике и проверять свои доменные центры сертификации. Если ваша компания использует AD CS, включите проверку ESC6 в регулярные аудиты: убедитесь, что EDITF_ATTRIBUTESUBJECTALTNAME2 не активен. А если по каким‑то причинам этот флаг нужен, оцените риски. Настройте оповещения или скрипты, которые сразу сообщат, если кто‑то изменит этот параметр, и отслеживайте выдачу и использование сертификатов.
Противостоять ESC6 несложно с помощью правильной конфигурации и постоянного мониторинга. Настраивайте инфраструктуру правильно, и атаки типа ESC6 останутся для вас лишь теоретическими примерами, а не реальной проблемой.