# AD Certificates

{{#include ../../banners/hacktricks-training.md}}

## Introduction

### Components of a Certificate

- **Суб'єкт** сертифіката позначає його власника.
- **Публічний ключ** поєднується з приватно утримуваним ключем, щоб зв'язати сертифікат з його законним власником.
- **Період дії**, визначений датами **NotBefore** та **NotAfter**, позначає ефективну тривалість сертифіката.
- Унікальний **Серійний номер**, наданий Центром сертифікації (CA), ідентифікує кожен сертифікат.
- **Видавець** відноситься до CA, який видав сертифікат.
- **SubjectAlternativeName** дозволяє додаткові імена для суб'єкта, підвищуючи гнучкість ідентифікації.
- **Основні обмеження** визначають, чи є сертифікат для CA або кінцевого суб'єкта, і визначають обмеження використання.
- **Розширені ключові використання (EKUs)** окреслюють конкретні цілі сертифіката, такі як підписання коду або шифрування електронної пошти, через ідентифікатори об'єктів (OIDs).
- **Алгоритм підпису** визначає метод підписання сертифіката.
- **Підпис**, створений за допомогою приватного ключа видавця, гарантує автентичність сертифіката.

### Special Considerations

- **Додаткові імена суб'єкта (SANs)** розширюють застосування сертифіката до кількох ідентичностей, що є критично важливим для серверів з кількома доменами. Безпечні процеси видачі є важливими для уникнення ризиків обману з боку зловмисників, які маніпулюють специфікацією SAN.

### Certificate Authorities (CAs) in Active Directory (AD)

AD CS визнає сертифікати CA в лісі AD через призначені контейнери, кожен з яких виконує унікальні ролі:

- Контейнер **Certification Authorities** містить довірені кореневі сертифікати CA.
- Контейнер **Enrolment Services** містить деталі корпоративних CA та їх шаблони сертифікатів.
- Об'єкт **NTAuthCertificates** включає сертифікати CA, авторизовані для автентифікації AD.
- Контейнер **AIA (Authority Information Access)** полегшує валідацію ланцюга сертифікатів з проміжними та крос CA сертифікатами.

### Certificate Acquisition: Client Certificate Request Flow

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

### Certificate Templates

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

## Certificate Enrollment

Процес реєстрації сертифікатів ініціюється адміністратором, який **створює шаблон сертифіката**, який потім **публікується** корпоративним Центром сертифікації (CA). Це робить шаблон доступним для реєстрації клієнтів, крок, досягнутий шляхом додавання імені шаблону до поля `certificatetemplates` об'єкта Active Directory.

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

### Template Enrollment Rights

Ці права визначаються через записи контролю доступу (ACE), що деталізують дозволи, такі як:

- Права **Certificate-Enrollment** та **Certificate-AutoEnrollment**, кожне з яких пов'язане з конкретними GUID.
- **ExtendedRights**, що дозволяє всі розширені дозволи.
- **FullControl/GenericAll**, що надає повний контроль над шаблоном.

### Enterprise CA Enrollment Rights

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

### Additional Issuance Controls

Можуть застосовуватися певні контролі, такі як:

- **Затвердження менеджера**: Поміщає запити в стан очікування до затвердження менеджером сертифікатів.
- **Агенти реєстрації та авторизовані підписи**: Визначають кількість необхідних підписів на CSR та необхідні OIDs політики застосування.

### Methods to Request Certificates

Сертифікати можна запитувати через:

1. **Протокол реєстрації сертифікатів Windows Client** (MS-WCCE), використовуючи інтерфейси DCOM.
2. **Протокол ICertPassage Remote** (MS-ICPR), через іменовані канали або TCP/IP.
3. **веб-інтерфейс реєстрації сертифікатів**, з встановленою роллю веб-реєстрації Центру сертифікації.
4. **Служба реєстрації сертифікатів** (CES), у поєднанні з службою політики реєстрації сертифікатів (CEP).
5. **Служба реєстрації мережевих пристроїв** (NDES) для мережевих пристроїв, використовуючи простий протокол реєстрації сертифікатів (SCEP).

Користувачі Windows також можуть запитувати сертифікати через GUI (`certmgr.msc` або `certlm.msc`) або командні інструменти (`certreq.exe` або команду PowerShell `Get-Certificate`).
```bash
# Example of requesting a certificate using PowerShell
Get-Certificate -Template "User" -CertStoreLocation "cert:\\CurrentUser\\My"
```
## Сертифікатна Аутентифікація

Active Directory (AD) підтримує сертифікатну аутентифікацію, в основному використовуючи **Kerberos** та **Secure Channel (Schannel)** протоколи.

### Процес Аутентифікації Kerberos

У процесі аутентифікації 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)** сертифіката, серед інших методів.

### Перерахування сертифікатних служб AD

Служби сертифікатів AD можна перерахувати через LDAP запити, що розкриває інформацію про **Enterprise Certificate Authorities (CAs)** та їх конфігурації. Це доступно будь-якому користувачу, аутентифікованому в домені, без спеціальних привілеїв. Інструменти, такі як **[Certify](https://github.com/GhostPack/Certify)** та **[Certipy](https://github.com/ly4k/Certipy)**, використовуються для перерахування та оцінки вразливостей в середовищах AD CS.

Команди для використання цих інструментів включають:
```bash
# Enumerate trusted root CA certificates and Enterprise CAs with Certify
Certify.exe cas
# Identify vulnerable certificate templates with Certify
Certify.exe find /vulnerable

# 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**; середовища тепер повинні бути в режимі *Повного виконання*. |
| 2023 | **CVE-2023-35350 / 35351** | *Віддалене виконання коду* в ролях AD CS Web Enrollment (certsrv) та CES. | Публічні PoC обмежені, але вразливі компоненти IIS часто відкриті внутрішньо. Патч з **липня 2023** у вівторок патчів. |
| 2024 | **CVE-2024-49019** – “EKUwu” / ESC15 | Користувачі з низькими привілеями, які мають права на реєстрацію, можуть переважити **будь-який** EKU або SAN під час генерації CSR, видаючи сертифікати, які можна використовувати для автентифікації клієнтів або підписування коду, що призводить до *компрометації домену*. | Вирішено в оновленнях **квітня 2024**. Видалити “Постачати в запиті” з шаблонів і обмежити права на реєстрацію. |

### Хронологія зміцнення Microsoft (KB5014754)

Microsoft представила трьохфазний розгортання (Сумісність → Аудит → Виконання), щоб перевести автентифікацію сертифікатів Kerberos від слабких неявних відображень. Станом на **11 лютого 2025**, контролери домену автоматично переходять на **Повне виконання**, якщо значення реєстру `StrongCertificateBindingEnforcement` не встановлено. Адміністратори повинні:

1. Патчити всі DC та сервери AD CS (травень 2022 або пізніше).
2. Моніторити події ID 39/41 для слабких відображень під час фази *Аудиту*.
3. Повторно видавати сертифікати автентифікації клієнтів з новим **SID розширенням** або налаштувати сильні ручні відображення до лютого 2025.

---

## Виявлення та покращення зміцнення

* **Defender for Identity AD CS sensor (2023-2024)** тепер надає оцінки позиції для ESC1-ESC8/ESC11 та генерує сповіщення в реальному часі, такі як *“Видача сертифіката контролера домену для не-DC”* (ESC8) та *“Запобігти реєстрації сертифікатів з довільними політиками застосування”* (ESC15). Переконайтеся, що датчики розгорнуті на всіх серверах AD CS, щоб скористатися цими виявленнями.
* Вимкніть або суворо обмежте опцію **“Постачати в запиті”** на всіх шаблонах; надавайте перевагу явно визначеним значенням 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}}