von Bhabesh Raj Rai, Associate Security Analyst Engineer

Jüngste Privilege-Escalation-Schwachstellen im Active Directory (AD) ermöglichen es normalen Domain-Nutzern, sich als Domain-Administratoren auszugeben. Ist der Angriff erfolgreich, könnten Administratoren in die missliche Lage geraten, ihr gesamtes AD bereinigen und neu aufbauen zu müssen. Mit LogPoint SIEM und SOAR können Administratoren AD-Privilege-Escalation mit zuverlässigen Erkennungsmechanismen und Out-of-the-box-Playbooks aufdecken, untersuchen und beheben.

Am 9. November 2021 hat Microsoft eine Reihe von Privilege-Escalation-Schwachstellen im AD behoben, die– wenn sie miteinander verkettet werden – es einem normalen Domain-Nutzer ermöglichen, sich als Benutzer mit erweiterten Berechtigungen auszugeben, beispielsweise als Domain-Administrator. Zudem sind mehrere Proof-of-Concepts (PoCs) öffentlich verfügbar, die es auch einem weniger versierten Bedrohungsakteur ermöglichen, eine gesamte Domain sehr einfach zu kompromittieren.

CVE-2021-42278 und CVE-2021-42287 sind beides Privilege-Escalation-Schwachstellen in den Active-Directory-Domain-Services und haben einen CVSS-Score von 8,8. Beide Schwachstellen ermöglichen es einem Angreifer, sich als Domain-Controller auszugeben. CVE-2021-42278 nutzt das Account-Spoofing sAMAccountName und CVE-2021-42287 nutzt die Kerberos PAC-Confusion (PAC: Privileged Attribute Certificate). Administratoren sollten sicherstellen, dass sie die Microsoft-Patches KB5008102 für CVE-2021-42278 und Microsofts KB5008380 für CVE-2021-42287 auf allen ihren Domain-Controllern installiert haben.

Der Sicherheitsexperte Charlie Clark hat ausführlich beschrieben, wie man diese Schwachstellen ausnutzen kann. Vereinfacht ausgedrückt, beginnt die Angriffskette mit der Erstellung eines neuen Benutzerkontos in der AD-Domain, gefolgt von der Umbenennung dieses Benutzerkontos, um den Namen eines bestehenden Domain-Controllers zu spiegeln, jedoch ohne das nachgestellte „$“. Anschließend wird eine Kerberos-TGT-Anfrage unter Verwendung dieses neuen Computernamens gesendet, gefolgt von der Umbenennung des erstellten Benutzerkontos in einen beliebigen Wert. Schließlich endet die Angriffskette mit der Anfrage eines Kerberos-S4U2self-Tickets unter Verwendung des abgerufenen TGTs. Ist jeder dieser Schritte erfolgreich, erhält der Angreifer ein Service-Ticket für einen Domain-Controller. Der Angreifer erhält dieses Ticket, denn wenn wir ein S4U2self-Ticket mit einem TGT eines Kontos anfordern, das nicht existiert (da es umbenannt wurde), sucht das Key Distribution Center (KDC) automatisch erneut, indem es ein nachgestelltes „$“ hinzufügt. Seit Clarks Offenlegungen sind PoCs für Python und EXE verfügbar und selbst Scripting-Anfänger können mit diesen PoCs eine gesamte AD-Domain sehr einfach kompromittieren.

Administratoren sollten beachten, dass zu Beginn der Angriffskette ein nicht-privilegierter Benutzer in der Lage sein sollte, einen Computer zu einer bestehenden Domain hinzuzufügen. Üblicherweise erlaubt das AD den Standard-Domain-Usern, einer AD-Domain über das Attribut MS-DS-Machine-Account-Quota bis zu zehn Computer hinzuzufügen. Wir empfehlen Administratoren, den Wert des Attributs in allen ihren Domains auf Null zu setzen.

LogPoint-Kunden können unser Package „UseCases v5.1.1“ verwenden, das Analysen für die AD-Privilege-Escalation-Schwachstellen umfasst.

Die Erkennung von AD-Privilege-Escalations mit LogPoint

Um AD-Privilege-Escalations zu erkennen, müssen LogPoint-Kunden die Logdaten-Quellen der AD-Domain-Services nutzen. Wie bereits beschrieben, besteht die Angriffskette aus mehreren Schritten. Das bedeutet, dass mehrere Event-Logdaten im Verlauf des Angriffs generiert werden. Sicherheitsanalysten können die generierten Logdaten nutzen, um zuverlässige Erkennungen zu erstellen. Sie können nach der Erstellung eines neuen Benutzerkontos (EID 4741) suchen, gefolgt von der Umbenennung dieses Benutzerkontos (EID 4781) in einen neuen Wert ohne nachgestelltes „$“.

[label=Computer label=Account label=Create] as s1   
followed by   
[label=Account label=Name label=Change target_user="*$" -new_user="*$"] as s2   
within 5 second   
on s1.computer=s2.target_user  
| rename s1.computer as computer, s1.user as user, s2.new_user as new_computer_name 
| chart count() by user, computer, new_computer_name

Die Suche nach der Erstellung eines Kontos, gefolgt von der Umbenennung in einen neuen Wert ohne nachgestelltes „$“

Als Nächstes können Sie nach der Umbenennung eines Kontos suchen, um das nachgestellte „$“ zu entfernen, gefolgt von einer Kerberos-TGT-Anfrage (EID 4768) unter Verwendung dieses umbenannten Kontos.

[label=Account label=Name label=Change target_user="*$" -new_user="*$"] as s1  
followed by   
[norm_id=WinServer event_id=4768 -user="*$"] as s2  
within 5 second on s1.new_user=s2.user
| rename s1.target_user as old_computer_name, s1.new_user as 
new_computer_name, s1.user as user, s2.source_address as source_address 
| chart count() by user, old_computer_name, new_computer_name, source_address

Die Suche nach der Änderung des Kontonamens, gefolgt von einer Kerberos-TGT-Anfrage unter Verwendung des umbenannten Kontos

Alternativ können Sie nach verdächtigen Kerberos-Service-Ticket-Anfragen (in diesem Fall S4U2self) suchen, bei denen sowohl im Service- als auch im Benutzerfeld ein Domain-Controller angegeben ist, aber letzteres kein abschließendes „$“ enthält.

norm_id=WinServer event_id=4769 service IN WINDOWS_DC
| norm on service <dc:'\S+'>$
| process compare(user, dc) as result
| search result=true
| chart count() by log_ts, user, dc, service, source_address

Kerberos service ticket requests

Die Suche nach verdächtigen Kerberos-Service-Ticket-Anfragen

Um den Nutzer mit der S4U2self-Anfrage zu finden, können Sie nach der bereits erwähnten verdächtigen Kerberos-Service-Ticket-Anfrage suchen, gefolgt von einer Benutzeranmeldung mit derselben IP-Adresse, die die verdächtige Service-Ticket-Anfrage gestellt hat..

[norm_id=WinServer event_id=4769 service IN WINDOWS_DC
| norm on service <dc:'\S+'>$ 
| process compare(user, dc) as result 
| search result=true] as s1 followed by 
[norm_id=WinServer event_id=4624] as s2 
within 5 second on s1.host=s2.host and s1.source_address=s2.source_address 
| rename s1.log_ts as log_ts, s2.log_ts as login_ts, s1.host as host, s1.user as user, 
         s1.service as service, s1.dc as dc, s2.user as impersonated_user, s2.source_address as source_address
| chart count() by log_ts, login_ts, user, service, dc, impersonated_user, source_address

Die Suche nach dem Benutzerkonto des Angreifers

Der Python-PoC verfügt über eine Option, nach einem erfolgreichen Exploit direkt eine Shell zu öffnen, die Sie im Event zur Installation eines neuen Service sehen können. Sie werden feststellen, dass dieser Service von dem betrügerischen Benutzer erstellt wurde.

label=Service label=Install path="%COMSPEC%*\\127.0.0.1\C$\*" 
| chart count() by user, file, service, path

suspicious paths in new service installations

Die Suche nach verdächtigen Pfaden in neuen Service-Installationen

Angreifer können, nachdem sie das Service-Ticket eines Domain-Controllers (DC) erhalten haben, die sehr einfach DCSync-Technik dazu verwenden, die Passwort-Hashes dieses DCs auszulesen. LogPoint-Kunden können Alarme verwenden, die in dem Package Alert Rules enthalten sind, um Attacken zu erkennen, die häufig von Angreifern verwendet werden.

Searching for artifacts of a DCSync attack

Die Suche nach Artefakten eines DCSync-Angriffs

Untersuchung der Aktivitäten nach einer Kompromittierung mithilfe von LogPoint SOAR

Administratoren können LogPoint SOAR nutzen, um Playbooks zu erstellen, die Untersuchungen im Zusammenhang mit den Aktivitäten der Angreifer nach einer Kompromittierung durchführen.

Im Rahmen dieser Untersuchung muss Folgendes überprüft werden:

  • Die Erstellung neuer Benutzerkonten für die Phase der Persistenz
  • Spuren von SYSTEM-Shells auf dem betroffenen Domain-Controller
  • Verdächtige Service-Installationen
  • Credential Dumping mit Mimikatz
  • DCSync-Angriffe

LogPoint SOAR playbook for investigating post-compromise activity after AD privilege escalation

Ein LogPoint SOAR-Playbook für die Untersuchung von Aktivitäten nach einer Kompromittierung durch AD-Privilege Escalation

Nach der Ausführung des Playbooks in LogPoint SOAR können Sie die von den einzelnen Komponenten des Playbooks erstellten Fälle in der Zeitleiste „Investigation Timeline“ einsehen, und sich einen allgemeinen Überblick über die Untersuchungsergebnisse verschaffen.

LogPoint SOAR investigation timeline gathers the results of the investigation

In der „Investigation Timeline“ von LogPoint SOAR sehen Sie die Ergebnisse der Untersuchung

Die Behebung nach Angriffen mit AD-Privilege-Escalation

Wenn es Angreifern gelungen ist, die gesamte Domain zu kompromittieren, müssen Administratoren ihr gesamtes Active Directory bereinigen und von Grund auf neu aufbauen. Dies ist eine manuelle, komplizierte Aufgabe, die üblicherweise nicht vollständig automatisiert werden kann. Um das AD wiederherzustellen, können Administratoren die folgenden Maßnahmen ergreifen:

  • Erstellung der neuen Anmeldedaten für alle Konten
  • Zurücksetzung des Passworts für das KRBTGT-Konto
  • Prüfung auf Änderungen in der Gruppenrichtlinie (GPO) und den Anmeldeskripten
  • Einstufung neuer Server zu DCs und Verschiebung der FSMO-Rollen dorthin, damit die alten DCs außer Betrieb genommen werden können

Administratoren sollten auf Privilege-Escalation-Schwachstellen achten, da Ransomware-Akteure diese leicht ausnutzen können, um ihre schadhafte Software schneller zu verbreiten. Wir empfehlen Sicherheitsverantwortlichen, den PoC in einer Lab-Umgebung zu testen, die dieselbe Konfiguration wie ihre Produktivumgebung aufweist. So können Security-Teams ihre Erkennungsmechanismen testen, gegebenenfalls anpassen und sicherstellen, dass die Anforderungen an die Logdaten-Quellen für die Bedrohungserkennung erfüllt sind, anstatt blindlings auf Erkennungsmethoden zu vertrauen.