ESC14. Явное сопоставление сертификатов
Атака ESC14 основана на слабых или некорректных значениях атрибута altSecurityIdentities. Он позволяет явно связать сертификат X.509 с учетной записью в AD. Проблема возникает, когда в altSecurityIdentities используется одно из небезопасных сопоставлений, например:
X509:<RFC822>— сопоставление по email (из поля SAN).X509:<S>— сопоставление только по Subject.X509:<I>Issuer<S>Subject— сопоставление по паре Issuer + Subject без SID.KERBEROS:<principal>@REALM— сопоставление по Kerberos principal.
Эти формы уязвимы, потому что злоумышленник может выпустить собственный сертификат с такими же значениями и использовать его для входа от имени жертвы.
Техника реализуется при включенном флаге CT_FLAG_NO_SECURITY_EXTENSION в шаблоне сертификата. Этот флаг отключает встраивание SID в сертификат, из‑за чего контроллер домена не может точно связать его с конкретным объектом AD. Тогда DC пытается выполнить сопоставление по слабым признакам, в том числе по altSecurityIdentities.
Если хотя бы один из уязвимых форматов присутствует в altSecurityIdentities, а шаблон позволяет выдачу таких «облегченных» сертификатов, злоумышленник получает возможность пройти PKINIT-аутентификацию и выдать себя за любого пользователя в домене.
Есть четыре основных сценария этой атаки:
- A (добавление сопоставления вручную). Атакующий изменяет
altSecurityIdentitiesучетной записи жертвы, добавляя в него сертификат своей учетной записи. Теперь сертификат злоумышленника воспринимается как принадлежащий учетной записи жертвы. - B, C и D (эксплуатация существующего слабого сопоставления). В этом случае у целевой учетной записи уже есть слабое сопоставление сертификатов X.509 (X509RFC822, X509IssuerSubject, X509SubjectOnly). Злоумышленник подгоняет параметры своей учетной записи, чтобы соответствовать существующей привязке.
Выше приведены лишь основные комбинации, остальные ищите в таблице на GitHub. А более детальное описание каждого типа атаки читайте в статье ADCS ESC14 Abuse Technique от SpecterOps.
Атрибут altSecurityIdentities
altSecurityIdentities — это мультитекстовый атрибут объектов‑пользователей и сервисных аккаунтов в Active Directory, предназначенный для явного сопоставления внешней цифровой идентичности с учетной записью AD.
Фактически он выступает «картой соответствия» между сертификатами X.509 (или другими механизмами аутентификации) и конкретным sAMAccountName.
| Тип строки в атрибуте | Что хранит | Риск в ходе ESC14 |
|---|---|---|
| X509:<RFC822> |
Email из поля Subject Alternative Name |
Злоумышленник может выпустить сертификат с тем же email |
| X509:<S> |
Полный Subject сертификата |
Для получения сертификата на имя |
| X509:<I>Issuer<S>Subject |
Пара Issuer + Subject без SID‑расширения |
Позволяет подогнать сертификат под уже существующую запись |
| KERBEROS:<principal>@REALM |
Сопоставление внешнего Kerberos principal |
Может использоваться для спуфинга |
Использование атрибута в атаке ESC14
- Если шаблон сертификата выдает «облегченные» сертификаты (без расширения SID, флаг
CT_FLAG_NO_SECURITY_EXTENSIONвключен), то DC пытается сопоставить сертификат с учетной записью именно поaltSecurityIdentities. - При наличии слабых строк (
X509:<RFC822>,<S>,<I>...<S>) злоумышленнику остается лишь выпустить собственный сертификат с тем же значением поля и пройти PKINIT‑аутентификацию от имени жертвы — пароль не нужен. - Атрибут не меняет группы и не вызывает очевидных событий аудита, поэтому атака малозаметна.
Атака возможна, только если включен CT_FLAG_NO_SECURITY_EXTENSION. При этом должно быть выполнено три условия:
- Учетная запись жертвы должна иметь атрибут
altSecurityIdentitiesс уязвимыми строками:X509:<RFC822>(привязка по email);X509:<S>(только Subject);X509:<I>Issuer<S>Subject(без<SR>).
- Шаблон сертификата должен поддерживать уязвимую настройку:
- Шаблон позволяет указывать произвольные Subject/SAN.
- EKU позволяет аутентификацию (Client Auth или Smart Card Logon).
- Нет ограничений на выпуск (типа RA‑одобрения, manager approval).
- У пользователя есть права на выпуск сертификатов через этот шаблон.
- Контроллер домена не должен использовать строгую проверку сертификатов: в реестре DC значение
HKLM\SYSTEM\CurrentControlSet\Services\Kdc\StrongCertificateBindingEnforcementравно0или1. Если у вас установлено обновление KB5014754, то с февраля 2025 года параметрStrongCertificateBindingEnforcementпо умолчанию равен2, что означает строгое сопоставление.
Атакующий (ESC14User) получает сертификат определенного шаблона (ESC14Temp) от корпоративного центра сертификации (GOOD-GOODEX-SERVER-CA-1 в домене good.expert). После он использует этот сертификат для аутентификации как привилегированная жертва (учетная запись Administrator).
Рассмотрим четыре сценария атаки ESC14 — от A до D — с пошаговыми действиями, схемами и пояснениями. Каждый включает необходимые условия и логику применения.
Условия и суть атаки
Атакующий имеет права на запись атрибута altSecurityIdentities учетной записи Administrator (например, получив права GenericWrite на учетную запись жертвы). Это позволяет явно привязать произвольный сертификат к учетной записи администратора.
Злоумышленник запрашивает сертификат на свое контролируемое лицо (например, на себя или на скомпрометированный компьютер), затем дописывает в атрибут Administrator ссылку на этот сертификат. После этого с помощью сертификата выполняется Kerberos PKINIT — аутентификация, и атакующий получает Kerberos TGT от имени Administrator.
Этот сценарий работает даже при строгом режиме сопоставления сертификатов на контроллере домена, так как используется прямое сопоставление по Issuer/Serial, считающееся надежным.
Схема атаки
Рассмотрим общую схему сценария A.
На этой схеме:
- Атакующий (ESC14User) — скомпрометированная учетная запись домена (
good.expert), от лица которой выполняются команды. Обладает нужными правами (например, на изменение атрибутов жертвы). - Центр сертификации — сервер AD CS
GOOD-GOODEX-SERVER-CA-1, выпускающий сертификаты по шаблону ESC14Temp. - Учетная запись жертвы (Administrator) — целевая привилегированная учетная запись, которую атакующий стремится имперсонировать.
- Контроллер домена (DC) — контроллер (KDC) по адресу
10.3.132.172, принимающий сертификат при Kerberos PKINIT и выдающий Kerberos-токены.
Атака по сценарию A состоит из следующих этапов:
- Атакующий запрашивает у CA выпуск сертификата по уязвимому шаблону ESC14Temp.
- Центр сертификации подтверждает запрос и выдает атакующему сертификат (публичный сертификат и приватный ключ).
- Злоумышленник дописывает в Active Directory в атрибут
altSecurityIdentitiesучетной записиAdministratorссылку, однозначно указывающую на выданный сертификат. - Атакующий с помощью утилиты (Rubeus или Certipy) выполняет Kerberos-аутентификацию по сертификату (PKINIT) — предъявляет сертификат контроллеру домена.
- Контроллер домена проверяет, что сертификат соответствует
altSecurityIdentitiesAdministrator, и выдает атакующему Kerberos TGT от имениAdministrator.
В итоге атакующий получает привилегированный Kerberos-токен и доступ от имени администратора. После завершения атаки запись в altSecurityIdentities очищается для маскировки.
Пошаговое выполнение сценария A
Теперь разберем ход атаки в деталях.
Шаг 1. Получение сертификата с помощью Certify
Атакующий запрашивает сертификат у CA, используя шаблон ESC14Temp. Команда выполняется в контексте скомпрометированной учетной записи (ESC14User), например, в PowerShell:
.\Certify.exe request /ca:GOOD-GOODEX-SERVER-CA-1\GOOD-GOODEX-SERVER-CA-1 /template:ESC14Temp
Шаг 2. Конвертация сертификата с помощью certutil
Сертификат и ключ сохраняются и объединяются в формат PFX (PKCS #12) для удобства использования. Например:
# Сохранить вывод Certify в файлы (предварительно выполнено вручную или перенаправлением) echo "[PRIVATE KEY]" > cert-a.key echo "[CERTIFICATE]" > cert-a.pem # Объединить PEM в PFX: certutil -MergePFX .\cert-a.pem .\cert-a.pfx
Когда Certify выводит сертификат, оператор должен сохранить приватный ключ (между -----BEGIN RSA PRIVATE KEY----- и -----END RSA PRIVATE KEY-----) в файл, например cert-a.key, а сертификат (блок BEGIN CERTIFICATE) — в cert-a.pem. Затем утилита Windows certutil с командой -MergePFX объединяет ключ и сертификат в PFX‑контейнер cert-a.pfx.
Пояснение для команд red team
При выполнении команды система предложит установить пароль на PFX‑файл. Для упрощения в лабораторных условиях можно оставить пароль пустым, нажав Enter: тогда PFX‑файл не будет зашифрован. В результате получается файл cert-a.pfx, содержащий приватный ключ и сертификат атакующего.
Шаг 3. Получение серийного номера и Issuer сертификата
Чтобы сформировалась строка сопоставления, необходимо определить издателя (Issuer) и серийный номер полученного сертификата. Атакующий выполняет команду certutil для вывода подробной информации: certutil -v -dump .\cert-a.pfx.
Пояснение для команд red team
Команда certutil -v -dump .\cert-a.pfx отобразит сведения о сертификате. Обратите внимание на поля Issuer и Serial. Issuer — это DN центра сертификации, выдавшего сертификат (например, CN=GOOD-GOODEX-SERVER-CA-1,DC=good,DC=expert). Serial будет указан в hex‑формате. Скопируйте эти значения, например: Issuer = CN=GOOD-GOODEX-SERVER-CA-1,DC=good,DC=expert; Serial = 0x6C0000000...25F9... (строка hex). Для последующего шага важно удалить префикс 0x и пробелы, чтобы получить чистую шестнадцатеричную строку серийного номера. Например, серийный номер 0x6c 25 95 f9... преобразуется в строку 6C2595F9....
Шаг 4. Формирование строки altSecurityIdentities
В сценарии A создается явное сопоставление сертификата: строка будет содержать Issuer и Serial, указывающие на сертификат атакующего. Формат строки — X509:<I>IssuerDN<SR>SerialHex. Злоумышленник подставляет значения из предыдущего шага: X509:<I>CN=GOOD-GOODEX-SERVER-CA-1,DC=good,DC=expert<SR>6C2595F9....
Пояснение для команд red team
Префикс X509:<I>...<SR>... означает сопоставление по Issuer и Serial (Reversed). Включается полное имя издателя сертификата (IssuerDN) после <I>, затем <SR> и без пробелов сразу подряд — шестнадцатеричный серийный номер сертификата. Обратите внимание: <SR> указывает на использование серийного номера, представленного в нужном порядке (в некоторых случаях требуется именно Serial (Reversed), как в примере). Эта строка уникально идентифицирует выданный сертификат.
Шаг 5. Назначение строки altSecurityIdentities учетной записи Administrator
Теперь атакующий прописывает сформированную строку в атрибут altSecurityIdentities жертвы (Administrator). Это можно сделать с помощью ADSI Edit либо PowerShell-скрипта Add-AltSecIDMapping. Например, с помощью PowerShell:
$targetDN = "CN=Administrator,CN=Users,DC=good,DC=expert"
$mapping = 'X509:<I>CN=GOOD-GOODEX-SERVER-CA-1,DC=good,DC=expert<SR>6C2595F9...'
Set-ADUser -Identity $targetDN -Add @{altSecurityIdentities=$mapping}
Либо используя скрипт:
Import-Module .\Add-AltSecIDMapping.ps1 Add-AltSecIDMapping -DistinguishedName $targetDN -MappingString $mapping
Пояснение для команд red team
Здесь targetDN — DN объекта Administrator в AD. Команда Set-ADUser -Add добавляет новое значение в многозначный атрибут altSecurityIdentities. В результате у учетной записи Administrator появляется явное сопоставление на сертификат атакующего. Иными словами, домен теперь «знает», что предъявление этого сертификата эквивалентно аутентификации в качестве Administrator.
Шаг 6. Получение Kerberos TGT через сертификат (Rubeus)
После установки атакующий может получить Kerberos-тикет от имени Administrator с помощью PKINIT, например используя утилиту Rubeus:
Rubeus.exe asktgt /user:Administrator /certificate:cert-a.pfx /password:"" /dc:10.3.132.172 /domain:good.expert /ptt
Пояснение для команд red team
- Команда
asktgtзапрашивает у KDC Kerberos TGT для пользователяAdministrator, используя предоставленный сертификат (файл PFXcert-a.pfx). - Параметр
/password:""указывает пустой пароль PFX (если вы не задавали пароль при экспорте). - Ключ
/dc:10.3.132.172направляет запрос на конкретный DC. - Указание
/domain:good.expert— домен учетной записи. Флаг/ptt(pass-the‑ticket) сразу загружает полученный тикет в текущую сессию (в оперативную память).
После выполнения этой команды Rubeus выводит, что TGT получен и (при /ptt) тикет внедрен, — с этого момента командная оболочка атакующего имеет Kerberos-токен Administrator (можно проверить с помощью klist). Благодаря ранее добавленному altSecurityIdentities контроллер домена принимает сертификат атакующего как принадлежащий Administrator и выдает TGT.
Шаг 7. Очистка следов — удаление altSecurityIdentities
Завершив атаку, злоумышленник удаляет добавленное значение altSecurityIdentities, чтобы скрыть следы и восстановить исходное состояние учетной записи Administrator. Например:
# Удалить значение altSecurityIdentities Set-ADUser -Identity $targetDN -Clear altSecurityIdentities
Либо атакующий может использовать специальный скрипт: Remove-AltSecIDMapping -DistinguishedName $targetDN.
Условия и суть атаки
У учетной записи жертвы (Administrator) заранее установлено в altSecurityIdentities слабое сравнение по email (тип X509RFC822). Например, altSecurityIdentities содержит значение X509:<RFC822>administrator@good.expert. Это означает, что любой сертификат с полем электронной почты administrator@good.expert будет принят для аутентификации как Administrator.
У атакующего нет прямого доступа на изменение altSecurityIdentities Administrator, однако есть возможность изменить атрибут mail контролируемого пользователя (ESC14User). В этом сценарии злоумышленник меняет email своей учетной записи на тот, что указан в маппинге жертвы, затем получает сертификат по шаблону, требующему наличие email. Таким образом в сертификат включается нужный RFC822Name. После этого атакующий использует полученный сертификат для PKINIT-аутентификации, и контроллер домена впускает его как Administrator на основании совпадения email.
Схема атаки
Рассмотрим общую схему сценария B.
На этой схеме:
- Атакующий (ESC14User) — контролируемая учетная запись, чьи атрибуты (email) можно изменять.
- AD-объект ESC14User — запись пользователя атакующего в AD, в которую вносится изменение адреса электронной почты.
- CA: GOOD-GOODEX-SERVER-CA-1 — CA, выпускающий сертификат по шаблону ESC14Temp (в этом случае шаблон настроен требовать наличие email).
- DC — KDC, который проверяет предъявленный сертификат: извлекает из него поле RFC822Name и ищет соответствие в
altSecurityIdentitiesAdministrator. - Учетная запись Administrator (жертва) — имеет
altSecurityIdentitiesс маппингом типа RFC822Name (email) на значениеadministrator@good.expert.
Атака по сценарию B состоит из следующих этапов:
- Атакующий через AD изменяет атрибут mail своей учетной записи
ESC14User, устанавливая адрес, совпадающий с тем, что указан вaltSecurityIdentitiesAdministrator(например,administrator@good.expert). - Злоумышленник запрашивает у CA выпуск сертификата по шаблону ESC14Temp, который использует поле mail пользователя для включения subject alternative name типа RFC822 (email) в сертификат.
- Центр сертификации выпускает для ESC14User сертификат, содержащий альтернативное имя — email
administrator@good.expert. - Атакующий предъявляет этот сертификат контроллеру домена при Kerberos-аутентификации (PKINIT).
- Контроллер домена видит, что в сертификате указан email
administrator@good.expert, сверяет его сaltSecurityIdentitiesучетной записиAdministratorи находит соответствие (X509RFC822).
Поскольку сертификат выпущен доверенным центром и метод сопоставления по email разрешен (в режиме совместимости), DC выдает атакующему Kerberos TGT от имени Administrator. В итоге злоумышленник получает права администратора. После атаки измененные значения (email) возвращаются в исходное состояние, при необходимости altSecurityIdentities жертвы очищается, если оно было добавлено для лабораторной демонстрации.
Пошаговое выполнение сценария B
Теперь разберем ход атаки в деталях.
Шаг 1. Настройка поля mail у атакующего
Атакующий устанавливает у своей учетной записи ESC14User адрес электронной почты, совпадающий с маппингом жертвы. Например, если известно, что у Administrator в altSecurityIdentities прописано administrator@good.expert, он выполняет:
Set-ADUser ESC14User -EmailAddress "administrator@good.expert"
Пояснение для команд red team
Эта команда (или аналогичное изменение через GUI/ADSI) задает атрибут mail для пользователя ESC14User. Предполагается, что атакующий имеет права изменить собственный email (или email другого скомпрометированного пользователя).
Теперь учетная запись ESC14User в AD имеет тот же email, что и указанный в altSecurityIdentities Administrator. Это подготовительный шаг, необходимый для того, чтобы центр сертификации включил нужный email в сертификат.
Шаг 2. Запрос сертификата с email через Certify
Злоумышленник запрашивает сертификат по шаблону ESC14Temp, который должен быть настроен на включение email в subject alternative name. Команда Certify может быть такой:
.\Certify.exe request /ca:"GOOD-GOODEX-SERVER-CA-1\GOOD-GOODEX-SERVER-CA-1" /template:ESC14Temp
Пояснение для команд red team
Certify выполнит запрос от имени ESC14User. Шаблон ESC14Temp в этом сценарии имеет флаг, требующий наличия email (CT_FLAG_SUBJECT_ALT_REQUIRE_EMAIL в атрибуте шаблона).
CA при выпуске возьмет из атрибутов пользователя значение mail и включит его как RFC822Name в сертификат. После выполнения команды Certify вы получите приватный ключ и сертификат (вывод в PEM).
В поле Subject Alternative Name этого сертификата теперь присутствует email administrator@good.expert. Убедиться в этом можно, просмотрев содержимое сертификата (например, выполнив certutil -dump или открыв PEM‑файл в текстовом редакторе: строка RFC822Name=administrator@good.expert).
Приватный ключ и сертификат сохраняются так же, как на втором шаге сценария A: создаются cert-b.pem и cert-b.key).
Шаг 3. Конвертация сертификата в PFX
Атакующий объединяет ключ и сертификат в файл PFX для последующего использования:
certutil -MergePFX .\cert-b.pem .\cert-b.pfx
Пояснение для команд red team
- Формирование строки altSecurityIdentities. В этом сценарии атакующему не требуется формировать или добавлять новое сопоставление. Предполагается, что учетная запись
Administratorуже имеетaltSecurityIdentitiesвидаX509:<RFC822>administrator@good.expert. Это уязвимая конфигурация, допустимая, например если администратору намеренно или по ошибке добавили сравнение по email. Таким образом, шаг формирования строки можно пропустить. - Назначение altSecurityIdentities жертве. В сценарии B нет этого шага, так как маппинг уже присутствует у жертвы. Атакующий не вносит изменений в атрибут
Administrator— это важное отличие от сценария A. Вся атака опирается на уже существующее слабое отображение сертификата по email.
Если по условиям лаборатории нужно было предварительно настроить altSecurityIdentities Administrator, это делает заранее администратор безопасности. Либо можно имитировать, выполнив Set-ADUser Administrator -Add @{altSecurityIdentities=’X509:<RFC822>administrator@good.expert’}, однако в реальных условиях это предпосылка, а не действие атакующего.
Шаг 4. Получение Kerberos TGT через сертификат (Certipy)
Теперь атакующий использует полученный сертификат с email для аутентификации. Вот как это происходит с утилитой Certipy (в качестве примера альтернативы Rubeus):
certipy auth -pfx cert-b.pfx -dc-ip 10.3.132.172 -username Administrator -domain good.expert
Пояснение для команд red team
Команда Certipy auth с параметром -pfx выполняет PKINIT-аутентификацию на указанный контроллер домена, используя сертификат из cert-b.pfx. Certipy автоматически определит, что в сертификате присутствует SAN с UPN или email, в нашем случае — email Administrator. При успешном сопоставлении Certipy получит Kerberos TGT от имени Administrator и сохранит его по умолчанию в файл кеша administrator.ccache, а также отобразит хеш пароля, если возможно. В выводе Certipy можно увидеть, что certificate identities включают SAN UPN или SAN email с указанным адресом и сообщение Got TGT.
Это означает, что аутентификация прошла: контроллер домена нашел в altSecurityIdentities Administrator соответствие email из сертификата и выдал билет. Если бы DC требовал строгого сопоставления, атака бы не сработала, но при настройках по умолчанию для Windows Server до 2025 года метод RFC822Name разрешен для PKINIT.
Шаг 5. Очистка изменений
После завершения атаки атакующий возвращает измененные данные обратно. Он восстанавливает поле mail своей учетной записи и при необходимости убирает у Administrator небезопасный altSecurityIdentities. Например:
Set-ADUser ESC14User -EmailAddress "<исходный_email>" # (Если altSecurityIdentities у Administrator был добавлен искусственно в лаборатории) Set-ADUser Administrator -Clear altSecurityIdentities
Пояснение для команд red team
Эти команды возвращают среду в исходное состояние. В реальной атаке сам по себе altSecurityIdentities жертвы атакующий не менял, однако после выявления инцидента администраторам нужно удалить подобные слабые маппинги (в этом случае — запись с RFC822Name), чтобы закрыть уязвимость. Кроме того, сертификат, выпущенный на имя атакующего с email администратора, следует отозвать на стороне CA.
Условия и суть атаки
У учетной записи Administrator в altSecurityIdentities есть сравнение по типу X509IssuerSubject, то есть сопоставление по издателю и имени субъекта сертификата. Этот вид отображения означает, что сертификат, выпущенный определенным центром (Issuer) и имеющий определенное имя Subject, будет принят как аутентификация данного пользователя. Например, Administrator может иметь altSecurityIdentities: X509:<I>CN=GOOD-GOODEX-SERVER-CA-1,DC=good,DC=expert<S>CN=Administrator,CN=Users,DC=good,DC=expert (здесь указаны DN издателя сертификата и субъекта с именем Administrator в домене). Такое сравнение полей уязвимо в том случае, если атакующий может выпустить на контролируемого пользователя сертификат с таким же Subject.
В этом сценарии атакующий имеет права менять CN (имя) своего пользователя ESC14User. Он перемещает или переименовывает свою учетную запись так, чтобы ее CN совпадал с именем субъекта из маппинга жертвы (например, Administrator). Затем злоумышленник запрашивает сертификат шаблона ESC14Temp, а центр сертификации формирует Subject сертификата на основе атрибутов AD (CN и прочие). В результате выданный сертификат получает Subject, идентичный требуемому. Поскольку проверяется только пара Issuer + Subject, новый сертификат подходит под altSecurityIdentities Administrator. Далее — стандартный PKINIT, получение TGT.
Условие: сертификат должен быть выдан тем же CA, который указан в маппинге (GOOD-GOODEX-SERVER-CA-1), и контроллер домена должен позволять слабое сопоставление. Issuer + Subject считается более надежным, чем только Subject, но при самом строгом режиме DC может требовать SID в сертификате. Однако по умолчанию Issuer + Subject допустимо.
Схема атаки
Рассмотрим общую схему сценария C.
На этой схеме:
- Атакующий (ESC14User) — учетная запись атакующего, которую можно переименовать (изменить CN).
- AD-объект ESC14User — запись пользователя в AD, подвергаемая изменению имени (CN) и при необходимости перемещению в другой контейнер.
- CA: GOOD-GOODEX-SERVER-CA-1 — CA, выпускающий сертификат. Важно, что это тот же CA, на который ссылается маппинг жертвы.
- DC — проверяет предъявленный сертификат: извлекает его Issuer и Subject, ищет совпадение с
altSecurityIdentitiesAdministrator. - Учетная запись Administrator — имеет
altSecurityIdentitiesс типом X509IssuerSubject, указывающим на конкретные Issuer и Subject Name.
Атака по сценарию C состоит из следующих этапов:
- Атакующий через учетную запись
ESC14Userвыполняет переименование — устанавливает для себяCN=Administrator. Поскольку в домене не может существовать двух объектов с одинаковым DN, атакующий, как правило, перемещает свою учетную запись в иной OU или контейнер (отличный от того, где находится реальныйAdministrator, например из Users в специально созданный OU), после чего меняет CN. В результате distinguished name учетной записи атакующего становится, например,CN=Administrator,OU=Temp,DC=good,DC=expert, что позволяет иметь CNAdministrator. - Злоумышленник запрашивает у CA сертификат по шаблону ESC14Temp. Шаблон настроен требовать наличие common name (CN) и не включать в Subject путь по каталогу (без флага
DirectoryPath), поэтому Subject выдаваемого сертификата совпадет с CN учетной записи и, возможно, доменными компонентами. В этом случае CA сформирует Subject сертификата какCN=Administrator,OU=Temp,DC=good,DC=expert. - CA выдает сертификат для
ESC14Userс указанным Subject. - Атакующий выполняет PKINIT — предъявляет сертификат контроллеру домена.
- Контроллер домена сопоставляет Issuer сертификата (
GOOD-GOODEX-SERVER-CA-1) и Subject (CN=Administrator,OU=Temp,...).
Хотя в Subject сертификата присутствует OU=Temp (поскольку вошел в distinguished name субъекта), altSecurityIdentities типа Issuer + Subject обычно сравнивает атрибуты CN (имя) и прочие поля Subject по строковому соответствию. Критично, что CN=Administrator присутствует и совпадает с маппингом (в данном примере предполагается, что маппинг на стороне Administrator хранил именно строку CN=Administrator,OU=Temp,DC=good,DC=expert или даже просто CN=Administrator — возможны вариации). Таким образом, сертификат признается соответствующим учетной записи Administrator, и DC выдает атакующему Kerberos TGT от имени Administrator. После атаки учетная запись атакующего переименовывается обратно и при необходимости у Administrator убирается уязвимый маппинг.
Пошаговое выполнение сценария C
Теперь разберем ход атаки в деталях.
Шаг 1. Изменение имени (CN) учетной записи атакующего
Для имитации имени администратора атакующий переименовывает свой объект AD. Например:
# Переместить учетную запись в другой контейнер, чтобы избежать конфликтов имен Move-ADObject "CN=ESC14User,CN=Users,DC=good,DC=expert" -TargetPath "OU=Temp,DC=good,DC=expert" # Переименовать CN в "Administrator" Rename-ADObject "CN=ESC14User,OU=Temp,DC=good,DC=expert" -NewName "Administrator"
Пояснение для команд red team
Эти команды требуют у атакующего соответствующих прав на изменение свойств учетной записи ESC14User (что логично: он контролирует свою учетную запись). Переместите объект в OU=Temp (предварительно созданный). Это нужно, если у Administrator маппинг содержит именно имя Administrator без учета OU либо если в том же контейнере Users уже есть CN=Administrator — система не позволит создать дубликат.
После перемещения выполняется Rename-ADObject, который меняет атрибут CN (и, соответственно, name) на Administrator. В итоге ESC14User теперь имеет CN как у жертвы. Заметьте: если маппинг X509IssuerSubject у Administrator был настроен не строго на строку CN=Administrator,CN=Users,..., а, например, просто на CN=Administrator (что маловероятно — обычно хранится полный Subject), то достаточно совпадения CN. На всякий случай сделайте точное совпадение полного Subject Distinguished Name.
Шаг 2. Запрос сертификата через Certify
Теперь атакующий запрашивает сертификат, используя обновленный объект ESC14User (с CN=Administrator). Команда аналогична предыдущим:
.\Certify.exe request /ca:"GOOD-GOODEX-SERVER-CA-1\GOOD-GOODEX-SERVER-CA-1" /template:ESC14Temp
Шаг 3. Конвертация в PFX
Злоумышленник объединяет сертификат и ключ:
certutil -MergePFX .\cert-c.pem .\cert-c.pfx
Пояснение для команд red team
- Формирование строки altSecurityIdentities. В сценарии C атакующий не создает новый маппинг. Предполагается, что учетная запись
Administratorуже имеетaltSecurityIdentitiesтипа X509IssuerSubject, ссылающийся на Issuer =GOOD-GOODEX-SERVER-CA-1и Subject, содержащий имяAdministrator. Таким образом, шаг формирования строки пропускается: маппинг существовал заранее. Например, администратор ранее получил сертификат и записал сопоставление или унаследовал его. - Назначение altSecurityIdentities жертве. Этот шаг не выполняется, так как нужный
altSecurityIdentitiesуже есть уAdministrator. Атакующий не меняет атрибут жертвы, он лишь подгоняет свой сертификат под имеющуюся запись. Если необходимо было эмулировать слабый маппинг в лаборатории, администратор добавил быaltSecurityIdentities, как показано выше. Но в рамках сценария это условие, а не действие атакующего.
Шаг 4. Получение Kerberos TGT через сертификат (Rubeus)
Атакующий использует Rubeus для получения билета с новым сертификатом:
Rubeus.exe asktgt /user:Administrator /certificate:cert-c.pfx /password:"" /dc:10.3.132.172 /domain:good.expert /ptt
Шаг 5. Очистка и восстановление
Завершив атаку, злоумышленник возвращает свою учетную запись на место и убирает изменения. Например:
Rename-ADObject "CN=Administrator,OU=Temp,DC=good,DC=expert" -NewName "ESC14User" Move-ADObject "CN=ESC14User,OU=Temp,DC=good,DC=expert" -TargetPath "CN=Users,DC=good,DC=expert" # (При необходимости у Administrator удаляется уязвимый маппинг) Set-ADUser Administrator -Clear altSecurityIdentities
Условия и суть атаки
В этом сценарии учетная запись Administrator имеет altSecurityIdentities типа X509SubjectOnly, то есть сопоставление только по имени субъекта сертификата, без привязки к конкретному издателю.
Пример: X509: (возможны варианты записи, например полное distinguished name субъекта без указания Issuer). Этот вариант — самый слабый, так как любой сертификат, выпущенный любым доверенным CA, с соответствующим Subject может быть использован для входа.
Атакующий, как и в сценарии C, может изменить свою учетную запись ESC14User так, чтобы ее CN совпадал с требуемым Subject (Administrator). Отличие в том, что теперь неважно, каким центром сертификации будет выпущен сертификат (хотя практически использовать удобнее корпоративный CA).
Предположим, altSecurityIdentities Administrator содержит строку X509: (без указания OU, DC). Атакующий переименовывает свою учетную запись ESC14User в CN=Administrator (при необходимости в другом OU). Затем запрашивает сертификат по шаблону, который требует наличие common name, но не включает привязку к каталогу или email (CT_FLAG_SUBJECT_REQUIRE_COMMON_NAME, без флага DIRECTORY_PATH и без REQUIRE_EMAIL).
Таким образом, Subject сертификата = CN=Administrator (возможно, без дополнительных полей). Контроллер домена при проверке сопоставляет только CN=Administrator. И поскольку Issuer не учитывается, сертификат, даже выданный тем же или иным доверенным CA, подходит. Далее — PKINIT и получение TGT администратора.
Условие: DC должен разрешать слабое сопоставление.
Схема атаки
Рассмотрим общую схему сценария D.
На этой схеме:
- Атакующий (ESC14User) — учетная запись, переименовываемая в
Administrator - AD-объект ESC14User — изменяется CN (и name) на требуемое.
- Центр сертификации —
GOOD-GOODEX-SERVER-CA-1, выпускает сертификат (в принципе мог бы быть любой Enterprise CA, так как Issuer не важен, но в домене доверены только те, что в хранилище NTAuth). - DC — принимает сертификат, извлекает имя субъекта.
- Учетная запись Administrator — имеет
altSecurityIdentitiesтипа SubjectOnly, например указано толькоCN=Administrator.
Атака по сценарию D состоит из следующих этапов:
- Атакующий перемещает свою учетную запись в другой OU и меняет имя своей учетной записи
ESC14UserнаAdministrator. Переименование обязательно, чтобы Subject сертификата содержал нужное значение. Перемещение нужно, чтобы избежать конфликта с оригинальным объектомCN=Administrator. - Атакующий запрашивает сертификат у CA. Шаблон ESC14Temp настроен без включения UPN/email, Subject формируется с common name =
Administrator. Если в шаблоне отключено требованиеDirectoryPath, то CA может выпустить сертификат только сCN=Administrator. Subject-строка не будет включатьOU=...,DC=...в зависимости от конфигурации шаблона. Однако, даже если включает, маппинг SubjectOnly может быть настроен гибко. Здесь для простоты предполагаем, что получен сертификат с Subject именноCN=Administrator. - CA выдает сертификат. Сертификат содержит Subject =
CN=Administrator. - С помощью Rubeus или Certipy атакующий осуществляет PKINIT, предъявляя сертификат. Certipy автоматически передает сертификат контроллеру домена.
- Контроллер домена проверяет
altSecurityIdentitiesAdministratorи находит запись SubjectOnly с именемCN=Administrator. Поскольку наш сертификат имеет такой Subject, этого достаточно для успешного входа. DC выдает Kerberos TGT дляAdministrator.
Атакующий получает привилегии администратора. После проведения атаки учетная запись и altSecurityIdentities приводятся в исходное состояние.
Пошаговое выполнение сценария D
Теперь разберем ход атаки в деталях.
Шаг 1. Переименование учетной записи атакующего
Этот шаг аналогичен описанному в сценарии C (шаг 1):
Move-ADObject "CN=ESC14User,CN=Users,DC=good,DC=expert" -TargetPath "OU=Temp,DC=good,DC=expert" Rename-ADObject "CN=ESC14User,OU=Temp,DC=good,DC=expert" -NewName "Administrator"
Пояснение для команд red team
Учетная запись ESC14User перемещена в OU=Temp и переименована в CN=Administrator. Теперь ее Subject DN потенциально будет начинаться с CN=Administrator. В этом сценарии предположим, что altSecurityIdentities жертвы содержит только CN (например, Subject CN=Administrator без указания OU/DC), поэтому точное совпадение CN — главное условие.
Шаг 2. Запрос сертификата через Certify
Атакующий запрашивает сертификат шаблона ESC14Temp:
.\Certify.exe request /ca:GOOD-GOODEX-SERVER-CA-1\GOOD-GOODEX-SERVER-CA-1 /template:ESC14Temp
Шаг 3. Конвертация сертификата
Злоумышленник сохраняет и объединяет сертификат в PFX:
certutil -MergePFX .\cert-d.pem .\cert-d.pfx
Пояснение для команд red team
- Формирование строки altSecurityIdentities. Шаг не выполняется, так как
altSecurityIdentitiesжертвы уже содержит нужное сопоставление. В условиях сценария D предполагается, что уAdministratorпрописаноX509:<Subject>...с именемAdministrator. Атакующий не добавляет ничего. - Назначение altSecurityIdentities жертве. Этот шаг пропускается — маппинг SubjectOnly уже был на месте, атакующий ничего не меняет в учетной записи
Administrator.
Шаг 4. Получение Kerberos TGT через сертификат (Certipy)
Атакующий может использовать Certipy для аутентификации:
certipy auth -pfx cert-d.pfx -dc-ip 10.3.132.172 -username Administrator -domain good.expert
Certipy выполнит PKINIT с сертификатом cert-d.pfx. Контроллер домена в режиме совместимости допускает сопоставление только по имени субъекта (значение S4U2Self в CertificateMappingMethods реестра по умолчанию включает SubjectOnly, 0x8). При предъявлении сертификата Certipy или KDC обнаружат, что его Subject содержит Administrator и найдут соответствие в altSecurityIdentities Administrator.
Таким образом, будет выдан TGT. Certipy сообщит об успешной аутентификации (получен TGT и, вероятно, NTLM‑хеш администратора, если у него были права на запрашиваемые данные, как это происходит автоматически для уверенности в получении привилегий). Атакующий теперь обладает учетными данными администратора в виде Kerberos-тикета.
Шаг 5. Очистка
Злоумышленник возвращает изменения: переименовывает свою учетную запись обратно и, если требуется, убирает у Administrator запись altSecurityIdentities.
Rename-ADObject "CN=Administrator,OU=Temp,DC=good,DC=expert" -NewName "ESC14User" Move-ADObject "CN=ESC14User,OU=Temp,DC=good,DC=expert" -TargetPath "CN=Users,DC=good,DC=expert" Set-ADUser Administrator -Clear altSecurityIdentities
Пояснение для команд red team
Учетная запись ESC14User возвращена в исходное состояние. Запись altSecurityIdentities типа SubjectOnly крайне опасна, так как позволяет любому сертификату с подходящим Subject аутентифицироваться как привилегированный пользователь. Удалите ее в ходе восстановления безопасности. Также отзовите выданный сертификат ESC14Temp, если CA не настроен на автоматическое отклонение подобных сертификатов.
Рассмотренные сценарии A–D техники ESC14 демонстрируют различные варианты использования атрибута altSecurityIdentities.
В зависимости от предварительной конфигурации целевой учетной записи (присутствие слабых маппингов) и привилегий атакующего, злоумышленник может либо явно привязать свой сертификат к жертве (сценарий A), либо подобрать сертификат под уже существующее сопоставление (сценарии B–D).
Общая логика — использование уязвимых шаблонов сертификатов AD CS (например, допускающих произвольный Subject или включение email) и последующая аутентификация с полученным сертификатом.
При построении механизмов обнаружения атак на инфраструктуру AD CS целесообразно опираться не только на отдельные события, но и на корреляцию различных типов активности, таких как регистрация сертификатов и последующая аутентификация по ним. Обратите внимание на рекомендации, изложенные в исследовании Certified Pre‑Owned от SpecterOps — особенно в подразделах, посвященных регистрации сертификатов (DETECT1) и использованию сертификатов для входа в систему (DETECT2).
Хотя в текущих версиях Windows отсутствуют уникальные идентификаторы событий, позволяющие надежно определить факт ручного сопоставления сертификата с учетной записью (например, через altSecurityIdentities), корреляция цепочек действий может указывать на потенциально вредоносную активность.
Примеры полезных корреляций
- Регистрация сертификата с шаблона, разрешающего произвольный Subject (Supply in the request), + последующее событие аутентификации по этому сертификату от имени привилегированной учетной записи.
- Повторяющаяся регистрация сертификатов с одного хоста или от имени одного пользователя + входы с использованием разных учетных данных (особенно с повышенными правами).
- Активность, связанная с изменением
altSecurityIdentities, + аутентификация без интерактивного входа (S4U, PKINIT, smart card).
Несмотря на отсутствие прямых индикаторов атаки, выстраивание поведенческой модели и регулярный сбор данных по регистрации и использованию сертификатов позволяют сформировать представление о нормальной активности в инфраструктуре. Это, в свою очередь, облегчает выявление аномалий, которые могут указывать на попытки компрометации.
Такой подход актуален не только для ESC14, но и для других техник, использующих слабые настройки шаблонов и сопоставления сертификатов в AD CS.
Один из эффективных подходов к раннему выявлению риска атаки ESC14 — анализ конфигурации компонентов AD CS и учетных записей в домене на предмет небезопасных параметров, даже без признаков активной эксплуатации.
В отличие от обнаружения на основе событий, этот подход позволяет превентивно выявить уязвимые шаблоны сертификатов, настройки контроллеров домена и учетные записи с потенциально опасными атрибутами, которые злоумышленник может использовать в случае компрометации.
Рассмотрим четыре ключевые конфигурационные ошибки, указывающие на потенциальную уязвимость к технике ESC14:
- Атрибут
altSecurityIdentitiesс небезопасным содержимым. - Шаблоны сертификатов с уязвимыми настройками.
- Контроллеры домена в режиме слабой проверки сертификатов.
- Пользователи с правом на выпуск сертификатов по уязвимым шаблонам.
Ошибка 1. Атрибут altSecurityIdentities с небезопасным содержимым
Если у учетной записи в AD установлен атрибут altSecurityIdentities и его значение содержит одну из следующих слабых форм сопоставления, это может позволить злоумышленнику выполнить аутентификацию от имени жертвы:
| Формат строки | Тип сопоставления | Уязвимость |
|---|---|---|
| X509:<RFC822>email@domain |
По email (RFC822) |
ESC14-B |
| X509:<S>CN=SomeUser,... |
Только Subject |
ESC14-D |
| X509:<I>Issuer<S>Subject |
Issuer + Subject |
ESC14-C |
Если такие строки присутствуют, рекомендуется немедленно проверить их актуальность и происхождение. Во многих случаях они могут быть устаревшими или добавленными по ошибке.
Ошибка 2. Шаблоны сертификатов с уязвимыми настройками
Шаблон, позволяющий атакующему выпустить сертификат от имени любой учетной записи, имеет следующие параметры:
CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT— разрешает указание произвольного Subject (Supply in the request).- 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). TemplatePropRASignatureCount = 0— отключены обязательные подписи RA.- Включен флаг
CT_FLAG_NO_SECURITY_EXTENSION— SID не включается в сертификат.
Эти параметры в опубликованном шаблоне с доступом для обычных пользователей представляют серьезную угрозу.
Ошибка 3. Контроллеры домена в режиме слабой проверки сертификатов
Контроллеры домена должны быть настроены на строгую проверку SID в сертификате при входе (strong certificate binding). Проверьте параметр реестра:
| Значение | Описание | DC уязвим |
|---|---|---|
| 0 |
Проверка отключена |
Да |
| 1 |
Проверка ведется, но не применяется |
Да |
| 2 |
Полный контроль SID (рекомендуется) |
Нет |
Значение 2 (Full Enforcement) обязательно по умолчанию, начиная с обновлений Windows Server от февраля 2025 года.
Ошибка 4. Пользователи с правом на выпуск сертификатов по уязвимым шаблонам
Если у злоумышленника или жертвы есть право Enroll на шаблон с описанными выше настройками, он может легко запросить и получить сертификат от имени любой другой учетной записи, если остальные условия соблюдены.
Ограничьте круг субъектов, у которых есть доступ к выдаче по чувствительным шаблонам, и используйте RA‑одобрение или manager approval.
Вот пример скрипта для поиска учетных записей Active Directory, у которых установлен атрибут altSecurityIdentities с потенциально уязвимыми формами явного сопоставления сертификатов (explicit certificate mapping):
Get-ADUser -Filter * -Properties altSecurityIdentities |
Where-Object {
$_.altSecurityIdentities -match 'X509:<(S|I|RFC822)'
} |
Select-Object SamAccountName, altSecurityIdentities
Вывод:
Обнаружение через конфигурационный анализ — один из самых надежных методов оценки устойчивости среды к атакам на AD CS. Даже если признаков активной эксплуатации нет, корректная оценка и устранение потенциальных уязвимостей позволяют предотвратить эскалацию привилегий и компрометацию домена.
В рамках контроля безопасности, основанного на конфигурационном анализе с использованием BI.ZONE EDR, автоматически собирается информация о потенциально уязвимых шаблонах сертификатов и учетных записях. Это позволяет выявлять риски до их эксплуатации.
При этом анализируются шаблоны сертификатов с включенным флагом CT_FLAG_NO_SECURITY_EXTENSION. Они уже отслеживаются в рамках детектирования атаки ESC9, так как отсутствие SID в сертификатах делает возможным привязку по altSecurityIdentities.
Дополнительно всегда производится сбор значений атрибута altSecurityIdentities у всех учетных записей. Эти значения направляются на анализ, чтобы выявить ошибки конфигурации и потенциально опасные сопоставления сертификатов (например, X509:<S>, X509:<RFC822>).
Вот как работает механизм:
- Сбор данных о шаблонах и флаге
CT_FLAG_NO_SECURITY_EXTENSIONвыполняется при первом запуске анализа и каждый раз при изменениях в кеше шаблонов сертификатов. - Значения
altSecurityIdentitiesсобираются периодически и независимо от состояния шаблонов, чтобы гарантировать актуальность и безопасность конфигурации на постоянной основе.
altSecurityIdentities в BI.ZONE EDR
Такой механизм позволяет:
- выявлять и устранять уязвимости заранее, до их возможной эксплуатации, например, в атаках ESC14;
- поддерживать в инфраструктуре безопасные, рекомендованные настройки;
- исключить слабые сертификатные сопоставления, которые могли быть созданы вручную, устарели или используются некорректно.
Предотвратить ESC14 возможно, если реализовать ряд технических и организационных мер по устранению предпосылок для ее эксплуатации.
Учетные записи, содержащие атрибут altSecurityIdentities с потенциально небезопасными значениями, могут быть использованы для подмены личности при аутентификации. Выполните проверку следующей командой PowerShell:
Get-ADUser -Filter * -Properties altSecurityIdentities |
Where-Object { $_.altSecurityIdentities -match "X509:<RFC822>|X509:<S>|X509:<I>" } |
Select SamAccountName, altSecurityIdentities
Рекомендуется удалить или скорректировать сопоставления следующих типов:
X509:<RFC822>— сопоставление по email.X509:<S>— только Subject.X509:<I><S>— Issuer + Subject (без<SR>).
Включенный CT_FLAG_NO_SECURITY_EXTENSION в шаблоне сертификатов предотвращает добавление SID в сертификат. Это делает возможной атаку по механизму явного сопоставления. Если использование этого флага не требуется по бизнес-процессам, отключите его во всех шаблонах.
Обновление безопасности KB5014754 от Microsoft включает механизм принудительной проверки соответствия SID в сертификате. Рекомендуется:
- Установить обновление KB5014754 на; все контроллеры домена.
- Установить параметр реестра
HKLM\SYSTEM\CurrentControlSet\Services\Kdc\StrongCertificateBindingEnforcement = 2.
Согласно описанию из KB5014754, включение этого режима обеспечивает полную защиту от ESC14 — даже при наличии слабого сопоставления в altSecurityIdentities.
Исключите использование шаблонов, которые:
- разрешают задавать произвольные значения Subject/SAN (
CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT); - поддерживают EKU Client Authentication или Smart Card Logon;
- не требуют одобрения (RA signature count =
0); - имеют включенный флаг
CT_FLAG_NO_SECURITY_EXTENSION.
Если они необходимы, используйте такие шаблоны только для строго контролируемых групп либо усильте их требованиями RA‑подписи.
Особое внимание уделяйте следующим условиям, если у пользователя нет административных полномочий, но при этом у него:
- настроен небезопасный
altSecurityIdentities; - контроллер не обновлен и не применяет строгую проверку;
- есть право выпускать сертификаты через уязвимый шаблон.
Это создает высокий риск эскалации привилегий. В таких случаях ограничьте доступ к шаблонам и приведите конфигурацию в соответствие рекомендациям по безопасности.
Атака ESC14 представляет серьезную угрозу для инфраструктуры Active Directory при сочетании нескольких факторов: небезопасного сопоставления сертификатов (altSecurityIdentities), слабых шаблонов и недостаточной проверки на стороне контроллеров домена.
В отличие от других атак на AD CS, эту технику можно реализовать без непосредственного вмешательства в инфраструктуру сертификации. Это делает ее особенно опасной в случае длительного незаметного присутствия злоумышленника в сети. Однако правильная архитектура и регулярный анализ конфигурации способны полностью предотвратить атаку. Даже вне зависимости от активности грамотный подход к управлению шаблонами, отслеживанию altSecurityIdentities и применению обновлений безопасности позволяет свести риски к нулю.
Таким образом, проактивная защита и конфигурационный аудит остаются важнейшими инструментами в борьбе с атаками типа ESC14 и должны быть неотъемлемой частью любой стратегии защиты AD CS.
