A significant design flaw has emerged in Microsoft’s latest Windows Server 2025, allowing attackers to bypass authentication and generate passwords for all managed service accounts across enterprise networks. This vulnerability, known as “Golden dMSA,” takes advantage of a fundamental weakness in the newly introduced delegated Managed Service Accounts (dMSAs), reducing complex cryptographic protections to a trivial brute-force attack that requires only 1,024 attempts.
Discovered by Semperis Security Researcher Adi Malyanker during an analysis of dMSA architecture, this vulnerability threatens to undermine Microsoft’s flagship security innovation aimed at transforming service account management.
Unlike traditional service accounts that depend on static passwords susceptible to Kerberoasting attacks, dMSAs were designed to bind authentication directly to authorized machines within Active Directory. This innovative approach was intended to eliminate credential theft by linking authentication to device identity rather than user-managed passwords.
The Golden dMSA attack, however, exposes a critical flaw in the ManagedPasswordId structure utilized for password generation. This structure comprises predictable time-based components, resulting in only 1,024 possible combinations. What should be a computationally intensive task becomes a straightforward brute-force operation that can be executed in mere minutes.
Windows Server 2025 Golden dMSA Attack
The attack unfolds in a systematic four-phase approach, enabling a single domain controller compromise to evolve into forest-wide persistent access:
- Attackers first extract cryptographic material from the Key Distribution Services (KDS) root key, which underpins all managed service account passwords.
- Next, they enumerate dMSA accounts throughout the Active Directory forest using specialized techniques that circumvent restrictive Access Control Lists.
- The third phase involves targeted guessing to identify the correct ManagedPasswordId attributes, followed by password generation with specialized tools.
- Finally, the attack exploits its forest-level scope, allowing cross-domain lateral movement and compromising every dMSA account across all domains within that forest.
The danger of this vulnerability lies not only in its scope but also in its persistence. Since KDS root keys do not have an expiration date, successful extraction could theoretically grant indefinite access, creating a persistent backdoor that survives typical security rotations and updates.
Semperis classifies this vulnerability as a moderate risk, noting that exploitation necessitates possession of a KDS root key, accessible only to the most privileged accounts: Domain Admins, Enterprise Admins, and SYSTEM-level access. However, researchers caution that the potential impact is extremely high, enabling attackers to bypass modern protections like Credential Guard and fundamentally challenge the perceived security benefits of machine-bound authentication.
This attack is particularly alarming as it completely circumvents Microsoft’s intended authentication flow. Instead of adhering to standard dMSA authentication procedures that require machine identity validation, the Golden dMSA technique leverages compromised cryptographic keys to generate valid passwords directly, rendering protections like Credential Guard ineffective.
Detecting Golden dMSA activity poses significant challenges for enterprise security teams. By default, no security events are logged when KDS root keys are compromised, necessitating manual configuration of System Access Control Lists (SACLs) on KDS root key objects to audit read access. This oversight renders the attack stealthy and difficult to detect in real-time. Tools for monitoring are available via GitHub, allowing organizations to track abnormal volumes of authentication requests targeting service accounts and unusual Ticket-Granting Ticket requests for dMSA accounts. However, these indicators require sophisticated log analysis and may lead to false positives in busy enterprise environments.
Microsoft acknowledged the vulnerability report submitted to the Microsoft Security Response Center on May 27, 2025. In their response on July 8, 2025, the company stated, “If you have the secrets used to derive the key, you can authenticate as that user. These features have never been intended to protect against a compromise of a domain controller.”
