Inhalt
Zusammenfassung
- Die Forscher von Akamai haben den Patch von Microsoft für die als BadSuccessor (CVE-2025-53779) bezeichnete Schwachstelle untersucht, um dessen Effektivität zu beurteilen.
- Wir kamen zu dem Schluss, dass der Patch zwar effektiv zur Minderung eines erheblichen Teils des Risikos im Zusammenhang mit BadSuccessor eingesetzt werden konnte, die Technik jedoch in bestimmten Szenarien weiterhin relevant ist.
- In diesem Blogbeitrag werden zwei Techniken beschrieben, die auf denselben Prinzipien von BadSuccessor basieren und es Angreifern ermöglichen können, Anmeldedaten zu extrahieren und Nutzerkonten zu kompromittieren.
Auf der DEF CON 2025 haben wir die Geschichte von BadSuccessor vorgestellt – eine Schwachstelle im Active Directory (AD), die den neuen Kontotyp von Windows Server 2025 ausnutzt: Delegated Managed Service Account (dMSA). Durch diese Sicherheitslücke kann ein Nutzer mit niedrigen Berechtigungen direkt zum Domainadministrator aufsteigen.
Binnen weniger als einer Woche hat Microsoft der Schwachstelle die ID CVE-2025-53779 zugewiesen und einen Patch geliefert. Der direkte Eskalationspfad wurde damit geschlossen.
In diesem Blogbeitrag analysieren wir den Patch, erklären, was sich geändert hat und was nicht, und zeigen, dass BadSuccessor zwar nicht mehr sofort zur Eskalation führt, die zugrunde liegenden Mechanismen aber dennoch relevant sind.
Wenn Sie die ursprüngliche Geschichte verpasst haben, lesen Sie unseren vorherigen BadSuccessor-Blogbeitrag.
Was war BadSuccessor (Pre-Patch)?
BadSuccessor missbraucht dMSA – einen Windows Server 2025-Kontotyp, der die Verwaltung von Dienstkonten vereinfachen soll. Wenn ein kontrollierter dMSA mit einem Konto in AD verknüpft wurde, behandelte das Key Distribution Center (KDC) das DMSA während der Authentifizierung als Nachfolger.
Diese einfache Verknüpfung hat gleichzeitig zwei gefährliche Folgen verursacht: Sie hat die effektiven Berechtigungen des Zielkontos in das Berechtigungsattribut-Zertifikat (Privilege Attribute Certificate, PAC) des dMSA integriert und ein dMSA-Schlüsselpaket zurückgegeben, das die Kerberos-Schlüssel (Zugangsdaten) des Ziels enthielt. Keine Gruppenänderungen, keine spezialisierten Tools – nur eine unscheinbare Verknüpfung und integrierte Windows-Dienstprogramme.
Entscheidend war, dass die Hürde niedrig war: Die Kontrolle über eine beliebige Organisationseinheit (OE) war ausreichend. Ein Angreifer konnte dort ein dMSA erstellen und mit einem beliebigen Ziel verknüpfen – selbst Domaincontroller, Domainadministratoren, geschützte Nutzer oder Konten, die als „sensibel und nicht übertragbar“ gekennzeichnet waren – und diese sofort kompromittieren.
Einen tieferen Einblick und eine Demo finden Sie in unserem vorherigen BadSuccessor-Blogbeitrag.
Microsoft-Patch für CVE-2025-53779
Vor dem Patch war unsere Annahme einfach: Der Kern-Bug war, dass keine echte Migration über den rootDSE-Vorgang migrateADServiceAccount durchgeführt werden musste. Es genügte, die Verknüpfungsattribute auf einem dMSA zu bearbeiten, damit das KDC diese akzeptiert.
Wir sind davon ausgegangen, dass Microsoft dieses Attribut schützt, sodass es nur durch den korrekten Migrationspfad festgelegt werden konnte, wodurch „simulierte“ Migrationen verhindert würden.
Nach Aufspielen des Patches haben wir den offensichtlichen Test durchgeführt: Als Nutzer, der ein dMSA steuert, habe ich das Verknüpfungsattribut genauso geschrieben wie zuvor. Der Schreibvorgang war dennoch erfolgreich – es gab keinen neuen Schutz für das Attribut – und ich konnte ein dMSA mit einem beliebigen Konto verknüpfen. Als ich mich jedoch als dMSA authentifiziert habe, um die Berechtigungen und Schlüssel des Ziels zu übernehmen, weigerte sich das KDC, ein Ticket auszustellen (Abbildung).
The error when authenticating a dMSA with a one-sided link — failure occurs at ticket issuance
Das hat uns dazu veranlasst, das KDC zu untersuchen. Änderungen in kdcsvc.dll zwingen das KDC, die Beziehung zum Zeitpunkt des Tickets zu validieren. Eine einseitige Verknüpfung vom dMSA zum Ziel funktioniert nicht mehr.
Bei unserem Test war der einzige Weg, um ein gültiges Ticket für ein dMSA zu erhalten, das nach dem Patch mit einem anderen Konto verknüpft ist, die gegenseitige Verknüpfung: Das Ziel muss auch das dMSA referenzieren, analog zum Ergebnis einer echten Migration. Anders als zuvor erfordert eine „erfolgreiche Durchführung“ nun die Kontrolle über das Objekt des Kontos selbst, nicht nur das dMSA.
Das bedeutet, dass die Patchüberprüfung in der KDC-Validierung implementiert wurde, nicht in verzeichnisseitigen Schutzmaßnahmen für das Attribut. Das Attribut kann noch geschrieben werden, aber das KDC wird es nur akzeptieren, wenn die Kopplung wie eine legitime Migration aussieht.
Eine weitere interessante Tatsache ist, dass die Migration auch dann funktioniert, wenn der Zielaccount aktiviert bleibt (während der formale Migrationsablauf ihn nach Abschluss deaktiviert).
Was ist BadSuccessor (Post-Patch)?
Obwohl die Schwachstelle gepatcht werden kann, lebt BadSuccessor als Technik weiter, d. h., die KDC-Überprüfung entfernt den Eskalationspfad vor dem Patch, behebt aber nicht das gesamte Problem.
Da der Patch keinen Schutz für das Verknüpfungsattribut eingeführt hat, kann ein Angreifer dennoch ein anderes Konto übernehmen, indem er ein kontrolliertes dMSA und ein Zielkonto verknüpft.
Diese Tatsache ermöglicht (mindestens) zwei praktische Primitive, die Verteidiger erwarten und überwachen sollten:
- Erwerb von Zugangsdaten und Berechtigungen
- Dump der Zielzugangsdaten in bereits eigenen Domains
Primitiv 1 – Erfassung von Zugangsdaten und Berechtigungen (Alternative für Schattenanmeldedaten)
Wenn ein Angreifer heute einen Ziel-Prinzipal kontrolliert (z. B. GenericWrite auf einem Nutzer oder Computer hat), kann er ihn entweder durch Hinzufügen von Schattenzugangsdaten oder durch gezielte Kerberoasting-Angriffe kompromittieren.
BadSuccessor eröffnet einen neuen Angriffspfad – wenn ein Angreifer ein dMSA steuert, kann er eine gegenseitige Kopplung durchführen und ein Ticket für das dMSA anfordern. Dadurch kann er:
- mit den effektiven Berechtigungen des Ziels agieren, während die dMSA-Identität verwendet wird (nützlich, wenn der Zielaccount genau überwacht wird)
- die Zielschlüssel aus dem dMSA-Schlüsselpaket abrufen, was schneller und zuverlässiger ist, als das Hinzufügen von SPNs und Kerberoasting (das nutzerspezifisch ist, zunächst einer erfolgreichen Kompromittierung bedarf und stärker auffällt)
- die Telemetrie verschieben, damit der Angriff nur Protokolle zu dMSA-Ziellinkbearbeitungen↔und Ticketausstellung (TGT) an das dMSA generiert
Primitiv 2 – Gezielter Dump von Anmeldedaten in bereits eigenen Domains (DCSync-Alternative)
In einer bereits kompromittierten Domain bietet BadSuccessor eine Möglichkeit, die Schlüssel der Prinzipals durch die normale Ticketausstellung abzulegen. Dies ist kein Ersatz für DCSync, sondern ein anderer Pfad mit unterschiedlichen Signalen, die vorhandene Erkennungen umgehen können.
Wie die Ausnutzung von BadSuccessor nach dem Patch erkannt werden kann
BadSuccessor kann nach dem Patch von Microsoft noch über zwei verschiedene Primitive ausgenutzt werden. Um eine mögliche Aktivität zu erkennen, versuchen Sie es mit einer der folgenden Maßnahmen:
- Systemzugriffskontrolllisten (SACLs): Prüfen Sie die Erstellung von dMSAs und Änderungen an den Migrationslinkattributen auf beiden Seiten – die Verknüpfung des dMSA und die Verknüpfung des überholten/vorhergehenden Kontos
- Verhaltensbezogene Hinweise:
- Wiederholte Protokolleinträge, die darauf hinweisen, dass ein dMSA-Kennwort in einem kurzen Zeitfenster abgerufen wurde
- Ein aktivierter Nutzer scheint mit einem dMSA verknüpft zu sein (eher ungewöhnlich)
- Ein zuvor deaktivierter Nutzer wird mit einem neuen dMSA verknüpft
Weitere Informationen zur Erkennung finden Sie in unserem vorherigen BadSuccessor-Blogbeitrag.
Abwehr
- Umgehend patchen. Aktualisieren Sie Ihre Windows Server 2025-Domaincontroller für CVE-2025-53779.
- Reduzieren Sie die Angriffsfläche. Prüfen Sie die Berechtigungen für OUs, Container und dMSA-Objekte. Straffen Sie die Delegationen und entfernen Sie umfassende Berechtigungen, sodass nur Administratoren der Ebene 0 dMSAs und deren Migrationsverknüpfungsattribute erstellen oder ändern können.
Fazit
Microsoft hat den direkten Eskalationspfad geschlossen, indem eine gegenseitige Kopplung erforderlich wurde, die wie eine echte Migration aussieht. Ein einseitiger Link führt nicht mehr zu Berechtigungen oder Schlüsseln. Aber BadSuccessor war schon immer mehr als nur ein Bug – es ist eine Technik. Dies ist ein zunehmendes Problem innerhalb der Branche – selbst wenn eine Schwachstelle beseitigt wird, finden Cyberkriminelle immer noch Schlupflöcher.
BadSuccessor wirkt auch nach dem Patch weiter, (1) als ein Primitiv zum Erwerb von Zugangsdaten und Berechtigungen, wenn ein Angreifer einen Ziel-Prinzipal und ein dMSA steuert, und (2) als ein replikationsfreier Pfad zum Extrahieren von Geheimnissen in bereits eigenen Domains.
Diese Ergebnisse sind nicht neu – es gibt andere Möglichkeiten, beides zu erreichen. Sie sind jedoch mit unterschiedlichen Anforderungen und Telemetrieanforderungen ausgestattet, weshalb ein Angreifer BadSuccessor bevorzugen könnte.
Eine letzte Anmerkung
Ein kurzer Hinweis zu dMSA selbst: Aus meiner Sicht stellt das Post-Patch-dMSA eine starke Ergänzung zur AD-Sicherheit dar. Bei bestimmungsgemäßer Verwendung verbessert es die Hygiene des Dienstkontos und reduziert langlebige Geheimnisse. Ich werde in einem nachfolgenden Blogbeitrag mehr über dMSA schreiben und darlegen, warum ich der Meinung bin, dass es eine großartige Ergänzung ist. Schauen Sie bald wieder vorbei!
Tags
