This is part five of a seven part series. Check out part 1 Kerberos authentication explained for links to the others.
In part four of this series, we saw how the replication of Configuration naming context (NC) to child domains allows for the GPO on site attack. Right after discovering this, the GoldenGMSA tool by Yuval Gordon was released, which makes it possible to compromise the password of a Group Managed Service Account’s (gMSA) in a domain if high privileges are obtained in the same domain.
Combining the Configuration NC replication attack research and the GoldenGMSA tool we found that another child to parent attack is possible.
Content
The GoldenGMSA tool
GoldenGMSA attack – from child to parent
Mitigation and detection
Part 5 conclusion
The GoldenGMSA tool
Here is a demonstration of the original attack:
Privileges required to compromise a gMSA are either:
Member of Enterprise Admins
Member of Domain Admins
SYSTEM on a DC
By requiring such high privileges this attack therefore seems like a domain persistence technique, to quote Yuval:
“The Golden GMSA attack occurs when an attacker dumps a KDS root key’s relevant attributes and then uses them to generate the password for associated gMSA accounts offline. The Golden GMSA attack is somewhat similar to the Golden Ticket attack, which allows attackers who compromise the krbtgt account to forge Ticket Granting Tickets (TGTs) as long as the krbtgt password remains unchanged.
One notable difference between a Golden Ticket attack and the Golden GMSA attack is that we are not aware of a way of rotating the KDS root key secret. Therefore, if a KDS root key is compromised, there is no way to protect the gMSAs associated with it. The only mitigation in such a scenario is to create new gMSAs with a new KDS root key. “
GoldenGMSA attack – from child to parent
We found that the GoldenGMSA attack also makes it possible to obtain gMSA passwords across intra-forest trusts, so that a child domain can compromise gMSA’s of a parent domain.
As specified by Yuval, the attack requires access to the following attributes of the KDS Root Key in the forest root:
cn
msKds-SecretAgreementParam
msKds-RootKeyData
msKds-KDFParam
msKds-KDFAlgorithmID
msKds-CreateTime
msKds-UseStartTime
msKds-Version
msKds-DomainID
msKds-PrivateKeyLength
msKds-PublicKeyLength
msKds-SecretAgreementAlgorithmID
The GoldenGMSA tool obtains these using LDAP by reading attributes of msKds-ProvRootKey objects in “CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=root,DC=local”:
Looking at the DACL we find ‘root\Domain Admins’, ‘root\Enterprise Admins’, and SYSTEM are granted ‘Full control’:
Reading the source code of the GoldenGMSA tool we found out that the two arguments:
‘gmsainfo’ queries the current domain (child domain) for gMSA accounts, where none exist (we want to compromise the parent domain)
‘kdsinfo’ queries the forest root (parent domain) for the KDS key attributes, which is not allowed by the ACL
The tool does therefore not work in a child domain:
But as described in part 4 in the GPO on site attack, the Configuration NC is replicated to child DCs, and we can therefore read KDS Root Keys in the DCs local replica with SYSTEM privileges:
This resulted in the discovery of another trust attack, which we added as a pull request to the GoldenGMSA with the parameters ‘-d, --domain’ and ‘-f, --forest’:
To demonstrate the Golden gMSA trust attack, we ran the following from ‘child.root.local’.
The parent domain (root.local) is queried for gMSA accounts
The child domain (child.root.local) is queried for the KDS Root Key
The password of the parent’s gMSA is computed by querying both domains again (known as the ‘online’ attack)
The password of the parent’s gMSA is computed again on a non-domain joined system by supplying the KDS key and gMSA info from above (known as the ‘offline’ attack):
Mitigation and detection
We believe no mitigations exist against this attack because the mitigation would be to prevent replication of KDC keys in the Configuration NC which we do not believe is possible.
Detection of the original single-domain Golden gMSA attack is described in the tool’s original blog post and is done by detecting successful read access to the msKds-RootKeyData attribute of any KDS root key objects in the parent domain.
Detection of our demonstrated Golden gMSA trust attack is different since KDS root key objects are not read in the parent domain. We also cannot trust objects which are replicated to the child domain, since we must assume attackers have control of it. Defenders should therefore configure a SACL on gMSAs in the parent domain to alert on successful read access to the ‘msDS-ManagedPasswordId’ attribute on every gMSA / ‘msDS-GroupManagedServiceAccount’ object in the domain, this can be done by adding a SACL to:
The ‘Managed Service Accounts’ container and inherited to any ‘msDS-GroupManagedServiceAccount’ object
The defaultSecurityDescriptor attribure of the ‘ms-DS-Group-Managed-Service-Account’ schema class, so that any new gMSA object has auditing by default.
The following SDDL can be appended to the default defaultSecurityDescriptor attribute: S:AI(OU;SA;RP;0e78295a-c6d3-0a40-b491-d62251ffa0a6;;WD)
The SACL will be present on any new gMSA:
Once the SACL is configured, any attempt to read the attribute required for an attack will generate the following security events on the parent DC where:
Event ID: 4662
Subject: is not from the gMSA's own domain
Object type: msDS-GroupManagedServiceAccount
Access: Read Property
Properties: Read Property {0e78295a-c6d3-0a40-b491-d62251ffa0a6} (msDS-ManagedPasswordId)
Part 5 conclusion
This post demonstrated another intra-forest trust attack - how the replication of the parent domain’s Configuration container allows a child domain to compromise gMSAs of a parent domain using the GoldenGMSA tool.
The compromise of a parent domain’s gMSA may not allow for instant parent domain compromise, but, as you will see in part 6, the Configuration container replication allows for another powerful child-to-parent attack – a compromise of the parent domain’s schema, just as if we were members of Schema Admins.