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.

Microsofts Windows Server 2025 bietet bedeutende Sicherheitsinnovationen, darunter die Einführung delegierter Managed Service Accounts (dMSAs), die die Verwaltung von Dienstkonten revolutionieren sollen. Im Gegensatz zu statischen, passwortbasierten Konten, die Opfer von Kerberoasting-Angriffen werden können, binden dMSAs die Authentifizierung direkt an autorisierte Computer 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.
• Gruppen-Managed-Service-Konten (gMSAs). Mit Windows Server 2012 wurde die Beschränkung auf mehrere Computer aufgehoben, sodass nun gemeinsame Dienstidentitäten über Cluster, Lastenausgleichsserver und verteilte Dienste hinweg genutzt werden können, während die Sicherheitsvorteile der MSAs erhalten bleiben.
• Delegierte Managed-Service-Konten (dMSAs). Die neueste Innovation von Windows Server 2025 markiert den Übergang von der zentralisierten Passwortverwaltung zur gerätegebundenen Authentifizierung und stellt damit eine grundlegende Veränderung in 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 Sicht eines Angreifers ist die Möglichkeit, dMSAs als Benutzer ohne Sonderrechte aufzulisten, entscheidend für die Ausweitung von Berechtigungen und die laterale Bewegung. 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.

Laut der Dokumentation von Microsoft gehen wir zur Erstellung von dMSAs zunächst wie folgt vor: CreateDelegatedServiceAccount Befehl, der Abbildung 1 zeigt.

Nun kommt der spannende Teil. Versuchen wir, unser neu erstelltes DMSA-Demo-Konto mithilfe von Get-ADServiceAccount (Abbildung 2).

An dieser Stelle stoßen wir auf unser erstes Hindernis. Ein Benutzer mit Berechtigungen kann das Konto problemlos einsehen, während ein Benutzer ohne Berechtigungen absolut nichts zu sehen bekommt – die Ergebnisse sind leer (Abbildung 3). Warum? Das liegt ausschließlich an den Standardeinstellungen in den Zugriffskontrolllisten (ACLs) des Kontos. Und glauben Sie mir, kein Administrator möchte sich damit herumschlagen.

Haben Sie in Abbildung 4 etwas Verdächtiges bemerkt? Authentifizierte Benutzer können keine Daten auf diesen Konten lesen.

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 Funktionsnamen lassen zwar bereits auf ihren Zweck schließen, doch Abbildung 6 zeigt die offizielle Dokumentation von Microsoft, um dies noch einmal ganz deutlich 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.

Nun zum spannenden Teil: Schauen wir uns einmal an, was passiert, wenn wir diese Win32-Funktionen einsetzen (Abbildung 7).

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

Diese Methode ist erfolgreich, da sie LDAP vollständig umgeht und somit diese restriktiven Zugriffsberechtigungen (ACLs) effektiv umgeht. Hier liegt der technische Clou: LsaLookupSids und LsaOpenPolicy Verlassen Sie 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?

Und hier kommt der clevere Teil: Wir kennzeichnen alle Konten, die mit einem „$“ enden, als verdächtig. Anschließend schließen wir systematisch Maschinenkonten und gMSAs aus.

Voilà! Nun verfügen wir über eine vollständige Auflistung 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 noch 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, der erstmals in Windows Server 2012 eingeführt wurde, ist das Herzstück der gMSA-Infrastruktur von Microsoft. Stellen Sie sich diesen als das kryptografische Herzstück hinter dem Key Distribution Service von Microsoft vor – als den Motor, der Passwörter für gMSAs generiert und verteilt.

Der Erwerb dieses Root-Schlüssels ist der entscheidende erste Schritt in der Angriffskette, da er es Angreifern ermöglicht, die Passwörter für jedes gMSA-Konto in der Domäne offline zu berechnen. Diese Fähigkeit ist verheerend, da gMSA-Konten so konzipiert sind, dass ihre Passwörter automatisch vom domain controller DC) geändert werden, wodurch sie für Administratoren sicher erscheinen. Mit dem KDS-Root-Schlüssel in der Hand kann ein Angreifer jedoch das aktuelle Passwort für jedes gMSA-Konto mathematisch ableiten, ohne sich jemals wieder mit dem DC verbinden zu müssen.

Folgendes macht das System so leistungsstark: Der KDS-Root-Schlüssel fungiert als ultimativer Hauptschlüssel. Von ihm aus 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 im Benennungskontext der Konfiguration (CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=,DC=), der auf alle beschreibbaren Domänencontroller in der Gesamtstruktur auf dem Stamm-Domänencontroller der Gesamtstruktur repliziert wird, für nicht privilegierte Benutzer jedoch verborgen bleibt. Microsoft hat hier in puncto Sicherheit keine Kompromisse eingegangen. Die Zugriffsrichtlinien (ACLs) für diese Schlüssel sind äußerst restriktiv (Abbildung 10), die den Zugriff nur auf die privilegiertesten Konten beschränkt: 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, pro Umgebung nur einen KDS-Stammschlüssel 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.

Im Rahmen meiner Recherchen habe ich etwas noch Faszinierenderes entdeckt. Selbst in Umgebungen mit mehreren KDS-Stammschlüsseln kann es vorkommen, dass das System aufgrund des Caching-Verfahrens den alten KDS-Stammschlüssel verwendet (es sei denn, wir setzen den KDS-Dienst auf bestimmte Weise zurück). Dies bedeutet, dass der ursprüngliche Schlüssel, den wir kompromittiert haben, aufgrund der Konzeption von Microsoft erhalten bleiben könnte – wodurch eine dauerhafte Hintertür entsteht, 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

Nun tauchen wir in den Kern des Angriffs ein – die Extraktion der dMSAs ManagedPasswordId Attribut.

ManagedPasswordId ist ein in AD gespeichertes Attribut, das die Metadaten enthält, die zur Ableitung des aktuellen Passworts eines MSA erforderlich sind. Wir müssen dieses Attribut abrufen, da es die wesentlichen kryptografischen Parameter enthält – darunter die Schlüsselkennung, den Erstellungszeitpunkt und weitere Details zur Ableitung –, die in Verbindung mit dem KDS-Stammschlüssel dazu dienen, das tatsächliche Passwort des gMSA mathematisch zu berechnen.

Falls Ihnen das bekannt vorkommt, haben Sie vollkommen Recht. Yuval Gordons hervorragende Forschungsarbeit zu 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?

An dieser Stelle stießen wir auf unser erstes großes Hindernis. Die zuvor entdeckten restriktiven ACLs hinderten uns vollständig daran, diese wichtigen Daten zu den dMSA-Konten auszulesen. 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: Ganzzahlwert, der eine Zeitvariable darstellt (darauf werden wir später noch näher eingehen)
• L1Index: Ein ganzzahliger Wert, der eine Zeitvariable darstellt (darauf werden wir später noch näher eingehen)
• L2Index: Ganzzahlwert, der eine Zeitvariable darstellt (darauf werden wir später noch näher eingehen)
• 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 vorhanden ist oder abgelaufen ist, legt das System einen neuen Startzeitpunkt 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).

Aus dieser Beobachtung habe ich eine entscheidende Erkenntnis gewonnen: Die Werte für L1 und L2 sind auf 31 (einschließlich) begrenzt. Dies ist nicht nur Theorie, sondern 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 mich eingehender mit dem Algorithmus von Golden gMSA befasste, stellte ich fest, dass er folgende 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 überprüft, indem ich für jeden Vektor das richtige Passwort und den NTLM-Hash berechnet habe, und anschließend mit^{dem smbclient2} von Impacket „Pass-the-Hash“-Angriffe durchgeführt (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 seiner Dokumentation erklärt Microsoft: „Das dMSA-Passwort kann nirgendwo anders als auf dem DC abgerufen oder gefunden werden“, womit ein grundlegender Unterschied zwischen den Authentifizierungsmechanismen von gMSA und dMSA hervorgehoben wird. Bei gMSAs ist der Vorgang unkompliziert. Eine Entität authentifiziert sich und fordert direkt die Anmeldedaten (das Passwort) des gMSA an; anschließend erhält sie das eigentliche Passwort für Authentifizierungszwecke.

dMSAs funktionieren nach einem völlig anderen Prinzip. Sie müssen sich unter Verwendung der Identität des Rechners authentifizieren, um ein Ticket für den dMSA-Benutzer zu erhalten. Das Passwort des dMSA verlässt den DC zu keinem Zeitpunkt. Stattdessen wird es zur Verschlüsselung des Tickets verwendet, das an den anfragenden Rechner zurückgesendet 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.

Doch genau hier verändert der „Golden dMSA“-Angriff alles. „Golden dMSA“ umgeht die üblichen Credential-Guard-Schutzmaßnahmen vollständig (Abbildung 28). Wir halten uns nicht mehr an die üblichen Authentifizierungsregeln.

Anstatt den von Microsoft vorgesehenen Authentifizierungsablauf zu befolgen, werden die dMSA-Anmeldedaten mithilfe des kryptografischen Angriffs direkt verwendet (Abbildung 29). Das bedeutet:

• Es ist keine Maschinenidentität erforderlich. Wir müssen den Host-Rechner nicht kompromittieren.
• „Credential Guard“ verliert seine Bedeutung. Da wir keine Anmeldedaten des Computers stehlen, bietet dieser Schutz keinerlei Sicherheit.

Microsoft hat bestätigt: „Ab dem Windows-Sicherheitsupdate vom April (KB5055523) ist der Schutz von Computerkonten durch Credential Guard unter Windows Server 2025 und Windows 11, Version 24H2, vorübergehend deaktiviert. Diese Funktion wurde aufgrund eines Problems bei der Rotation von Computerkennwörtern unter Verwendung von 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 mithilfe der „Golden dMSA“-Technik erfolgreich ein dMSA-Konto kompromittiert hat, geht der eigentliche Spaß erst richtig los. Dabei geht es nicht nur darum, Zugriff auf ein einzelnes Dienstkonto zu erlangen. Vielmehr geht es darum, diesen Einstiegspunkt für verheerende laterale Bewegungen zu nutzen. Darüber hinaus ermöglicht diese Technik Angreifern, Passwörter zu knacken und Berechtigungen für Dienstkonten zu erlangen, die sowohl die Migration zum kompromittierten dMSA begonnen als auch abgeschlossen haben.

An dieser Stelle wird der Angriff aus Sicht der Sicherheit wirklich beängstigend. Der „Golden dMSA“-Angriff ist nicht durch Domänengrenzen eingeschränkt. Er findet auf Forest-Ebene statt. Sobald wir den KDS-Stammschlüssel einer beliebigen Domäne innerhalb des Forests kompromittiert haben, können wir systematisch jedes dMSA-Konto in allen Domänen dieses Forests ins Visier nehmen 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 nimmt exponentiell zu. Was mit der Kompromittierung eines einzigen DCs beginnt, eskaliert bis hin zur vollständigen Kontrolle über alle dMSA-geschützten Dienste in einer gesamten Unternehmensstruktur. Es handelt sich nicht nur um eine Ausweitung von Berechtigungen. Es ist eine unternehmensweite digitale Dominanz 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 überprüfen, habe ich einen neuen Benutzer angelegt – versteckt im Root-DC –, auf den ausschließlich das dMSA-Konto Zugriff hat. Wenn wir die Daten dieses Benutzers erfolgreich auslesen 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 die neueste Sicherheitsinnovation von Microsoft in Windows Server 2025 untergraben kann. Diese Technik macht sich die architektonische Grundlage delegierter Managed Service Accounts zunutze. Der Angriff nutzt einen kritischen Konstruktionsfehler aus: den ManagedPasswordId Struktur enthält vorhersehbare zeitbasierte Komponenten mit nur 1.024 möglichen Kombinationen, was die Brute-Force-Passwortgenerierung rechnerisch trivial macht.

Was dies besonders verheerend macht, ist die Auswirkung auf das gesamte KDS-System. Eine einzige erfolgreiche Schlüsselextraktion ermöglicht domänenübergreifende laterale Bewegung und dauerhaften Zugriff auf alle verwalteten Dienstkonten und deren Ressourcen auf unbestimmte Zeit, da KDS-Stammschlüssel kein Ablaufdatum haben. Die Sicherheitslücke verwandelt Microsofts sicherste Technologie für Dienstkonten in eine potenzielle unternehmensweite Hintertür, umgeht moderne Schutzmaßnahmen wie Credential Guard und stellt die angenommenen Sicherheitsvorteile der gerätegebundenen Authentifizierung grundlegend in Frage.

Offenlegung

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

Am 8. Juli 2025 antwortete Microsoft unter anderem: „Wenn Sie über die Geheimnisse verfügen, die zur Ableitung des Schlüssels verwendet werden, können Sie sich als dieser Benutzer authentifizieren. Diese Funktionen waren nie dazu gedacht, vor einer Kompromittierung eines domain controller 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.