diff --git a/src/windows-hardening/active-directory-methodology/ad-certificates.md b/src/windows-hardening/active-directory-methodology/ad-certificates.md index b2a41c3f9..d8e452600 100644 --- a/src/windows-hardening/active-directory-methodology/ad-certificates.md +++ b/src/windows-hardening/active-directory-methodology/ad-certificates.md @@ -19,7 +19,7 @@ ### Special Considerations -- **Додаткові імена суб'єкта (SANs)** розширюють застосування сертифіката на кілька ідентичностей, що є критично важливим для серверів з кількома доменами. Безпечні процеси видачі є важливими для уникнення ризиків обману з боку зловмисників, які маніпулюють специфікацією SAN. +- **Додаткові імена суб'єкта (SANs)** розширюють застосування сертифіката до кількох ідентичностей, що є критично важливим для серверів з кількома доменами. Безпечні процеси видачі є важливими для уникнення ризиків обману з боку зловмисників, які маніпулюють специфікацією SAN. ### Certificate Authorities (CAs) in Active Directory (AD) @@ -27,25 +27,25 @@ AD CS визнає сертифікати CA в лісі AD через приз - Контейнер **Certification Authorities** містить довірені кореневі сертифікати CA. - Контейнер **Enrolment Services** містить деталі корпоративних CA та їх шаблони сертифікатів. -- Об'єкт **NTAuthCertificates** включає сертифікати CA, авторизовані для аутентифікації AD. +- Об'єкт **NTAuthCertificates** включає сертифікати CA, авторизовані для автентифікації AD. - Контейнер **AIA (Authority Information Access)** полегшує валідацію ланцюга сертифікатів з проміжними та крос CA сертифікатами. ### Certificate Acquisition: Client Certificate Request Flow 1. Процес запиту починається з того, що клієнти знаходять корпоративний CA. -2. Створюється CSR, що містить публічний ключ та інші деталі, після генерації пари публічного-приватного ключів. +2. Створюється CSR, що містить публічний ключ та інші деталі, після генерації пари публічного-приватного ключа. 3. CA оцінює CSR відповідно до доступних шаблонів сертифікатів, видаючи сертифікат на основі дозволів шаблону. 4. Після затвердження CA підписує сертифікат своїм приватним ключем і повертає його клієнту. ### Certificate Templates -Визначені в AD, ці шаблони окреслюють налаштування та дозволи для видачі сертифікатів, включаючи дозволені EKUs та права на реєстрацію або модифікацію, що є критично важливими для управління доступом до сертифікатних послуг. +Визначені в AD, ці шаблони окреслюють налаштування та дозволи для видачі сертифікатів, включаючи дозволені EKUs та права на реєстрацію або модифікацію, що є критично важливими для управління доступом до послуг сертифікатів. ## Certificate Enrollment -Процес реєстрації сертифікатів ініціюється адміністратором, який **створює шаблон сертифіката**, який потім **публікується** корпоративним Центром сертифікації (CA). Це робить шаблон доступним для реєстрації клієнтів, що досягається шляхом додавання імені шаблону до поля `certificatetemplates` об'єкта Active Directory. +Процес реєстрації сертифікатів ініціюється адміністратором, який **створює шаблон сертифіката**, який потім **публікується** корпоративним Центром сертифікації (CA). Це робить шаблон доступним для реєстрації клієнтів, крок, досягнутий шляхом додавання імені шаблону до поля `certificatetemplates` об'єкта Active Directory. -Щоб клієнт міг запитати сертифікат, **права на реєстрацію** повинні бути надані. Ці права визначаються дескрипторами безпеки на шаблоні сертифіката та самому корпоративному CA. Дозволи повинні бути надані в обох місцях, щоб запит був успішним. +Щоб клієнт міг запросити сертифікат, **права на реєстрацію** повинні бути надані. Ці права визначаються дескрипторами безпеки на шаблоні сертифіката та самому корпоративному CA. Дозволи повинні бути надані в обох місцях, щоб запит був успішним. ### Template Enrollment Rights @@ -63,15 +63,15 @@ AD CS визнає сертифікати CA в лісі AD через приз Можуть застосовуватися певні контролі, такі як: -- **Затвердження менеджера**: ставить запити в стан очікування до затвердження менеджером сертифікатів. -- **Агенти реєстрації та авторизовані підписи**: визначають кількість необхідних підписів на CSR та необхідні OIDs політики застосування. +- **Затвердження менеджера**: Поміщає запити в стан очікування до затвердження менеджером сертифікатів. +- **Агенти реєстрації та авторизовані підписи**: Визначають кількість необхідних підписів на CSR та необхідні OIDs політики застосування. ### Methods to Request Certificates Сертифікати можна запитувати через: 1. **Протокол реєстрації сертифікатів Windows Client** (MS-WCCE), використовуючи інтерфейси DCOM. -2. **Протокол віддаленого проходження ICertPassage** (MS-ICPR), через іменовані канали або TCP/IP. +2. **Протокол ICertPassage Remote** (MS-ICPR), через іменовані канали або TCP/IP. 3. **веб-інтерфейс реєстрації сертифікатів**, з встановленою роллю веб-реєстрації Центру сертифікації. 4. **Служба реєстрації сертифікатів** (CES), у поєднанні з службою політики реєстрації сертифікатів (CEP). 5. **Служба реєстрації мережевих пристроїв** (NDES) для мережевих пристроїв, використовуючи простий протокол реєстрації сертифікатів (SCEP). @@ -87,15 +87,15 @@ Active Directory (AD) підтримує сертифікатну аутенти ### Процес Аутентифікації Kerberos -У процесі аутентифікації Kerberos запит користувача на отримання квитка (Ticket Granting Ticket, TGT) підписується за допомогою **приватного ключа** сертифіката користувача. Цей запит проходить кілька перевірок контролером домену, включаючи **дійсність** сертифіката, **шлях** та **статус відкликання**. Перевірки також включають підтвердження, що сертифікат походить з надійного джерела, та підтвердження наявності видавця в **NTAUTH сертифікатному сховищі**. Успішні перевірки призводять до видачі TGT. Об'єкт **`NTAuthCertificates`** в AD, розташований за: +У процесі аутентифікації Kerberos запит користувача на отримання квитка (Ticket Granting Ticket, TGT) підписується за допомогою **приватного ключа** сертифіката користувача. Цей запит проходить кілька перевірок доменним контролером, включаючи **дійсність** сертифіката, **шлях** та **статус відкликання**. Перевірки також включають підтвердження, що сертифікат походить з надійного джерела, та підтвердження наявності видавця в **NTAUTH сертифікатному сховищі**. Успішні перевірки призводять до видачі TGT. Об'єкт **`NTAuthCertificates`** в AD, розташований за: ```bash CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC= ``` -є центральним для встановлення довіри до сертифікатної аутентифікації. +є центральним для встановлення довіри для аутентифікації сертифікатів. ### Аутентифікація через Secure Channel (Schannel) -Schannel забезпечує безпечні TLS/SSL з'єднання, під час яких клієнт представляє сертифікат, який, якщо успішно перевірений, надає доступ. Відображення сертифіката на обліковий запис AD може включати функцію Kerberos **S4U2Self** або **Subject Alternative Name (SAN)** сертифіката, серед інших методів. +Schannel забезпечує безпечні TLS/SSL з'єднання, де під час рукостискання клієнт представляє сертифікат, який, якщо успішно перевірений, надає доступ. Відображення сертифіката на обліковий запис AD може включати функцію Kerberos **S4U2Self** або **Subject Alternative Name (SAN)** сертифіката, серед інших методів. ### Перерахування сертифікатних служб AD @@ -108,16 +108,52 @@ Certify.exe cas # Identify vulnerable certificate templates with Certify Certify.exe find /vulnerable -# Use Certipy for enumeration and identifying vulnerable templates -certipy find -vulnerable -u john@corp.local -p Passw0rd -dc-ip 172.16.126.128 +# Use Certipy (>=4.0) for enumeration and identifying vulnerable templates +certipy find -vulnerable -dc-only -u john@corp.local -p Passw0rd -target dc.corp.local + +# Request a certificate over the web enrollment interface (new in Certipy 4.x) +certipy req -web -target ca.corp.local -template WebServer -upn john@corp.local -dns www.corp.local # Enumerate Enterprise CAs and certificate templates with certutil certutil.exe -TCAInfo certutil -v -dstemplate ``` +--- + +## Останні вразливості та оновлення безпеки (2022-2025) + +| Рік | ID / Назва | Вплив | Основні висновки | +|------|-----------|--------|----------------| +| 2022 | **CVE-2022-26923** – “Certifried” / ESC6 | *Ескалація привілеїв* шляхом підробки сертифікатів облікових записів машин під час PKINIT. | Патч включено в оновлення безпеки **10 травня 2022**. Аудит та контроль сильного відображення були введені через **KB5014754**; середовища тепер повинні бути в режимі *Повного виконання*. citeturn2search0 | +| 2023 | **CVE-2023-35350 / 35351** | *Віддалене виконання коду* в ролях AD CS Web Enrollment (certsrv) та CES. | Публічні PoC обмежені, але вразливі компоненти IIS часто відкриті внутрішньо. Патч з **липня 2023** Patch Tuesday. citeturn3search0 | +| 2024 | **CVE-2024-49019** – “EKUwu” / ESC15 | Користувачі з низькими привілеями, які мають права на реєстрацію, можуть переважити **будь-який** EKU або SAN під час генерації CSR, видаючи сертифікати, які можна використовувати для автентифікації клієнтів або підписування коду, що призводить до *компрометації домену*. | Вирішено в оновленнях **квітня 2024**. Видалити “Постачати в запиті” з шаблонів та обмежити права на реєстрацію. citeturn1search3 | + +### Хронологія зміцнення Microsoft (KB5014754) + +Microsoft представила трьохфазний розгортання (Сумісність → Аудит → Виконання), щоб перевести автентифікацію сертифікатів Kerberos від слабких неявних відображень. Станом на **11 лютого 2025**, контролери домену автоматично переходять на **Повне виконання**, якщо значення реєстру `StrongCertificateBindingEnforcement` не встановлено. Адміністратори повинні: + +1. Патчити всі DC та сервери AD CS (травень 2022 або пізніше). +2. Моніторити події ID 39/41 для слабких відображень під час фази *Аудиту*. +3. Повторно видавати сертифікати автентифікації клієнтів з новим **SID розширенням** або налаштувати сильні ручні відображення до лютого 2025. citeturn2search0 + +--- + +## Виявлення та покращення зміцнення + +* **Defender for Identity AD CS sensor (2023-2024)** тепер надає оцінки позиції для ESC1-ESC8/ESC11 та генерує сповіщення в реальному часі, такі як *“Видача сертифіката контролера домену для не-DC”* (ESC8) та *“Запобігти реєстрації сертифікатів з довільними політиками застосування”* (ESC15). Переконайтеся, що датчики розгорнуті на всіх серверах AD CS, щоб скористатися цими виявленнями. citeturn5search0 +* Вимкніть або суворо обмежте опцію **“Постачати в запиті”** на всіх шаблонах; надавайте перевагу явно визначеним значенням SAN/EKU. +* Видаліть **Будь-яка мета** або **Без EKU** з шаблонів, якщо це абсолютно не потрібно (вирішує сценарії ESC2). +* Вимагайте **схвалення менеджера** або спеціалізовані робочі процеси агента реєстрації для чутливих шаблонів (наприклад, WebServer / CodeSigning). +* Обмежте веб-реєстрацію (`certsrv`) та кінцеві точки CES/NDES до надійних мереж або за автентифікацією клієнтських сертифікатів. +* Застосуйте шифрування реєстрації RPC (`certutil –setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQ`), щоб зменшити ризик ESC11. + +--- + ## Посилання - [https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf](https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf) - [https://comodosslstore.com/blog/what-is-ssl-tls-client-authentication-how-does-it-work.html](https://comodosslstore.com/blog/what-is-ssl-tls-client-authentication-how-does-it-work.html) +- [https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16) +- [https://advisory.eventussecurity.com/advisory/critical-vulnerability-in-ad-cs-allows-privilege-escalation/](https://advisory.eventussecurity.com/advisory/critical-vulnerability-in-ad-cs-allows-privilege-escalation/) {{#include ../../banners/hacktricks-training.md}}