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:
Wir bezeichnen die SIDs, die den Formatierungsregeln für legitime SIDs entsprechen, aber tatsächlich noch nicht auf ein Objekt verweisen, als „synthetisch“.
Das Berechtigungssystem von Active Directory besteht aus drei Teilen:
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.
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).
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.
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.
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.
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.