AD Certificates

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

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).

# Example of requesting a certificate using PowerShell
Get-Certificate -Template "User" -CertStoreLocation "cert:\\CurrentUser\\My"

Сертифікатна Аутентифікація

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

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

У процесі аутентифікації Kerberos запит користувача на отримання квитка на отримання квитка (TGT) підписується за допомогою приватного ключа сертифіката користувача. Цей запит проходить кілька перевірок доменним контролером, включаючи дійсність сертифіката, шлях та статус відкликання. Перевірки також включають підтвердження того, що сертифікат походить з надійного джерела, та підтвердження наявності видавця в NTAUTH сертифікатному сховищі. Успішні перевірки призводять до видачі TGT. Об'єкт NTAuthCertificates в AD, розташований за:

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 та Certipy, використовуються для перерахування та оцінки вразливостей в середовищах AD CS.

Команди для використання цих інструментів включають:

# 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 for enumeration and identifying vulnerable templates
certipy find -vulnerable -u [e-mail] -p Passw0rd -dc-ip 172.16.126.128

# Enumerate Enterprise CAs and certificate templates with certutil
certutil.exe -TCAInfo
certutil -v -dstemplate

References

• 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

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Підтримайте HackTricks

• Перевірте плани підписки!

• Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.

• Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.