Ein Feature, das zum Angriffsvektor wurde
Wenn Microsoft ein neues Sicherheitsfeature einführt, erwartet niemand, dass genau dieses Feature den direkten Weg zum Domain Admin öffnet. Genau das ist mit Delegated Managed Service Accounts (dMSA) in Windows Server 2025 passiert. Was als elegante Lösung für das Altlastenproblem statischer Service-Account-Passwörter konzipiert war, enthielt einen fundamentalen Designfehler im Migrationsmechanismus — und dieser Fehler erlaubte es jedem Benutzer mit Schreibrechten auf einer beliebigen Organisationseinheit, sich zum Domain Admin zu erheben.
Sicherheitsforscher Yuval Gordon von Akamai entdeckte die Schwachstelle und taufte sie „BadSuccessor". Die Bezeichnung trifft den Kern: Ein Angreifer konfiguriert einen dMSA als vermeintlichen Nachfolger eines privilegierten Kontos, und der Kerberos-Dienst übernimmt gutgläubig sämtliche Berechtigungen des Originals. Kein Passwort-Reset, keine Gruppenänderung, kein Alarm — nur ein einziges AD-Attribut, das den Unterschied zwischen einem normalen Benutzer und einem Domain Admin ausmacht.
Was dMSA eigentlich lösen sollte
Um die Tragweite von BadSuccessor zu verstehen, lohnt ein Blick auf das Problem, das dMSA adressiert. In der Praxis finden wir in Assessments regelmäßig Service Accounts mit Passwörtern, die seit Jahren nicht rotiert wurden. Diese Konten sind das primäre Ziel für Kerberoasting: Ein normaler Domänenbenutzer fordert ein Service Ticket an, extrahiert den Hash und knackt das Passwort offline.
Group Managed Service Accounts (gMSA) lösen dieses Problem teilweise — das Passwort wird automatisch rotiert und vom Domain Controller verwaltet. Der Haken: Die Migration eines bestehenden Service Accounts auf gMSA erfordert ein komplett neues Konto und die manuelle Neukonfiguration aller betroffenen Dienste. Für Umgebungen mit Dutzenden oder Hunderten von Service Accounts ist das ein erheblicher Aufwand, der in der Praxis häufig aufgeschoben wird.
dMSA sollte genau diese Migrationshürde beseitigen. Der neue Kontotyp kann einen bestehenden Service Account in-place ablösen, einschließlich aller Berechtigungen und Service Principal Names. Während einer Lernphase ermittelt das System automatisch, welche Maschinen den Account nutzen. Nach Abschluss wird die Authentifizierung transparent auf den dMSA umgestellt, das Passwort des Originals deaktiviert. Zusätzlich bindet dMSA die Authentifizierung an eine konkrete Maschinenidentität und integriert sich mit Credential Guard, sodass die Credentials in einer virtualisierten Sicherheitsumgebung geschützt werden.
Eine elegante Lösung also — mit einer fatalen Schwachstelle im Migrationsprotokoll.
Der Angriff im Detail
Die entscheidenden Attribute
Der BadSuccessor-Angriff dreht sich um zwei AD-Attribute, die den dMSA-Migrationsprozess steuern:
| Attribut | Funktion | Missbrauch |
|---|---|---|
msDS-ManagedAccountPrecededByLink |
Verweist auf den abzulösenden Service Account | Angreifer setzt hier den Distinguished Name eines Domain Admins |
msDS-DelegatedMSAState |
Migrationsstatus (0 = neu, 1 = aktiv, 2 = abgeschlossen) | Angreifer setzt direkt auf 2 (abgeschlossen) |
Der Angriffsablauf
Der Angriff erfordert lediglich CreateChild-Rechte auf einer beliebigen Organisationseinheit — eine Berechtigung, die in den meisten AD-Umgebungen großzügig delegiert wird. In Akamais Untersuchung verfügten in 91 % der analysierten Umgebungen Benutzer außerhalb der Domain-Admins-Gruppe über diese Rechte.
Der konkrete Ablauf sieht wie folgt aus: Der Angreifer erstellt zunächst ein neues dMSA-Objekt in einer OU, auf die er Schreibzugriff hat. Anschließend schreibt er den Distinguished Name eines privilegierten Kontos — etwa eines Domain Admins oder des KRBTGT-Accounts — in das Attribut msDS-ManagedAccountPrecededByLink. Danach setzt er msDS-DelegatedMSAState auf den Wert 2, was dem Domain Controller signalisiert, dass die Migration abgeschlossen ist.
Wenn der Angreifer nun ein Kerberos-Ticket für den dMSA anfordert, geschieht das Entscheidende: Das Key Distribution Center (KDC) auf dem Domain Controller liest das Migrationsattribut, erkennt den vermeintlichen Vorgänger und kopiert dessen Gruppenmitgliedschaften in das Ticket-Granting Ticket (TGT) des dMSA. Der Angreifer erhält ein gültiges Kerberos-Ticket mit Domain-Admin-Berechtigungen — ohne jemals das Passwort des Domain Admins zu kennen oder dessen Konto zu modifizieren.
Warum klassische Detection versagt
BadSuccessor ist aus Sicht der Verteidigung besonders tückisch, weil der Angriff keine der üblichen Warnsignale auslöst. Es findet keine Änderung an Gruppenmitgliedschaften statt, die ein SIEM erfassen würde. Das Zielkonto wird nicht modifiziert — kein Passwort-Reset, keine Attributänderung. Es gibt kein auffälliges Login-Event, da sich der Angreifer mit einem legitimem dMSA-Konto authentifiziert. Und klassische Tools wie BloodHound erkannten diesen Angriffspfad initial nicht, weil die dMSA-Migrationsbeziehung in der Standard-Datenerfassung nicht abgebildet war.
Der Angriff umgeht damit die meisten etablierten Detection-Strategien für Active-Directory-Kompromittierungen. Während Techniken wie DCSync oder Golden Ticket spezifische Signaturen hinterlassen, bewegt sich BadSuccessor innerhalb der vorgesehenen Funktionalität des Migrationsmechanismus — nur eben mit manipulierten Eingabedaten.
Betroffene Umgebungen
Ein verbreitetes Missverständnis lautet: „Wir nutzen keine dMSAs, also sind wir nicht betroffen." Das Gegenteil war der Fall. Die einzige Voraussetzung für den Angriff war die Präsenz eines einzigen Windows Server 2025 Domain Controllers in der Umgebung. Sobald dieser das AD-Schema um die dMSA-Attribute erweitert hatte, konnte jeder Benutzer mit OU-Schreibrechten den Angriff ausführen — unabhängig davon, ob dMSAs produktiv genutzt wurden oder nicht.
Das Schema-Update erfolgt automatisch beim Hochstufen eines Windows Server 2025 zum Domain Controller. Viele Organisationen, die einen neuen DC für Tests oder eine schrittweise Migration bereitgestellt hatten, waren sich nicht bewusst, dass sie damit die Angriffsfläche für ihre gesamte Domäne verändert hatten.
Besonders gefährdete Szenarien
In der Praxis sind bestimmte Konstellationen besonders anfällig. Hybride Umgebungen, in denen ein neuer Windows Server 2025 DC neben älteren DCs betrieben wird, kombinieren die erweiterte Angriffsfläche mit häufig gewachsenen, unbereinigten Delegationsstrukturen. Managed-Service-Provider, die für mehrere Kunden OUs mit delegierten Berechtigungen verwalten, schaffen unbeabsichtigt Cross-Tenant-Risiken. Und Umgebungen mit automatisierter Provisionierung — etwa über ITSM-Systeme, die Benutzerkonten per LDAP anlegen — haben in der Regel genau die CreateChild-Rechte, die BadSuccessor ausnutzt.
Auch die Angriffskette selbst verdient Beachtung. BadSuccessor ist nicht nur ein einzelner Exploit, sondern ein wirkungsvoller Baustein in komplexeren Angriffen. Ein Angreifer, der über Phishing oder Social Engineering Zugang zu einem Helpdesk-Konto erlangt hat, kann sich über BadSuccessor direkt zum Domain Admin eskalieren — ohne die üblichen Zwischenschritte wie Lateral Movement oder Credential Harvesting, die traditionelle Erkennungssysteme abfangen würden. Besonders in Ransomware-Szenarien verkürzt das die Zeit von der initialen Kompromittierung bis zur vollständigen Domain-Übernahme erheblich — von Tagen auf Minuten.
Timeline und Microsofts Reaktion
Die Chronologie der Schwachstelle zeigt ein in der Branche leider bekanntes Muster bei der Risikobewertung neuer Angriffsvektoren:
| Datum | Ereignis |
|---|---|
| 1. April 2025 | Akamai meldet die Schwachstelle an Microsoft |
| Mai 2025 | Microsoft stuft das Risiko als „Moderate" ein — unterhalb der Schwelle für ein sofortiges Sicherheitsupdate |
| 21. Mai 2025 | Akamai veröffentlicht die technische Analyse und Proof-of-Concept-Tools |
| Mai–Juni 2025 | Weitere PoC-Exploits erscheinen, darunter SharpSuccessor für .NET-Umgebungen |
| August 2025 | Microsoft veröffentlicht den Patch unter CVE-2025-53779 |
Microsofts initiale Einstufung als „Moderate" sorgte in der Security-Community für erhebliche Kritik. Die Begründung — dass der Angreifer bereits Schreibrechte auf einer OU benötigt — ignorierte die Realität, dass genau diese Rechte in den meisten Umgebungen breit delegiert werden. Es ist übliche Praxis, Helpdesk-Teams, Provisioning-Systemen oder Service Desks die Berechtigung zur Erstellung von Benutzer- und Computerobjekten in bestimmten OUs einzuräumen. Was vorher als harmlose Verwaltungsaufgabe galt, wurde durch BadSuccessor zu einem direkten Weg zur Domain-Übernahme.
Die Veröffentlichung der Proof-of-Concept-Tools durch Akamai erhöhte den Druck. Neben dem originalen Python-basierten PoC erschien mit SharpSuccessor eine .NET-Implementierung von Logan Goins, die sich nahtlos in bestehende Angriffs-Frameworks wie Cobalt Strike integrieren ließ. Die breite Verfügbarkeit funktionsfähiger Exploits machte deutlich, dass die Schwachstelle nicht nur ein theoretisches Risiko darstellte, sondern aktiv in Angriffsketten eingesetzt werden konnte. Microsoft reagierte schließlich im August 2025 mit dem offiziellen Patch.
Gegenmaßnahmen
Patch installieren
Seit August 2025 steht der offizielle Patch (CVE-2025-53779) zur Verfügung. Microsoft hat die Validierung im KDC verschärft: Ein einseitiger Migrationslink im dMSA-Objekt genügt nicht mehr — der KDC prüft nun, ob eine tatsächliche, beidseitige Migrationsbeziehung vorliegt. Organisationen, die den Patch noch nicht eingespielt haben, sollten dies priorisiert nachholen.
Schema-Level-Härtung
Als zusätzliche Sicherheitsebene — oder als Sofortmaßnahme vor dem Patch — lässt sich das Attribut msDS-ManagedAccountPrecededByLink auf Schema-Ebene gegen reguläre LDAP-Schreiboperationen sperren. Die Methode setzt die systemOnly-Eigenschaft des Attributs auf TRUE, sodass nur noch die offiziellen PowerShell-Cmdlets (Start-ADServiceAccountMigration, Complete-ADServiceAccountMigration) das Attribut über operationelle Schreibvorgänge setzen können.
Diese Maßnahme wirkt auf Forest-Ebene, ist reversibel und kann auch dann angewendet werden, wenn kein Windows Server 2025 DC im Einsatz ist — als präventive Absicherung für zukünftige Upgrades. Für Organisationen, die dMSA-Migrationen aktiv durchführen, lässt sich die Sperre temporär deaktivieren und anschließend wieder aktivieren.
OU-Berechtigungen auditieren
BadSuccessor hat einen blinden Fleck in vielen Berechtigungsmodellen offengelegt: CreateChild-Rechte auf OUs wurden selten als sicherheitskritisch betrachtet. Organisationen sollten systematisch prüfen, welche nicht-privilegierten Konten über Schreibrechte auf Organisationseinheiten verfügen. Akamai stellt hierfür das PowerShell-Skript Get-BadSuccessorOUPermissions.ps1 bereit.
Die Ergebnisse dieser Prüfung sollten zum Anlass genommen werden, das Delegationsmodell grundlegend zu überarbeiten. Provisionierung von Konten sollte über dedizierte Service Accounts mit eng begrenzten Berechtigungen erfolgen — nicht über persönliche Benutzerkonten von Helpdesk-Mitarbeitern. Ein sauber implementiertes Tiering-Modell hätte die Auswirkungen von BadSuccessor erheblich begrenzt, da Tier-0-Konten (Domain Admins, KRBTGT) in geschützten OUs mit restriktiven ACLs liegen. Wer sein Delegationsmodell im Rahmen eines umfassenden Identity & Access Hardening überarbeitet, adressiert nicht nur BadSuccessor, sondern eine ganze Klasse von Angriffen, die auf überprivilegierte OU-Berechtigungen setzen.
Detection implementieren
Auch nach dem Patch sollte die Erstellung und Modifikation von dMSA-Objekten überwacht werden. Die relevanten Windows-Sicherheitsereignisse sind:
| Event-ID | Bedeutung | Relevanz |
|---|---|---|
| 5137 | Neues AD-Objekt erstellt | dMSA-Erstellung erkennen |
| 5136 | AD-Attribut geändert | Änderungen an Migrationsattributen überwachen |
| 2946 | KDC: TGT-Ausstellung für dMSA | Unerwartete dMSA-Authentifizierungen erkennen |
Diese Events sollten in das zentrale SIEM eingespeist und mit Alerting-Regeln versehen werden. Besonderes Augenmerk verdienen dMSA-Objekte, deren msDS-ManagedAccountPrecededByLink auf privilegierte Konten verweist — insbesondere auf Mitglieder der Gruppen Domain Admins, Enterprise Admins oder auf das KRBTGT-Konto.
Über die Event-basierte Erkennung hinaus empfiehlt sich eine regelmäßige Bestandsaufnahme aller existierenden dMSA-Objekte in der Domäne. Ein einfacher LDAP-Filter auf die Objektklasse msDS-DelegatedManagedServiceAccount liefert eine vollständige Liste. Jedes dMSA-Objekt, das nicht durch einen dokumentierten Migrationsprozess erstellt wurde, sollte als potenzieller Angriffsindikator behandelt werden. Spezialisierte AD-Security-Tools wie Semperis Directory Services Protector bieten mittlerweile dedizierte Indicators of Exposure (IOE) und Indicators of Compromise (IOC) für dMSA-Missbrauch.
dMSA sicher einsetzen
Trotz BadSuccessor bleibt dMSA ein sinnvolles Werkzeug für die Service-Account-Migration — vorausgesetzt, die Rahmenbedingungen stimmen. Organisationen, die dMSA produktiv nutzen wollen, sollten den Migrationsprozess als Change-Management-Verfahren behandeln. Jede Migration wird dokumentiert, genehmigt und in einem definierten Wartungsfenster durchgeführt. Die Schema-Level-Sperre auf msDS-ManagedAccountPrecededByLink bleibt standardmäßig aktiv und wird nur für die Dauer der Migration aufgehoben.
Microsoft empfiehlt für die Lernphase der Migration eine Dauer von mindestens zwei Kerberos-Ticket-Lebenszeiten — das entspricht in der Standardkonfiguration 14 Tagen. In dieser Phase ermittelt der Domain Controller automatisch, welche Maschinen den ursprünglichen Service Account nutzen, und befüllt die Zugriffsliste des dMSA. Erst nach Abschluss dieser Phase sollte die Migration mit Complete-ADServiceAccountMigration finalisiert werden. Ein voreiliger Abschluss kann dazu führen, dass berechtigte Systeme den Zugriff verlieren.
Die privilegierten Konten — Domain Admins, Enterprise Admins, KRBTGT und Konten in Tier-0-OUs — sollten zusätzlich über explizite Deny-ACEs auf dem msDS-ManagedAccountPrecededByLink-Attribut geschützt werden. So wird selbst bei einer temporären Aufhebung der Schema-Sperre verhindert, dass diese Konten als Migrationsziel missbraucht werden können. Diese Schutzmaßnahme ist unabhängig vom Patch und stellt eine dauerhafte Absicherung dar, die auch gegen zukünftige, noch unbekannte Varianten des Angriffs wirkt.
Was BadSuccessor über AD-Sicherheit lehrt
BadSuccessor reiht sich in eine wachsende Liste von Schwachstellen ein, die nicht auf Implementierungsfehler zurückgehen, sondern auf Designentscheidungen in der AD-Architektur. Wie bei Shadow Credentials, AD CS-Missbrauch oder Pass-the-Hash liegt das Problem nicht in einem Bug, der gefixt wird und dann erledigt ist. Es liegt in der fundamentalen Art, wie Active Directory Vertrauen und Berechtigungen verwaltet.
Jedes neue Feature, das Microsoft dem AD hinzufügt — dMSA, Entra ID-Synchronisierung, Certificate Services — erweitert die Angriffsfläche. Gleichzeitig bleiben die Grundprinzipien der Verteidigung dieselben: Least Privilege, saubere Tier-Trennung, restriktive Delegationen und kontinuierliches Monitoring. Organisationen, die diese Grundlagen konsequent umsetzen, sind gegen neue Angriffsvektoren wie BadSuccessor deutlich widerstandsfähiger — auch bevor ein Patch verfügbar ist.
Die Parallele zu anderen AD-Schwachstellen der letzten Jahre ist auffällig. ESC1 bis ESC13 bei AD CS, die Missbrauchspfade über RBCD (Resource-Based Constrained Delegation) und die verschiedenen Relay-Angriffe auf NTLM — all diese Schwachstellen teilen ein Muster: Funktionalität, die für legitime Verwaltungsaufgaben konzipiert wurde, wird durch fehlende Validierung am Eintrittspunkt zum Angriffsvektor. Die Verteidigung muss deshalb über einzelne Patches hinausdenken und sich auf das Berechtigungsmodell als Ganzes konzentrieren.
Die zentrale Lehre aus BadSuccessor ist dabei nicht technischer Natur. Sie lautet: Delegierte Berechtigungen, die seit Jahren als harmlos galten, können durch ein einziges Schema-Update zu kritischen Angriffsvektoren werden. Wer sein AD-Berechtigungsmodell nicht regelmäßig überprüft und an neue Funktionen anpasst, bewegt sich auf dünnem Eis. Ein Privileged Access Management-Konzept mit Just-in-Time-Zugriff und regelmäßigen Berechtigungsreviews ist keine optionale Verbesserung, sondern eine Grundvoraussetzung für jede Organisation, die Active Directory als Rückgrat ihrer IT-Infrastruktur betreibt.
Handlungsempfehlung für Unternehmen
Für Organisationen, die Windows Server 2025 bereits im Einsatz haben oder den Einstieg planen, ergeben sich folgende priorisierte Maßnahmen:
Der Patch CVE-2025-53779 sollte auf allen Domain Controllern installiert sein. Parallel dazu empfiehlt sich die Schema-Level-Härtung des Migrationsattributs als Defense-in-Depth-Maßnahme — auch gepatchte Umgebungen profitieren von dieser zusätzlichen Sicherheitsebene, da sie vor möglichen Patch-Umgehungen oder verwandten Angriffstechniken schützt.
Ein umfassendes Audit der OU-Berechtigungen identifiziert überprivilegierte Konten, die für BadSuccessor oder ähnliche Angriffe missbraucht werden könnten. Der Fokus liegt dabei nicht nur auf CreateChild-Rechten, sondern auf allen Schreibberechtigungen, die die Erstellung oder Modifikation von Managed Service Accounts ermöglichen. Die Ergebnisse sollten in ein bereinigtes Delegationsmodell münden, das dem Least-Privilege-Prinzip folgt.
Die Implementierung spezifischer SIEM-Regeln für dMSA-bezogene Events schließt die Überwachungslücke. Organisationen, die noch kein Active-Directory-spezifisches Monitoring betreiben, sollten BadSuccessor als Anlass nehmen, ihre Detection-Fähigkeiten grundlegend zu evaluieren — dMSA-Missbrauch ist nur einer von vielen Angriffsvektoren, die ohne dediziertes AD-Monitoring unsichtbar bleiben. Angriffstechniken wie Kerberoasting, DCSync oder Golden Ticket hinterlassen ebenfalls spezifische Event-Signaturen, die nur dann erkannt werden, wenn die entsprechenden Audit-Policies konfiguriert und die Events zentral ausgewertet werden.
Für Unternehmen, die den Einstieg in Windows Server 2025 noch planen, bietet sich die Gelegenheit, das AD-Berechtigungsmodell und die Detection-Infrastruktur vor dem Upgrade zu evaluieren und zu härten — nicht erst danach, wenn die neuen Angriffsflächen bereits aktiv sind.
Ein gehärtetes Active Directory ist die wichtigste Einzelmaßnahme gegen Ransomware und laterale Bewegung. Unser Identity & Access Hardening umfasst die vollständige Implementierung des Tiering-Modells, Angriffspfad-Analyse, OU-Berechtigungsaudits und Detection-Engineering — zugeschnitten auf Ihre AD-Umgebung. Jetzt Assessment anfragen.