Golden dMSA: What Is dMSA Authentication Bypass?

Key findings

• Semperis Security Researcher Adi Malyanker found a critical design flaw in delegated Managed Service Accounts (dMSAs) introduced in Windows Server 2025.
• Because the flaw greatly simplifies brute-force password generation, exploiting it is low complexity.
• The Golden dMSA attack enables attackers to bypass authentication and generate passwords for all dMSAs and gMSAs and their associated service accounts.
• Detection of Golden dMSA activity requires manual log configuration and auditing, making mitigation difficult.
• Semperis researchers rate this vulnerability as MODERATE because to exploit it, attackers must possess a KDS root key available only to only the most privileged accounts: root Domain Admins, Enterprise Admins, and SYSTEM.
• However, this attack can be high impact, enabling cross-domain lateral movement and persistent access to all managed service accounts and their resources indefinitely.

Microsoft’s Windows Server 2025 delivers significant security innovations, including the introduction of delegated Managed Service Accounts (dMSAs) designed to revolutionize service account management. Unlike static password-based accounts that can fall victim to Kerberoasting attacks, dMSAs bind authentication directly to authorized machines in Active Directory (AD).

This machine-centric approach eliminates credential theft by tying authentication to device identity rather than user-managed passwords. Only explicitly authorized machines can access the dMSA.

This article reveals a new attack against delegated Managed Service Accounts called the Golden DMSA attack. The technique allows attackers to bypass the intended machine-managed authentication and generate passwords for all associated dMSAs offline.

What is Golden dMSA?

Golden dMSA is a persistence and privilege-escalation method that allows attackers to generate passwords for all dMSAs—and group Managed Service Accounts (gMSAs)—and their associated service accounts.

The attack leverages a critical design flaw: a structure that’s used for the password-generation computation contains predictable time-based components with only 1,024 possible combinations, making brute-force password generation computationally trivial.

This attack may be used for both persistence and privilege escalation in any AD environment with dMSA accounts. Semperis rates this vulnerability as moderate risk because its execution depends on partial compromise of the forest.

Read on to learn how we uncovered the vulnerability that enables Golden dMSA, the details we found behind the design flaw,
and how you can detect and mitigate authentication bypass activity.

How does a Golden dMSA attack work?

After an attacker gains elevated privileges within a domain, they can systematically compromise all dMSA and gMSA accounts through a straightforward four-phase attack.

Phase 1: Extracting KDS root key material (pre-requirement for the attack). The attacker dumps cryptographic material from the Key Distribution Services (KDS) root key—the foundation for all managed service account passwords.

Phase 2: Enumerating dMSA accounts. In phase 1, the SYSTEM or Domain Admin user doesn’t have permissions to enumerate dMSAs in other domains. In this second phase, the attacker attempts, by brute force or by using LDAP, to discover data such as sAMAccountName attributes and security identifiers (SIDs) on dMSA accounts in the AD forest.

Phase 3: Guessing the ManagedPasswordID. Next, the attacker attempts to identify the correct ManagedPasswordId attribute and password hashes through targeted guessing.

Phase 4: Password generation. Using specialized tools like GoldenDMSA, the attacker can generate valid passwords for any gMSA or dMSA associated with the compromised key.

This process requires no additional privileged access once the KDS root key is obtained, making it a particularly dangerous persistence method.

The attack highlights the critical trust boundary of managed service accounts. They rely on domain-level cryptographic keys for security. Although automatic password rotation provides excellent protection against typical credential attacks, Domain Admins, DnsAdmins, and Print Operators can bypass these protections entirely and compromise all of the dMSAs and gMSAs in the forest.

What are dMSAs? A brief service account history

For decades, Windows administrators used regular domain accounts to run services—a functional but flawed approach that evolved with the introduction of service accounts. Unlike interactive user accounts that represent actual people, service accounts exist solely to provide an identity context for automated processes.

The first service accounts relied on static passwords that created operational nightmares. Coordinating password changes across multiple teams, services, and applications often led to outages and resistance to security best practices.

Worse, static passwords enabled devastating attacks. Kerberoasting exploits let attackers request service tickets and crack passwords offline, while weak or unchanged credentials provided easy targets for privilege escalation.

Since then, Microsoft has created different versions of service accounts.

• Managed Service Accounts (MSAs). Windows Server 2008 R2 introduced automatic 240-character password rotation every 30 days along with automatic service principal name (SPN) management. The catch? MSAs are limited to single machines.
• Group Managed Service Accounts (gMSAs). Windows Server 2012 solved the multi-machine limitation, enabling shared service identities across clusters, load balancers, and distributed services while maintaining the MSA’s security benefits.
• Delegated Managed Service Accounts (dMSAs). Windows Server 2025’s latest innovation shifts from centralized password management to machine-bound authentication, representing a fundamental change in service account security.

This evolution from traditional accounts to gMSA to dMSA creates an interesting attack surface—one that the Golden dMSA technique exploits by leveraging the shared cryptographic foundation between gMSA and dMSA systems.

How attackers find dMSAs: Breaking the invisibility barrier

From an attacker’s perspective, the ability to enumerate dMSAs as an unprivileged user is crucial for privilege escalation and lateral movement. To obtain a dMSA password, you must know its name and SID.

However, one of the most intriguing challenges when dealing with dMSAs is finding these elusive accounts in the first place.

According to Microsoft’s documentation, to create dMSAs, we start with the CreateDelegatedServiceAccount command that Figure 1 shows.

Now comes the fun part. Let’s try to display our newly created DMSA-Demo account using Get-ADServiceAccount (Figure 2).

Here’s where we hit our first roadblock. A privileged user can view the account just fine, but a non-privileged user gets absolutely nothing—empty results (Figure 3). Why? It all comes down to the defaults in the access control lists (ACLs) of the account. And trust me, no administrator wants to mess with these.

Notice something suspicious in Figure 4? Both authenticated users and Everyone are completely locked out from reading any data on these accounts.

So how on earth can a non-privileged user access information about dMSA accounts?

This is where the detective work begins. After countless investigations and failed attempts, I discovered we can construct a list of potential SIDs and translate each one to NTAccount objects. (I used C# for this magic.)

Under the hood, the translate function leverages these powerful Win32 APIs: LsaOpenPolicy and LsaLookupSids (Figure 5).

The function names give away their purpose, but Figure 6 shows Microsoft’s official documentation to make it crystal clear.

Interestingly, an Impacket tool called lookupsid¹ uses exactly the same technique, employing hLsarOpenPolicy2 and hLsarLookupSids to enumerate SIDs.

Now for the exciting part: Let’s see what happens when we unleash these Win32 functions (Figure 7).

Jackpot! We’ve retrieved every single account in the domain, plus other objects with SIDs.

This method succeeds because it completely sidesteps LDAP, effectively bypassing those restrictive ACLs. Here’s the technical beauty: LsaLookupSids and LsaOpenPolicy don’t rely on LDAP at all. Instead, the LSA protocol communicates through \PIPE\lsarpc as the RPC endpoint over SMB.

But wait—how can we identify which accounts from this massive list are dMSAs?

Here’s the clever part: We flag all accounts ending with $ as suspects. Then we systematically eliminate machine accounts and gMSAs.

Voilà! We’re left with a complete inventory of all dMSAs in the domain.

Plot twist: This technique works across domain boundaries too! We can enumerate dMSAs from other domains using the exact same method.

Here’s a bonus discovery.

Thanks to my colleagues Andrea Pierini and Shai Laronne, we’ve uncovered an alternative LDAP-based approach (Figure 8).

The secret sauce? When we initiate the search directly from the container itself, we can hunt for these specific account types. Combined with our previous SID enumeration method, we can extract the SID information while filtering out gMSAs and computer accounts (Figure 9).

This dual approach gives us multiple attack vectors for dMSA discovery—a game-changer for any security assessment.

Why is the KDS root key central to Golden dMSA attacks?

First introduced in Windows Server 2012, the KDS root key is the crown jewel of Microsoft’s gMSA infrastructure. Think of it as the cryptographic mastermind behind Microsoft’s Key Distribution Service—the engine that generates and distributes passwords for gMSAs.

Obtaining this root key is the critical first step in the attack chain as it allows attackers to compute the passwords for any gMSA in the domain offline. This capability is devastating because gMSAs are designed to have their passwords automatically rotated by the domain controller (DC), making them appear secure to administrators. However, with the KDS root key in hand, an attacker can mathematically derive the current password for any gMSA account without ever connecting to the DC again.

Here’s what makes it so powerful: The KDS root key functions as the ultimate master key. From it, all gMSA passwords are derived through an elegant key derivation process.

But there’s more. Microsoft recently expanded the KDS root key to control dMSA accounts.

Now the KDS root key is twice as valuable for attackers since it unlocks both gMSA and dMSA passwords.

The KDS root key typically resides on the root DC of the forest—the most protected real estate in AD. Microsoft wasn’t playing around with security here. The ACLs on these keys are incredibly restrictive (Figure 10) limiting access to only the most privileged accounts: root Domain Admins, Enterprise Admins, and SYSTEM.

However, despite these iron-clad restrictions, these precious keys can still be retrieved from other DCs throughout the forest, but only with SYSTEM-level access (Figure 11).

At this point you might think that having SYSTEM permissions on a DC diminishes the exploitability of Golden dMSA. However this is a single DC out of the whole forest, and the attack flow fundamentally changes the threat landscape from a localized compromise to a forest-wide persistent backdoor.

This means that although SYSTEM access on a DC already represents a significant breach, the Golden dMSA technique transforms that breach into a much more dangerous and durable threat by enabling the attacker to maintain persistent access to gMSAs, dMSAs, and their associated service accounts across the entire forest—without requiring continued presence on the compromised DC.

Pay close attention to this critical detail: KDS root keys have no expiration date

Microsoft’s recommendation is to maintain just one KDS root key per environment.

Do the math here. Theoretically, after compromising a single KDS root key, an attacker could potentially generate passwords for all future dMSA and gMSA accounts indefinitely.

I’ve discovered something even more intriguing during my research. Even in environments with multiple KDS root keys, the system consistently uses the first (oldest) KDS root key for compatibility reasons. This means that original key we’ve compromised could be preserved by Microsoft’s design—creating a persistent backdoor that could last for years.

This architectural decision transforms a single successful key extraction into a long-term strategic advantage for attackers, making the KDS root key one of the most valuable targets in any Windows domain.

Cracking the code: From gMSA to dMSA password generation

Now we’re diving into the heart of the attack—extracting the dMSA’s ManagedPasswordId attribute.

ManagedPasswordId is an attribute stored in AD that contains the metadata needed to derive an MSA’s current password. We need to acquire this attribute because it holds the essential cryptographic parameters—including the key identifier, creation time, and other derivation details—that work together with the KDS root key to mathematically compute the gMSA’s actual password.

If this sounds familiar, you’re absolutely right. Yuval Gordon’s great research on gMSA Active Directory Attacks introduced the world to Golden gMSA. That attack technique involves extracting the KDS root key from AD, querying available gMSAs along with their SID and ManagedPasswordId attributes, and calculating passwords from the data.

In researching Golden dMSA, my hypothesis was simple but powerful: Microsoft could have recycled the same code from gMSA to dMSA for password creation and renewal. But could we actually reproduce the Golden gMSA attack against dMSA accounts?

Here’s where we hit our first major obstacle. Those restrictive ACLs we discovered earlier completely block us from reading this critical data on dMSA accounts. We needed to dig deeper and expand our algorithm.

Reverse engineering ManagedPasswordId structure

To crack this puzzle, I started investigating the ManagedPasswordId structure itself. I created a fresh dMSA account and extracted its ManagedPasswordID attribute.

After analyzing the byte array and comparing it across different instances, I discovered it contains the components that Figure 12 shows.

This structure looked familiar. It’s practically identical to gMSA’s ManagedPasswordID format (Figure 13).

Figure 14 shows the complete breakdown of this structure, with these key components:

• Version: Integer value with decimal value (1,0,0,0)
• Reserved: Integer value with decimal value of (75, 68, 83, 75)
• isPublicKey: Integer value with decimal value (2,0,0,0)
• L0Index: Integer value representing a time variable (we’ll explore this later)
• L1Index: Integer value representing a time variable (we’ll explore this later)
• L2Index: Integer value representing a time variable (we’ll explore this later)
• RootKeyIdentifier: GUID value constructed from the KDS root key ID.

The field of RootKeyIdentifier can be constructed from the KDS root keys (RKL is the KDS root key id, i.e f06c3c8d-b2c2-4cc6-9a1a-8b3b3c82b9f0), as Figure 15 shows.

• cbUnknown: Integer value with decimal value (0, 0, 0, 0)
• cbDomainName: Integer value representing (domain name length * 2) + 2.
• cbForestName: Integer value representing (forest name length * 2) + 2.
• DomainName: Domain name of the dMSA account in this special format
• ForestName: Forest name of the dMSA account in this special format

Notice something in the cbDomainName and cbForestName: We multiply by 2 and add 2 because ASCII bytes with value 0 are inserted between each character. So root.test becomes r.o.o.t…t.e.s.t.. in the actual structure.

By studying the Microsoft Learn article on msDS-ManagedPassword and the Microsoft KDS Provider KdsCli.dll (which implements most of the password logic), I traced the flow starting from GetgMSAPasswordBlob(), as Figure 16 shows.

The logic is elegant. When the ManagedPasswordId doesn’t exist or expires, the system establishes a new start time and calls GetPasswordBasedOnTimestamp(), as Figure 17 shows.

This brings us to one of the most significant observations of our research. The L0, L1, and L2 values are generated in GetIntervalID(), then passed to GetKey() when constructing a new key BLOB (Figure 18).

From this observation, I discovered something crucial: L1 and L2 values are limited to 31 (inclusive). This isn’t just theory; it’s confirmed both in the DLL (Figure 19) and Microsoft’s GetKey() documentation (Figure 20).

The GetPasswordBasedOnTimestamp() method will be also called when a renewal of the ManagedPasswordId is required.

The breakthrough discovery

Now comes the game-changing revelation.

We can predict most of what the ManagedPasswordID vector needed to compute gMSA and dMSA passwords. We know L1Index and L2Index are bound to values we can obtain through brute force. The main challenge appeared to be L0Index, which, as a 4-byte integer, could have billions of potential values.

When digging further into Golden gMSA’s algorithm, I found that it creates these objects:

• L0Key, containing KDS root key attributes (Figure 21)
• L0KeyId, calculated from current time
• GenerateKDFContext and GenerateDerivedKey, which derive L1Key and L2Key byte vectors once (Figure 21) or a couple of times (Figure 22)

Here’s the critical insight.

• L0Keyid, L1Keyid, and L2Keyid values are entirely time-based and user-independent (as Figure 19 above shows).
• The only user-controlled value is the ManagedPasswordId vector itself, which we provide alongside the KDS Root Key, domain and forest names, and SID.

This is where everything clicked. When I traced where L0Index (from the ManagedPasswordId) is actually used in the algorithm, I found the revelations that Figure 23 and Figure 24 show.

This is an amazing detail. L0index is not used at all from the MsdsManagedPasswordId vector, which means that it does not matter what value we use.

Password guessing: Putting it all together

We can now construct almost the entire ManagedPasswordId vector—the final piece needed to predict gMSA and dMSA passwords and hashes. Since L0Index is ignored, and L1Index and L2Index must be between 0-31 (inclusive), we have only 32 × 32 = 1,024 possible vectors to test.

I tested this conclusion by calculating the correct password and NTLM hash for each vector, then attempted Pass the Hash attacks using Impacket’s smbclient² (Figure 25).

Success! This method worked perfectly for gMSA accounts. We could predict their hashes within 1,024 attempts without needing the specific ManagedPasswordId.

But still, I could not Pass the Hash with dMSA’s password hash. In addition, we needed to ask how we could leverage this attack when Pass the Hash attacks are mitigated from this domain.

After examining the attributes of one of my dMSAs, I saw that it requires connection with Kerberos encryption type AES 256, as Figure 26 shows. (You’ll recall that I followed Microsoft’s recommendation for enforcing AES 256 when creating a dMSA.)

I tried to generate an AES 256 hash out of the service’s password. After some exhausting attempts, I discovered that gMSAs and dMSAs use a slightly different salt format for AES 256 hashing:

<Domain name in UPPER case>host<user's full UPN in lower case (without $)>

For example:

ROOT.TESThostdmsa-demo8.root.test

With this salt format, I could finally generate valid Kerberos tickets for dMSA accounts.

Mapping the Golden dMSA attack flow

The diagram in Figure 27 summarizes the Golden dMSA attack.

1. Start with SYSTEM privileges on one of the DCs in the domain or Enterprise Admin privileges to dump the KDS root keys.
2. Brute-force dMSA accounts’ SIDs or use LDAP queries to identify target accounts.
3. Create a wordlist containing all 1,024 possible ManagedPasswordIds for this specific user.
4. Compute the password for each possible pair (KDS root keys, ManagedPasswordIds) and hash it to NTLM/AES256.
5. Test each password hash via Pass the Hash or Overpass the Hash techniques.

This attack transforms dMSA accounts from seemingly impenetrable targets into manageable brute-force challenges, requiring only 1,024 attempts to crack any dMSA password in the domain.

How a Golden dMSA attack bypasses normal authentication

In its documentation, Microsoft states, “dMSA’s secret can’t be retrieved or found anywhere other than on the DC,” highlighting a fundamental difference between gMSA and dMSA authentication mechanisms. With gMSAs, the process is straightforward. An entity authenticates itself and directly requests the gMSA’s credentials (password), then receives the actual password for authentication purposes.

dMSAs operate on an entirely different principle. They must authenticate using the machine’s identity to obtain a ticket for the dMSA user. The dMSA’s password never leaves the DC. Instead, it’s used to encrypt the ticket that gets returned to the requesting machine.

To avoid cases in which an attacker steals the machine’s hash and uses it to request a ticket, Microsoft recommends using Credential Guard. This mitigation creates a robust barrier that should stop most credential theft attacks in their tracks.

But here’s where the Golden dMSA attack changes everything. Golden dMSA completely circumvents normal Credential Guard protections (Figure 28). We’re not playing by the normal authentication rules anymore.

Instead of following Microsoft’s intended authentication flow, the dMSA credentials are used directly using the cryptographic attack (Figure 29). This means:

• No machine identity required. We don’t need to compromise the host machine.
• Credential Guard becomes irrelevant. Since we’re not stealing machine credentials, this protection offers zero defense.

Microsoft has acknowledged that, “Starting with the April Windows security update (KB5055523), Credential Guard protected machine accounts is temporarily disabled in Windows Server 2025 and Windows 11, version 24H2. This feature has been disabled due to an issue with machine password rotation using Kerberos. The feature remains disabled until a permanent fix is available.”

What is the true risk of Golden dMSA? Forest-wide devastation

Once an attacker has successfully compromised a dMSA account using the Golden dMSA technique, the real fun begins. This isn’t just about gaining access to one service account. It’s about leveraging that foothold for devastating lateral movement. In addition, this technique allows attackers to crack passwords and obtain permissions of service accounts that have both started and completed migrations to the compromised dMSA.

Here’s where the attack becomes truly terrifying from a security perspective. The Golden dMSA attack isn’t limited by domain boundaries. It operates at the forest level. Once we compromise the KDS root key from any single domain within the forest, we can systematically target and compromise every dMSA account across all domains in that forest.

This means a single successful KDS root key extraction transforms into:

• Cross-domain account compromise. No domain boundaries can stop us.
• Forest-wide credential harvesting. Every dMSA in every domain becomes vulnerable.
• Unlimited lateral movement. We can jump between domains at will using compromised dMSA accounts.
• Persistent access. With no expiration on KDS keys, this access could last indefinitely.

The attack scales exponentially. What starts as one DC compromise escalates to owning every dMSA-protected service across an entire enterprise forest. It’s not just privilege escalation. It’s enterprise-wide digital domination through a single cryptographic vulnerability.

What is the Golden dMSA tool?

To learn how this attack technique is exploited, we took the logic of the attack and included it in a tool called GoldenDMSA³. The tool incorporates the structural principles of the GoldenGMSA tool.⁴

An attacker can use the GoldenDMSA tool to enumerate all gMSAs, dMSAs, and their associated KDS root keys, use brute force attacks to obtain their passwords, and achieve tickets to the accounts. An attacker with high privileges can also use the GoldenDMSA tool to dump the KDS root keys.

To demonstrate the tool in action, let’s look at an exploitation between domains in a forest.

To begin, the attacker sits in a domain called child.root.test (Figure 30) and tries to obtain dMSAs from root.test (Figure 31).

Then, the attacker must create a wordlist (Figure 32) that will be used for the ManagedPasswordIds brute-force attack.

Finally, we will launch a brute-force attack with the help of the wordlist (Figure 33).

The password is Base64 encoded (Figure 34) because it could include non-printable characters. To test the ticket’s validity, I created a new user—hidden in the root DC—that only the dMSA account could read. If we can successfully read the user’s data, we know our generated ticket is valid.

How to detect Golden dMSA: Uncovering hidden indicators

By default, no security events are logged when a KDS root key is compromised. To detect Golden dMSA attacks, defenders must manually configure a System Access Control List (SACL) on KDS root key objects to audit read access to the msKds-RootKeyData attribute.

To do this, open the Active Directory Editor Interface (ADSI Edit) tool and:

• Select the Configuration naming context
• Navigate to Services, then click Group Key Distribution Service
• Select Master Root Keys and right-click the relevant KDS root key
• Go to the Security tab, click the Advanced button
• Select the Auditing tab and configure an audit rule for read access on Authenticated Users/Everyone

When this SACL is in place, any unauthorized attempt to extract KDS root key data will trigger security event 4662 on the DC (Figure 35). This event will show an object type of msKds-ProvRootKey and an account name that is not a DC, indicating potential malicious activity.

New DSP security indicator aids in Golden dMSA detection

As you can see, manual detection of KDS root key compromise is challenging for most teams. Semperis has provided a new Service Accounts Protection module, an enhancement of Directory Services Protector (DSP) capabilities. The module includes a security indicator called KDS root key ACL was modified, which looks for ACL modifications on KDS root keys (Figure 36) that could enable attackers to read those keys and launch a Golden dMSA attack.

Additional clues to watch for

In addition, defenders should:

• Monitor for abnormal volumes of AS-REQ authentication requests targeting the same service account (identifiable by accounts ending with $), particularly when followed by PREAUTH-FAILED (error code 24) responses. This pattern may indicate an attempted Overpass the Hash attack.
• Look for abnormal Ticket-Granting Ticket (TGT) requests of dMSA accounts, especially when launched by user accounts.

Semperis snapshot

The Golden dMSA attack leverages a cryptographic vulnerability that can undermine Microsoft’s latest security innovation in Windows Server 2025. This technique exploits the architectural foundation of delegated Managed Service Accounts. The attack leverages a critical design flaw: the ManagedPasswordId structure contains predictable time-based components with only 1,024 possible combinations, making brute-force password generation computationally trivial.

What makes this particularly devastating is its forest-wide scope. A single successful key extraction enables cross-domain lateral movement and persistent access to all managed service accounts and their resources indefinitely, since KDS root keys have no expiration date. The vulnerability transforms Microsoft’s most secure service account technology into a potential enterprise-wide backdoor, bypassing modern protections like Credential Guard and fundamentally challenging the assumed security benefits of machine-bound authentication.

Disclosure

The issue was initially reported to the Microsoft Security Response Center (MSRC) on May 27, 2025.

On July 8, 2025, Microsoft responded in part: “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.”

Learn more about threats to Managed Service Accounts

• BadSuccessor: How to Detect and Mitigate dMSA Privilege Escalation
• How to Block BadSuccessor
• gMSA Active Directory Attacks

Endnotes

1. https://github.com/fortra/impacket/blob/master/examples/lookupsid.py
2. https://github.com/fortra/impacket/blob/master/examples/smbclient.py
3. https://github.com/Semperis/GoldenDMSA/tree/main
4. https://github.com/Semperis/GoldenGMSA

Disclaimer

This content is provided for educational and informational purposes only. It is intended to promote awareness and responsible remediation of security vulnerabilities that may exist on systems you own or are authorized to test. Unauthorized use of this information for malicious purposes, exploitation, or unlawful access is strictly prohibited. Semperis does not endorse or condone any illegal activity and disclaims any liability arising from misuse of the material. Additionally, Semperis does not guarantee the accuracy or completeness of the content and assumes no liability for any damages resulting from its use.