Group Managed Service Account (GMSA) Passwortoffenlegung Active Directory: Warum automatische Rotation keine Sicherheitsgrenze ist

Group Managed Service Account (GMSA) Passwortoffenlegung Active Directory

Group Managed Service Account (GMSA) Passwortoffenlegung Active Directory zählt zu den folgenreichsten Lücken, die EtcSec bei der Hygiene von Dienstkonten sieht, weil das dabei exponierte Konto oft genau jenes ist, das alle für von Natur aus sicher hielten. Ein Group Managed Service Account (gMSA) ist Microsofts Lösung für eines der ältesten Probleme in Active Directory: statische, menschlich bekannte Dienstkonto-Passwörter, die jahrelang unverändert in Skripten, geplanten Tasks und Konfigurationsdateien liegen. Der Domain Controller generiert ein 256 Byte langes Zufallspasswort und rotiert es automatisch — standardmäßig alle 30 Tage —, sodass kein Administrator es jemals eintippt oder irgendwo speichert (Microsoft Learn — Manage Group Managed Service Accounts). Das ist das Versprechen, und für sich genommen hält es auch.

Was diese Exposition trotzdem verursacht, ist kein geleaktes Passwort — es ist eine zu weit gefasste Liste von Principals, die es lesen dürfen. „Niemand kennt das Passwort" gilt nur so lange, wie die Liste derer, die es abrufen dürfen, eng gehalten wird — und diese Liste wird von einem einzigen Attribut gesteuert, das weit häufiger zu breit bleibt, als Verteidiger erwarten.

Wofür ein gMSA Gedacht Ist

Dienste, die identisch über eine lastverteilte Serverfarm laufen — IIS-App-Pools, geplante Tasks, Windows-Dienste — benötigen einen Principal, der sich auf jedem Host gleich verhält, damit Kerberos-Mutual-Authentication funktioniert. Ein gMSA bietet das, ohne ein geteiltes, manuell synchronisiertes Passwort: Jeder Host mit Abrufrechten holt sich das aktuelle Passwort direkt von AD über LDAP, sobald der Dienst es benötigt (Microsoft Learn).

Warum die Leserechte-Liste Trotzdem Exposition Schafft

Die Lücke zeigt sich in der Praxis auf zwei Arten: Eine für den gMSA erstellte Sicherheitsgruppe wird für etwas Unabhängiges wiederverwendet und sammelt über die Zeit still neue Mitglieder an, oder die Gruppe wird bei der Einrichtung in eine breitere, bereits bestehende Admin-Gruppe verschachtelt, weil das der schnellste Weg war, den Dienst zum Laufen zu bringen. Beide Wege lassen die Leserliste breiter als die ein oder zwei Hosts, die sie tatsächlich brauchen — und anders als eine normale Prüfung privilegierter Gruppen wird diese ACL nicht im selben Rhythmus überprüft wie Gruppenmitgliedschaften.

Wie Es Funktioniert: PrincipalsAllowedToRetrieveManagedPassword

Das Attribut msDS-GroupMSAMembership

Beim Erstellen eines gMSA legen Sie fest, welche Computerkonten oder Sicherheitsgruppen dessen Passwort abrufen dürfen:

New-ADServiceAccount -Name svc-app01 -DNSHostName svc-app01.corp.local `
  -PrincipalsAllowedToRetrieveManagedPassword "SG-App01-Hosts"

Dieser Parameter schreibt in msDS-GroupMSAMembership, ein Attribut, das einen Security Descriptor im Format String(NT-Sec-Desc) enthält — eine base64-kodierte ACL, die nicht direkt gelesen werden kann. PrincipalsAllowedToRetrieveManagedPassword ist der freundliche PowerShell-Wrapper, den AD zum Lesen und Schreiben bereitstellt (Microsoft Learn — Set-ADServiceAccount); die Mechanik des rohen Attributs ist im Detail bei DSInternals und in der InternalAllTheThings-gMSA-Referenz dokumentiert.

Wer dort gelistet ist, kann das Attribut msDS-ManagedPassword abfragen, das AD bei jedem Lesevorgang neu berechnet und als MSDS-MANAGEDPASSWORD_BLOB mit dem aktuellen Klartext-Passwort zurückgibt. Entscheidend: Das ist keine Prüfung auf Basis privilegierter Gruppen — Domain Admins erhalten keinen impliziten Zugriff. Nur die in msDS-GroupMSAMembership explizit genannten Principals können das Passwort lesen, wer auch immer das im Einzelfall ist (DSInternals).

Wie Die Liste Zu Breit Wird

Es gibt keine eingebaute Warnung, wenn PrincipalsAllowedToRetrieveManagedPassword über seinen ursprünglichen Umfang hinauswächst. Eine „vorübergehend" während einer Migration hinzugefügte Gruppe, eine von der Delegation einer übergeordneten OU geerbte verschachtelte Mitgliedschaft oder eine verschachtelte Admin-Gruppe, die hinzugefügt wurde, weil sie bereits die richtigen Computerkonten enthielt — jedes davon erweitert still, wer sich als das Dienstkonto ausgeben kann, ohne eine entsprechende Änderung am gMSA-Objekt selbst, die bei einer Routineprüfung auffallen würde. Das ist dieselbe Problemklasse wie in ACL-Missbrauch und DCSync: eine Berechtigung, an deren Vergabe sich niemand erinnert, immer noch gültig, immer noch ausnutzbar.

Die Angriffskette: Von Einer Zu Breiten Gruppe Zur Vollständigen Identitätsübernahme

Ein Realer Fall: Der Citrix-gMSA In Domain Admins

Sean Metcalfs Bericht auf ADSecurity.org dokumentiert einen konkreten Fall dieses Musters: Ein Citrix-gMSA, das selbst Mitglied von Domain Admins war, hatte seine Passwort-Abrufrechte an eine Gruppe namens „Citrix04" delegiert — die bei näherer Betrachtung ein gewöhnliches Benutzerkonto enthielt. Die Kompromittierung dieses einen Benutzerkontos reichte aus, um das Passwort eines Domain-Admin-äquivalenten gMSA abzugreifen (ADSecurity.org — GMSA Security Tip #14).

Das Passwort Lesen, Sobald Man Auf Der Liste Steht

Sobald ein Principal auf der Liste der berechtigten Leser steht, erfordert das Extrahieren des Passworts keinen Exploit — nur einen Lesevorgang:

# Mit den Modulen AD + DSInternals
$gmsa = Get-ADServiceAccount -Identity "svc-app01" -Properties 'msDS-ManagedPassword'
$blob = ConvertFrom-ADManagedPasswordBlob $gmsa.'msDS-ManagedPassword'
ConvertTo-NTHash -Password $blob.SecureCurrentPassword

Get-ADServiceAccount liefert den Blob, ConvertFrom-ADManagedPasswordBlob (DSInternals) dekodiert ihn in das aktuelle und das vorherige Klartext-Passwort, und ConvertTo-NTHash leitet den NT-Hash für die Offline-Nutzung ab (DSInternals). Tools wie GMSAPasswordReader.exe und gMSADumper.py automatisieren denselben LDAP-Lesevorgang remote, ohne den Zielhost je zu berühren.

Genau diese Beziehung bildet BloodHounds ReadGMSAPassword-Edge ab: jeder Benutzer, jede Gruppe oder jeder Computer mit Abrufrechten auf einen gMSA. SpecterOps dokumentiert drei Missbrauchspfade, sobald diese Edge vorliegt — das Token des gMSA stehlen oder injizieren, falls er bereits auf einem berechtigten Host angemeldet ist, einen Task oder Dienst planen, der auf einem berechtigten Host als gMSA läuft, oder das Passwort remote abrufen und den resultierenden NT-Hash für Overpass-the-Hash nutzen (BloodHound — ReadGMSAPassword). Keiner dieser Wege erfordert, dass die automatische Rotation des gMSA fehlschlägt — Rotation bedeutet lediglich, dass der Angreifer das Passwort nach jedem Zyklus erneut liest, genau wie ein berechtigter Host es auch tut.

Erkennung

Windows-Event-IDs Zum Korrelieren

Diese Event-IDs und der Korrelationsansatz (Abgleich von 4662, 2946 und 4624 über die Logon-ID innerhalb eines kurzen Zeitfensters) sind in TrustedSecs Bericht zur Jagd auf gMSA-Missbrauch dokumentiert (TrustedSec — Splunk SPL Queries for Detecting GMSA Attacks). Ohne SACL auf dem gMSA-Objekt wird 4662 nie ausgelöst — Auditing muss pro Objekt bewusst aktiviert werden.

Die Leserliste Direkt Auditieren

Log-basierte Erkennung erfasst einen Lesevorgang erst, nachdem er stattgefunden hat. Auditieren Sie stattdessen die Autorisierungsliste direkt und domänenweit, statt auf ein Ereignis zu warten:

Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword |
  Select-Object Name, PrincipalsAllowedToRetrieveManagedPassword

Führen Sie das gegen jeden gMSA in der Domäne aus und expandieren Sie jede zurückgegebene Gruppe — ein einzelner Sicherheitsgruppenname kann ein veraltetes Benutzerkonto, eine zu breite OU-basierte Gruppe oder eine verschachtelte privilegierte Gruppe verbergen, die nie Abrufrechte hätte haben sollen.

Behebung (Remediation)

1. Erfassen Sie jeden gMSA und seine Leser mit der obigen Abfrage. Expandieren Sie die Gruppenmitgliedschaft, nicht nur den obersten Principal-Namen — genau hier verbirgt sich die Citrix04-artige Überraschung.
2. Beschränken Sie PrincipalsAllowedToRetrieveManagedPassword auf genau die Hosts, die es brauchen. Nutzen Sie Set-ADServiceAccount -Identity <gMSAName> -PrincipalsAllowedToRetrieveManagedPassword <enge-Gruppe>, um eine zu breite Gruppe durch eine zu ersetzen, die auf die konkreten Computerkonten beschränkt ist, die den Dienst ausführen (Microsoft Learn — Set-ADServiceAccount).
3. Verifizieren Sie vor und nach der Änderung, dass nichts kaputtgeht, mit Test-ADServiceAccount -Identity <gMSAName> auf jedem Host, der Zugriff behalten soll (Microsoft Learn — Manage Group Managed Service Accounts).
4. Verschachteln Sie eine gMSA-Leser-Gruppe niemals in eine breitere Admin-Gruppe, um bei der Einrichtung einen Schritt zu sparen — genau diese Verschachtelung führt dazu, dass eine einzige Gruppe die Passwort-Abrufrechte für Konten steuert, für die sie nie gedacht war. Siehe Gefährliche Gruppenverschachtelung dazu, wie transitive Mitgliedschaft Pfade schafft, die Verteidiger nicht erwarten.
5. Wenn der gMSA selbst in einer privilegierten Gruppe sitzt (Domain Admins oder gleichwertig), behandeln Sie das als zusätzlichen, eigenständigen Befund — zu breite Passwort-Leserechte bei einem Mitglied einer privilegierten Gruppe sind ein schnellerer Weg zu Domain Admin als jedes der beiden Probleme für sich. Das ist etwas anderes als reine Hygiene bei privilegierter Gruppenmitgliedschaft, behandelt in Active Directory Privileged Accounts: Protected Users, Delegation und Service-Account-Lücken.
6. Aktivieren Sie Directory-Service-Access-Auditing (SACL) auf gMSA-Objekten, damit 4662-Ereignisse für die wichtigsten Konten tatsächlich generiert werden, statt die Lücke erst während eines Incidents zu entdecken.

Wie EtcSec Dies Erkennt

EtcSecs GMSA_PASSWORD_READERS-Check markiert gMSA-Objekte, bei denen PrincipalsAllowedToRetrieveManagedPassword einen Principal enthält, der breiter ist als der erwartete Host-Umfang — Benutzerkonten, generische Sicherheitsgruppen oder verschachtelte Mitgliedschaften, die das Passwort nicht abrufen können sollten. Er wird ergänzt durch GMSA_OLD_PASSWORD, das gMSAs markiert, deren verwaltetes Passwort nicht planmäßig rotiert wurde, und DANGEROUS_GROUP_NESTING, das das Muster der transitiven Mitgliedschaft erfasst, das die Überbreite meist erst verursacht.

Verwandte Lektüre: Kerberoasting Detection Prevention Guide behandelt den SPN-basierten Angriff, gegen den gMSAs weitgehend immun sind (kein knackbares Ticket, da das Passwort aus 256 Byte Zufallsdaten besteht) — nützlicher Kontext dafür, warum die Einführung von gMSAs das Risiko bei Dienstkonten nicht beseitigt, sondern nur auf diese ACL verlagert. BadSuccessor dMSA Privilege Escalation behandelt einen verwandten, aber eigenständigen Eskalationspfad bei verwalteten Konten über delegierte MSAs.