>

ESC5 — це критична атака на сертифікати, спрямована на Active Directory Certificate Services (ADCS). Ця атака на ADCS експлуатує небезпечний доступ до приватного ключа Центру сертифікації (CA). Коли зловмисники отримують права локального адміністратора на сервері ЦС, вони можуть експортувати приватний ключ. Це дозволяє їм підробляти дійсні сертифікати для будь-якого облікового запису AD, включно з адміністраторами домену. Така атака на сертифікати дозволяє супротивникам проходити автентифікацію через Kerberos PKINIT, забезпечуючи горизонтальне переміщення мережею без знання паролів чи хешів. Атака ESC5 ADCS підкреслює важливість захисту приватного ключа ЦС для запобігання цій серйозній вразливості.

Зміст

• Огляд атаки ESC5
• Механізм атаки ESC5
• Структура вразливого контролю доступу до об’єктів PKI
• Передумови
• Перерахування та експлуатація
• Додавання/перевірка прав локального адміністратора на сервері ЦС
• Атака ESC5 за допомогою Certipy
• Постексплуатація
• Горизонтальне переміщення та підвищення привілеїв за допомогою impacket-psexec
• Заходи протидії

Огляд атаки ESC5

ESC5 — це метод компрометації Active Directory Certificate Services (ADCS), за якого зловмисник із правами локального адміністратора на сервері ЦС викрадає приватний ключ Центру сертифікації. Володіння цим ключем дозволяє підробляти сертифікати для будь-якого користувача, зокрема для адміністраторів домену. Це відкриває шлях до автентифікації через Kerberos PKINIT і повного доступу до домену без використання паролів чи хешів.

Ця атака є надзвичайно потужною та прихованою, оскільки вона базується на вбудованій довірі Active Directory до ключів підпису Центру сертифікації (CA).

Ключові умови, що роблять ESC5 можливою:

• Доступ локального адміністратора до сервера ЦС → Атакувальнику потрібні права адміністратора на сервері для вилучення приватного ключа.
• Незахищений приватний ключ ЦС → Ключ Центру сертифікації має бути недостатньо захищеним, що дозволяє його викрадення.
• Відсутність відкликання або тривалий термін дії сертифікатів → Якщо сертифікати видаються на довгий термін без механізмів відкликання, зловмисники можуть зберігати тривалий доступ.
• Довіра до підписаних сертифікатів ЦС → Active Directory довіряє будь-якому сертифікату, підписаному цим ЦС, що дозволяє фальсифікувати документи для будь-якого облікового запису AD, включаючи адміністраторів домену.

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

• Компрометація прав локального адміністратора на сервері ЦС → Зловмисник отримує привілеї локального адміністратора на сервері Центру сертифікації, зазвичай через горизонтальне переміщення або некоректно налаштовані групи.
• Експорт сертифіката та приватного ключа ЦС → Використовуючи такі інструменти, як Certipy-AD, атакуючий експортує сертифікат ЦС разом із приватним ключем у файл формату .pfx.
• Фальсифікація сертифіката для привілейованого користувача → Маючи приватний ключ, зловмисник підробляє сертифікат для облікового запису з високими привілеями (наприклад, administrator@ignite.local), який сприймається Active Directory як дійсний.
• Автентифікація за допомогою підробленого сертифіката (PKINIT) → Атакуючий використовує фальсифікований сертифікат для проходження автентифікації через Kerberos PKINIT, імітуючи цільового користувача та отримуючи TGT.
• Горизонтальне переміщення та контроль над доменом → Використовуючи отриманий TGT, зловмисник підвищує привілеї та переміщується мережею, що часто призводить до отримання прав адміністратора домену.

Структура вразливого контролю доступу до об’єктів PKI

Успіх атаки ESC5 залежить від конкретних недоліків у налаштуванні PKI:

• Дозволи сервера ЦС → Якщо можливий доступ локального адміністратора, зловмисник може вилучити приватний ключ ЦС.
• Захист приватного ключа → Слабкий захист (або його повна відсутність) ключа ЦС дозволяє несанкціонований експорт та зловживання.
• Модель довіри AD → Active Directory за замовчуванням довіряє сертифікатам, виданим ЦС — навіть якщо вони були підроблені.
• Kerberos з PKINIT → Дозволяє вхід у систему за допомогою сертифікатів, забезпечуючи приховану імітацію привілейованих користувачів.

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

Передумови

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

Якщо ви читаєте цей матеріал, ми припускаємо, що ви вже знайомі зі шляхами атак на AD CS та розгортанням лабораторій. Ймовірно, ви вже вмієте:

• Перераховувати шаблони сертифікатів за допомогою Certipy або Metasploit.
• Розуміти значення таких налаштувань шаблонів, як ENROLLEE_SUPPLIES_SUBJECT та Client Authentication.
• Орієнтуватися в структурі та ієрархії ЦС та шаблонів у межах Active Directory.

Замість того, щоб повертатися до налаштування лабораторії, ця стаття зосереджена безпосередньо на експлуатації критичної помилки конфігурації — шляху атаки ESC5. На відміну від атак, спрямованих на дозволи шаблонів (як-от ESC4), ESC5 фокусується на експлуатації небезпечного доступу до приватного ключа ЦС.

Перерахування та експлуатація

Додавання/перевірка прав локального адміністратора на сервері ЦС

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

Поширеною помилкою конфігурації є некоректне додавання користувачів до локальної групи адміністраторів (Administrators).

Використовуйте ці команди, щоб перевірити або додати користувача (наприклад, «raj»):

net localgroup Administrators "igniteraj" /add
net localgroup Administrators

Перевірте, чи входить «raj» до групи адміністраторів (Administrators); це може надати несанкціонований доступ до сервера ЦС, полегшуючи проведення атаки ESC5.

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

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

Щоб створити резервну копію сертифіката ЦС та приватного ключа, виконайте таку команду:

certipy-ad ca -backup -u raj@ignite.local -p Password@1 -ca ignite-DC-CA -target 192.168.1.48

Ця команда експортує сертифікат ЦС та приватний ключ у файл із назвою ignite-DC-CA.pfx.

Маючи доступ до приватного ключа ЦС, ми можемо підробляти сертифікати для будь-якого UPN (наприклад, administrator@ignite.local), фактично обходячи механізми контролю дозволів Active Directory.

Використовуючи приватний ключ, ми можемо виконати наступну команду для фальсифікації сертифіката конкретного користувача:

certipy-ad forge -ca-pfx 'ignite-DC-CA.pfx' -upn administrator@ignite.local

Це створює дійсний підписаний сертифікат (administrator_forged.pfx), що дозволяє нам видати себе за цільового користувача (наприклад, адміністратора домену) та отримати несанкціонований доступ до ресурсів.

AD підтримує PKINIT, що уможливлює автентифікацію Kerberos за допомогою сертифікатів. Маючи підроблений сертифікат, ми можемо запросити TGT для administrator@ignite.local, отримуючи доступ до ресурсів домену

Виконайте команду Auth, щоб отримати наступне:

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

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

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

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

Маючи доступ адміністратора домену, скористайтеся інструментом psexec із пакета Impacket, щоб отримати оболонку (shell) з правами SYSTEM на віддалених машинах через SMB.

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

impacket-psexec ignite.local/administrator@ignite.local -hashes :32196b56ffe6f45e294117b91a83bf38

Ми отримуємо доступ адміністратора домену шляхом створення резервної копії приватного ключа ЦС завдяки правам локального адміністратора на сервері Центру сертифікації. Після цього ми підробляємо сертифікат для administrator@example.local, проходимо автентифікацію за допомогою PKINIT і запитуємо TGT.

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

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

• Доступ до ЦС → Видаліть усіх зайвих локальних адміністраторів із серверів Центру сертифікації.
• Безпека шаблонів → Вимкніть параметр ENROLLEE_SUPPLIES_SUBJECT та видаліть непотрібні розширення призначення ключів (EKU).
• Аудит → Регулярно використовуйте інструменти Certipy та ADCSaudit для пошуку вразливостей.
• Моніторинг → Відстежуйте входи в систему за сертифікатами та аномалії в автентифікації на основі SAN.