Server (Un)Trust-Konto

Persistenz im Active Directory durch Manipulation des userAccountControl

Ich habe mich in letzter Zeit mit Gruppenverwalteten Dienstkonten (gMSAs) beschäftigt und die MS-SAMR Protokollspezifikation für einige Informationen gelesen. Dabei bin ich im Abschnitt userAccountControl auf interessante Informationen gestoßen, die uns veranlasst haben, alles stehen und liegen zu lassen und es zu testen:

Effektiv, wenn das UF_SERVER_TRUST_ACCOUNT-Bit im userAccountControl-Attribut eines Computerobjekts gesetzt ist, dann muss Active Directory die primaryGroupId desselben Objekts auf die RID der Domain Controllers-Gruppe setzen. Daher kann das einfache Ändern von userAccountControl einem Computerobjekt die Privilegien eines Domänencontrollers verleihen.

Untersuchung des Verhaltens

Wir haben mit dem Testen unter Verwendung eines Domain Admin-Kontos in unserem Labor begonnen und zunächst versucht, den Standardwert userAccountControl für einen Domain-Controller von 0x82000 (Dezimal 532480) zu verwenden, der die Summe der Bitflags für SERVER_TRUST_ACCOUNT (0x2000, Dezimal 8192) und TRUSTED_FOR_DELEGATION (0x80000, Dezimal 524288) ist.

Nachdem der Wert von userAccountControl geändert wurde, stellen wir fest, dass die primaryGroupId auf 516 (die RID für die Domain Controllers-Gruppe) aktualisiert wird und wir einen großartigen Start haben! Als Nächstes wollten wir wissen, ob nur das SERVER_TRUST_ACCOUNT-Bit erforderlich ist, also haben wir erneut versucht, das Attribut userAccountControl auf 8192 zu setzen.

Wir haben somit die Genauigkeit der Protokollspezifikation bestätigt und dass nur das SERVER_TRUST_ACCOUNT-Bit eine Änderung der primaryGroupId bewirkt.

Erforschung der erforderlichen Privilegien

Wir beginnen damit, mögliche Missbrauchsvektoren in Betracht zu ziehen. Wenn nur die Fähigkeit erforderlich ist, das Attribut userAccountControl zu ändern, dann könnten wir auf eine interessante Technik zur privilege escalation stoßen. Wir haben mit einem nicht privilegierten Konto begonnen, das nur Berechtigungen zum Ändern des Attributs userAccountControl hatte und stießen schnell auf Zugriffsverweigerungsfehler.

Es stellt sich heraus, dass wir nur ein paar Zeilen weiter unten in der MS-SAMR-Dokumentation hätten lesen sollen. Abschnitt 5 des Attributs „userAccountControl“ beschreibt zusätzliche Berechtigungen, die erforderlich sind, um bestimmte Bits des „userAccountControl“ zu setzen. Um das Bit „userAccountControl UF_SERVER_TRUST_ACCOUNT“ zu setzen, muss der Akteur die Berechtigung „DS-Install-Replica“ („Hinzufügen/Entfernen einer Replik in der Domäne“) für das Domänenobjekt erteilt bekommen haben.

Wir haben unserem nicht-privilegierten Benutzer diese Berechtigung erteilt und unseren Test erneut durchgeführt.

Nachdem wir dem nicht privilegierten Benutzer das Schreibrecht userAccountControl und das Recht DS-Install-Replica auf das Domain-Objekt erteilt hatten, war unser Test erfolgreich.

Standardmäßig wird die Berechtigung „DS-Install-Replica“ den Gruppen „Domain Admins“ und „Enterprise Admins“ erteilt. Daher stellt dieser Ansatz in allen außer schlecht konfigurierten Umgebungen keinen Privilegienerhöhungsvektor dar. Angesichts der begrenzten erforderlichen Berechtigungen begannen wir jedoch, über Anwendungen für die Domain-Persistenz nachzudenken.

Anwendungen für Domain-Persistenz

Bei der Bewertung, ob dies eine interessante Methode zur Aufrechterhaltung darstellt, haben wir mehrere Faktoren berücksichtigt: dass nur eine begrenzte Anzahl von Privilegien erforderlich ist, dass diese Privilegien nicht häufig überprüft werden, dass (objectClass=computer) Konten leicht zu erstellen sind, dass Computer selten überprüft werden (viele Organisationen kämpfen mit veralteten Computerobjekten), und dass die Ausnutzung des Mechanismus einfach ist und Anzeichen kurzlebig sind.

Die Konfiguration dieses Mechanismus erfordert nur wenige kleine Schritte:

1. Erstellen Sie ein gefälschtes Computer-, MSA- oder gMSA-Konto. Ein bestehendes Konto kann ebenfalls verwendet werden, aber die Wirksamkeit des Persistenzmechanismus wird durch die Häufigkeit der Passwortänderungen begrenzt sein. Allerdings könnte ein bestehendes, aber veraltetes (nicht mehr verwendetes) Computerkonto ein attraktives Ziel sein.
2. Gewähren Sie das Privileg „Replik in Domäne hinzufügen/entfernen“ einem kompromittierten regulären Benutzer, einer Gruppe oder einer bekannten Entität. Wir haben „Authentifizierte Benutzer“ verwendet, damit ein Angreifer jedes reguläre Benutzerkonto kompromittieren und die Dominanz über die Domäne wiedererlangen kann.
3. Gewähren Sie das „Write userAccountControl“-Privileg für das Computerobjekt derselben Entität wie im obigen Schritt.

Erstellen eines Computerkontos mit einem bekannten Passwort

Es scheint offensichtlich, aber nicht jeder kennt vielleicht die Möglichkeit, ein Computerkonto mit einem bekannten Passwort zu erstellen, indem man die Cmdlets New-ADComputer oder New-ADServiceAccount verwendet, zum Beispiel:

New-ADComputer „ComputerName“ -AccountPassword (ConvertTo-SecureString -AsPlainText -Force „Password“)

Das Kennen des Klartext-Passworts ist aus mehreren Gründen vorteilhaft. Am wichtigsten ist, dass wir die NTLM-, AES-128- und AES-256-Hashes mit den ConvertTo-NTHash- und ConvertTo-KerberosKey-Cmdlets aus Michael Grafnetters DSInternals PowerShell-Modul berechnen können. Wenn der Angreifer sich entscheidet, die Hintertür zu nutzen, muss er sich als Computerkonto authentifizieren, um dessen Privilegien zu nutzen, und wird dies mit der Overpass-the-Hash-Technik tun. Die Angabe der NTLM- und AES-Hashes umgeht die meisten Erkennungen von Overpass-the-Hash.

Wiedererlangung der Domain-Dominanz

Nachdem das Konto und die Berechtigungen vorbereitet wurden, benötigt der Angreifer, falls er den Zugang zu seinen administrativen Anmeldeinformationen verliert oder aus dem Netzwerk vertrieben wird, lediglich die Kompromittierung eines regulären Benutzers, um die Dominanz über das Domain wiederzuerlangen.

With any user account, the adversary only needs to modify the userAccountControl attribute of their staged computer to 0x2000 (8192). This modification also causes an immediate replication, which means that the adversary does not need to target specific domain controllers. Once the userAccountControl is complete, the adversary can use their domain controller privileges to compromise the domain.

Zum Beispiel könnte der Angreifer das Computerkonto nutzen, um DCSync durchzuführen und den Passwort-Hash von krbtgt zu kompromittieren. Da die Replikation scheinbar von einem Domain-Controller kommt, erkennen die meisten DCSync Bedrohungserkennungen die Aktivität nicht. Sobald sie das Geheimnis von krbtgt repliziert haben, können sie einfach userAccountControl zurück auf 0x1000 (4096) setzen und das Computerkonto wird wieder als normales Computerkonto erscheinen.

Automatisierung der Technik

Um das potenzielle Wirksamkeit dieser Methode zu demonstrieren, habe ich zwei neue PowerShell-Funktionen erstellt, die available on GitHub verfügbar sind.

Die erste Funktion, Add-ServerUntrustAccount, automatisiert die drei Einrichtungsschritte – das Erstellen eines gefälschten Computerkontos mit einem bekannten Passwort und das Gewähren der Berechtigungen „Authentifizierte Benutzer“ für „Replikat im Domain hinzufügen/entfernen“ und „userAccountControl schreiben“.

Die zweite Funktion, Invoke-ServerUntrustAccount, automatisiert die Ausnutzung der Hintertür und ist dafür vorgesehen, als nicht-privilegierter Benutzer ausgeführt zu werden. Die Funktion setzt das Attribut userAccountControl auf 0x2000 (8192), verwendet dann Pass-the-Hash, um sich als gefälschtes Computerkonto zu authentifizieren, führt ein DCSync der krbtgt-Hashes durch und setzt anschließend userAccountControl zurück auf 0x1000 (4096).

Entdeckung von Mechanismen und Erkennung von Exploitation

Um dies und andere ähnliche Mechanismen zu finden, sollten Organisationen regelmäßig sensible Active Directory-Berechtigungen prüfen. Das Überwachen (oder sogar Blockieren) von Änderungen an sensiblen Berechtigungen (wie das „Hinzufügen/Entfernen von Replikaten in der Domäne“) in Echtzeit ist ebenfalls vorteilhaft. Wir haben mehrere beliebte Open-Source-Tools zur Überwachung von Active Directory-Berechtigungen getestet und nur AD ACL Scanner hat die Berechtigungen unseres Gegners korrekt als problematisch hervorgehoben.

Active Directory-Ereignisprotokolle – insbesondere Ereignis-IDs 5136 und 4662 – ermöglichen eine grundlegende Echtzeitüberwachung von ACL-Änderungen und können verwendet werden, um das Domänenprivileg „Replik in Domäne hinzufügen/entfernen“ zu erkennen. Der Prozess zur Analyse dieser Ereignisse ist jedoch nicht einfach.

Darüber hinaus ist es wichtig, Computerkonten (sowie MSA- und gMSA-Konten), die veraltet sind oder nicht mit einem tatsächlichen Gerät im Netzwerk übereinstimmen, zu finden und zu entfernen. Zum Beispiel können Sie mit PowerShell schnell veraltete oder ungenutzte Computerkonten finden (ersetzen Sie „-90“ durch das maximale Alter eines Computerkontos in Ihrer Domäne):

$Date = [DateTime]::Today.AddDays(-90); Get-ADComputer -Filter ‘(Enabled -eq $true) -and (PasswordLastSet -le $Date)’ | Select Name

Erkennung von Ausnutzung

Die Erkennung des Einsatzes dieser Technik durch einen Gegner basiert auf der Überwachung von Änderungen am Attribut userAccountControl. Ereignis-ID 4742 – Computer Account Management kann verwendet werden, um Änderungen an userAccountControl-Werten zu überwachen. Jede Modifikation von userAccountControl mit dem gesetzten Bit 0x2000 außerhalb einer erwarteten Domaincontroller-Promotion ist bedenklich.

Abschließend

Obwohl offensichtlich nicht so schwerwiegend wie eine kritische Schwachstelle, bleiben solche Techniken in Unternehmen häufig unentdeckt und können die Arbeit eines Incident Responders erheblich erschweren. Angesichts der niedrigen Erkennungsrate in den von uns getesteten Active Directory-Auditing-Tools halten wir dies für eine interessante Technik, die weniger bekannte Verhaltensweisen ausnutzt und leicht übersehen werden könnte. Wir freuen uns über Ihre Kommentare und Fragen und es wäre fahrlässig, wenn wir Sie nicht auf unseren Attack Catalog, hinweisen würden, wo Sie mehr darüber erfahren können, wie bestimmte Angriffe funktionieren.