Golden dMSA turns managed service accounts into a forest-wide backdoor

At a glance

What this is: Golden dMSA is a Windows Server 2025 service account attack that can let an attacker generate valid passwords for dMSAs and gMSAs after obtaining the KDS root key.

Why it matters: It matters because identity teams cannot treat managed service accounts as self-protecting identities when a single root key compromise can collapse the whole trust model.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.

👉 Read Semperis's analysis of the Golden dMSA attack and service account exposure

Context

Golden dMSA is a service account governance problem, not just a Windows research finding. The attack targets delegated Managed Service Accounts and group Managed Service Accounts, which are meant to reduce password handling risk by binding access to machine-managed authentication rather than static credentials.

The core issue is that the trust model still depends on the KDS root key and on metadata that can be brute-forced far more easily than the design assumes. For teams managing NHI, this is a reminder that stronger automation does not eliminate lifecycle risk when a single cryptographic root can control many identities.

Key questions

Q: What breaks when managed service account passwords can be generated offline?

A: The assumption that machine-bound authentication removes credential theft risk breaks first. If an attacker can reconstruct valid passwords from the KDS root key and ManagedPasswordId data, they no longer need to steal a live secret. That turns service account protection into a root-key governance problem and can preserve access across password changes.

Q: Why do dMSAs and gMSAs still create lateral movement risk in Active Directory?

A: Because both account types still depend on shared directory infrastructure that can be abused if privileged cryptographic material is exposed. A single root key compromise can let attackers generate valid credentials for many accounts, then move across domains or services using those identities. The risk is structural, not just operational.

Q: How do security teams know whether service account governance is working?

A: Look for three signals: whether root secrets are tightly tiered, whether account enumeration is visible, and whether auditing captures attempts to read password-derivation material. If those signals are missing, the programme may look mature on paper while remaining blind to offline password reconstruction and persistent access.

Q: Who is accountable when a managed service account root key is exposed?

A: Accountability sits with the team that governs privileged directory secrets, not only with the owners of the affected service accounts. Frameworks such as the NIST Cybersecurity Framework 2.0 and NHI governance models both point to the same issue: control ownership must include the cryptographic root that creates the identity.

Technical breakdown

KDS root key compromise as the starting point

Golden dMSA begins with access to the Key Distribution Service root key, the cryptographic foundation used to derive managed service account passwords. Once an attacker can read or dump that root key material, the rest of the attack becomes a computation problem rather than a login problem. The design matters because the KDS root key is shared across managed identities, so compromise of one high-value secret can translate into forest-wide reach. That makes the root key a control boundary, not just another directory object.

Practical implication: Protect the KDS root key as a tier-0 secret and audit every path that can expose it.

ManagedPasswordId structure and brute-force password generation

The ManagedPasswordId attribute carries the metadata needed to derive password material, including time-based components and a root key identifier. Semperis shows that the relevant fields have a small enough search space to make brute-force generation practical once the key is known. That is the real architectural weakness: the system assumes the metadata is inaccessible, but the attacker can often enumerate accounts and guess the needed parameters. When the derivation inputs are predictable, cryptographic strength drops sharply.

Practical implication: Treat any assumption that password derivation metadata is opaque as invalid and monitor for enumeration plus offline generation activity.

Why dMSA authentication bypasses normal service account protections

dMSAs were intended to move service account security away from static passwords and toward machine-bound authentication. Golden dMSA bypasses that improvement by reconstructing valid credentials offline, which means the intended device binding no longer protects the account once the derivation inputs are exposed. This is why the attack is dangerous across domains and not just on a single host. The service account still looks managed, but its authentication trust has been undermined at the cryptographic layer.

Practical implication: Assume machine binding is not sufficient on its own and verify which service accounts would still be reachable if password derivation were exposed.

Threat narrative

Attacker objective: The attacker wants durable control over managed service accounts so they can move laterally and preserve privileged access without repeated re-compromise.

1. Entry occurs when an attacker obtains KDS root key material from a highly privileged Active Directory context or equivalent foothold.
2. Escalation follows as the attacker enumerates dMSA and gMSA objects, reconstructs ManagedPasswordId inputs, and generates valid passwords offline.
3. Impact is persistent authentication bypass, cross-domain lateral movement, and indefinite access to managed service accounts and their resources.

Breaches seen in the wild

• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

KDS root key governance, not password rotation, is the decisive control plane for dMSA security. Delegated Managed Service Accounts were built to remove human password handling, but the attack shows that the real trust boundary moved upward into the directory root key. That means the security conversation shifts from account lifecycle convenience to tier-0 cryptographic governance. Practitioners should treat dMSA and gMSA protection as a question of root-key survivability, not just password hygiene.

ManagedPasswordId is the named concept that exposes the attack's failure mode: derivation metadata with a small enough search space to be brute-forced once the root key is known. This is not a generic over-privilege problem. It is a structural weakness in how the password-generation inputs are represented and protected, which makes offline reconstruction possible after a single key compromise. The implication is that some managed identities are only as strong as their least protected derivation input.

Machine-bound authentication does not eliminate identity blast radius when one cryptographic root governs many accounts. The design assumption was that binding to authorized machines would prevent credential theft from becoming account takeover. Golden dMSA breaks that assumption because the attacker does not need to steal an active service password; they generate one. For identity programmes, that means trust in shared derivation infrastructure must be assessed as aggressively as the identities it supports.

This attack is a lifecycle failure as much as a compromise event because the affected identities can remain usable indefinitely once the KDS root key is exposed. Rotation policies on the service account itself do not solve a compromise of the root that keeps re-issuing valid credentials. The practical conclusion is that lifecycle governance must extend to the secret that manufactures the lifecycle, not just to the accounts that consume it.

Detection that depends on manual auditing reveals a governance gap, not just an ops gap. If the organisation has to hand-build SACLs and watch for rare directory events to see the attack, then visibility is not aligned to the risk model. That is a control design issue, not a logging preference. Practitioners should read this as evidence that many NHI programmes still under-instrument their most powerful identity roots.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks.
• That pattern is why the NHI Lifecycle Management Guide matters here: the attack surface is not just creation, but the hidden persistence of privileged identity roots.

What this signals

KDS-root governance is emerging as the control plane that determines whether managed service accounts can be trusted at all. When a single forest-level secret can regenerate many identities, lifecycle work must move upward from account rotation to cryptographic root protection, with visible audit hooks around the objects that create trust.

With 72% of organisations having experienced or suspecting a breach of non-human identities, per The 2024 ESG Report: Managing Non-Human Identities, this attack fits a broader pattern of invisible identity exposure. Teams that cannot see root secrets and directory enumeration cannot credibly claim that managed service accounts are under control.

For practitioners, the next step is to align directory-secrets governance with the lifecycle model in the NHI Lifecycle Management Guide. The point is not more paperwork. It is proving that the identities which generate credentials are themselves managed, monitored, and revocable under your operating model.

For practitioners

• Inventory every dMSA and gMSA dependency chain Map which applications, clusters, and administrative workflows rely on managed service accounts, then identify which identities inherit trust from the KDS root key. Prioritise tier-0 and cross-domain exposures first. This is the shortest path to understanding blast radius.
• Protect the KDS root key as a tier-0 secret Restrict who can read, administer, or back up the Group Key Distribution Service root key objects. Review domain admin and equivalent privileges, and treat any ACL change on key objects as a security event.
• Instrument directory auditing for root-key reads and account enumeration Configure SACLs on master root keys so read access to msKds-RootKeyData generates a detectable event, and pair that with alerts for unusual SID enumeration and dMSA discovery activity. Manual detection is too late if visibility is absent.
• Separate service account compromise from service account derivation risk Test whether a password rotation event would still leave the organisation exposed if the key material used to generate those passwords were compromised. That distinction changes the control priority from account hygiene to cryptographic root governance.
• Use 52 NHI Breaches Analysis patterns to stress-test persistence assumptions Compare the forest-wide persistence risk here with recurring NHI compromise patterns in the 52 NHI Breaches Analysis, especially cases where one secret enabled long-lived access. Use that pattern to validate whether your current detection and offboarding logic would notice root-level identity compromise.

Key takeaways

• Golden dMSA exposes a structural weakness in managed service account design: once the KDS root key is exposed, the attacker can regenerate valid credentials for many identities.
• The attack matters because it converts a single privileged secret into forest-wide persistence, lateral movement, and authentication bypass across dMSAs and gMSAs.
• Defence depends on tier-0 secret governance, directory auditing, and lifecycle visibility for the keys that create managed identities, not just for the identities themselves.

Key terms

• Delegated Managed Service Account: A delegated managed service account is a directory-backed service identity designed to run on authorised machines without manually handled passwords. It inherits much of the managed-service-account model, but its security still depends on the integrity of the directory objects and cryptographic roots that generate and protect its credentials.
• KDS Root Key: The KDS root key is the cryptographic foundation used by Active Directory to derive managed service account passwords. If an attacker can access it, they may be able to compute credentials for multiple related accounts, which makes it a tier-0 secret rather than a routine configuration object.
• ManagedPasswordId: ManagedPasswordId is the metadata structure used to derive managed service account passwords. It contains fields that help compute current or future passwords, which means its protection is as important as protecting the account itself when defenders rely on automated credential generation.
• Identity Blast Radius: Identity blast radius is the scope of systems, accounts, and services that become exposed when one identity control fails. In this case, one compromised root key can affect many managed service accounts, turning a narrow secret exposure into broad lateral movement and persistence risk.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Semperis: Golden dMSA attack analysis and managed service account exposure. Read the original.