BadSuccessor: Missbrauch von dMSA zur Eskalation von Berechtigungen in Active Directory
Zusammenfassung
Der Akamai-Forscher Yuval Gordon entdeckte eine Schwachstelle für den privilegierten Zugriff in Windows Server 2025, die es Angreifern ermöglicht, einen beliebigen Nutzer in Active Directory (AD) zu kompromittieren.
Der Angriff nutzt die dMSA-Funktion (Delegated Managed Service Account) aus, die in Windows Server 2025 eingeführt wurde. Sie arbeitet mit der Standardkonfiguration und ist trivial zu implementieren.
Dieses Problem betrifft wahrscheinlich die meisten Unternehmen, die auf AD setzen. In 91 % der untersuchten Umgebungen fanden wir Nutzer außerhalb der Domain-Admins-Gruppe, die über die erforderlichen Berechtigungen zur Durchführung dieses Angriffs verfügten.
Obwohl Microsoft angibt, dass dieses Problem in Zukunft behoben werden soll, ist derzeit kein Patch verfügbar. Daher müssen Unternehmen andere proaktive Maßnahmen ergreifen, um die Gefahr eines solchen Angriffs zu verringern. Microsoft hat unsere Ergebnisse geprüft und die Veröffentlichung dieser Informationen genehmigt.
In diesem Blogbeitrag finden Sie ausführliche Informationen zum Angriff sowie zu den Strategien zur Erkennung und Abwehr.
Inhalt
Einführung
In Windows Server 2025 hat Microsoft „delegated Managed Service Accounts“ (dMSAs) eingeführt. Ein dMSA ist ein neuer Typ von Dienstkonto in Active Directory (AD), das die Funktionen von group Managed Service Accounts (gMSAs) erweitert. Eine wichtige Funktion von dMSAs ist die Möglichkeit, vorhandene nicht verwaltete Servicekonten durch nahtlose Konvertierung in dMSAs zu migrieren.
Während wir versucht haben, herauszufinden, wie die ADs von dMSAs funktionieren, haben wir etwas Unerwartetes herausgefunden. Auf den ersten Blick sah der Migrationsmechanismus wie eine saubere und gut konzipierte Lösung aus. Etwas an der Art und Weise, wie es hinter den Kulissen funktioniert hat, hat unsere Aufmerksamkeit erregt.
Bei unseren Nachforschungen fanden wir einen überraschenden Eskalationspfad: Durch den Missbrauch von dMSAs können Angreifer jeden Prinzipal in der Domain übernehmen. Alles, was ein Angreifer zum Ausführen dieses Angriffs benötigt, ist eine harmlose Berechtigung auf einer beliebigen Organisationseinheit (OE) in der Domain – eine Berechtigung, die oft unter dem Radar bleibt.
Und das Beste: Der Angriff funktioniert automatisch – Ihre Domain muss überhaupt keine dMSAs verwenden. Solange die Funktion vorhanden ist, die in einer beliebigen Domain mit mindestens einem Windows Server 2025-Domaincontroller (DC) ausgeführt wird, ist sie verfügbar.
In diesem Blogbeitrag erfahren Sie, wie wir das entdeckt haben, wie der Angriff funktioniert und was Sie tun können, um ihn zu erkennen oder zu verhindern.
Was ist ein dMSA?
Bevor Sie sich mit den Angriffen vertraut machen, ist es wichtig zu verstehen, was dMSAs eigentlich sind und wie sie funktionieren sollen.
Ein dMSA wird in der Regel erstellt, um ein vorhandenes Legacy-Dienstkonto zu ersetzen. Um einen nahtlosen Übergang zu ermöglichen, kann ein dMSA die Berechtigungen des Legacy-Kontos durch Ausführen eines Migrationsprozesses übernehmen. Dieser Migrationsablauf verknüpft das dMSA eng mit dem ersetzten Konto, d. h. dem ursprünglichen Konto, das ersetzt werden soll. Dieser Ablauf – und die Berechtigungen, die er auf dem Weg gewährt – ist der Punkt, an dem die Dinge interessant werden.
dMSA-Migrationsablauf
Der Migrationsprozess eines dMSA kann durch Aufruf des neuen Cmdlets „Start-ADServiceAccountMigration“ ausgelöst werden. Intern wird ein neuer LDAP-rootDSE-Vorgang namens migateADServiceAccount aufgerufen, der die folgenden Argumente verwendet:
Der Distinguished Name (DN) des dMSA
Der DN des ersetzten Kontos
Eine Konstante, die StartMigration entspricht
Der Migrationsstatus eines dMSA wird durch das msDS-DelegatedMSAState-Attribut vorgegeben – ein neues Attribut, das den aktuellen Status des dMSA bestimmt. Derzeit gibt es keine offizielle Dokumentation für das msDS-DelegatedMSAState-Attribut, daher basiert die folgende Tabelle auf unserer eigenen Verhaltensanalyse und unseren Experimenten.
Wert |
Bedeutung |
0 |
Unbekannt (möglicherweise deaktiviert, aber unbestätigt) |
1 |
Migration läuft |
2 |
Migration abgeschlossen |
3 |
Eigenständiges dMSA (keine Migration) |
msDS-DelegatedMSAState-Migrationswerte und korrelierte Bedeutungen
Neben diesem Attribut werden während des Migrationsprozesses einige weitere wichtige Attribute verwendet.
Auf dem dMSA-Objekt:
msDS-GroupMSAMembership: Enthält eine Liste der Prinzipals, die zur Verwendung dieses dMSA autorisiert sind
msDS-ManagedAccountPrecededByLink: DN des ersetzten Kontos
Auf dem ersetzten Kontoobjekt:
msDS-SupersededManagedAccountLink: DN des „nachfolgenden“ dMSA
msDS-SupersededServiceAccountState: Hat dieselbe Bedeutung wie msDS-DelegatedMSAState und beschreibt den ursprünglichen Migrationsstatus des Kontos
Beim Auslösen einer Migration nimmt der Vorgang die folgenden Änderungen vor:
msDS-DelegatedMSAState wird auf 1 eingestellt (Migration läuft)
Der ntSecurityDescriptor des dMSA wird aktualisiert, damit er das ersetzte Konto zulässt:
Leseberechtigungen
Schreibzugriff auf das msDS-GroupMSAMembership-Attribut
Der msDS-ManagedAccountPrecededByLink wird so eingestellt, dass er auf das ersetzte Konto verweist
Der msDS-SupersededManagedAccountLink wird so eingestellt, dass er auf das dMSA verweist
Setzt den msDS-SupersededServiceAccountState des ersetzten Kontos auf 1.
Zu diesem Zeitpunkt befindet sich das dMSA im Status „Migration läuft“. Es ist noch nicht voll funktionstüchtig, aber es ist jetzt bekannt, welche Systeme noch das alte Dienstkonto verwenden.
Sobald der Befehl Complete-ADServiceAccountMigration ausgegeben wurde, geschieht Folgendes:
Das dMSA übernimmt Schlüsselkonfigurationen wie SPNs, Delegationseinstellungen und andere vertrauliche Attribute aus dem überholten Konto.
Das ersetzte Konto ist deaktiviert
msDS-DelegatedMSAState und msDS-SupersededServiceAccountState werden beide auf 2 eingestellt (Migration abgeschlossen)
Die Migration ist abgeschlossen und jeder Dienst, der sich auf das ersetzte Konto verlassen hat, verwendet jetzt die dMSA zur Authentifizierung.
Die dMSA-Authentifizierung
Jetzt, da wir die Erstellung und Migration von dMSAs verstehen, ist es an der Zeit, uns auf die Funktionsweise der Authentifizierung, die Änderungen zur Unterstützung von dMSAs zu konzentrieren und wie diese Änderungen den Migrationsprozess nahtlos gestalten.
Zum leichteren Verständnis sehen wir uns das Dienstkonto svc_sql legacy an, mit dem ein Dienst auf dem SQL_SRV$-Server ausgeführt wird. Wenn der Dienst für den Zugriff auf Ressourcen in der Domain erforderlich ist, wird die normale Authentifizierung mit dem svc_sql-Konto durchgeführt (Abbildung 1).
Fig. 1: Legacy service account authentication flow
Authentifizierung während der Migration
Jetzt wechseln wir das Dienstkonto zu einer neuen dMSA namens DMSA$ und lösen eine Migration aus. Wenn der Service auf SQL_SRV$ während des Migrationszeitraums als svc_sql authentifiziert wird, führt das zu einer geringfügigen Änderung im Authentifizierungsablauf.
Der Client sendet AS-REQ zur Authentifizierung als svc_sql
Das Key Distribution Center (KDC) gibt AS-REP mit einem zusätzlichen Feld aus: KERB-SUPERSEDED-BY-USER (dieses Feld enthält den Namen und die Realm der neuen dMSA DMSA$)
Wenn der Host dMSAs (Windows Server 2025 oder Windows 11 24H2) unterstützt und die dMSA-Authentifizierung aktiviert ist, wird er:
Den DMSA$-Namen extrahieren
Eine LDAP-Abfrage für DMSA$ durchführen, um die folgenden Attribute abzurufen:
msDS-GroupMSAMembership
distinguishedName
objectClass
Da der Service auf SQL_SRV$als svc_sql ausgeführt wird, löst die Authentifizierung selbst von svc_sql eine LDAP-Änderungsanfrage aus, wodurch SQL_SRV$ der Liste der Prinzipals hinzugefügt wird, die das Passwort des DMSA$ abrufen dürfen (Abbildung 2).
Das ist möglich, weil svc_sql während des Migrationsprozesses Schreibzugriff auf das Attribut msDS-GroupMSAMembership auf dem dMSA erhalten hat – durch diese Änderung kann es seinen Hostrechner autorisieren, auf die Zugangsdaten des Kontos zuzugreifen.
Fig. 2: Kerberos authentication flow during dMSA migration
Diese nahtlose Berechtigungserteilung stellt sicher, dass zum Zeitpunkt der Migration jeder Computer, der zuvor svc_sql verwendet hat, im Attribut msDS-GroupMSAMembership von DMSA$ aufgeführt wird, sodass er sich als dMSA authentifizieren kann.
Authentifizierung nach Abschluss der Migration
Sobald die Migration abgeschlossen ist (durch Complete-ADServiceAccountMigration), ändert sich das Verhalten erneut.
Wenn der Client versucht, sich als svc_sql zu authentifizieren, indem er AS-REQ sendet, erhält er kein AS-REP mehr
Stattdessen antwortet das DC mit KRB-ERROR. Das deutet darauf hin, dass svc_sql deaktiviert ist
Der Fehler KRB-ERROR enthält das Feld KERB-SUPERSEDED-BY-USER, durch das der Client erkennen kann, dass svc_sql migriert wurde, und die Authentifizierung mit DMSA$ automatisch wiederholen kann (Abbildung 3).
Fig. 3: Kerberos authentication flow after the dMSA migration is completed
SQL_SRV$ und alle anderen Computer, die zuvor svc_sql verwendet haben, werden nun transparent auf DMSA$ umgestellt.
Unerwartetes Verhalten
Ein interessanter Aspekt der dMSA-Authentifizierung in Kerberos ist das Privilege Attribute Certificate (PAC).
Bei der Authentifizierung bettet Kerberos ein PAC in Tickets ein – eine Struktur, die Dienste zur Bestimmung der Zugriffsebene eines Clients verwenden. In einem standardmäßigen Ticket Granting Ticket (TGT) enthält das PAC die SIDs der Nutzer und aller Gruppen, zu denen sie gehören.
Allerdings haben wir beim Einloggen mit einem dMSA etwas Unerwartetes beobachtet.
Das PAC enthielt nicht nur die dMSAs-SID, sondern auch die SIDs des ersetzten Dienstkontos und aller zugehörigen Gruppen.
Ausnutzen des dMSA-Migrationsprozesses zur Erhöhung von Berechtigungen
Nach der Migration gewährt das KDC dem dMSA alle Berechtigungen des ursprünglichen (ersetzten) Kontos.
Das ist aus Designperspektive sinnvoll. Das Ziel ist, ein nahtloses Migrationserlebnis zu bieten, bei der sich das neue Konto genauso verhält wie das ersetzte – dieselben SPNs, dieselben Weiterleitungen, dieselben Gruppenmitgliedschaften.
Aber aus der Sicht eines Sicherheitsforschers fällt dieses Verhalten sofort auf. Als wir ein System sahen, das automatisch Berechtigungen von einem Konto auf ein anderes kopiert, ohne dass eine manuelle Neukonfiguration erforderlich war, haben wir weitergeforscht: Wie entscheidet es, von welchem Konto kopiert werden soll? Kann das beeinflusst werden? Kann es ausgenutzt werden?
Dies führte uns direkt zu einer wichtigen Erkenntnis. Dieses interessante Verhalten der PAC-Übernahme scheint durch ein einziges Attribut gesteuert zu werden: msDS-ManagedAccountPrecededByLink.
Das KDC verwendet dieses Attribut, um zu bestimmen, wer das dMSA „ersetzt“ – wenn ein dMSA authentifiziert wird, wird das PAC ausschließlich auf Grundlage dieser Verknüpfung erstellt.
Es ist an der Zeit, wie ein Angreifer zu denken
Wie sieht das aus der Perspektive eines Angreifers aus? Sehen wir uns nun ein mögliches Angriffsszenario an und schauen wir, wie weit ein Angreifer mit dieser Funktion erreichen könnte.
Unser erster Versuch: Ein dMSA verwenden, um ein Kontoübernahme-Primitiv zu erstellen. Wenn wir davon ausgehen, dass wir über Berechtigungen für ein Nutzerkonto verfügen, könnten wir die Berechtigungen des Nutzers dann auf ein neues dMSA „migrieren“, um sie heimlich zu kompromittieren? Diese Herangehensweise klingt logisch. Wir müssen nur noch:
Ein dMSA erstellen
Die Migration zwischen dem Zielnutzer und dem dMSA mit dem Vorgang migrateADServiceAccount rootDSE abschließen
Als dMSA authentifizieren und erhalten alle Berechtigungen des Zielnutzers
Das einzige Problem daran: Es funktioniert nicht.
Selbst wenn wir sowohl das dMSA als auch das ersetzte Konto vollständig kontrollieren, können wir keine Migration durchführen, da nach unserem Wissen nur Domain Admins den Vorgang migrateADServiceAccount ausführen dürfen. Abbildung 4 zeigt ein Beispiel für einen fehlgeschlagenen Versuch.
Fig. 4: A failed attempt to use a dMSA to create an account takeover primitive
Weiter zu unserem nächsten Ansatz. Natürlich brauchen wir etwas Komplexes, Kreatives und tiefgreifend Technisches. Wir müssen mehr über nicht dokumentierte Verhaltensweisen erfahren, vielleicht sogar einen Teil des KDC modifizieren ... oder wir könnten einfach zwei Attribute festlegen.
Obwohl wir eine Migration nicht direkt durchführen können, können wir sie sehr einfach „simulieren“, indem wir einfach die folgenden Attribute direkt auf das dMSA-Objekt setzen.
Wir legen die DN des Zielkontos auf msDS-ManagedAccountPrecedByLink fest
Setzen von msDS-DelegatedMSAState auf Wert 2 (Migration abgeschlossen)
Ab diesem Zeitpunkt erstellt das KDC jedes Mal, wenn wir als dMSA authentifiziert werden, das PAC mithilfe der SIDs des verlinkten Kontos, im Attribut msDS-ManagedAccountPrecededByLink und gibt uns so die vollständigen Berechtigungen des ersetzten Kontos.
Wir stellen vor: BadSuccessor
Eine interessante Tatsache bei dieser „simulierten Migration“ ist, dass keine Berechtigungen für das ersetzte Konto erforderlich sind. Die einzige Anforderung sind Schreibberechtigungen für die Attribute eines dMSA. Ein beliebiges dMSA.
Sobald wir ein dMSA als „verfügt über einen vorherigen Nutzer“ markiert haben, geht das KDC automatisch davon aus, dass eine legitime Migration stattgefunden hat, und erteilt unserem dMSA automatisch jede Berechtigung des ursprünglichen Nutzers als wären wir der rechtmäßige Nachfolger.
Aber das würde bei Konten mit hohen Berechtigungen sicher nicht funktionieren, oder? Naja ...
Darüber hinaus funktioniert diese Technik, die wir „BadSuccessor“ genannt haben, bei jedem Nutzer, einschließlich Domain-Admins (Abbildung 5). Damit kann jeder Nutzer, der ein dMSA-Objekt kontrolliert, die gesamte Domain kontrollieren. Mehr ist nicht nötig. Keine tatsächliche Migration. Keine Überprüfung. Keine Überwachung.
Fig. 5: Full attack flow, showing all steps needed to have a BadSuccessor
Ausnutzung von dMSAs: Von niedrigen Berechtigungen bis zur Domaindominierung
An dieser Stelle denken Sie vielleicht: „Nun, ich verwende keine dMSAs in meiner Umgebung, das betrifft mich also nicht.“ Da liegen Sie möglicherweise falsch.
Ein mögliches Missbrauchsszenario: Ein Angreifer erhält die Kontrolle über ein bestehendes dMSA und nutzt diesen Zugriff, um den BadSuccessor-Angriff durchzuführen. Es gibt jedoch ein anderes Szenario, das Angreifern wahrscheinlich viel häufiger zur Verfügung steht: Ein Angreifer erstellt ein neues dMSA.
Wenn ein Anwender ein Objekt in AD erstellt, hat er volle Berechtigungen für alle seine Attribute. Wenn ein Angreifer also ein neues dMSA erstellen kann, kann er die gesamte Domain kompromittieren.
Normalerweise wird ein dMSA, die mit dem Cmdlet New-ADServiceAccount erstellt wird, im Container „Managed Service Accounts“ gespeichert. Obwohl es Nutzern möglich ist, Zugriff auf diesen Container zu erhalten, haben standardmäßig nur integrierte privilegierte Active-Directory-Gruppen Berechtigungen dafür. Es ist also nicht sehr wahrscheinlich, dass wir in diesen Container schreiben können.
dMSAs sind jedoch nicht auf den Container „Managed Service Accounts“ beschränkt, sie können auch in jeder normalen Organisationseinheit (OE) angelegt werden. Jeder Nutzer mit der Berechtigung „msDS-DelegatedManagedServiceAccount erstellen“ oder „Alle untergeordneten Objekte erstellen“ auf einer beliebigen OE kann ein dMSA erstellen.
Erstellung des dMSA
Die Möglichkeit, dass Anwender Objekte in einer OE anlegen, ist eine relativ gängige Konfiguration. Da diese Fähigkeit als harmlos angesehen wird, ist es unwahrscheinlich, dass Nutzer mit dieser Berechtigung überwacht und angemessen gehärtet werden.
Um das dMSA zu erstellen, suchen wir zunächst nach einer OE, auf der wir Berechtigungen haben. Glücklicherweise hat jemand in unserer Beispielumgebung eine OE namens „temp“ erstellt und unserem unberechtigten Nutzer mit der „schwachen“ Berechtigungen ausgestattet, alle untergeordneten Objekte zu erstellen (Abbildung 6).
Fig. 6: Example of required privileges on an OU
Mit diesen Berechtigungen können wir dann ein dMSA mit dem Cmdlet New-ADServiceAccount erstellen. Wie in Abbildung 7 zu sehen ist, kann der unprivilegierte Nutzer zwar kein dMSA im Standard-MSA-Container anlegen, aber er kann das dMSA mit dem Pfadargument in der zugänglichen OE anlegen.
Fig. 7: Creating the dMSA in an allowed location using the New-ADServiceAccount PowerShell cmdlet
Wir sind jetzt die glücklichen Besitzer eines neu erstellten, nicht funktionierenden dMSA. Als Eigentümer/Ersteller können wir uns selbst die Berechtigung für das Objekt geben, einschließlich dem Schreibzugriff auf beide Attribute, die wir für diesen Angriff verwenden werden. Diese können wir dann wie folgt ändern:
msDS-ManagedAccountPrecededByLink: Wir legen diesen Wert auf den DN eines beliebigen Nutzers oder Computers fest – Domain-Controller, Mitglieder von Domain-Admins, geschützte Nutzer und (ironischerweise) sogar Konten mit der Markierung „Konto ist vertraulich und kann nicht delegiert werden“
msDS-DelegatedMSAState: Setzen Sie diesen Wert auf 2, um eine abgeschlossene Migration zu simulieren (Abbildung 8).
Fig. 8: Modifying attributes to mimic successful migration
Wie bereits erwähnt, scheint dieser Angriff bei allen Konten in AD zu funktionieren. Wir konnten keine Konfiguration finden, die verhindert, dass ein Konto als ersetztes Ziel verwendet wird.
Ein TGT für das dMSA erhalten
Eine Möglichkeit, sich bei unserem dMSA zu authentifizieren, besteht darin, einen Dienst zu erstellen und ihn so zu konfigurieren, dass er mit dem dMSA-Konto ausgeführt wird. Das ist machbar, aber nicht bequem. Glücklicherweise unterstützt Rubeus dank einer großartigen Pull-Anfrage von Joe Dibley nun die dMSA-Authentifizierung (Abbildung 9), sodass wir damit ein TGT für unser dMSA anfordern können:
Rubeus.exe asktgs /targetuser:attacker_dmsa$ /service:krbtgt/aka.test /dmsa /opsec /nowrap /ptt /ticket:<Machine TGT>
Fig. 9: Requesting TGT for the new dMSA using Rubeus
dMSA → Domain-Admin
In diesem Beispiel haben wir das integrierte Administratorkonto als Ziel festgelegt. Wir haben das PAC des Tickets, das wir für unser dMSA erhalten haben, mit Wireshark untersucht (Abbildung 10) und es umfasste Folgendes:
RID des dMSA (1137)
RID des ersetzten Kontos (500 – Administrator)
Alle Gruppenmitgliedschaften des ersetzten Kontos (512 – Domain-Admins, 519 – Unternehmens-Admins)
Fig. 10: dMSA’s PAC that includes the Administrator’s groups’ RIDs
Das ist alles, was der Domaincontroller braucht, um uns als legitimen Nachfolger zu behandeln. Denken Sie immer daran: Es sind keine Änderungen der Gruppenmitgliedschaften, die Gruppe Domain Admins bleibt unberührt und es sind keine verdächtigen LDAP-Schreibvorgänge auf dem tatsächlich privilegierte Konto erforderlich.
Mit Änderungen an nur zwei Attributen wird ein einfaches neues Objekt zum Nachfolger – und das KDC validiert die Legitimität des Vorgänger-Links nicht. Wenn er vorhanden ist, werden die Privilegien gewährt. Wir haben nicht eine Gruppenmitgliedschaft geändert, kein bestehendes Konto aufgewertet und keine Warnung vor einer Erweiterung der herkömmlichen Privilegien ausgelöst.
Demo: End-to-End-Ablauf des Angriffs
Sehen Sie sich dieses Video an, um eine vollständige Demonstration des Angriffs in Aktion zu erhalten.
Demonstration: Missbrauchs von dMSA zur Erweiterung von Berechtigungen in Active Directory
Und das war noch nicht alles – Ausnutzen von dMSAs, um Anmeldedaten zu gefährden
Das Erstellen eines TGT für einen beliebigen Nutzer, ist cool, aber es reicht uns nicht. Was wäre, wenn wir auch ihre Anmeldedaten wollen? Glücklicherweise kann uns das dMSA auch in diesem Szenario weiterhelfen.
Wenn Sie eine Anfrage nach einem TGT für ein dMSA stellen, wird eine neue Struktur mit dem Namen CURB-DMSA-KEY-PACKAGE mitgeliefert. Diese Struktur enthält zwei Felder: current-keys und previous-keys. Laut MSDN sollen diese Schlüssel enthalten, die sich auf das aktuelle und das vorherige Passwort des dMSA beziehen – und das tun sie. Aber das ist noch nicht alles.
Wir waren überrascht, dass selbst bei der Anfrage nach einem TGT für ein neu erstelltes dMSA das Feld previous-keys nicht leer war. Da es gerade erst angelegt wurde, sollte es kein „vorheriges Passwort“ geben. Wir haben diese Tatsache ignoriert, bis wir erkannten, dass etwas uns sehr vertraut vorkam.
Wie in Abbildung 11 dargestellt hatte das zweite Element in der Struktur einen einzelnen Schlüssel des Typs 23 (RC4-HMAC). Dieser Verschlüsselungstyp wird nicht gesaltet, d. h. identische Passwörter generieren identische Schlüssel, selbst über Nutzer hinweg.
Fig. 11: ASN.1 decoded value of the KERB-DMSA-KEY-PACKAGE, decoded at https://pkitools.net/pages/ca/asn1.html
Und dieser Schlüssel hier? Die jahrelange Verwendung dasselbe Passwort in Laborumgebungen macht sich endlich bezahlt. Wir haben ihn sofort erkannt. Es war der Schlüssel zu Aa123456 – dem Passwort, das wir für unser Zielkonto während der Demonstration verwendet haben.
Stellen Sie sich das vor: Der Schlüssel für ein separates Konto endete irgendwie in der Struktur vorherige Schlüssel des dMSA.
Kompromittierung von Schlüsseln in großem Umfang
Was passiert hier also? Und warum?
Der msDS-ManagedAccountPrecededByLink verknüpft das dMSA nicht nur zu Berechtigungszwecken mit dem ersetzten Konto, sondern ermöglicht auch, dass das dMSA seine Schlüssel übernimmt. Das bedeutet, dass dieser Angriff auch dazu verwendet werden kann, die Schlüssel eines beliebigen (oder jedes) Nutzers und Computers in der Domain abzurufen. Mit diesem Schlüssel können wir uns beim Konto authentifizieren.
Obwohl wir die gesamte Implementierung nicht analysiert haben, ist unsere Theorie, dass dieses Verhalten eine nahtlose Kontinuität während der Kontomigration zum Vorteil des Endnutzers gewährleisten soll.
Nehmen wir an, wir haben einen Dienst, der mit einem älteren Dienstkonto ausgeführt wird. Konten in der gesamten Domain fordern Tickets für diesen Dienst an, die mit dem Schlüssel des Legacy-Dienstkontos verschlüsselt werden. Angenommen, wir ersetzen das alte Konto durch ein dMSA, die Migration wird abgeschlossen und das Servicekonto wird durch das dMSA ersetzt – aber das dMSA hat keinen Zugriff auf den Schlüssel des alten Kontos.
Das Ergebnis: Wenn ein Client versucht, sich mit seinem vorhandenen Ticket zu authentifizieren, kann der Server es nicht mit dem neuen dMSA-Schlüssel entschlüsseln, wodurch alle ausgegebenen Tickets unbrauchbar werden, obwohl sie nicht abgelaufen sind.
Um eine solche Serviceunterbrechung zu verhindern, legt das KDC die Schlüssel des vorherigen Kontos in die Schlüsselpaketstruktur des neuen dMSA. Die Schlüssel werden dabei so behandelt, als wären sie die vorherigen Zugangsdaten des dMSA selbst und dadurch kann es „alte“ Tickets entschlüsseln.
Sobald wir das verstehen, ergibt ein weiterer merkwürdiger Umstand plötzlich Sinn. Das Feld current-keys enthält drei Elemente, die jeweils aus einer Ganzzahl (für den Verschlüsselungstyp) und einer Octet-Zeichenfolge (dem entsprechenden Schlüssel) bestehen. Auf dieser Seite finden Sie Informationen zu den Werten des Verschlüsselungstyps. In unserem Fall enthält die Liste Schlüssel für RC4-HMAC, AES256 und AES128. Das Feld previous-keys sieht aber etwas anders aus, es enthält nur einen Schlüssel, der RC4-HMAC entspricht (Abbildung 12). Warum enthält die Liste previous-keys nur eine Art von Schlüsseln und warum ist es ausgerechnet RC4-HMAC?
Fig. 12: KERB-DMSA-KEY-PACKAGE structure, highlighting the different keys
Die Antwort liegt in den Verschlüsselungstypen, die vom ursprünglichen (ersetzten) Konto unterstützt werden. Servicetickets werden nur mit Verschlüsselungstypen verschlüsselt, die der Zielservice unterstützt. Wie im hervorragenden Blogbeitrag von Harmj0y erläutert, steuert das Attribut msDS-SupportedEncryptionTypes dieses Verhalten. Wenn dieses Attribut nicht definiert ist (wie es standardmäßig der Fall ist für Nutzerkonten), verwendet das System standardmäßig nur RC4-HMAC. Daher existiert in previous-keys nur ein RC4-HMAC-Schlüssel.
Mit anderen Worten: Das KDC gibt dem dMSA nur die Schlüssel aus dem ursprünglichen Konto, die erforderlich wären, um vor der Migration ausgestellte Servicetickets zu entschlüsseln. Diese werden basierend auf den Verschlüsselungstypen bestimmt, die vom ursprünglichen Prinzipal unterstützt werden. Sie können dies überprüfen, indem Sie das Attribut msDS-SupportedEncryptionTypes überprüfen.
Die Antwort von Microsoft
Wir haben diese Details über MSRC am 1. April 2025 an Microsoft gemeldet. Nach der Prüfung unseres Berichts und des Proof of Concept bestätigte Microsoft das Problem und seine Gültigkeit. Sie beurteilten es jedoch als eine Schwachstelle mit mittlerem Schweregrad und gaben an, dass sie derzeit nicht den Schwellenwert für sofortige Behebung erreicht.
Laut Microsoft erfordert eine erfolgreiche Ausnutzung, dass der Angreifer bereits spezifische Berechtigungen für das dMSA-Objekt hat. Dies weist auf erhöhte Berechtigungen hin. Als Reaktion auf das Szenario der Erstellung eines neuen dMSA verweist Microsoft auf KB5008383, in dem die Risiken im Zusammenhang mit der Berechtigung CreateChild erläutert werden.
Obwohl wir die Antwort von Microsoft schätzen, müssen wir der Einschätzung des Schweregrads respektvoll widersprechen.
Diese Schwachstelle führt zu einer bisher unbekannten und wirkungsstarken Möglichkeit für einen Missbrauch, die es jedem Nutzer mit CreateChild-Berechtigungen auf einer OE ermöglicht, einen beliebigen Nutzer in der Domain zu kompromittieren und die gleiche zu erhalten wie die Berechtigung zur Replikation von Verzeichnisänderungen, die für DCSync-Angriffe verwendet wird.
Darüber hinaus haben wir keinen Hinweis darauf gefunden, dass aktuelle Branchenpraktiken oder Tools den Zugriff auf CreateChild – oder genauer gesagt auf CreateChild für dMSAs – als kritisches Problem kennzeichnen. Wir glauben, dass dies sowohl die Tarnung als auch die Schwere des Problems unterstreicht.
Erkennung und Abwehr
Erkennung
Um einen potenziellen Missbrauch dieses Angriffsvektors zu erkennen, sollten sich Unternehmen auf die folgenden Bereiche konzentrieren:
Audit-dMSA-Erstellung – Konfigurieren Sie eine SACL, um die Erstellung neuer msDS-DelegatedManagedServiceAccount-Objekte zu protokollieren (Ereignis-ID 5137; Abbildung 13). Achten Sie besonders auf Konten, die normalerweise nicht für die Erstellung von Servicekonten verantwortlich sind.
Fig. 13: Event example of dMSA creation
Attributänderungen überwachen – Konfigurieren Sie eine SACL für Änderungen am Attribut „msDS-ManagedAccountPrecededByLink“ (Ereignis-ID 5136; Abbildung 14). Änderungen an diesem Attribut sind ein starker Indikator für einen versuchten oder erfolgreichen Missbrauch.
Fig. 14: Event example of dMSA link creation
dMSA-Authentifizierung verfolgen – Wenn ein TGT für ein dMSA generiert wird und die Struktur KERB-DMSA-KEY-PACKAGE enthalten ist, protokolliert der Domaincontroller die Ereignis-ID 2946 (Directory Service Log).
Im Feld „Group Managed Service Account Object“ wird (obwohl es sich um ein dMSA und nicht um ein gMSA handelt) der DN der authentifizierten dMSA angezeigt und im Feld „Caller SID“ erscheint „S-1-5-7 “ (Abbildung 15). Häufige oder unerwartete 2946-Ereignisse mit ungewöhnlichen dMSAs sollten untersucht werden.
Fig. 15: Event example of dMSA authentication
Berechtigungen überprüfen – Achten Sie besonders auf Berechtigungen für OEs und Container. Weiterleitungen mit unmäßig vielen Berechtigungen können Missbrauch begünstigen.
Abwehr
Bis ein formaler Patch von Microsoft veröffentlicht wird, sollten Abwehrmaßnahmen darauf ausgerichtet sein, die Fähigkeit zur Erstellung von dMSAs zu begrenzen und die Berechtigungen nach Möglichkeit zu verschärfen.
Abwehrspezialisten sollten alle Prinzipals (Nutzer, Gruppen, Computer) mit Berechtigungen zum Erstellen von dMSAs in der Domain identifizieren und diese Berechtigung nur auf vertrauenswürdige Administratoren beschränken.
Zu diesem Zweck haben wir ein PowerShell-Skript veröffentlicht, das:
Alle nicht standardmäßigen Prinzipals aufgelistet sind, die dMSAs erstellen können
Die OEs auflistet, in denen jeder Prinzipal diese Berechtigung hat
Microsoft hat uns darüber informiert, dass seine technischen Teams an einem Patch arbeiten, und wir werden die Hinweise zur Risikominderung in diesem Blogbeitrag aktualisieren, sobald weitere technische Details verfügbar sind.
Fazit
Diese Studie zeigt, wie selbst engmaschige Berechtigungen, von denen oft angenommen wird, dass sie ein geringes Risiko darstellen, weitreichende Folgen in Active-Directory-Umgebungen haben können. Angreifer sind sehr kreativ. Wenn uns die jüngsten technologischen Fortschritte etwas gelehrt haben, dann dass auch scheinbar gutartige Funktionen in den falschen Händen ernsthafte Folgen haben können. dMSAs wurde als moderne Lösung für die Dienstkontoverwaltung eingeführt, doch Ihre Einführung führte auch zu neuen Komplexitäten – und damit zu neuen Exploit-Möglichkeiten.
Unternehmen sollten die Möglichkeit, dMSAs zu erstellen oder bestehende zu kontrollieren, ebenso gründlich überprüfen wie andere sensible Vorgänge. Die Berechtigungen zum Verwalten dieser Objekte müssen streng eingeschränkt sein, und Änderungen an ihnen sollten regelmäßig überwacht und geprüft werden.
Wir hoffen, dass diese Studie die Risiken aufzeigt, die mit Windows Server 2025 im Allgemeinen – und dMSAs im Besonderen – verbunden sind, und dass sie Abwehrspezialisten dabei unterstützt,, die potenziellen Auswirkungen falsch konfigurierter Berechtigungen besser zu verstehen und abzuwehren.
