Intigriti
Intigriti is the Europe's #1 ethical hacking and bug bounty platform.
Bug bounty tip: sign up for Intigriti, a premium bug bounty platform created by hackers, for hackers! Join us today and start earning bounties up to $100,000!
Register

AD Certificates

Reading time: 6 minutes

tip

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

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

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

powershell
# 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, розташований за:

bash
CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<domain>,DC=<com>

є центральним для встановлення довіри для сертифікатної аутентифікації.

Аутентифікація через безпечний канал (Schannel)

Schannel забезпечує безпечні TLS/SSL з'єднання, де під час рукостискання клієнт представляє сертифікат, який, якщо успішно перевірений, надає доступ. Відображення сертифіката на обліковий запис AD може включати функцію Kerberos S4U2Self або Subject Alternative Name (SAN) сертифіката, серед інших методів.

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

Служби сертифікатів AD можна перерахувати через LDAP запити, що розкриває інформацію про Enterprise Certificate Authorities (CAs) та їх конфігурації. Це доступно будь-якому користувачу, аутентифікованому в домені, без спеціальних привілеїв. Інструменти, такі як Certify та 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 for enumeration and identifying vulnerable templates
certipy find -vulnerable -u john@corp.local -p Passw0rd -dc-ip 172.16.126.128

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

Посилання

tip

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

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