[English]In Windows Server 2025 wurden delegated Managed Service Accounts (dMSA) neu eingeführt. Deren Design ermöglicht schwerwiegende Angriffe auf Managed Service Accounts und Active Directory-Ressourcen. Semperis-Research hat nun mit Golden dMSA ein Tool entwickelt, das die Logik des Angriffs enthält und dabei hilft, die Angriffsmechanismen besser zu verstehen und Abwehrmaßnahmen einzuleiten.
Was sind dMSAs?
Microsoft hat in Windows Server 2025 delegierte verwaltete Dienstkonten (dMSAs) eingeführt. Ein dMSA ist ein neuer Typ von Dienstkonto im Active Directory (AD), der die Möglichkeiten von gMSAs (Group Managed Service Accounts) erweitert. Eine dMSA wird in der Regel erstellt, um ein bestehendes Dienstkonto zu ersetzen.
Dabei ermöglicht ein dMSA, bestehende nicht verwaltete Dienstkonten zu migrieren, indem sie nahtlos in dMSAs umgewandelt werden. Um einen nahtlosen Übergang zu ermöglichen, kann eine dMSA die Berechtigungen des alten Kontos beim Migrationsprozess "erben". Durch die Migration wird das dMSA eng an das abgelöste Konto gekoppelt.
Rückblick auf BadSuccessor (dMSA Privilegien-Erhöhung)
Der Akamai-Sicherheitsforscher Yuval Gordon hatte durch Analyse des Migrationsvorgangs in Windows Server 2025 eine Schwachstelle in der Funktion "Delegated Managed Service Account" (dMSA) entdeckt, die es Angreifern ermöglicht, jeden Benutzer in der Active Directory (AD) zu kompromittieren. Ich hatte dies im Mai 2025 in Blog-Beiträgen (siehe Artikellinks am Beitragsende) angesprochen.
Golden dMSA-Angriff auf Active Directory
Semperis Sicherheitsforscher Adi Malyanker hat sich die Funktion "Delegated Managed Service Account" (dMSA) unter Windows Server 2025 genauer angesehen und ist ebenfalls auf einen kritischen Designfehler gestoßen. Da der Designfehler die Passwortgenerierung mittels Brute-Force stark vereinfacht, ist die Ausnutzung wenig komplex, erfordert aber bestimmte Voraussetzungen (Kompromittierung eines Forest).
Das Problem wurde dem Microsoft Security Response Center (MSRC) am 27. Mai 2025 gemeldet. Am 8. Juli 2025 antwortete Microsoft sinngemäß, "wenn Angreifer über die Geheimnisse verfügen, die zur Ableitung des erforderlichen Schlüssels verwendet wurden, können sie sich als dieser Benutzer authentifizieren. Diese Funktionen waren nie dazu gedacht, vor einer Kompromittierung eines Domänencontrollers zu schützen."
Die Gefahr ist aber, dass Angreifer Golden dMSA benutzen, um sich unbemerkt im Active Directory auszubreiten und persistent einzunisten. Die Details der Entdeckung sowie der Ablauf eines Angriffs wird im Semperis-Beitrag Golden dMSA: What Is dMSA Authentication Bypass? offen gelegt. Nachfolgend ziehe ich einige Informationen für Administratoren heraus.
Golden dMSA-Angriff
Der Golden dMSA genannte Angriff ermöglicht es Thread-Akteuren, die Authentifizierung zu umgehen und Passwörter für alle dMSAs und gMSAs und die damit verbundenen Dienstkonten zu generieren.
Der Angriff nutzt eine kryptografische Schwachstelle beim Design 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. Dadurch wird die Brute-Force-Passwortgenerierung rechnerisch trivial.
Große Wirkung, aber Risiko mäßig
Dieser Angriff kann laut dem Semperis-Sicherheitsforscher sowohl zur Persistenz als auch zur Privilegienerweiterung in jeder AD-Umgebung mit dMSA-Konten genutzt werden. Ein erfolgreicher Angriff kann große Auswirkungen haben, da er domänenübergreifende laterale Bewegungen und dauerhaften Zugriff auf alle verwalteten Dienstkonten und ihre Ressourcen auf unbestimmte Zeit ermöglicht.
Allerdings stuft der Sicherheitsforscher das Risiko einer Ausnutzung nur als "mäßig" ein, da die erfolgreiche Ausführung des Angriffs von einer teilweisen Kompromittierung des Forest abhängt. Hintergrund ist, dass Angreifer einen KDS-Root-Schlüssel besitzen müssen. Dieser KDS-Root-Schlüssel steht aber nur den privilegiertesten Konten (Root Domain Admins, Enterprise Admins und SYSTEM) zur Verfügung.
GoldenDMSA-Tool zur Erkennung
Das Problem für Sicherheitsverantwortliche ist, dass die Erkennung von Aktivitäten über golden dMSA-Angriffe eine manuelle Protokollkonfiguration und -überprüfung erfordert, was Gegenmaßnahmen erschwert. Denn es werden standardmäßig keine Sicherheitsereignisse protokolliert, wenn ein KDS-Root-Schlüssel gefährdet ist.
Um zu verstehen, wie diese Angriffstechnik in der Praxis funktioniert, hat Semperis Researcher Adi Malyanker mit GoldenDMSA ein Tool entwickelt, das die Logik des Angriffs enthält und es Administratoren ermöglicht, effizient zu untersuchen, zu bewerten und zu simulieren, wie die Technik in realen Umgebungen ausgenutzt werden kann. Die Tools stehen auf GitHub bereit und sind in diesem Semperis-Blog-Beitrag verlinkt.
"Golden dMSA deckt einen kritischen Designfehler auf, der es Angreifern ermöglicht, Passwörter für Service Accounts zu generieren und in Active Directory-Umgebungen unentdeckt zu bleiben", erklärt Adi Malyanker. "Ich habe ein Tool entwickelt, das Verteidigern und Researchern hilft, die Angriffsmechanismen besser zu verstehen. Unternehmen sollten ihre Systeme proaktiv bewerten, um dieser neuen Bedrohung einen Schritt voraus zu sein."
Ähnliche Artikel:
BadSuccessor: dMSA zur Privilegien-Erhöhung in Active Directory missbrauchen
BadSuccessor: Nachlese zur dMSA AD-Privilegien-Erhöhungs-Problematik
MVP: 2013 – 2016
Wenn man erstmal Root Domain Admin oder Enterprise Admin ist, braucht man auch den Rest des Angriffs nicht mehr. Was mir mehr Sorgen macht, ist ein Angreifer der SYSTEM Rechte hat, dafür gab es in der Vergangenheit schon genug Exploits. Mir stellt sich allerdings die Frage, wo das passieren muss, reicht ein 2025er Mitgliedsserver, auf dem solche dMSA Konten verwendet werden, oder muss das auf einem 2025er DC passieren? Wenn letzteres, naja, dann… … hat man schon ganz andere Probleme, wen interessieren dann noch dMSA Konten?
Das betrifft nur 2025er DCs, denn nur da gibt es dMSA.
Es zeigt einfach ein AD wirklich ab zu dichten ist einfach unmöglich. MS sich auch nicht wirklich bemüht hier wirklich neue große Änderungen zu bringen. Es wird halt etwas dran gemacht, um etwas getan zu haben.
stimmt überhaupt nicht die Aussage, von mir aus ein AD ist per Default nicht sicher, aber dass eine Abdichtung unmöglich ist, ist totaler Quatsch. Und die totale Sicherheit gibt es in der IT nirgends, dann zieh halt den Stromstecker.
Es kostet Zeit und Arbeit, meinetwegen noch Budget für Auditing Tools und AD Backup, aber das war's.
Jeder Server und jeder Client ist per Default unsicher konfiguriert.
Da muß man immer manuell die Maschinen härten.
Beispielsweise sind auf Servern standardmäßig der Audio- und der Druckdienst aktiv.
Die braucht man aber nur auf Terminalservern und den Druckdienst auf Druckservern.
Auf allen anderen Servern gehören diese Dienste deaktiviert.
Ebenso alle Dienste, die man nicht explizit auf den Servern und Clients braucht.
usw. usw.
Und zum Härten eines DCs gehört eben auch das Härten des ADs.
ja, mühsam.