maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/windows-hardening/active-directory-methodology/ad-certi

Browse Source
This commit is contained in:
Translator 2025-07-10 10:09:26 +00:00
parent 89e57f90c2
commit 01375322b3
1 changed files with 50 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
src/windows-hardening/active-directory-methodology/ad-certificates.md
View File

@ -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=<domain>,DC=<com>
```
є центральним для встановлення довіри до сертифікатної аутентифікації.
є центральним для встановлення довіри для аутентифікації сертифікатів.
### Аутентифікація через 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}}