Microsoft’s new delegated Managed Service Accounts (dMSA) feature in Windows Server 2025 was designed to improve Active Directory (AD) security by using randomized keys and machine-bound authentication. However, security researchers have uncovered a critical design flaw in dMSAs, dubbed the “Golden dMSA” attack, that completely undermines this security model. In essence, Golden dMSA lets an attacker generate valid passwords for any managed service account across the entire AD forest if they can first extract a secret key from one domain controller. This bypasses modern protections like Credential Guard and creates a long-lasting backdoor into enterprise networks. In this post, we explain what the Golden dMSA attack is, how it works, why it’s so dangerous, and what organizations can do to defend against it.
Background: Active Directory Service Accounts and dMSA
Active Directory environments use service accounts to run system services (e.g. database servers, applications). Traditionally, these accounts had static passwords, which made them vulnerable to Kerberoasting attacks (where attackers steal service tickets and recover the password hash). In recent years Microsoft introduced group Managed Service Accounts (gMSAs) and now dMSAs to improve security.
A delegated Managed Service Account (dMSA) is a new type of account in Windows Server 2025 that migrates a legacy service account to one with fully randomized cryptographic keys. According to Microsoft’s documentation, a dMSA is tied to specific machines: only explicitly authorized computer accounts in AD can use the service account, rather than any user who knows a password. This design was intended to eliminate credential theft – if an attacker cannot steal or reuse a password, they should not be able to impersonate the service account. In practice, dMSAs were meant to thwart Kerberoasting by removing a static, reusable secret.
Unfortunately, the very mechanism that generates and validates dMSA passwords contains a flaw. Semperis researcher Adi Malyanker discovered that a component of the password-generation structure (the ManagedPasswordId) is only 1,024 possibilities wide and predictable. In other words, what was supposed to be a cryptographically strong, rotating key system can actually be brute-forced in minutes. The Golden dMSA research shows that attackers who already have a foot in the door (with high-level AD privileges) can exploit this weakness to persist in the network and move laterally across domains undetected.
How the Golden dMSA Attack Works
The Golden dMSA attack is a four-phase process that turns a single compromised domain controller (DC) into forest-wide control over all dMSA and gMSA accounts. The attack only proceeds if an adversary has already gained a high privilege (like SYSTEM) on a DC – but once that initial barrier is passed, no additional domain admin rights are needed to complete the exploit. The core idea is that by extracting the Key Distribution Service (KDS) root key from a DC, attackers can then regenerate any service account password normally produced by AD, without ever interacting with the DC again. The four stages are:
The Golden dMSA attack unfolds in four phases, beginning with stealing the KDS root key from a compromised domain controller and ending with lateral movement across the entire Active Directory forest.
- Phase 1 – Steal the KDS Root Key: An attacker with SYSTEM privileges on one domain controller extracts the cryptographic root key used by AD’s KDS service. This master key underpins all managed service account passwords. With this key in hand, the attacker can compute any future dMSA/gMSA password offline.
- Phase 2 – Enumerate dMSA Accounts: Next, the attacker finds all dMSA (and gMSA) accounts in the Active Directory forest. Using standard APIs or LDAP queries (e.g. LsaOpenPolicy, LsaLookupSids), they list every service account that delegates to a DC. Because the attacker already has high-level rights, they can bypass any restrictive ACLs and gather account identifiers needed for the next step.
- Phase 3 – Guess the Weak ManagedPasswordID: For each targeted dMSA, the attacker computes or guesses the time-based ManagedPasswordId values. Due to the design flaw, this ID only has 1,024 possible values. In practice, the attacker can simply brute-force the right ID by trying all combinations until the account password calculation succeeds. This is extremely fast – a task that should have been computationally impossible is now trivial.
- Phase 4 – Generate and Use Service Account Credentials: Finally, using the stolen KDS root key and the correct ManagedPasswordId, the attacker computes valid passwords (Kerberos keys) for any dMSA or gMSA. They can then use standard techniques like Pass-the-Hash or Overpass-the-Hash to authenticate as those service accounts. From this point on, the attacker can access any resources these accounts control, issue service tickets, and move laterally across domains at will. No further DC access is needed – the attacker has all the secrets required.
Each phase above requires no more privileges beyond the initial DC SYSTEM compromise, making the process especially dangerous. As Malyanker notes, once the KDS root key is extracted, the attacker has a “particularly dangerous persistence method” that can control every managed account in the enterprise. In short, Golden dMSA transforms what began as one compromised server into full forest-wide access using a single cryptographic vulnerability.
Why Golden dMSA is So Dangerous
The impact of the Golden dMSA flaw is severe. By design, compromising the KDS root key in any one domain effectively compromises every dMSA and gMSA account in the entire AD forest. This creates an indefinite backdoor across domains. Even if an organization rotates KDS keys going forward, Microsoft’s compatibility design means the oldest root key is still used by default, so the original compromised key remains valid for years. In practice, an attacker who penetrates a DC could harvest credentials or Kerberos tickets for dozens of service accounts in minutes, without raising the usual alarms.
Moreover, Golden dMSA completely sidesteps Windows security controls. For example, it renders Credential Guard and other OS-level protections moot, because the attacker is not stealing secrets from memory or the disk – they are mathematically regenerating them. In Microsoft’s own words: “If you have the secrets used to derive the [KDS] key, you can authenticate as that user” – and that is exactly what this attack provides. In other words, Golden dMSA undoes the security benefits that dMSAs were supposed to provide (binding accounts to machines and automatic rotation) and gives domain-level admins the power to bypass those protections entirely.
Semperis rates the risk as moderate only because exploiting Golden dMSA requires an attacker to already have the highest privileges (e.g. Domain Admin or SYSTEM on a DC). It is not a remote worm. But if that barrier is overcome – for example, through an earlier intrusion or supply-chain compromise – the consequences are extreme. An enterprise can be fully taken over, all while traditional defenses log no obvious red flags. As Malyanker explains, one DC breach “escalates to owning every dMSA-protected service across an entire enterprise forest”. This is not just privilege escalation on one server; it is digital domination of the whole network via a single cryptographic flaw.
Detection and Mitigation Strategies
Detecting Golden dMSA exploitation is notoriously difficult, since there are no default audit logs when the KDS root key is accessed. By default, Active Directory does not log reads of the KDS key objects, so attackers can steal it silently. Organizations must proactively enable auditing on those keys (System Access Control Lists) if they want alerts. Without that, the attacker’s activities leave little trace.
That said, defenders can watch for indirect indicators of abuse. For instance, a surge of authentication attempts to high-value service accounts or a spike in Ticket Granting Ticket (TGT) requests for dMSA/gMSA accounts could suggest something is wrong. Unusual access patterns from DCs or from systems that should not normally use certain service accounts can also be a clue. However, these signals require advanced log analysis and can easily be lost in the noise of a busy network.
Because no official patch is planned (Microsoft has noted that dMSAs were not intended to protect against a compromised DC), organizations must rely on defensive measures:
- Least Privilege & DC Hardening: Limit the number of accounts that can log into DCs and extract secrets. Use privileged access workstations (PAWs), multi-factor authentication, and strict “just-in-time” admin models to reduce the chance that an attacker reaches a DC at all.
- Key Rotation: Although KDS root keys do not expire by default, administrators can perform a manual key rollover in AD (using
Add-KdsRootKey) to replace old keys. However, Golden dMSA still notes that AD uses the first (oldest) key for compatibility. Regularly rotating keys and then demoting old DCs may limit exposure, but this is complex and error-prone. - Audit KDS Key Access: Configure Security ACLs on the KDS root key objects (both for user and computer contexts) to log any read operations. This at least gives a chance to catch an attacker stepping through the exploit.
- Use Simulation Tools: Semperis has released a proof-of-concept tool (GoldenDMSA) that implements the attack. Security teams can use this tool in a controlled environment to understand how their systems would be affected and to test detection rules. Running simulated attack exercises helps ensure that defenses are tuned before a real attacker hits.
- Monitor Service Account Behavior: Beyond dMSAs, keep an eye on any managed service accounts. Sudden changes in how these accounts authenticate or unexpected service failures could signal that someone is playing with account credentials.
In general, the Golden dMSA finding highlights the importance of continuous vigilance. Features like dMSA add complexity to identity infrastructure, and defenders should assume that new features will need review and monitoring. Organizations should conduct thorough risk assessments of their Windows Server 2025 deployment and tighten controls around Active Directory management as recommended by security researchers.
