Golden GMSA

This blogs briefs the attack vector targeting Group Managed Service Accounts (gMSA). An attacker who has administrator privileges can dump the KDS Root Key and obtain the password of gMSA

Theory and Background

In General, passwords of the Service Accounts are not auto-rotated and are managed by IT Administrators which makes it vulnerable to Kerberoasting Attack. Attacker with the domain user privileges can get the service ticket and crack it offline to obtain the password of the service account. To solve this problem, Group Managed Service Account was introduced by Microsoft which had the sole purpose of auto-rotating the passwords of service accounts.

Despite the possible attack-vectors in gMSA

• Usage of services across multiple servers

• Automated Password Management

Password Management in gMSA

The gMSA passwords are randomly generated, automatically rotated, and not required to be known by any user. The service accounts themselves are 'installed' on the server that is to be querying the password information from Active Directory at run time. When a server needs to access the gMSA accounts, it makes a request to the DC for the recent password of that particular account. The account attribute msDS-ManagedPassword is the BLOG contains the password.

Attribute - msDS-ManagedPassword

The CurrentPassword is the placeholder where the password for gMSA Account is present. The msDS-GroupMSAMembership attribute is used for access checks to determine if a requestor has permission to retrieve the password for a group MSA.

The passwords of these accounts are computed when it is required. The gMSA password is computed via calling a function that is present in kdscli.dll. Calling this function requires three things:

1. SID of the gMSA Account

2. msds-ManagedPasswordID of the gMSA (can be retrieved by using an LDAP query)

3. GKE (Group Key Envelope ), which can be generated by calling the GetKey method on the DC with high privileges via RPC

Configuring gMSA aka Vulnerable Environment

Creating the KDS Root Key at the domain controller

Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))

Verifying the Root Keys

Get-KdsRootKey

Creating the gMSA account

New-ADServiceAccount -Name <NAME> -DNSHostName <NAME.DOMAIN.LOCAL> -PrincipalsAllowedToRetrieveManagedPassword <SERVERS>

PrincipalsAllowedToRetrieveManagedPassword - AD Objects that can only use the this service account. This can be pointing to a server or a domain group which contains the servers.

Configuring the Service Principal Name (SPN) for the created GMSA Account.

Set-ADServiceAccount -Name <NAME> -ServicePrincipalName @{Add=<SPN_VALUE>}

Attack Scenario & Exploitation

The tool used for performing the GoldenGMSA Attack can be found here. The tool can retrieve the msDS-ManagedPasswordID based on a gMSA SID and can generate the gMSA’s password offline. Attacker upon retrieving the passwords of the gMSA Accounts, can compromise services that use the gMSA by forging a Silver Ticket or obtaining a Kerberos service ticket for privileged accounts through S4U2Self.

Retrieving the gMSA information present in the domain

GoldenGMSA.exe gmsainfo

Dumping the KDS Root Key (This requires higher privileges)

GoldenGMSA.exe kdsinfo

Computing the password for the gMSA Account (gmsa-test01), it returns a password in Base 64 encoded format

GoldenGMSA.exe computer --sid <SID>