Golden dMSA: Was ist die Umgehung der dMSA-Authentifizierung?

Wichtigste Ergebnisse

• Der Semperis-Sicherheitsforscher Adi Malyanker fand einen kritischen Designfehler in delegierten verwalteten Dienstkonten (dMSAs), die mit Windows Server 2025 eingeführt wurden.
• Da die Schwachstelle die Brute-Force-Generierung von Passwörtern stark vereinfacht, ist die Ausnutzung der Schwachstelle wenig komplex.
• Der Golden dMSA-Angriff ermöglicht es Angreifern, die Authentifizierung zu umgehen und Passwörter für alle dMSAs und gMSAs und die zugehörigen Dienstkonten zu generieren.
• Die Erkennung von Golden dMSA-Aktivitäten erfordert eine manuelle Protokollkonfiguration und -prüfung, was eine Schadensbegrenzung erschwert.
• Die Forscher von Semperis stufen diese Sicherheitslücke als MÄSSIG ein, da Angreifer einen KDS-Root-Schlüssel besitzen müssen, der nur den privilegiertesten Konten zur Verfügung steht: Root Domain Admins, Enterprise Admins und SYSTEM.
• Dieser Angriff kann jedoch große Auswirkungen haben, da er domänenübergreifende Seitwärtsbewegungen und dauerhaften Zugriff auf alle verwalteten Dienstkonten und deren Ressourcen ermöglicht.

Windows Server 2025 von Microsoft bietet bedeutende Sicherheitsinnovationen, darunter die Einführung von delegierten verwalteten Dienstkonten (dMSAs), die die Verwaltung von Dienstkonten revolutionieren sollen. Im Gegensatz zu statischen, kennwortbasierten Konten, die Kerberoasting-Angriffen zum Opfer fallen können, binden dMSAs die Authentifizierung direkt an autorisierte Rechner in Active Directory (AD).

Dieser maschinenzentrierte Ansatz verhindert den Diebstahl von Anmeldeinformationen, da die Authentifizierung an die Geräteidentität und nicht an vom Benutzer verwaltete Passwörter gebunden ist. Nur ausdrücklich autorisierte Geräte können auf die dMSA zugreifen.

Dieser Artikel enthüllt einen neuen Angriff gegen delegierte Managed Service Accounts, den sogenannten Golden DMSA-Angriff. Die Technik ermöglicht es Angreifern, die vorgesehene maschinengesteuerte Authentifizierung zu umgehen und Kennwörter für alle zugehörigen dMSAs offline zu generieren.

Was ist Golden dMSA?

Golden dMSA ist eine Persistenz- und Privilegien-Eskalationsmethode, die es Angreifern ermöglicht, Passwörter für alle dMSAs - und Group Managed Service Accounts (gMSAs) - und die zugehörigen Dienstkonten zu generieren.

Der Angriff nutzt einen kritischen Designfehler aus: Eine Struktur, die für die Berechnung der Passwörter verwendet wird, enthält vorhersehbare zeitbasierte Komponenten mit nur 1.024 möglichen Kombinationen, was die Brute-Force-Passwortgenerierung rechnerisch trivial macht.

Dieser Angriff kann sowohl zur Persistenz als auch zur Privilegienerweiterung in jeder AD-Umgebung mit dMSA-Konten genutzt werden. Semperis stuft diese Schwachstelle als mittleres Risiko ein, da ihre Ausführung von einer teilweisen Kompromittierung des Forest abhängt.

Lesen Sie weiter, um zu erfahren, wie wir die Sicherheitslücke aufgedeckt haben, die Golden dMSA ermöglicht, welche Details wir hinter dem Designfehler gefunden haben,
und wie Sie die Umgehung der Authentifizierung erkennen und abschwächen können.

Wie funktioniert ein Golden dMSA-Angriff?

Nachdem ein Angreifer erhöhte Privilegien innerhalb einer Domäne erlangt hat, kann er systematisch alle dMSA- und gMSA-Konten durch einen unkomplizierten Vier-Phasen-Angriff kompromittieren.

Phase 1: Extrahieren von KDS-Root-Schlüsselmaterial (Voraussetzung für den Angriff). Der Angreifer entwendet kryptografisches Material aus dem Stammschlüssel der Key Distribution Services (KDS) - der Grundlage für alle Passwörter für verwaltete Dienstkonten.

Phase 2: Aufzählung der dMSA-Konten. In Phase 1 hat der SYSTEM- oder Domänen-Admin-Benutzer nicht die Berechtigung, dMSAs in anderen Domänen aufzuzählen. In dieser zweiten Phase versucht der Angreifer, mit roher Gewalt oder unter Verwendung von LDAP Daten wie sAMAccountName Attribute und Sicherheitskennungen (SIDs) auf dMSA-Konten in der AD-Gesamtstruktur.

Phase 3: Erraten der ManagedPasswordID. Als nächstes versucht der Angreifer, den richtigen ManagedPasswordId Attribute und Passwort-Hashes durch gezieltes Erraten.

Phase 4: Generierung von Passwörtern. Mit speziellen Tools wie GoldenDMSA kann der Angreifer gültige Passwörter für jede gMSA oder dMSA generieren, die mit dem kompromittierten Schlüssel verbunden ist.

Dieses Verfahren erfordert keinen zusätzlichen privilegierten Zugriff, sobald der KDS-Root-Schlüssel erlangt wurde, was es zu einer besonders gefährlichen Persistenzmethode macht.

Der Angriff verdeutlicht die kritische Vertrauensgrenze von verwalteten Dienstkonten. Sie sind für ihre Sicherheit auf kryptografische Schlüssel auf Domänenebene angewiesen. Obwohl die automatische Kennwortrotation einen ausgezeichneten Schutz gegen typische Angriffe mit Anmeldeinformationen bietet, können Domänenadministratoren, DnsAdmins und Print Operators diese Schutzmaßnahmen vollständig umgehen und alle dMSAs und gMSAs im Forest kompromittieren.

Was sind dMSAs? Eine kurze Geschichte des Servicekontos

Jahrzehntelang haben Windows-Administratoren normale Domänenkonten verwendet, um Dienste auszuführen - ein funktionaler, aber fehlerhafter Ansatz, der sich mit der Einführung von Dienstkonten weiterentwickelt hat. Im Gegensatz zu interaktiven Benutzerkonten, die tatsächliche Personen repräsentieren, dienen Dienstkonten lediglich dazu, einen Identitätskontext für automatisierte Prozesse bereitzustellen.

Die ersten Servicekonten basierten auf statischen Passwörtern, die einen Albtraum für den Betrieb darstellten. Die Koordinierung von Passwortänderungen über mehrere Teams, Dienste und Anwendungen hinweg führte oft zu Ausfällen und Widerstand gegen bewährte Sicherheitsverfahren.

Schlimmer noch, statische Passwörter ermöglichten verheerende Angriffe. Kerberoasting-Angriffe ermöglichten es Angreifern, Service-Tickets anzufordern und Passwörter offline zu knacken, während schwache oder unveränderte Anmeldedaten leichte Ziele für die Ausweitung von Privilegien boten.

Seitdem hat Microsoft verschiedene Versionen von Dienstkonten entwickelt.

• Verwaltete Dienstkonten (MSAs). Windows Server 2008 R2 führte die automatische Rotation des 240-Zeichen-Kennworts alle 30 Tage zusammen mit der automatischen Verwaltung von Dienstprinzipalnamen (SPN) ein. Der Haken an der Sache? MSAs sind auf einzelne Rechner beschränkt.
• Gruppenverwaltete Dienstkonten (gMSAs). Windows Server 2012 löste die Beschränkung auf mehrere Maschinen, indem es gemeinsame Dienstidentitäten über Cluster, Load Balancer und verteilte Dienste hinweg ermöglichte und gleichzeitig die Sicherheitsvorteile der MSAs beibehielt.
• Delegierte verwaltete Dienstkonten (dMSAs). Die neueste Innovation von Windows Server 2025 geht von der zentralen Kennwortverwaltung zur maschinengebundenen Authentifizierung über und stellt eine grundlegende Veränderung der Sicherheit von Dienstkonten dar.

Diese Entwicklung von traditionellen Konten zu gMSA zu dMSA schafft eine interessante Angriffsfläche - eine, die die Golden dMSA-Technik ausnutzt, indem sie die gemeinsame kryptografische Grundlage von gMSA- und dMSA-Systemen nutzt.

Wie Angreifer dMSAs finden: Das Durchbrechen der Unsichtbarkeitsbarriere

Aus der Sicht eines Angreifers ist die Fähigkeit, dMSAs als unprivilegierter Benutzer aufzuzählen, entscheidend für die Ausweitung von Privilegien und für Seitwärtsbewegungen. Um ein dMSA-Passwort zu erhalten, müssen Sie dessen Namen und SID kennen.

Eine der faszinierendsten Herausforderungen beim Umgang mit dMSAs ist es jedoch, diese schwer fassbaren Konten überhaupt erst einmal zu finden.

Gemäß der Microsoft-Dokumentation beginnen wir bei der Erstellung von dMSAs mit der Datei CreateDelegatedServiceAccount Befehl, der Abbildung 1 zeigt.

Jetzt kommt der spaßige Teil. Lassen Sie uns versuchen, unser neu erstelltes DMSA-Demo-Konto mit Get-ADServiceAccount (Abbildung 2).

Hier stoßen wir auf unsere erste Hürde. Ein privilegierter Benutzer kann das Konto problemlos einsehen, aber ein nicht privilegierter Benutzer erhält absolut nichts - leere Ergebnisse(Abbildung 3). Und warum? Es liegt an den Standardeinstellungen in den Zugriffskontrolllisten (ACLs) des Kontos. Und glauben Sie mir, kein Administrator möchte daran herumpfuschen.

Haben Sie in Abbildung 4 etwas Verdächtiges bemerkt? Sowohl authentifizierte Benutzer als auch "Jeder" sind vom Lesen der Daten auf diesen Konten vollständig ausgeschlossen.

Wie um alles in der Welt kann also ein nicht privilegierter Benutzer auf Informationen über dMSA-Konten zugreifen?

Hier beginnt die Detektivarbeit. Nach unzähligen Untersuchungen und Fehlversuchen habe ich entdeckt, dass wir eine Liste potenzieller SIDs erstellen und jede einzelne in NTAccount-Objekte übersetzen können. (Ich habe für diesen Zauber C# verwendet.)

Unter der Haube nutzt die Funktion translate diese leistungsstarken Win32-APIs: LsaOpenPolicy und LsaLookupSids (Abbildung 5).

Die Namen der Funktionen verraten ihren Zweck, aber Abbildung 6 zeigt die offizielle Dokumentation von Microsoft, um dies zu verdeutlichen.

Interessant ist, dass ein Impacket-Tool namens lookupsid¹ verwendet genau die gleiche Technik, indem es die hLsarOpenPolicy2 und hLsarLookupSids um die SIDs aufzuzählen.

Und jetzt kommt der spannende Teil: Schauen wir uns an, was passiert, wenn wir diese Win32-Funktionen freischalten(Abbildung 7).

Jackpot! Wir haben jedes einzelne Konto in der Domäne abgerufen, sowie weitere Objekte mit SIDs.

Diese Methode ist erfolgreich, weil sie LDAP komplett umgeht und diese restriktiven ACLs effektiv umgeht. Hier ist die technische Schönheit: LsaLookupSids und LsaOpenPolicy stützen sich überhaupt nicht auf LDAP. Stattdessen kommuniziert das LSA-Protokoll über \PIPE\lsarpc als RPC-Endpunkt über SMB.

Aber halt - wie können wir erkennen, welche Konten in dieser riesigen Liste dMSAs sind?

Jetzt kommt der clevere Teil: Wir kennzeichnen alle Konten, die mit $ enden, als verdächtig. Dann eliminieren wir systematisch Maschinenkonten und gMSAs.

Voilà! Wir verfügen nun über ein vollständiges Inventar aller dMSAs in der Domäne.

Der Clou: Diese Technik funktioniert auch über Domänengrenzen hinweg! Wir können dMSAs aus anderen Domänen mit genau derselben Methode aufzählen.

Hier ist eine zusätzliche Entdeckung.

Dank meiner Kollegen Andrea Pierini und Shai Laronne haben wir einen alternativen LDAP-basierten Ansatz entdeckt(Abbildung 8).

Der Clou? Wenn wir die Suche direkt vom Container aus starten, können wir nach diesen spezifischen Kontotypen suchen. In Kombination mit unserer vorherigen SID-Aufzählungsmethode können wir die SID-Informationen extrahieren und gleichzeitig gMSAs und Computerkonten herausfiltern(Abbildung 9).

Dieser duale Ansatz bietet uns mehrere Angriffsvektoren für die Entdeckung von dMSA - ein entscheidender Vorteil für jede Sicherheitsbewertung.

Warum ist der KDS-Stammschlüssel für Golden dMSA-Angriffe so wichtig?

Der KDS-Stammschlüssel wurde erstmals in Windows Server 2012 eingeführt und ist das Kronjuwel der gMSA-Infrastruktur von Microsoft. Betrachten Sie ihn als das kryptografische Superhirn hinter Microsofts Key Distribution Service, der Maschine, die Passwörter für gMSAs generiert und verteilt.

Die Erlangung dieses Root-Schlüssels ist der entscheidende erste Schritt in der Angriffskette, da er es Angreifern ermöglicht, die Passwörter für jeden gMSA in der Domäne offline zu berechnen. Diese Fähigkeit ist verheerend, denn gMSAs sind so konzipiert, dass ihre Passwörter automatisch vom Domain Controller (DC) rotiert werden, was sie für Administratoren sicher erscheinen lässt. Mit dem KDS-Root-Schlüssel in der Hand kann ein Angreifer jedoch das aktuelle Passwort für jedes gMSA-Konto mathematisch ableiten, ohne jemals wieder eine Verbindung zum DC herzustellen.

Das macht ihn so mächtig: Der KDS-Stammschlüssel fungiert als der ultimative Hauptschlüssel. Von ihm werden alle gMSA-Passwörter durch einen eleganten Schlüsselableitungsprozess abgeleitet.

Aber das ist noch nicht alles. Microsoft hat kürzlich den KDS-Root-Schlüssel erweitert, um dMSA-Konten zu kontrollieren.

Jetzt ist der KDS-Root-Schlüssel für Angreifer doppelt so wertvoll, da er sowohl gMSA- als auch dMSA-Passwörter freischaltet.

Der KDS-Stammschlüssel befindet sich in der Regel auf dem Stamm-DC des Forests - dem am besten geschützten Bereich in AD. Microsoft hat hier nicht mit der Sicherheit herumgespielt. Die ACLs für diese Schlüssel sind unglaublich restriktiv(Abbildung 10) und beschränken den Zugriff nur auf die privilegiertesten Konten: Root Domain Admins, Enterprise Admins und SYSTEM.

Trotz dieser eisernen Beschränkungen können diese wertvollen Schlüssel immer noch von anderen DCs im gesamten Forest abgerufen werden, allerdings nur mit Zugriff auf SYSTEM-Ebene(Abbildung 11).

An dieser Stelle könnten Sie denken, dass SYSTEM-Berechtigungen auf einem DC die Angreifbarkeit von Golden dMSA verringern. Es handelt sich jedoch um einen einzelnen DC aus dem gesamten Forest und der Angriffsfluss verändert die Bedrohungslandschaft grundlegend von einer lokalen Kompromittierung zu einer fortwährenden Hintertür im gesamten Forest.

Das bedeutet, dass der SYSTEM-Zugriff auf einen DC zwar bereits eine erhebliche Sicherheitslücke darstellt, die Golden dMSA-Technik diese Lücke jedoch in eine viel gefährlichere und dauerhaftere Bedrohung verwandelt, indem sie es dem Angreifer ermöglicht, dauerhaften Zugriff auf gMSAs, dMSAs und die zugehörigen Dienstkonten im gesamten Forest aufrechtzuerhalten, ohne dass er weiterhin auf dem kompromittierten DC präsent sein muss.

Achten Sie genau auf dieses wichtige Detail: KDS-Root-Schlüssel haben kein Verfallsdatum

Microsoft empfiehlt, nur einen KDS-Stammschlüssel pro Umgebung zu verwalten.

Rechnen Sie mal nach. Theoretisch könnte ein Angreifer nach der Kompromittierung eines einzigen KDS-Stammschlüssels unbegrenzt Passwörter für alle zukünftigen dMSA- und gMSA-Konten generieren.

Bei meinen Nachforschungen habe ich etwas noch Faszinierenderes entdeckt. Selbst in Umgebungen mit mehreren KDS-Stammschlüsseln verwendet das System aus Kompatibilitätsgründen stets den ersten (ältesten) KDS-Stammschlüssel. Das bedeutet, dass der ursprüngliche Schlüssel, den wir kompromittiert haben, durch Microsofts Design erhalten bleiben könnte - eine dauerhafte Hintertür, die über Jahre hinweg bestehen bleiben könnte.

Diese architektonische Entscheidung verwandelt eine einzelne erfolgreiche Schlüsselextraktion in einen langfristigen strategischen Vorteil für Angreifer und macht den KDS-Stammschlüssel zu einem der wertvollsten Ziele in jeder Windows-Domäne.

Den Code knacken: Von der gMSA zur dMSA-Passwortgenerierung

Jetzt tauchen wir in den Kern des Angriffs ein - wir extrahieren die dMSAs ManagedPasswordId Attribut.

ManagedPasswordId ist ein im AD gespeichertes Attribut, das die Metadaten enthält, die zur Ableitung des aktuellen Passworts eines MSA benötigt werden. Wir müssen dieses Attribut erfassen, da es die wesentlichen kryptographischen Parameter enthält - einschließlich der Schlüsselkennung, des Erstellungszeitpunkts und anderer Details zur Ableitung -, die zusammen mit dem KDS-Stammschlüssel das aktuelle Passwort der gMSA mathematisch berechnen.

Wenn Ihnen das bekannt vorkommt, haben Sie völlig recht. Yuval Gordons großartige Forschung über gMSA Active Directory Angriffe hat die Welt mit Goldene gMSA. Diese Angriffstechnik beinhaltet das Extrahieren des KDS-Stammschlüssels aus dem AD, das Abfragen der verfügbaren gMSAs zusammen mit ihrer SID und ManagedPasswordId Attribute und die Berechnung von Passwörtern aus den Daten.

Als ich Golden dMSA untersuchte, war meine Hypothese einfach, aber überzeugend: Microsoft könnte für die Erstellung und Erneuerung von Kennwörtern denselben Code von gMSA zu dMSA recycelt haben. Aber konnten wir den Golden gMSA-Angriff auf dMSA-Konten tatsächlich reproduzieren?

Hier stoßen wir auf unser erstes großes Hindernis. Die restriktiven ACLs, die wir vorhin entdeckt haben, blockieren das Lesen dieser wichtigen Daten auf dMSA-Konten vollständig. Wir mussten tiefer graben und unseren Algorithmus erweitern.

Reverse Engineering der ManagedPasswordId-Struktur

Um dieses Rätsel zu lösen, habe ich begonnen, die ManagedPasswordId Struktur selbst. Ich habe ein neues dMSA-Konto erstellt und dessen Daten extrahiert. ManagedPasswordID Attribut.

Nachdem ich das Byte-Array analysiert und über verschiedene Instanzen hinweg verglichen hatte, stellte ich fest, dass es die in Abbildung 12 gezeigten Komponenten enthält.

Diese Struktur kam mir bekannt vor. Sie ist praktisch identisch mit der von gMSA ManagedPasswordID Format (Abbildung 13).

Abbildung 14 zeigt die vollständige Aufschlüsselung dieser Struktur mit diesen Schlüsselkomponenten:

• Version: Ganzzahliger Wert mit Dezimalwert (1,0,0,0)
• Reserviert: Ganzzahliger Wert mit Dezimalwert von (75, 68, 83, 75)
• isPublicKey: Integer-Wert mit Dezimalwert (2,0,0,0)
• L0Index: Ganzzahliger Wert, der eine Zeitvariable repräsentiert (wir werden das später noch genauer untersuchen)
• L1Index: Ganzzahliger Wert, der eine Zeitvariable repräsentiert (wir werden das später noch genauer untersuchen)
• L2Index: Ganzzahliger Wert, der eine Zeitvariable repräsentiert (wir werden das später noch genauer untersuchen)
• RootKeyIdentifier: GUID-Wert, der aus der ID des KDS-Stammschlüssels gebildet wird.

Der Bereich der RootKeyIdentifier kann aus den KDS-Stammschlüsseln konstruiert werden (RKL ist die KDS-Stammschlüssel-ID, d.h. f06c3c8d-b2c2-4cc6-9a1a-8b3b3c82b9f0), als Abbildung 15 zeigt.

• cbUnknown: Ganzzahliger Wert mit Dezimalwert (0, 0, 0, 0)
• cbDomainName: Ganzzahliger Wert, der (Länge des Domänennamens * 2) + 2 entspricht.
• cbForestName: Ganzzahliger Wert, der (Länge des Waldnamens * 2) + 2 entspricht.
• Domänenname: Domänenname des dMSA-Kontos in diesem speziellen Format
• WaldName: Waldname des dMSA-Kontos in diesem speziellen Format

Beachten Sie etwas in der cbDomainName und cbForestName: Wir multiplizieren mit 2 und addieren 2, da zwischen jedem Zeichen ASCII-Bytes mit dem Wert 0 eingefügt werden. So wird aus root.test r.o.o.t…t.e.s.t.. in der eigentlichen Struktur.

Durch das Studium der Microsoft Learn Artikel über msDS-ManagedPassword und der Microsoft KDS Provider KdsCli.dll (die den größten Teil der Kennwortlogik implementiert), habe ich den Fluss von der GetgMSAPasswordBlob(), als Abbildung 16 zeigt.

Die Logik ist elegant. Wenn die ManagedPasswordId nicht existiert oder abläuft, legt das System eine neue Startzeit fest und ruft GetPasswordBasedOnTimestamp(), als Abbildung 17 zeigt.

Dies bringt uns zu einer der wichtigsten Beobachtungen unserer Forschung. Die L0-, L1- und L2-Werte werden in GetIntervalID(), dann übergeben an GetKey() wenn Sie einen neuen BLOB-Schlüssel erstellen (Abbildung 18).

Bei dieser Beobachtung habe ich etwas Entscheidendes entdeckt: Die Werte von L1 und L2 sind auf 31 (einschließlich) begrenzt. Das ist nicht nur Theorie; es wird sowohl in der DLL (Abbildung 19) und Microsofts GetKey() Dokumentation (Abbildung 20).

Die GetPasswordBasedOnTimestamp() Methode wird auch aufgerufen, wenn eine Erneuerung der ManagedPasswordId ist erforderlich.

Die bahnbrechende Entdeckung

Jetzt kommt die entscheidende Enthüllung.

Wir können das meiste von dem vorhersagen, was die ManagedPasswordID Vektor, der für die Berechnung der gMSA- und dMSA-Passwörter benötigt wird. Wir wissen L1Index und L2Index sind an Werte gebunden, die wir mit roher Gewalt erhalten können. Die größte Herausforderung scheint zu sein L0Index, die als 4-Byte-Ganzzahl Milliarden von möglichen Werten haben kann.

Als ich den Algorithmus von Golden gMSA genauer untersuchte, fand ich heraus, dass er diese Objekte erzeugt:

• L0Key, die KDS-Stammschlüsselattribute (Abbildung 21)
• L0KeyId, berechnet aus der aktuellen Zeit
• GenerateKDFContext und GenerateDerivedKey, die sich ableiten L1Key und L2Key Byte-Vektoren einmal (Abbildung 21) oder ein paar Mal (Abbildung 22)

Hier ist die entscheidende Erkenntnis.

• L0Keyid, L1Keyid, und L2Keyid Werte sind vollständig zeitbasiert und benutzerunabhängig (wie Abbildung 19 oben zeigt).
• Der einzige vom Benutzer kontrollierte Wert ist der ManagedPasswordId Vektor selbst, den wir zusammen mit dem KDS-Stammschlüssel, den Domänen- und Waldnamen und der SID bereitstellen.

Hier hat alles geklickt. Als ich verfolgte, wo L0Index (aus dem ManagedPasswordId) tatsächlich in dem Algorithmus verwendet wird, fand ich die Enthüllungen, dass Abbildung 23 und Abbildung 24 zeigen.

Dies ist ein erstaunliches Detail. L0index überhaupt nicht verwendet wird, von der MsdsManagedPasswordId Vektor, was bedeutet, dass es keine Rolle spielt, welchen Wert wir verwenden.

Passwort erraten: Alles zusammengenommen

Wir können nun fast die gesamte ManagedPasswordId Vektor - der letzte Teil, der für die Vorhersage von gMSA- und dMSA-Passwörtern und Hashes benötigt wird. Da L0Index wird ignoriert, und L1Index und L2Index zwischen 0-31 (einschließlich) liegen muss, haben wir nur 32 × 32 = 1.024 mögliche Vektoren zu testen.

Ich habe diese Schlussfolgerung getestet, indem ich das korrekte Passwort und den NTLM-Hash für jeden Vektor berechnet und dann Pass the Hash-Angriffe mit dem ^smbclient2 von Impacket versucht habe(Abbildung 25).

Erfolgreich! Diese Methode hat bei gMSA-Konten perfekt funktioniert. Wir konnten ihre Hashes innerhalb von 1.024 Versuchen vorhersagen, ohne dass wir die spezifischen ManagedPasswordId.

Aber trotzdem konnte ich den Hash nicht mit dem Passwort-Hash von dMSA weitergeben. Außerdem mussten wir uns fragen, wie wir diesen Angriff ausnutzen können, wenn Pass the Hash-Angriffe in diesem Bereich abgeschwächt werden.

Nachdem ich die Attribute einer meiner dMSAs untersucht hatte, sah ich, dass sie eine Verbindung mit dem Kerberos-Verschlüsselungstyp AES 256 erfordert, wie Abbildung 26 zeigt. (Sie werden sich erinnern, dass ich bei der Erstellung einer dMSA der Empfehlung von Microsoft gefolgt bin, AES 256 zu erzwingen).

Ich habe versucht, aus dem Passwort des Dienstes einen AES 256-Hash zu erzeugen. Nach einigen anstrengenden Versuchen fand ich heraus, dass gMSAs und dMSAs ein leicht unterschiedliches Salt-Format für AES 256 Hashing verwenden:

<Domain name in UPPER case>host<user's full UPN in lower case (without $)>

Zum Beispiel:

ROOT.TESThostdmsa-demo8.root.test

Mit diesem Salzformat konnte ich endlich gültige Kerberos-Tickets für dMSA-Konten erzeugen.

Abbildung des Golden dMSA-Angriffsflusses

Das Diagramm in Abbildung 27 fasst den Golden dMSA-Angriff zusammen.

1. Beginnen Sie mit SYSTEM-Rechten auf einem der DCs in der Domäne oder mit Enterprise Admin-Rechten, um die KDS-Root-Schlüssel zu dumpen.
2. Erzwingen Sie die SIDs der dMSA-Konten oder verwenden Sie LDAP-Abfragen, um die Zielkonten zu identifizieren.
3. Erstellen Sie eine Wortliste mit allen 1.024 möglichen ManagedPasswordIds für diesen speziellen Benutzer.
4. Berechnen Sie das Passwort für jedes mögliche Paar (KDS-Stammschlüssel, ManagedPasswordIds) und den Hashwert in NTLM/AES256.
5. Testen Sie jeden Passwort-Hash mit den Techniken Pass the Hash oder Overpass the Hash.

Dieser Angriff verwandelt dMSA-Konten von scheinbar undurchdringlichen Zielen in überschaubare Brute-Force-Herausforderungen. Es sind nur 1.024 Versuche erforderlich, um ein beliebiges dMSA-Passwort in der Domäne zu knacken.

Wie ein Golden dMSA-Angriff die normale Authentifizierung umgeht

In der Dokumentation von Microsoft heißt es: "Das dMSA-Geheimnis kann nirgendwo anders als auf dem DC abgerufen oder gefunden werden", was einen grundlegenden Unterschied zwischen gMSA- und dMSA-Authentifizierungsmechanismen hervorhebt. Bei gMSAs ist der Prozess ganz einfach. Eine Entität authentifiziert sich und fordert direkt die Anmeldeinformationen (Passwort) der gMSA an und erhält dann das eigentliche Passwort für die Authentifizierung.

dMSAs arbeiten nach einem völlig anderen Prinzip. Sie müssen sich anhand der Identität des Rechners authentifizieren, um ein Ticket für den dMSA-Benutzer zu erhalten. Das Passwort der dMSA verlässt niemals den DC. Stattdessen wird es verwendet, um das Ticket zu verschlüsseln, das an den anfragenden Rechner zurückgeschickt wird.

Um Fälle zu vermeiden, in denen ein Angreifer den Hash des Rechners stiehlt und damit ein Ticket anfordert, empfiehlt Microsoft die Verwendung von Credential Guard. Diese Abschwächung schafft eine robuste Barriere, die die meisten Angriffe auf den Diebstahl von Anmeldeinformationen bereits im Ansatz stoppen sollte.

Aber hier ändert der Golden dMSA-Angriff alles. Golden dMSA umgeht die normalen Credential Guard-Schutzmaßnahmen vollständig(Abbildung 28). Wir halten uns nicht mehr an die normalen Authentifizierungsregeln.

Anstatt dem von Microsoft vorgesehenen Authentifizierungsablauf zu folgen, werden die dMSA-Anmeldedaten direkt mit dem kryptografischen Angriff verwendet(Abbildung 29). Dies bedeutet:

• Keine Rechneridentität erforderlich. Wir müssen den Host-Rechner nicht kompromittieren.
• Credential Guard wird irrelevant. Da wir keine Anmeldedaten des Computers stehlen, bietet dieser Schutz keinerlei Schutz.

Microsoft hat bestätigt, dass "ab dem Windows-Sicherheitsupdate vom April(KB5055523) die von Credential Guard geschützten Rechnerkonten in Windows Server 2025 und Windows 11, Version 24H2, vorübergehend deaktiviert sind. Diese Funktion wurde aufgrund eines Problems bei der Rotation von Maschinenkennwörtern mit Kerberos deaktiviert. Die Funktion bleibt deaktiviert, bis eine dauerhafte Lösung verfügbar ist."

Was ist das wahre Risiko von Golden dMSA? Waldweite Verwüstung

Sobald ein Angreifer ein dMSA-Konto mithilfe der Golden dMSA-Technik erfolgreich kompromittiert hat, beginnt der eigentliche Spaß. Hier geht es nicht nur darum, Zugang zu einem Dienstkonto zu erhalten. Es geht darum, diese Ausgangsposition für verheerende Seitwärtsbewegungen zu nutzen. Darüber hinaus können Angreifer mit dieser Technik Passwörter knacken und Berechtigungen von Dienstkonten erhalten, die sowohl eine Migration zu der kompromittierten dMSA begonnen als auch abgeschlossen haben.

Hier wird der Angriff aus der Sicherheitsperspektive wirklich erschreckend. Der Golden dMSA-Angriff ist nicht durch Domänengrenzen begrenzt. Er funktioniert auf der Ebene des Forest. Sobald wir den KDS-Root-Schlüssel einer einzelnen Domäne innerhalb des Forests kompromittiert haben, können wir systematisch jedes dMSA-Konto in allen Domänen dieses Forests angreifen und kompromittieren.

Das bedeutet, dass eine einzige erfolgreiche Extraktion des KDS-Root-Schlüssels sich in:

• Domänenübergreifende Kontokompromittierung. Keine Domänengrenzen können uns aufhalten.
• Waldweites Sammeln von Anmeldeinformationen. Jede dMSA in jeder Domäne wird angreifbar.
• Unbegrenzte seitliche Bewegung. Wir können mit kompromittierten dMSA-Konten nach Belieben zwischen Domänen wechseln.
• Dauerhafter Zugriff. Da die KDS-Schlüssel nicht ablaufen, kann dieser Zugriff auf unbestimmte Zeit erfolgen.

Der Angriff skaliert exponentiell. Was mit der Kompromittierung eines einzelnen DCs beginnt, führt dazu, dass jeder dMSA-geschützte Dienst in einem ganzen Unternehmensforest in die Hände der Angreifer gelangt. Es handelt sich nicht nur um eine Ausweitung der Privilegien. Es handelt sich um die unternehmensweite digitale Herrschaft durch eine einzige kryptografische Schwachstelle.

Was ist das Golden dMSA Tool?

Um zu erfahren, wie diese Angriffstechnik ausgenutzt wird, haben wir die Logik des Angriffs übernommen und in ein Tool namens ^GoldenDMSA3 integriert. Das Tool enthält die strukturellen Prinzipien des GoldenGMSA-Tools^.4

Ein Angreifer kann das GoldenDMSA-Tool verwenden, um alle gMSAs, dMSAs und die zugehörigen KDS-Root-Schlüssel aufzuzählen, mit Brute-Force-Angriffen die Passwörter zu erlangen und Tickets für die Konten zu erhalten. Ein Angreifer mit hohen Privilegien kann das GoldenDMSA-Tool auch verwenden, um die KDS-Root-Schlüssel auszulesen.

Um das Tool in Aktion zu demonstrieren, lassen Sie uns eine Ausnutzung zwischen Domänen in einem Forest betrachten.

Zunächst befindet sich der Angreifer in einer Domäne namens child.root.test (Abbildung 30) und versucht, dMSAs zu erhalten von root.test (Abbildung 31).

Dann muss der Angreifer eine Wortliste erstellen (Abbildung 32), die für die ManagedPasswordIds Brute-Force-Angriff.

Schließlich werden wir mit Hilfe der Wortliste einen Brute-Force-Angriff starten(Abbildung 33).

Das Passwort ist Base64-kodiert(Abbildung 34), da es nicht druckbare Zeichen enthalten könnte. Um die Gültigkeit des Tickets zu testen, habe ich einen neuen Benutzer erstellt - versteckt im Stamm-DC -, den nur das dMSA-Konto lesen kann. Wenn wir die Daten des Benutzers erfolgreich lesen können, wissen wir, dass unser generiertes Ticket gültig ist.

So erkennen Sie Golden dMSA: Entdeckung versteckter Indikatoren

Standardmäßig werden keine Sicherheitsereignisse protokolliert, wenn ein KDS-Stammschlüssel kompromittiert wird. Um Golden dMSA-Angriffe zu erkennen, müssen Verteidiger manuell eine Systemzugriffskontrollliste (SACL) für KDS-Stammschlüsselobjekte konfigurieren, um den Lesezugriff auf die msKds-RootKeyData Attribut.

Öffnen Sie dazu das Tool Active Directory Editor Interface (ADSI Edit) und:

• Wählen Sie den Benennungskontext Konfiguration
• Navigieren Sie zu Dienste und klicken Sie dann auf Group Key Distribution Service
• Wählen Sie Master Root Keys und klicken Sie mit der rechten Maustaste auf den entsprechenden KDS Root Key
• Gehen Sie zur Registerkarte Sicherheit, klicken Sie auf die Schaltfläche Erweitert
• Wählen Sie die Registerkarte Auditing und konfigurieren Sie eine Audit-Regel für den Lesezugriff auf Authentifizierte Benutzer/Alle

Wenn diese SACL in Kraft ist, löst jeder unbefugte Versuch, KDS-Root-Schlüsseldaten zu extrahieren, das Sicherheitsereignis 4662 auf dem DC aus (Abbildung 35). Dieses Ereignis zeigt einen Objekttyp von msKds-ProvRootKey und einen Kontonamen, der kein DC ist, was auf mögliche bösartige Aktivitäten hinweist.

Neuer DSP hilft bei der Erkennung von Golden dMSA

Wie Sie sehen können, ist die manuelle Erkennung einer Kompromittierung des KDS-Root-Schlüssels für die meisten Teams eine Herausforderung. Semperis hat ein neues Modul zum Schutz von Dienstkonten bereitgestellt, eine Erweiterung der Funktionen von Directory Services Protector DSP). Das Modul enthält einen Sicherheitsindikator namens KDS root key ACL was modified, der nach ACL-Änderungen an KDS-Root-Schlüsseln(Abbildung 36) sucht, die es Angreifern ermöglichen könnten, diese Schlüssel zu lesen und einen Golden dMSA-Angriff zu starten.

Weitere Anhaltspunkte, auf die Sie achten sollten

Darüber hinaus sollten die Verteidiger:

• Überwachen Sie das anormale Volumen von AS-REQ-Authentifizierungsanfragen die auf dasselbe Servicekonto abzielen (erkennbar an Konten, die mit $ enden), insbesondere wenn sie von PREAUTH-FAILED (Fehlercode 24) Antworten. Dieses Muster kann auf einen versuchten Overpass the Hash-Angriff hinweisen.
• Achten Sie auf abnormale Ticket-Granting Ticket (TGT)-Anfragen von dMSA-Konten, insbesondere wenn sie von Benutzerkonten gestartet werden.

Semperis Schnappschuss

Der Golden dMSA-Angriff nutzt eine kryptografische Schwachstelle aus, die Microsofts neueste Sicherheitsinnovation in Windows Server 2025 untergraben kann. Diese Technik nutzt die architektonische Grundlage von delegierten Managed Service Accounts aus. Der Angriff nutzt einen kritischen Designfehler aus: die ManagedPasswordId Struktur enthält vorhersehbare zeitbasierte Komponenten mit nur 1.024 möglichen Kombinationen, was die Brute-Force-Passwortgenerierung rechnerisch trivial macht.

Das besonders Verheerende daran ist, dass es sich um einen ganzen Wald handelt. Eine einzige erfolgreiche Schlüsselextraktion ermöglicht domänenübergreifende Seitwärtsbewegungen und dauerhaften Zugriff auf alle verwalteten Dienstkonten und deren Ressourcen auf unbestimmte Zeit, da KDS-Root-Schlüssel kein Verfallsdatum haben. Die Schwachstelle verwandelt Microsofts sicherste Technologie für Dienstkonten in eine potenzielle unternehmensweite Hintertür, die moderne Schutzmaßnahmen wie Credential Guard umgeht und die angenommenen Sicherheitsvorteile der maschinengebundenen Authentifizierung grundlegend in Frage stellt.

Offenlegung

Das Problem wurde dem Microsoft Security Response Center (MSRC) erstmals am 27. Mai 2025 gemeldet.

Am 8. Juli 2025 antwortete Microsoft auszugsweise: "Wenn Sie über die Geheimnisse verfügen, die zur Ableitung des Schlüssels verwendet wurden, können Sie sich als dieser Benutzer authentifizieren. Diese Funktionen waren nie dazu gedacht, vor einer Kompromittierung eines Domänencontrollers zu schützen."

Erfahren Sie mehr über Bedrohungen für Managed Service-Konten

• BadSuccessor: Wie man dMSA Privilege Escalation erkennt und abschwächt
• Wie man BadSuccessor blockiert
• gMSA Active Directory Angriffe

Endnoten

1. https://github.com/fortra/impacket/blob/master/examples/lookupsid.py
2. https://github.com/fortra/impacket/blob/master/examples/smbclient.py
3. https://github.com/Semperis/GoldenDMSA/tree/main
4. https://github.com/Semperis/GoldenGMSA

Haftungsausschluss

Dieser Inhalt wird ausschließlich zu Bildungs- und Informationszwecken bereitgestellt. Er soll das Bewusstsein und die verantwortungsvolle Behebung von Sicherheitslücken fördern, die auf Systemen bestehen können, die Sie besitzen oder zu deren Prüfung Sie berechtigt sind. Die unbefugte Nutzung dieser Informationen zu böswilligen Zwecken, zur Ausbeutung oder zum unrechtmäßigen Zugriff ist strengstens untersagt. Semperis befürwortet oder duldet keine illegalen Aktivitäten und lehnt jede Haftung ab, die aus dem Missbrauch des Materials entsteht. Darüber hinaus übernimmt Semperis keine Garantie für die Richtigkeit oder Vollständigkeit der Inhalte und haftet nicht für Schäden, die sich aus der Verwendung der Inhalte ergeben.