GoldenGMSA
Theory
What is a gMSA account?
Within an Active Directory environment, service accounts are often created and used by different applications. These accounts usually have a password that is rarely updated. To address this issue, it is possible to create Group Managed Service Accounts (gMSA), which are managed directly by AD, with a strong password and a regular password rotation.
The password of a gMSA account can legitimately be requested by authorized applications. In that case, an LDAP request is made to the domain controller, asking for the gMSA account's msDS-ManagedPassword
attribute's value.
A gMSA account's msDS-ManagedPassword
attribute doesn't actually store the password (it's a constructed attribute). Everytime that attribute is requested by an authorized principal, the domain controller computes it and returns the result. The calculation is detailed a bit more in the password calculation part of this recipe, but simply said, it relies on a static master key (i.e. one of the KDS root keys) and some additional data relative to the gMSA account.
The "GoldenGMSA" persistence lies in the fact that the KDS root keys used for gMSA password calculation don't change (at least not without some admin intervention or custom automation). Once they are exfiltrated and saved, any gMSA account password can be calculated since the additional values needed can be obtained by any low-privileged user.
Practice
Obtaining persistence
Once an AD environment is compromised, acquiring the "GoldenGMSA" persistence requires to dump the KDS root keys.
The KDS (Key Distribution Service) root keys can be exfiltrated from the domain with high-privileged access with GoldenGMSA (C#).
Without the --forest
argument, the forest root domain is queried, hence requiring Enterprise Admins or Domain Admins privileges in the forest root domain, or SYSTEM privileges on a forest root Domain Controller.
With the --forest
argument specifying the target domain or forest, SYSTEM privileges are required on the corresponding domain or forest Domain Controller. In case a child domain is specified, the parent domain keys will be dumped as well.
Retrieving gMSA passwords
Later on, the attacker can then, with low-privileged access to the domain:
dump some information relative to the gMSA account to retrieve the password for
use those elements to calculate the gMSA password
Account information dump
In addition to the KDS root keys, the following information, relative to a gMSA, need to be dumped in order to compute its password:
SID (Security IDentifier)
RootKeyGuid: indicating what KDS root key to use
Password ID: which rotates regularly
The information can be dumped with low-privilege access to AD with GoldenGMSA (C#).
In order to dump the necessary information of a single gMSA, its SID can be used as filter with the --sid
argument.
Password calculation
Given a gMSA SID, the corresponding KDS root key (matching the RootKeyGuid obtained beforehand), and the Password ID, the actual plaintext password can be calculated with GoldenGMSA (C#).
Since the password is randomly generated and is not intended to be used by real users with a keyboard (but instead by servers, programs, scripts, etc.) the password is very long, complex and can include non-printable characters. GoldenGMSA will output the password in base64.
In order to use the password, its MD4 (i.e. NT) hash can be calculated, for .
The GoldenGMSA (C#) tool featured in this recipe can retrieve gMSA password without the --kdskey
or --pwdid
arguments, by requesting those information. If the --kdskey
is not supplied, high-privilege access will be needed by the tool, which is outside the scope of the GoldenGMSA technique explained in this recipe.
Resources
Last updated