von Bhabesh Raj Rai, Security Research
Am Patch-Tuesday dieses Monats hat Microsoft eine schwerwiegende Sicherheitsschwachstelle (CVE-2022-26923) in den AD-Domain-Services behoben, die einen CVSS-Wert von 8,8 hat und damit als kritisch einzustufen ist. Diese Schwachstelle ermöglicht es einem authentifizierten User mit geringen Benutzerrechten ein Zertifikat von privilegierten Konten, wie beispielsweise Domain-Controllern, von den AD-Zertifikatsdiensten zu erhalten, und somit seine Rechte auszuweiten.
Einen Tag nach dem Patch-Tuesday veröffentlichte Oliver Lyak – der Security-Researcher, der die Schwachstelle entdeckte – in seinem Blog technische Details zu dieser Schwachstelle. Er hat auch das certipy-Tool aktualisiert, um eine einfache Ausnutzung dieser Schwachstelle zu ermöglichen.
Um diese Schwachstelle auszunutzen, muss es in der Domäne einen AD CS-Server (AD CS: Active Directory Certificate Services) geben. AD CS ist Microsofts Antwort von auf die Public-Key-Infrastruktur (PKI). Domain-Nutzer können auf Basis einer vordefinierten Zertifikat-Vorlage ein Zertifikat von dem AD CS-Server anfordern. Dieses Zertifikat kann für verschiedene Zwecke verwendet werden, meist kommt es für die Client-Authentifizierung zum Einsatz. Das bedeutet, dass Nutzer mit diesem Zertifikat als Authentifizierungsmedium ein Kerberos TGT anfordern können.
AD CS verfügt über separate Zertifikat-Vorlagen für Nutzer und Computer, wobei beide für die Client-Authentifizierung verwendet werden können. Bei der Benutzer-Authentifizierung per Zertifikat versucht der Domain-Controller, den UPN (UPN: User Principal Name) aus dem Zertifikat einem Benutzer zuzuordnen, während der Domain-Controller bei der Computer-Authentifizierung per Zertifikat versucht, den dNSHostName zuzuordnen, da Computer-Accounts keinen UPN haben. Der Ersteller des Computer-Accounts hat das Recht, den Eigenschaftswert von dNSHostName zu ändern. Außerdem muss dNSHostName im Gegensatz zu UPN in einer Domäne nicht eindeutig sein. Falls Sie jedoch den dNSHostName-Wert ändern, wird der servicePrincipalName-Wert ebenfalls aktualisiert, um den neuen dNSHostName-Wert widerzuspiegeln. Falls Sie also die dNSHostName-Eigenschaft eines Computer-Accounts aktualisieren, um einen Domain-Controller zu spiegeln, versucht der Domain-Controller, den servicePrincipalName zu aktualisieren. Hierbei kann es zu einem Konflikt mit dem eigenen servicePrincipalName des Domain-Controllers kommen, und dies führt zu einer indirekten Constraint-Verletzung.
Der Ersteller des Computer-Accounts hat jedoch auch das Recht, den servicePrincipalName zu ändern. Der neue Wert muss mit dem dNSHostName konform sein. Sie können diese Constraint-Prüfung umgehen, wenn Sie den servicePrincipalName-Wert löschen, der den dNSHostName enthält. Schließlich wird es der Domain-Controller erlauben, den dNSHostName des neu erstellten Computer-Accounts auf einem der Domain-Controller zu aktualisieren. Der Domain-Controller muss den servicePrincipalName nicht aktualisieren, da Sie nur die Werte gelöscht haben, die den dNSHostName-Wert enthalten.
Jetzt können Sie mit der Machine-Vorlage ein Zertifikat für den neu erstellten Computer-Account bei dem AD CS-Server anfordern, und der Domain-Controller sollte die dNSHostName-Eigenschaft als Identifikation einbetten. Anschließend können Sie sich mit diesem Zertifikat bei dem Domain-Controller authentifizieren, um den Hash des Machine-Accounts des Domain-Controllers zu erhalten. Mit diesem Hash können Sie entweder direkt eine DCSync-Attacke nutzen und alle Hashes des Domain-Controllers verwerfen, oder Sie erhalten das Kerberos-TGT des Domain-Controllers.
Der letzte Teil dieser Angriffskette ähnelt dem Petitpotam-Relay-Angriff, bei dem Angreifer den erhaltenen Hash einer Entität an einen AD CS-Server weiterleiten und das Zertifikat dieser Entität bekommen. Informieren Sie sich, wie Sie die Ausnutzung dieser Privilege-Escalation-Schwachstelle mit LogPoint erkennen können.
Erforderliche Logdaten-Quellen
- Windows AD
- Windows AD CS
- Zeek
Administratoren sollten sicherstellen, dass sie die folgenden Einstellungen aktiviert haben, da diese standardmäßig deaktiviert sind.
- Certificate Services Audit-Unterkategorie
- „Issue and manage certificate requests“-Audit auf dem AD CS-Server
Die Ausnutzung der Schwachstelle mit LogPoint erkennen
Analysten sollten nach neu erstellten Computer-Accounts suchen, bei denen der dns_host-Wert so eingestellt ist, dass er einen der Domain-Controller vortäuscht. WINDOWS_DC ist eine Liste, die alle FQDNs (FQDN: Fully Qualified Domain Name) der Domain-Controller enthalten muss, die in Ihrer Domäne betrieben werden.
1norm_id=WinServer label=Computer label=Account label=Create dns_host IN WINDOWS_DC
Die Suche nach neu erstellten Computer-Accounts
Analysten können auch nach ungewöhnlichen SPN-Werten (SPN: Service Principal Name) bei neu erstellten Computer-Accounts suchen, die die Angreifer so einstellen, dass sie die zuvor beschriebene dNSHostName-Validierungsprüfung umgehen können.
1norm_id=WinServer label=Computer label=Account label=Create 2
service="HOST/*RestrictedKrbHost/*"
Die Suche nach SPN-Manipulationen
Suchen Sie als Nächstes nach einer Abweichung zwischen den Werten für computer und dns_host in den generierten Events des Computer-Accounts. In der folgenden Abfrage lautet der Domain-Name knowledgebase.local. Analysten sollten diesen Wert durch ihren eigenen Domain-Namen ersetzen, bevor sie diese Abfrage nutzen.
1norm_id=WinServer label=Computer label=Account label=Create dns_host=* 2
| process eval("computer_name=rtrim(computer, '$')") 3
| process eval("dns_name=rtrim(dns_host, '.knowledgebase.local')") 4
| process compare(computer_name, dns_name) as result 5
| search result=*
Die Suche nach einer Diskrepanz zwischen den Werten computer und dns_host in den generierten Events des Computer-Accounts
Analysten sollten erfolgreiche Zertifikat-Anfragen für die Machine-Vorlage in der Zeitspanne rund um die Erstellung eines neuen Computer-Accounts überprüfen.
1norm_id=WinServer label=Certificate label=Request label=Approve 2
attributes="CertificateTemplate:Machine"
Die Suche nach erfolgreichen Zertifikat-Anforderungen für die Machine-Vorlage
Sie können die beiden Events korrelieren und einen Alarm auslösen, wenn ein neu erstellter Computer-Account, der einen Domain-Controller vortäuscht, erfolgreich ein Zertifikat für die Machine-Vorlagen anfordert.
1[ norm_id=WinServer label=Computer label=Account label=Create dns_host IN WINDOWS_DC ] as s1 2
followed by [ norm_id=WinServer label=Certificate label=Request label=Approve attributes="CertificateTemplate:Machine" 3
| norm on requester \<requester_account:'\S+'> ] as s2 4
within 1 hour on s1.computer=s2.requester_account 5
| rename s1.log_ts as account_creation_ts, s1.computer as computer, s1.user as user, s1.service as service, s1.dns_host as dns_host, s2.subject as certificate_subject 6
| chart count() by account_creation_ts, computer, user, service, dns_host, certificate_subject
Die Korrelation der Erstellung eines Computer-Accounts mit der erfolgreichen Zertifikat-Anfrage einer Machine-Vorlage
Angreifer können eine DCSync-Attacke direkt nutzen, um alle Hashes von einem Domain-Controller zu löschen, nachdem sie dessen Hash erhalten haben. Analysten können Zeek verwenden, um nach dem Datenverkehr einer Verzeichnis-Replikation zu suchen, der von Systemen ausgeht, die keine Domain-Controller sind. WINDOWS_DC_IPS ist eine Liste, die alle IP-Adressen der Domain-Controller enthalten muss, die in Ihrer Domäne betrieben werden.
1norm_id=Zeek event_category=dce_rpc endpoint=drsuapi 2
operation IN ["DRSGetNCChanges", "DRSReplicaSync"] -source_address IN WINDOWS_DC_IPS
Die Suche nach DCSync-Artifakten in den Zeek-Events
Stellen Sie Patches und Abhilfemaßnahmen schnellstmöglich bereit
LogPoint empfiehlt Administratoren, die Anleitung von Microsoft (KB5014754) zur vollständigen Behebung dieser Schwachstelle zu lesen. Zudem rät LogPoint Administratoren dringend, alle Server, auf denen Active Directory-Zertifikatsdienste und Windows-Domain-Controller laufen, die eine Zertifikat-basierte Authentifizierung ermöglichen, mit dem Update vom 10. Mai 2022 zu patchen. Nach diesem Mai-Update befinden sich die Systeme im Kompatibilitätsmodus. Wenn ein Zertifikat einem Benutzer – stark oder schwach – zugeordnet werden kann, erfolgt die Authentifizierung wie erwartet. Es wird jedoch eine Warnung generiert – es sei denn, das Zertifikat ist älter als der Benutzer. Ist das Zertifikat älter als der Benutzer, schlägt die Authentifizierung fehl, und es wird ein Fehler protokolliert.
Microsoft empfiehlt Administratoren, nach dem Patch auf Warnmeldungen zu achten, die möglicherweise nach einem Monat oder später auftreten könnten. Falls keine Warnungen auftreten, rät Microsoft dringend dazu, den Full-Enforcement-Modus auf allen Domain-Controllern zu aktivieren, die eine Zertifikat-basierte Authentifizierung verwenden. Microsoft wird alle Systeme bis zum 9. Mai 2023 auf den Full-Enforcement-Modus aktualisieren.
Incident-Response bei echten, sicherheitsrelevanten Vorfällen
Administratoren können folgende Schritte unternehmen, wenn sie einen True-Positive-Alarm entdecken.
- Erkennen Sie kompromittierte Benutzerkonten.
- Identifizieren Sie betroffene Domain-Controller und CA-Server.
- Suchen Sie nach Spuren einer DCSync-Attacke.
- Prüfen Sie das Anlegen neuer Benutzer rund um das Zeitfenster auf Persistenz.
LogPoint-Kunden können ihre SOAR-Playbooks ausführen, um kompromittierte Benutzerkonten zu reparieren und betroffene Systeme zu bereinigen.
Das Isolate-Host-Playbook in LogPoint SOAR
Ist es Angreifern gelungen, eine Domäne zu kompromittieren, müssen Administratoren ihr gesamtes Active Directory bereinigen und von Grund auf neu aufbauen. Dies ist eine komplexe, manuelle Aufgabe, die in der Regel nicht vollständig automatisiert werden kann. Um das AD wiederherzustellen, können Administratoren die folgenden Maßnahmen für den Active-Directory-Aufbau ergreifen.
- Erstellen Sie neue Anmeldeinformationen für alle Konten.
- Leiten Sie Verfahren zum Zurücksetzen des Passworts für das KRBTGT-Konto ein.
- Überprüfen Sie die Gruppenrichtlinie (GPO) und die Anmeldeskripts auf Änderungen.
- Stufen Sie neue Server zu DCs herauf und verschieben Sie die FSMO-Rollen (FSMO: Flexible Single Master Operations) auf diese, um die alten DCs außer Betrieb nehmen zu können.
In jüngster Zeit traten zahlreiche Privilege-Escalation-Schwachstellen auf, die sowohl Windows als auch Linux betreffen. Ransomware-Akteure nutzen diese in der Regel schnell aus, um möglichst viel Zeit für die Verbreitung ihrer Ransomware zu haben. LogPoint rät Unternehmen, zu prüfen, ob ihre AD-Umgebung anfällig für diese Schwachstellen ist, die erforderlichen Patches einzuspielen und Abhilfemaßnahmen zu nutzen.
LogPoint-Kunden können die Windows-Applikation im Help-Center herunterladen und von den nützlichen Inhalten zur Erkennung der Schwachstelle profitieren.
