Ist diese SID schon vergeben? Varonis Threat Labs entdeckt Injektionsangriff mit synthetischen SIDs

In unseren Varonis Threat Labs haben wir eine Technik entdeckt, mit der Bedrohungsakteure mit bereits bestehenden hohen Berechtigungen synthetische SIDs in eine Active Directory Access Control List (ACL) injizieren können. Dadurch entsteht ein Szenario, das Backdoors und versteckte Berechtigungen ermöglicht, wenn ein neues Konto mit einer entsprechenden legitimen SID erstellt wird.

Dieser Angriff ist möglich, da:

SIDs sich leicht erraten lassen, weil sie hauptsächlich konsekutiv zugewiesen werden
Active Directory nicht prüft, ob eine SID, die auf eine ACL angewendet wird, gültig ist

Wir bezeichnen die SIDs, die den Formatierungsregeln für legitime SIDs entsprechen, aber tatsächlich noch nicht auf ein Objekt verweisen, als „synthetisch“.

Hintergrund

Das Berechtigungssystem von Active Directory besteht aus drei Teilen:

Trustees: Objekte, auf die Berechtigungen angewendet werden. Dazu gehören in der Regel Benutzerkonten, Gruppen und Computerkonten.
Security Identifier (SID): In Active Directory werden Sicherheitsprinzipale durch eine SID (Security Identifier, zu Dt. Sicherheitsidentifikator) identifiziert. Die SID ist ein eindeutiger Identifikator, die verwendet wird, um jede Entität zu repräsentieren, die vom Betriebssystem authentifiziert werden kann. Sie ist mehr oder weniger mit einer Sozialversicherungs- oder Passnummer vergleichbar, nur eben für ein Domainobjekt. Die SID wird von einem Domänencontroller ausgestellt und einem Objekt bei der Erstellung zugewiesen. Sie kann nicht wiederverwendet oder zur Identifizierung einer anderen Entität benutzt werden.
Access Control List (ACL): die Zuordnung zwischen einem Objekt (SID) und Berechtigungen innerhalb von Active Directory.

Keine SID-Verifizierung

Bei der Erstellung einer ACL wird die SID des Trustees nicht darauf hin überprüft, ob sie in der Domäne existiert. Da für die SID keine Gültigkeitsprüfung mit ausreichenden Berechtigungen durchgeführt wird, ist es möglich, einer ACL eine nicht vorhandene, „synthetische“ SID hinzuzufügen.

Diese nicht vorhandenen (synthetischen) SIDs mit ACL-Berechtigungen bleiben so lange unschädlich in den ACLs, bis ein neues Benutzer- oder Computerkonto erstellt wird, dem diese (nun ehemals) synthetische SID zugewiesen wird. Diese neuen Konten erben sofort die zuvor gewährten ACL-Berechtigungen.

Untersuchung von ACLs

Sie können die ACL eines Objekts anzeigen, indem Sie auf die Registerkarte „Sicherheit“ gehen:

Windows löst die SID des Eintrags auf und zeigt, für bessere Lesbarkeit, den Benutzernamen an. Hinter den Kulissen identifiziert die ACL den Benutzer jedoch über seine SID, wie in der SDDL definiert (mehr über SDDLs können Sie hier erfahren: https://docs.microsoft.com/en-us/windows/win32/secauthz/security-descriptor-string-format).

Injektion einer synthetischen SID in eine ACL

Da Windows bei der Erstellung einer ACL nicht überprüft, ob die SIDs in der Domäne existieren, lässt sich unsere synthetische SID in die ACL eines beliebigen Objekts einfügen, für das wir Berechtigungen haben:

Hinweis: Der Domänenabschnitt der SID ist änderbar, „S-1-5-21“ jedoch nicht.
Die Synthetische SID im Screenshot:

kann nicht aufgelöst werden („Konto unbekannt“), da sie nicht zugewiesen ist
ist gültig für den ACL-Eintrag

Es ist nicht einfach, die Kontrolle über eine bestehende SID zu erlangen, da SIDs nicht von anderen Benutzern übernommen oder wiederverwendet werden können. Indem wir jedoch abbilden, welche SIDs derzeit in der Domäne existieren, können wir vorhersagen, mit welchen SIDs neue Benutzer erstellt werden. So können wir ein Szenario herbeiführen, in dem ein neu erstelltes Konto unsere injizierten Berechtigungen erbt.

Wir können die derzeit vorhandenen SIDs mit PowerShell abbilden:

(([adsisearcher]"(objectSid=*)").FindAll()).Properties.objectsid | ForEach-Object {(New-Object System.Security.Principal.SecurityIdentifier($_,0)).Value}

Die SID im folgenden Bild ist mit keinem Konto verbunden und ist die nächste verfügbare SID in der Domäne. Ihr wurde die volle Kontrolle über das Objekt „Remote Management Users“ (Remote-Verwaltungsbenutzer) gewährt:

Wir haben ein Konto mit dem Namen „ThisIsMySid“ erstellt und es hat die SID übernommen:

Der Benutzer „ThisIsMySID“ hat nun die volle Kontrolle über das Gruppenobjekt.

Bemerkenswerterweise funktioniert dieser Trick auch für die Zuweisung von Windows-Berechtigungen wie SeDebugPrivilege, SeRemoteInteractiveLogonRight oder andere Berechtigungseinschränkungen.

Exploit

Der Hauptvektor für den Exploit ist hier die Persistenz. Bedrohungsakteure mit Domänenkontrolle können zukünftigen SIDs Berechtigungen hinzufügen und dann erneut Fuß fassen, indem sie ein Benutzer- oder Computerkonto erstellen.

Ein Konto lässt sich problemlos erstellen, vorausgesetzt man hat die Kontrolle über ein normales Benutzerkonto. Authentifizierte Benutzer können standardmäßig bis zu 10 Computerkonten erstellen, und Computerkonten werden, wie auch normalen Benutzern, SIDs zugewiesen, die diesen Exploit ermöglichen.

DCSync-Exploit-Szenario

Indem eine SID zum Domänenobjekt hinzugefügt und ihm Synchronisierungsberechtigungen (die für den DCSync-Angriff erforderlich sind) gewährt werden, schafft der Bedrohungsakteur eine Backdoor. Und natürlich kann mehr als eine SID hinzugefügt werden, um sicherzustellen, dass sie nicht durch regelmäßige Aktivitäten überschrieben wird.

Um erneut Fuß fassen zu können, müsste der Bedrohungsakteur die Kontrolle über ein Standard-Benutzerkonto (möglicherweise durch Phishing) erlangen und dieses Konto zum Erstellen eines Computerkontos verwenden:

Das neu erstellte Konto ersetzt eine der verfügbaren SIDs und verfügt über DCSync-Berechtigungen.

Sanierung und Überwachung

Microsoft betrachtet dies nicht als Sicherheitsproblem, allerdings wird eine Überwachung empfohlen, da die Zuweisung von synthetischen SIDs als anormales Verhalten gilt.

Es wird empfohlen, die folgenden Punkte zu überwachen, um das Risiko dieser Technik zu vermindern.

Warnungen bei abnormalen Berechtigungsänderungen, Zuweisungen von Rechten und Erteilung von Berechtigungen in Active-Directory-Umgebungen – unabhängig davon, ob dies automatisch über Skripte, über Malware oder manuell durch eine aktive Bedrohung erfolgt
Verhaltensbasierte Modellierung (wie von Varonis angeboten) für Objekte, die gegenüber ACL-Änderungen empfindlich sind
Änderungen an Directory-Dienstobjekten in Ihrer Organisation (Windows-Ereignis 5136)
Verhaltensbasierte Modellierung (wie von Varonis angeboten), um einen Alarm zu erzeugen, wenn einem Benutzer Berechtigungen für ein sensibles Objekt erteilt werden, bzw. um einen zum Objekt hinzugefügten Trustee zu überwachen und einen Alarm zu erzeugen, falls er nicht existiert.
Direkte Berechtigungszuweisungen (Windows-Ereignis 4704) können auf die Injektion einer synthetischen SID hinweisen.

Verwaiste SIDs entfernen

Ein Prozess zur Überwachung und Entfernung verwaister SIDs verhindert, dass der Angreifer auch die Kontrolle über die synthetischen SIDs erlangt.
Verwenden Sie PowerShell, ICACLS oder eigens dafür vorgesehene Tools, um verwaiste SIDs zu finden und sie zu entfernen.

Quellen

Wie soll ich vorgehen?

Im Folgenden finden Sie drei Möglichkeiten, wie Sie das Datenrisiko in Ihrem Unternehmen verringern können:

Vereinbaren Sie eine Demo mit uns, um Varonis in Aktion zu erleben. Wir passen die Session an die Datensicherheitsanforderungen Ihres Unternehmens an und beantworten alle Fragen.

Sehen Sie sich ein Beispiel unserer Datenrisikobewertung an und erfahren Sie, welche Risiken in Ihrer Umgebung lauern könnten. Varonis DRA ist völlig kostenlos und bietet einen klaren Weg zur automatischen Sanierung.

Folgen Sie uns auf LinkedIn, YouTubeund X (Twitter), um kurze Einblicke in alle Themen der Datensicherheit zu erhalten, einschließlich Data Security Posture Management (DSPM), Bedrohungserkennung, KI-Sicherheit und mehr.

Eric Saraga