BadSuccessor dMSA Privilege Escalation: Wie Nutzer mit geringen Rechten zum Domain Admin werden

BadSuccessor dMSA privilege escalation — von Akamai öffentlich BadSuccessor genannt — ist eine Technik, die delegated Managed Service Accounts (dMSA), eine mit Windows Server 2025 eingeführte Funktion, missbraucht, um einem Nutzer mit geringen Rechten zu erlauben, jedes Konto der Domäne zu imitieren — bis hin zum Domain Admin. Sie wurde vom Akamai-Forscher Yuval Gordon im Mai 2025 dokumentiert und erhielt die Kennung CVE-2025-53779; Microsoft lieferte mit dem Sicherheitsupdate vom 12. August 2025 (KB5064010) einen Fix.

Dieser Artikel erklärt den Mechanismus, warum er einen so großen Teil realer Umgebungen betrifft, und wie man ihn erkennt und behebt — einschließlich dessen, was der Patch tatsächlich geändert hat und was die öffentliche Forschung sagt, worauf man danach noch achten sollte.

Zu benachbarten Active-Directory-Eskalationspfaden siehe Kerberos-Delegation: Unkontrollierte Delegation bis RBCD-Missbrauch und ACL-Missbrauch und DCSync: Wie stille Rechte zum Domain Admin öffnen. BadSuccessor ist ein eigenständiger Mechanismus, der sich von beiden unterscheidet — er verändert weder die ACL noch die Delegationseinstellungen eines bestehenden Kontos; er missbraucht Objekt-Erstellungsrechte auf einer OU, um ein neues Objekt zu fabrizieren. Er ähnelt zudem Shadow Credentials: Missbrauch von msDS-KeyCredentialLink in Active Directory — beide Techniken eskalieren Rechte durch das Schreiben in ein Identitätsverknüpfungs-Attribut statt durch das Knacken eines Anmeldedaten.

Was ist BadSuccessor dMSA Privilege Escalation?

Delegated Managed Service Accounts (dMSA) sind eine Windows-Server-2025-Funktion, die Organisationen erlauben soll, alte Dienstkonten in ein verwaltetes, kennwortloses Identitätsmodell zu migrieren, ohne jede Abhängigkeit neu bereitstellen zu müssen. Teil dieses Migrationsdesigns ist ein „Nachfolge"-Mechanismus: Ein dMSA kann mit einem älteren Konto verknüpft werden, das es ersetzen soll, und Active Directory überträgt während der Übergangsphase einen Teil von dessen Zugriffsrechten.

Warum dMSA überhaupt existiert

Microsoft entwickelte dMSA, um ein reales operatives Problem zu lösen: Alte, eigenständige Dienstkonten tragen oft statische, selten rotierte Kennwörter und breite, dauerhafte Rechte, weil die Migration zu einem verwalteten Identitätsmodell traditionell bedeutete, jede abhängige Anwendung neu bereitzustellen. Das Nachfolgemodell von dMSA — das neue verwaltete Konto mit dem alten, zu ersetzenden Konto zu verknüpfen — sollte diese Migration nahezu transparent machen. BadSuccessor missbraucht das in diese Transparenz eingebaute Vertrauen, nicht einen Fehler in der Kennwortverwaltung selbst.

Der BadSuccessor-Mechanismus

Laut Akamais ursprünglicher Forschung (bestätigt durch Unit 42, Semperis und Tarlogic) missbraucht der Angriff zwei dMSA-Attribute, denen der KDC während der von ihnen dargestellten „Migration" ohne Gegenprüfung vertraut:

• msDS-ManagedAccountPrecededByLink — ein DN-Verweis (Distinguished Name) auf das Konto, das der dMSA „beerben" soll. Öffentliche Forschung beschreibt den KDC vor dem Patch als jemanden, der das PAC (Privilege Attribute Certificate) des Kontos aus dem beliebigen DN in diesem Feld erstellt, ohne zu prüfen, ob tatsächlich eine Migrationsbeziehung besteht.
• msDS-DelegatedMSAState — der Migrationsstatus (0 = keine, 1 = in Bearbeitung, 2 = abgeschlossen).

Schritt für Schritt: So funktionierte der Angriff vor dem Patch

1. Der Angreifer identifiziert eine OU oder einen Container, in dem er CreateChild-Rechte besitzt — laut Akamais Tests ein sowohl verbreitetes als auch selten genau geprüftes Recht.
2. Der Angreifer erstellt ein neues dMSA-Objekt in dieser OU.
3. Der Angreifer schreibt den DN des Zielkontos (zum Beispiel eines Domain Admin) in msDS-ManagedAccountPrecededByLink.
4. Der Angreifer setzt msDS-DelegatedMSAState auf 2 („abgeschlossen"), wodurch die fabrizierte Migration als beendet markiert wird.
5. Öffentliche Berichte beschreiben, dass der KDC vor dem Patch jede nachfolgende Authentifizierung als dMSA anschließend so behandelte, als sei sie eine Fortsetzung der Identität des Zielkontos — und das PAC mit den SIDs und Gruppenmitgliedschaften des Ziels aufbaute, ohne dass das Zielkonto selbst je verändert wurde.

Akamais eigene Tests ergaben, dass 91 % der untersuchten Umgebungen mindestens einen Nicht-Admin-Nutzer mit ausreichenden Rechten hatten, um diesen Angriff durchzuführen — größtenteils, weil CreateChild-Delegation auf OU-Ebene verbreitet und selten genau geprüft ist.

Auswirkung des Patches vom August 2025

Microsofts Update vom 12. August 2025 (KB5064010, CVE-2025-53779) änderte, wie kdcsvc.dll die Nachfolgebeziehung validiert: Die Ticketausstellung erfordert jetzt, dass die Verknüpfung eine echte gegenseitige Kopplung widerspiegelt, statt eine einseitige Schreiboperation auf msDS-ManagedAccountPrecededByLink zu akzeptieren. Das bloße Verweisen eines neu erstellten dMSA auf ein privilegiertes Konto, wie oben beschrieben, führt nach dem Update nicht mehr zu einem Imitations-Ticket.

Microsofts Schweregrad-Einschätzung

MSRC bewertete das gemeldete Problem zunächst als nicht dringlich genug für eine sofortige Behebung und stufte es als moderate Schwere ein, als Akamai es erstmals meldete; es wurde im regulären August-2025-Patch-Tuesday-Zyklus als normaler Fix ausgeliefert, nicht als Out-of-Band-Veröffentlichung. Microsofts aktuelle Einschätzung bewertet die Ausnutzung als „weniger wahrscheinlich", und öffentliche Berichte beschreiben zum Zeitpunkt der Veröffentlichung keine bestätigte Ausnutzung in freier Wildbahn.

Was die Forschung über den Patch sagt

Akamais eigene Folgeforschung („BadSuccessor Is Dead, Long Live BadSuccessor(?)") und ein anschließender Community-Beitrag von AlteredSecurity („BetterSuccessor") beschreiben beide den Patch als das Schließen des direkten, einseitigen Verknüpfungspfads, während sie darauf hinweisen, dass die Forschung zum dMSA-Missbrauch in engeren Szenarien fortgesetzt wurde. Dieser Artikel reproduziert diese Folgetechniken nicht; betrachten Sie den Patch als weitgehend — nicht notwendigerweise vollständig — schließend für den ursprünglichen BadSuccessor-Pfad, und priorisieren Sie die unten stehenden Erkennungs- und Delegations-Härtungsschritte unabhängig vom Patch-Status.

Warum es so weit verbreitet ist

BadSuccessor ist unter AD-Rechteausweitungstechniken ungewöhnlich, weil es keine Fehlkonfiguration im herkömmlichen Sinne erfordert. Es funktioniert gegen das Standard-Berechtigungsmodell von dMSA, sobald ein Windows-Server-2025-DC in der Domäne existiert. Die tatsächliche Exposition entsteht dadurch, wie breit CreateChild-Rechte auf OUs und Containern in realen Umgebungen delegiert werden — oft an Helpdesk-Gruppen, Anwendungsteams oder alte Delegationen, die nie überprüft wurden. Öffentliche Forschung von Semperis und Unit 42 weist beide auf dieselbe Grundursache hin: OU- und Domänenwurzel-Delegationspraktiken, die breiter sind als beabsichtigt, nicht ein einzelner fehlender Patch.

Das schließt direkt an ein Muster an, das in AD-Angriffspfade: Wie sich Fehlkonfigurationen aneinanderreihen behandelt wird: Die gefährlichsten Expositionen sind fast nie ein einzelner kritischer Fehler — es sind angesammelte Delegationen und Berechtigungen, die niemand seit ihrer Einrichtung überprüft hat.

Erkennung

Behebung

1. Zuerst patchen

Wenden Sie das Sicherheitsupdate vom 12. August 2025 (KB5064010 / CVE-2025-53779) auf jeden Windows-Server-2025-Domänencontroller an.

2. CreateChild-Delegation prüfen und einschränken

Überprüfen Sie OU- und Domänenwurzel-Berechtigungen für Konten und Gruppen, die Objekte erstellen können — insbesondere msDS-DelegatedManagedServiceAccount-Objekte — und entfernen Sie Delegationen, die nicht aktiv benötigt werden. Dies ist die Kontrolle, die bestimmt, ob der Angriffspfad überhaupt existiert, unabhängig vom Patch-Status.

3. SACL-basierte Überwachung aktivieren

Konfigurieren Sie die Überwachung für die dMSA-Objekterstellung (Ereignis-ID 5137) und für Änderungen an msDS-ManagedAccountPrecededByLink / msDS-DelegatedMSAState (Ereignis-ID 5136), und alarmieren Sie bei jeder solchen Änderung durch ein nicht privilegiertes Konto.

4. Bestehende dMSAs inventarisieren

Bestätigen Sie, dass jeder dMSA in der Domäne einer legitimen, erwarteten Migration entspricht, und überprüfen Sie den msDS-ManagedAccountPrecededByLink-Wert für jeden einzelnen.

# Alle dMSA-Objekte und ihre Nachfolge-Verknüpfung zur manuellen Überprüfung inventarisieren
Get-ADServiceAccount -Filter "ObjectClass -eq 'msDS-DelegatedManagedServiceAccount'" -Properties msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState |
  Select-Object Name, msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState

Wie EtcSec dies erkennt

Der AD-Schwachstellenkatalog von EtcSec enthält eine dedizierte Prüfung, BADSUCCESSOR_DMSA_ESCALATION, die dieses dMSA-Eskalationsrisiko kennzeichnet. Da die eigentliche Exposition in der Breite der Delegation liegt und nicht in einem einzelnen falsch konfigurierten Objekt, meldet EtcSec zusätzlich DELEGATION_PRIVILEGE-Befunde — breite OU- oder Domänenwurzel-Delegationen — als die zugrunde liegende Bedingung, die BadSuccessor in einer gegebenen Umgebung überhaupt erst ermöglicht, unabhängig davon, ob bereits ein Windows-Server-2025-DC vorhanden ist. Teams, die bereits privilegierte Zugriffsausweitung mit Privilegierter Zugriff Drift Active Directory: Wie Admin-Rechte nach Audits zurückkehren verfolgen, betrachten dasselbe zugrunde liegende Problem — nie überprüfte Delegation — aus einem anderen Blickwinkel.

Primärquellen

• Akamai: BadSuccessor — Abusing dMSA to Escalate Privileges in Active Directory
• Akamai: BadSuccessor Is Dead, Long Live BadSuccessor(?)
• Microsoft Security Update Guide: CVE-2025-53779
• NVD: CVE-2025-53779
• Help Net Security: Microsoft fixes "BadSuccessor" Kerberos vulnerability (CVE-2025-53779)
• Unit 42 (Palo Alto Networks): When Good Accounts Go Bad — Exploiting Delegated Managed Service Accounts in Active Directory
• Semperis: BadSuccessor — How to Detect and Mitigate dMSA Privilege Escalation
• Tarlogic: BadSuccessor — Escalating Privilege Using dMSA Abuse in Active Directory
• AlteredSecurity: BetterSuccessor — Still Abusing dMSA for Privilege Escalation (BadSuccessor After Patch)