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

This commit is contained in:
Translator 2025-08-28 22:31:07 +00:00
parent 955d2a35f7
commit a20ddc7540
2 changed files with 343 additions and 310 deletions

View File

@ -1,4 +1,4 @@
# AD Certificates # Certyfikaty AD
{{#include ../../../banners/hacktricks-training.md}} {{#include ../../../banners/hacktricks-training.md}}
@ -6,107 +6,117 @@
### Składniki certyfikatu ### Składniki certyfikatu
- **Podmiot** certyfikatu oznacza jego właściciela. - The **Subject** of the certificate denotes its owner.
- **Klucz publiczny** jest sparowany z kluczem prywatnym, aby powiązać certyfikat z jego prawowitym właścicielem. - A **Public Key** is paired with a privately held key to link the certificate to its rightful owner.
- **Okres ważności**, określony przez daty **NotBefore** i **NotAfter**, oznacza czas obowiązywania certyfikatu. - The **Validity Period**, defined by **NotBefore** and **NotAfter** dates, marks the certificate's effective duration.
- Unikalny **Numer seryjny**, dostarczony przez Urząd Certyfikacji (CA), identyfikuje każdy certyfikat. - A unique **Serial Number**, provided by the Certificate Authority (CA), identifies each certificate.
- **Wystawca** odnosi się do CA, który wydał certyfikat. - The **Issuer** refers to the CA that has issued the certificate.
- **SubjectAlternativeName** pozwala na dodatkowe nazwy dla podmiotu, zwiększając elastyczność identyfikacji. - **SubjectAlternativeName** allows for additional names for the subject, enhancing identification flexibility.
- **Podstawowe ograniczenia** identyfikują, czy certyfikat jest dla CA, czy dla podmiotu końcowego, oraz definiują ograniczenia użytkowania. - **Basic Constraints** identify if the certificate is for a CA or an end entity and define usage restrictions.
- **Rozszerzone zastosowania kluczy (EKU)** określają konkretne cele certyfikatu, takie jak podpisywanie kodu czy szyfrowanie e-maili, za pomocą identyfikatorów obiektów (OID). - **Extended Key Usages (EKUs)** delineate the certificate's specific purposes, like code signing or email encryption, through Object Identifiers (OIDs).
- **Algorytm podpisu** określa metodę podpisywania certyfikatu. - The **Signature Algorithm** specifies the method for signing the certificate.
- **Podpis**, stworzony za pomocą klucza prywatnego wystawcy, gwarantuje autentyczność certyfikatu. - The **Signature**, created with the issuer's private key, guarantees the certificate's authenticity.
### Specjalne uwagi ### Szczególne uwagi
- **Nazwy alternatywne podmiotu (SAN)** rozszerzają zastosowanie certyfikatu na wiele tożsamości, co jest kluczowe dla serwerów z wieloma domenami. Bezpieczne procesy wydawania są niezbędne, aby uniknąć ryzyka podszywania się przez atakujących manipulujących specyfikacją SAN. - **Subject Alternative Names (SANs)** rozszerzają zastosowanie certyfikatu na wiele tożsamości, co jest kluczowe dla serwerów obsługujących wiele domen. Bezpieczne procesy wydawania są niezbędne, aby uniknąć ryzyka podszywania się przez atakujących modyfikujących specyfikację SAN.
### Urzędy Certyfikacji (CA) w Active Directory (AD) ### Certificate Authorities (CAs) w Active Directory (AD)
AD CS uznaje certyfikaty CA w lesie AD poprzez wyznaczone kontenery, z których każdy pełni unikalne role: AD CS rozpoznaje certyfikaty CA w lesie AD za pomocą wyznaczonych kontenerów, z których każdy pełni unikalną rolę:
- Kontener **Certification Authorities** przechowuje zaufane certyfikaty root CA. - **Certification Authorities** container przechowuje zaufane certyfikaty root CA.
- Kontener **Enrolment Services** zawiera szczegóły dotyczące Enterprise CA i ich szablonów certyfikatów. - **Enrolment Services** container zawiera informacje o Enterprise CAs i ich certificate templates.
- Obiekt **NTAuthCertificates** zawiera certyfikaty CA autoryzowane do uwierzytelniania AD. - **NTAuthCertificates** object obejmuje certyfikaty CA uprawnione do uwierzytelniania w AD.
- Kontener **AIA (Authority Information Access)** ułatwia walidację łańcucha certyfikatów z certyfikatami CA pośrednimi i krzyżowymi. - **AIA (Authority Information Access)** container ułatwia walidację łańcucha certyfikatów dzięki certyfikatom pośrednim i cross CA.
### Pozyskiwanie certyfikatu: Proces żądania certyfikatu klienta ### Pozyskiwanie certyfikatu: przebieg żądania klienta
1. Proces żądania rozpoczyna się od znalezienia przez klientów Enterprise CA. 1. Proces żądania zaczyna się od odnalezienia Enterprise CA przez klienta.
2. Tworzony jest CSR, zawierający klucz publiczny i inne szczegóły, po wygenerowaniu pary kluczy publiczno-prywatnych. 2. Tworzony jest CSR, zawierający klucz publiczny i inne dane, po wygenerowaniu pary klucz publicznyprywatny.
3. CA ocenia CSR w odniesieniu do dostępnych szablonów certyfikatów, wydając certyfikat na podstawie uprawnień szablonu. 3. CA ocenia CSR względem dostępnych certificate templates i wydaje certyfikat na podstawie uprawnień szablonu.
4. Po zatwierdzeniu, CA podpisuje certyfikat swoim kluczem prywatnym i zwraca go do klienta. 4. Po zatwierdzeniu CA podpisuje certyfikat swoim kluczem prywatnym i zwraca go klientowi.
### Szablony certyfikatów ### Certificate Templates
Zdefiniowane w AD, te szablony określają ustawienia i uprawnienia do wydawania certyfikatów, w tym dozwolone EKU oraz prawa do rejestracji lub modyfikacji, co jest kluczowe dla zarządzania dostępem do usług certyfikacyjnych. Zdefiniowane w AD, te szablony określają ustawienia i uprawnienia do wydawania certyfikatów, w tym dozwolone EKU oraz prawa do enrollment i modyfikacji — kluczowe do zarządzania dostępem do usług certyfikacyjnych.
## Rejestracja certyfikatu ## Rejestracja certyfikatu
Proces rejestracji certyfikatów inicjuje administrator, który **tworzy szablon certyfikatu**, który następnie jest **publikowany** przez Enterprise Certificate Authority (CA). Umożliwia to klientom rejestrację, co osiąga się poprzez dodanie nazwy szablonu do pola `certificatetemplates` obiektu Active Directory. Proces rejestracji certyfikatów jest inicjowany przez administratora, który **tworzy certificate template**, który następnie jest **publikowany** przez Enterprise Certificate Authority (CA). To udostępnia szablon do rejestracji przez klientów, co osiąga się dodając nazwę szablonu do pola `certificatetemplates` obiektu Active Directory.
Aby klient mógł zażądać certyfikatu, muszą być przyznane **prawa rejestracji**. Prawa te są określone przez deskryptory zabezpieczeń na szablonie certyfikatu oraz samym Enterprise CA. Uprawnienia muszą być przyznane w obu lokalizacjach, aby żądanie mogło być skuteczne. Aby klient mógł zażądać certyfikatu, muszą być przyznane mu **enrollment rights**. Prawa te są definiowane przez security descriptors na certificate template oraz na samym Enterprise CA. Uprawnienia muszą być nadane w obu miejscach, aby żądanie zakończyło się sukcesem.
### Prawa rejestracji szablonów ### Prawa do rejestracji szablonu
Prawa te są określone za pomocą wpisów kontroli dostępu (ACE), szczegółowo opisujących uprawnienia, takie jak: Prawa te są określone przez Access Control Entries (ACE), szczegółowo opisujące uprawnienia takie jak:
- Prawa **Certificate-Enrollment** i **Certificate-AutoEnrollment**, każde związane z określonymi GUID. - **Certificate-Enrollment** i **Certificate-AutoEnrollment** prawa, każde powiązane z określonymi GUID.
- **ExtendedRights**, pozwalające na wszystkie rozszerzone uprawnienia. - **ExtendedRights**, pozwalające na wszystkie rozszerzone uprawnienia.
- **FullControl/GenericAll**, zapewniające pełną kontrolę nad szablonem. - **FullControl/GenericAll**, zapewniające pełną kontrolę nad szablonem.
### Prawa rejestracji Enterprise CA ### Prawa Enterprise CA do rejestracji
Prawa CA są określone w jego deskryptorze zabezpieczeń, dostępnym za pośrednictwem konsoli zarządzania Urzędem Certyfikacji. Niektóre ustawienia pozwalają nawet użytkownikom o niskich uprawnieniach na zdalny dostęp, co może stanowić zagrożenie dla bezpieczeństwa. Prawa CA są opisane w jego security descriptorze, dostępnym przez konsolę zarządzania Certificate Authority. Niektóre ustawienia mogą nawet umożliwiać zdalny dostęp użytkownikom o niskich uprawnieniach, co może stanowić zagrożenie bezpieczeństwa.
### Dodatkowe kontrole wydawania ### Dodatkowe kontrole wydawania
Mogą obowiązywać pewne kontrole, takie jak: Mogą być stosowane pewne kontrole, takie jak:
- **Zatwierdzenie menedżera**: Umieszcza żądania w stanie oczekiwania do zatwierdzenia przez menedżera certyfikatów. - **Manager Approval**: umieszcza żądania w stanie oczekującym do momentu zatwierdzenia przez managera certyfikatów.
- **Agenci rejestracji i autoryzowane podpisy**: Określają liczbę wymaganych podpisów na CSR oraz niezbędne identyfikatory polityki aplikacji OID. - **Enrolment Agents and Authorized Signatures**: określają liczbę wymaganych podpisów w CSR oraz niezbędne Application Policy OIDy.
### Metody żądania certyfikatów ### Metody żądania certyfikatów
Certyfikaty można żądać za pośrednictwem: Certyfikaty można żądać przez:
1. **Windows Client Certificate Enrollment Protocol** (MS-WCCE), używając interfejsów DCOM. 1. **Windows Client Certificate Enrollment Protocol** (MS-WCCE), używając interfejsów DCOM.
2. **ICertPassage Remote Protocol** (MS-ICPR), przez nazwaną rurę lub TCP/IP. 2. **ICertPassage Remote Protocol** (MS-ICPR), przez named pipes lub TCP/IP.
3. **interfejsu internetowego rejestracji certyfikatów**, z zainstalowaną rolą Web Enrollment Urzędu Certyfikacji. 3. Interfejs webowy certificate enrollment, z rolą Certificate Authority Web Enrollment zainstalowaną.
4. **Usługi rejestracji certyfikatów** (CES), w połączeniu z usługą polityki rejestracji certyfikatów (CEP). 4. **Certificate Enrollment Service** (CES), w powiązaniu z Certificate Enrollment Policy (CEP) service.
5. **Usługi rejestracji urządzeń sieciowych** (NDES) dla urządzeń sieciowych, używając Protokółu Prostej Rejestracji Certyfikatów (SCEP). 5. **Network Device Enrollment Service** (NDES) dla urządzeń sieciowych, używając Simple Certificate Enrollment Protocol (SCEP).
Użytkownicy systemu Windows mogą również żądać certyfikatów za pośrednictwem GUI (`certmgr.msc` lub `certlm.msc`) lub narzędzi wiersza poleceń (`certreq.exe` lub polecenia `Get-Certificate` PowerShell). Użytkownicy Windows mogą także żądać certyfikatów przez GUI (`certmgr.msc` lub `certlm.msc`) lub narzędzia wiersza poleceń (`certreq.exe` lub polecenie PowerShell `Get-Certificate`).
```bash ```bash
# Example of requesting a certificate using PowerShell # Example of requesting a certificate using PowerShell
Get-Certificate -Template "User" -CertStoreLocation "cert:\\CurrentUser\\My" Get-Certificate -Template "User" -CertStoreLocation "cert:\\CurrentUser\\My"
``` ```
## Uwierzytelnianie za pomocą certyfikatów ## Uwierzytelnianie za pomocą certyfikatów
Active Directory (AD) wspiera uwierzytelnianie za pomocą certyfikatów, głównie wykorzystując protokoły **Kerberos** i **Secure Channel (Schannel)**. Active Directory (AD) obsługuje uwierzytelnianie przy użyciu certyfikatów, głównie z wykorzystaniem protokołów **Kerberos** i **Secure Channel (Schannel)**.
### Proces Uwierzytelniania Kerberos ### Proces uwierzytelniania Kerberos
W procesie uwierzytelniania Kerberos, żądanie użytkownika o Ticket Granting Ticket (TGT) jest podpisywane za pomocą **klucza prywatnego** certyfikatu użytkownika. To żądanie przechodzi przez kilka walidacji przez kontroler domeny, w tym **ważność** certyfikatu, **ścieżkę** oraz **status unieważnienia**. Walidacje obejmują również weryfikację, że certyfikat pochodzi z zaufanego źródła oraz potwierdzenie obecności wystawcy w **sklepie certyfikatów NTAUTH**. Pomyślne walidacje skutkują wydaniem TGT. Obiekt **`NTAuthCertificates`** w AD, znajdujący się pod: W procesie uwierzytelniania Kerberos żądanie użytkownika o Ticket Granting Ticket (TGT) jest podpisywane przy użyciu **klucza prywatnego** certyfikatu użytkownika. To żądanie podlega kilku weryfikacjom wykonywanym przez kontroler domeny, w tym sprawdzeniu **ważności**, **ścieżki** oraz **statusu unieważnienia** certyfikatu. Weryfikacje obejmują także potwierdzenie, że certyfikat pochodzi z zaufanego źródła oraz obecności wystawcy w **magazynie certyfikatów NTAUTH**. Udane weryfikacje skutkują wydaniem TGT. Obiekt **`NTAuthCertificates`** w AD, znajdujący się pod:
```bash ```bash
CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<domain>,DC=<com> CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<domain>,DC=<com>
``` ```
jest kluczowe dla ustanowienia zaufania w przypadku uwierzytelniania certyfikatów. jest kluczowe dla ustanawiania zaufania w uwierzytelnianiu za pomocą certyfikatów.
### Uwierzytelnianie Secure Channel (Schannel) ### Secure Channel (Schannel) Authentication
Schannel ułatwia bezpieczne połączenia TLS/SSL, gdzie podczas handshake klient przedstawia certyfikat, który, jeśli zostanie pomyślnie zweryfikowany, upoważnia do dostępu. Mapowanie certyfikatu do konta AD może obejmować funkcję Kerberos **S4U2Self** lub **Subject Alternative Name (SAN)** certyfikatu, między innymi metody. Schannel umożliwia bezpieczne połączenia TLS/SSL, w których podczas handshake klient przedstawia certyfikat, który — jeśli zostanie pomyślnie zweryfikowany — uprawnia do dostępu. Mapowanie certyfikatu na konto AD może wykorzystywać funkcję Kerberos **S4U2Self** lub **Subject Alternative Name (SAN)** certyfikatu, między innymi metodami.
### Enumeracja usług certyfikatów AD ### AD Certificate Services Enumeration
Usługi certyfikatów AD można enumerować za pomocą zapytań LDAP, ujawniając informacje o **Enterprise Certificate Authorities (CAs)** i ich konfiguracjach. Jest to dostępne dla każdego użytkownika uwierzytelnionego w domenie bez specjalnych uprawnień. Narzędzia takie jak **[Certify](https://github.com/GhostPack/Certify)** i **[Certipy](https://github.com/ly4k/Certipy)** są używane do enumeracji i oceny podatności w środowiskach AD CS. Usługi certyfikatów AD można wyliczyć za pomocą zapytań LDAP, ujawniając informacje o **Enterprise Certificate Authorities (CAs)** i ich konfiguracjach. Jest to dostępne dla dowolnego użytkownika uwierzytelnionego w domenie bez specjalnych uprawnień. Narzędzia takie jak **[Certify](https://github.com/GhostPack/Certify)** i **[Certipy](https://github.com/ly4k/Certipy)** są używane do enumeracji i oceny podatności w środowiskach AD CS.
Polecenia do korzystania z tych narzędzi obejmują: Przykładowe polecenia użycia tych narzędzi obejmują:
```bash ```bash
# Enumerate trusted root CA certificates and Enterprise CAs with Certify # Enumerate trusted root CA certificates, Enterprise CAs and HTTP enrollment endpoints
Certify.exe cas # Useful flags: /domain, /path, /hideAdmins, /showAllPermissions, /skipWebServiceChecks
# Identify vulnerable certificate templates with Certify Certify.exe cas [/ca:SERVER\ca-name | /domain:domain.local | /path:CN=Configuration,DC=domain,DC=local] [/hideAdmins] [/showAllPermissions] [/skipWebServiceChecks]
Certify.exe find /vulnerable
# Identify vulnerable certificate templates and filter for common abuse cases
Certify.exe find
Certify.exe find /vulnerable [/currentuser]
Certify.exe find /enrolleeSuppliesSubject # ESC1 candidates (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT)
Certify.exe find /clientauth # templates with client-auth EKU
Certify.exe find /showAllPermissions # include template ACLs in output
Certify.exe find /json /outfile:C:\Temp\adcs.json
# Enumerate PKI object ACLs (Enterprise PKI container, templates, OIDs) useful for ESC4/ESC7 discovery
Certify.exe pkiobjects [/domain:domain.local] [/showAdmins]
# Use Certipy for enumeration and identifying vulnerable templates # Use Certipy for enumeration and identifying vulnerable templates
certipy find -vulnerable -u john@corp.local -p Passw0rd -dc-ip 172.16.126.128 certipy find -vulnerable -u john@corp.local -p Passw0rd -dc-ip 172.16.126.128
@ -115,9 +125,11 @@ certipy find -vulnerable -u john@corp.local -p Passw0rd -dc-ip 172.16.126.128
certutil.exe -TCAInfo certutil.exe -TCAInfo
certutil -v -dstemplate certutil -v -dstemplate
``` ```
## Odniesienia ## Źródła
- [https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf](https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf) - [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://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)
- [GhostPack/Certify](https://github.com/GhostPack/Certify)
- [GhostPack/Rubeus](https://github.com/GhostPack/Rubeus)
{{#include ../../../banners/hacktricks-training.md}} {{#include ../../../banners/hacktricks-training.md}}