A Golden gMSA attack recovers the KDS root key, the domain secret that derives every group Managed Service Account (gMSA) password. With the key and a target account's attributes, the attacker computes the gMSA password offline, at any time, with no further contact with a DC, similar to a Golden Ticket but for service accounts. It is a durable persistence technique because rotating a gMSA password does not help while the root key is known. Defend by protecting the KDS root key as tier-0.
What a Golden gMSA attack is
gMSA passwords are not stored per account; they are computed from the KDS root key plus account attributes, and the domain rotates them automatically. That design is convenient, but it means the KDS root key is a master secret. Whoever reads it can derive the current and future password of every gMSA in the domain.
How the attack works
With rights to read the KDS root key (Domain Admin, or a principal with access to the Key Distribution Service object) the attacker extracts it and the target gMSA's attributes, then computes the password offline with a tool such as GoldenGMSA. The recovered password (or its hash) is then used to authenticate as the service account. Because the computation is offline, it leaves no authentication trail until the derived credential is used.
How to defend against it
Treat the KDS root key as a tier-0 secret: audit who can read the Key Distribution Service objects and keep that set minimal. Monitor access to the KDS root key object, scope gMSA usage so a compromised service account reaches little, and remember that rotating a gMSA password does not remediate a leaked root key, you must generate a new root key and migrate.
References
- [1]MITRE ATT&CK Enterprise Matrix(MITRE ATT&CK)
- [2]Microsoft: Group Managed Service Accounts overview(Microsoft)
One leaked KDS root key hands over every service account you have. Talk to a security expert about testing your tier-0 secrets.