AD CS Domänen-Persistenz

Reading time: 8 minutes

Dies ist eine Zusammenfassung der in https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf beschriebenen Techniken zur Domänen-Persistenz. Siehe das Dokument für weitere Details.

Forging Certificates with Stolen CA Certificates (Golden Certificate) - DPERSIST1

Woran erkennt man, dass ein Zertifikat ein CA-Zertifikat ist?

Ein Zertifikat kann als CA-Zertifikat identifiziert werden, wenn mehrere Bedingungen erfüllt sind:

• Das Zertifikat ist auf dem CA-Server gespeichert; der private Schlüssel ist durch die DPAPI der Maschine gesichert oder — falls das Betriebssystem es unterstützt — durch Hardware wie TPM/HSM.
• Sowohl die Felder Issuer als auch Subject des Zertifikats stimmen mit dem Distinguished Name der CA überein.
• Eine "CA Version"-Erweiterung ist ausschließlich in CA-Zertifikaten vorhanden.
• Dem Zertifikat fehlen Extended Key Usage (EKU)-Felder.

Um den privaten Schlüssel dieses Zertifikats zu extrahieren, ist auf dem CA-Server das Tool certsrv.msc über die eingebaute GUI die unterstützte Methode. Nichtsdestotrotz unterscheidet sich dieses Zertifikat nicht von anderen im System gespeicherten; daher können Methoden wie die THEFT2 technique zur Extraktion angewandt werden.

Das Zertifikat und der private Schlüssel können auch mit Certipy mittels des folgenden Befehls erhalten werden:

certipy ca 'corp.local/administrator@ca.corp.local' -hashes :123123.. -backup

Nachdem das CA-Zertifikat und dessen privater Schlüssel im .pfx-Format erlangt wurden, können Tools wie ForgeCert verwendet werden, um gültige Zertifikate zu erstellen:

# Generating a new certificate with ForgeCert
ForgeCert.exe --CaCertPath ca.pfx --CaCertPassword Password123! --Subject "CN=User" --SubjectAltName localadmin@theshire.local --NewCertPath localadmin.pfx --NewCertPassword Password123!

# Generating a new certificate with certipy
certipy forge -ca-pfx CORP-DC-CA.pfx -upn administrator@corp.local -subject 'CN=Administrator,CN=Users,DC=CORP,DC=LOCAL'

# Authenticating using the new certificate with Rubeus
Rubeus.exe asktgt /user:localdomain /certificate:C:\ForgeCert\localadmin.pfx /password:Password123!

# Authenticating using the new certificate with certipy
certipy auth -pfx administrator_forged.pfx -dc-ip 172.16.126.128

Dieses gefälschte Zertifikat wird bis zum angegebenen Enddatum gültig sein und so lange wie das Root-CA-Zertifikat gültig ist (in der Regel 5 bis 10+ Jahre). Es ist außerdem für Maschinen gültig, sodass in Kombination mit S4U2Self ein Angreifer Persistenz auf jedem Domain-Computer aufrechterhalten kann, solange das CA-Zertifikat gültig ist.
Außerdem können die mit dieser Methode generierten Zertifikate nicht widerrufen werden, da die CA keine Kenntnis von ihnen hat.

Betrieb unter Strong Certificate Mapping Enforcement (2025+)

Seit dem 11. Februar 2025 (nach dem Rollout von KB5014754) sind Domänencontroller standardmäßig auf Full Enforcement für Zertifikatzuordnungen eingestellt. Praktisch bedeutet das, dass deine gefälschten Zertifikate entweder:

• Eine starke Bindung an das Zielkonto enthalten (zum Beispiel die SID security extension), oder
• Mit einer starken, expliziten Zuordnung am Attribut altSecurityIdentities des Zielobjekts gepaart sein.

Ein zuverlässiger Ansatz zur Persistenz ist es, ein gefälschtes Zertifikat auszustellen, das an die gestohlene Enterprise CA gebunden ist, und dann eine starke, explizite Zuordnung zum Ziel-Principal hinzuzufügen:

# Example: map a forged cert to a target account using Issuer+Serial (strong mapping)
$Issuer  = 'DC=corp,DC=local,CN=CORP-DC-CA'           # reverse DN format expected by AD
$SerialR = '1200000000AC11000000002B'                  # serial in reversed byte order
$Map     = "X509:<I>$Issuer<SR>$SerialR"             # strong mapping format
Set-ADUser -Identity 'victim' -Add @{altSecurityIdentities=$Map}

Notes

• Wenn Sie gefälschte Zertifikate erstellen können, die die SID‑Sicherheits‑Erweiterung enthalten, werden diese selbst unter Full Enforcement implizit gemappt. Andernfalls bevorzugen Sie explizite, starke Zuordnungen. Siehe account-persistence für mehr zu expliziten Zuordnungen.
• Widerruf hilft Verteidigern hier nicht: Gefälschte Zertifikate sind der CA‑Datenbank unbekannt und können daher nicht widerrufen werden.

Trusting Rogue CA Certificates - DPERSIST2

Das NTAuthCertificates-Objekt ist definiert, um ein oder mehrere CA-Zertifikate in seinem cacertificate-Attribut zu enthalten, die von Active Directory (AD) verwendet werden. Der Verifizierungsprozess durch den domain controller prüft das NTAuthCertificates-Objekt auf einen Eintrag, der mit der in das Issuer‑Feld des authentifizierenden Zertifikats angegebenen CA übereinstimmt. Die Authentifizierung wird fortgesetzt, wenn eine Übereinstimmung gefunden wird.

Ein selbstsigniertes CA‑Zertifikat kann von einem Angreifer dem NTAuthCertificates-Objekt hinzugefügt werden, vorausgesetzt, er hat die Kontrolle über dieses AD‑Objekt. Normalerweise dürfen nur Mitglieder der Gruppe Enterprise Admin, zusammen mit Domain Admins oder Administrators in der forest root’s domain, dieses Objekt ändern. Sie können das NTAuthCertificates-Objekt mit certutil.exe bearbeiten, z. B. mit dem Befehl certutil.exe -dspublish -f C:\Temp\CERT.crt NTAuthCA, oder indem sie das PKI Health Tool verwenden.

Weitere nützliche Befehle für diese Technik:

# Add/remove and inspect the Enterprise NTAuth store
certutil -enterprise -f -AddStore NTAuth C:\Temp\CERT.crt
certutil -enterprise -viewstore NTAuth
certutil -enterprise -delstore NTAuth <Thumbprint>

# (Optional) publish into AD CA containers to improve chain building across the forest
certutil -dspublish -f C:\Temp\CERT.crt RootCA          # CN=Certification Authorities
certutil -dspublish -f C:\Temp\CERT.crt CA               # CN=AIA

Diese Möglichkeit ist besonders relevant in Kombination mit der zuvor beschriebenen Methode, die ForgeCert verwendet, um Zertifikate dynamisch zu erzeugen.

Post-2025 mapping considerations: placing a rogue CA in NTAuth only establishes trust in the issuing CA. To use leaf certificates for logon when DCs are in Full Enforcement, the leaf must either contain the SID security extension or there must be a strong explicit mapping on the target object (for example, Issuer+Serial in altSecurityIdentities). See AD CS Account Persistence.

Böswillige Fehlkonfiguration - DPERSIST3

Möglichkeiten für persistence durch Änderungen an Sicherheitsdeskriptoren von AD CS-Komponenten sind zahlreich. Änderungen, die im Abschnitt "Domain Escalation" beschrieben sind, können von einem Angreifer mit erhöhten Rechten böswillig umgesetzt werden. Dazu gehört das Hinzufügen von "control rights" (z. B. WriteOwner/WriteDACL/etc.) zu sensiblen Komponenten wie:

• Das AD-Computerobjekt des CA-Servers
• Den RPC/DCOM-Server des CA-Servers
• Jedes untergeordnete AD-Objekt oder Container in CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM> (zum Beispiel der Certificate Templates-Container, der Certification Authorities-Container, das NTAuthCertificates-Objekt, etc.)
• AD-Gruppen, denen standardmäßig oder organisationsseitig Rechte zur Kontrolle von AD CS delegiert wurden (wie die eingebaute Cert Publishers-Gruppe und deren Mitglieder)

Ein Beispiel für eine böswillige Umsetzung wäre, dass ein Angreifer mit erhöhten Berechtigungen in der Domäne die Berechtigung WriteOwner auf der Standard-User-Zertifikatvorlage hinzufügt, wobei der Angreifer selbst der Principal für dieses Recht ist. Um dies auszunutzen, würde der Angreifer zunächst den Besitz der User-Vorlage auf sich selbst übertragen. Anschließend würde das mspki-certificate-name-flag auf 1 gesetzt, um ENROLLEE_SUPPLIES_SUBJECT zu aktivieren und es einem Benutzer zu erlauben, einen Subject Alternative Name in der Anfrage anzugeben. Danach könnte sich der Angreifer mit der Vorlage einschreiben, einen Domain-Administrator-Namen als alternativen Namen wählen und das erworbene Zertifikat zur Authentifizierung als DA verwenden.

Praktische Stellschrauben, die Angreifer für langfristige Domain-persistence setzen könnten (siehe AD CS Domain Escalation für vollständige Details und Erkennung):

• CA-Policy-Flags, die SAN von Requestern erlauben (z. B. Aktivierung von EDITF_ATTRIBUTESUBJECTALTNAME2). Dies hält ESC1-ähnliche Pfade ausnutzbar.
• Template-DACL oder Einstellungen, die die Ausstellung von zur Authentifizierung geeigneten Zertifikaten erlauben (z. B. Hinzufügen der Client Authentication EKU, Aktivierung von CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT).
• Kontrolle über das NTAuthCertificates-Objekt oder die CA-Container, um rogue Issuer kontinuierlich wieder einzubringen, falls Verteidiger eine Bereinigung versuchen.

Referenzen

• Microsoft KB5014754 – Certificate-based authentication changes on Windows domain controllers (enforcement timeline and strong mappings). https://support.microsoft.com/en-au/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16
• Certipy – Command Reference and forge/auth usage. https://github.com/ly4k/Certipy/wiki/08-%E2%80%90-Command-Reference
• 0xdf – HTB: Certificate (SeManageVolumePrivilege to exfil CA keys → Golden Certificate)