gMSADumper
A group Managed Service Account has a managed password that approved principals can retrieve. Overbroad reader membership can expose its authentication material. The report uses a BloodHound ReadGMSAPassword edge as the investigation lead.
Retrieve under the authorised identity
python3 gMSADumper.py --help
python3 gMSADumper.py -u labuser -p '<LAB_PASSWORD>' \
-d example.test -l dc01.example.test
Record the account used and the LDAP endpoint. The script lists reader information and parses blobs that the current identity can access. A listed gMSA is not proof that its password blob was readable.
Interpret and validate
A returned NT hash represents the gMSA, whose name usually ends in $. The managed password is long binary-derived material; do not assume a usable human-readable password accompanies every result.
nxc smb 192.0.2.20 -d example.test -u 'svc-lab$' -H '<NT_HASH>'
Success: retrieval produces authentication material for a specific gMSA, and the selected service accepts it. Ordinary authentication success does not imply local administrator or WinRM access. Determine the gMSA’s actual group membership, service permissions and remote-logon rights before choosing the next action. Reduce managed-password reader permissions and remove obsolete service privileges.
Prerequisites and account discovery
Start with the domain FQDN, a reachable DC, and a known reader identity. The right is tied to the gMSA’s password-reader security descriptor; it may be inherited through group membership. Check the effective membership rather than relying only on a group name in a graph.
ldapsearch -LLL -x -H ldaps://dc01.example.test \
-D 'labuser@example.test' -W -b 'DC=example,DC=test' \
'(objectClass=msDS-GroupManagedServiceAccount)' \
sAMAccountName distinguishedName memberOf servicePrincipalName
This query inventories accounts without asking for their password blobs. Use a trusted CA for LDAPS. Missing msDS-ManagedPassword in an ordinary search is not proof that the account has no password.
Choose the authentication material deliberately
| Available material | Tool path | Important detail |
|---|---|---|
| Password | -u, -p, -d, -l | Quote shell-sensitive passwords |
| LM:NT pair | Upstream accepts the pair through -p | This is not NetExec’s -H syntax |
| Existing Kerberos cache | -k, -d, -l | FQDN, realm and cache principal must agree |
export KRB5CCNAME="$PWD/labuser.ccache"
klist
python3 gMSADumper.py -k -d example.test -l dc01.example.test
Upstream’s interface differs from other gMSA tools. Check its installed help before copying flags for signing, TLS or a different authentication method. This script can enumerate multiple gMSAs; it is not automatically limited to the single account that interested you in BloodHound.
What to record from the output
| Item | Why it matters |
|---|---|
gMSA name including $ | Identifies the service account rather than the reader |
| DC and timestamp | Password rotation and replication can affect later validation |
| Reader SID/group | Explains the access path and where to remediate it |
| Whether a blob was actually parsed | Separates discovery from disclosure |
| Service validation result | Establishes usable authentication and its limits |
Do not put the recovered hash in a public report. A redacted output line and a restricted evidence attachment are enough to connect the account to the result.
Troubleshooting
| Symptom | Check before retrying |
|---|---|
| No accounts listed | Correct naming context, domain and DC; tool compatibility |
| Account listed but no hash | Effective reader permission and whether the blob was returned |
| LDAP bind fails | Identity format, transport requirements, password/hash syntax |
| Kerberos principal error | DC FQDN, realm configuration and available cache |
| Hash authenticates but WinRM fails | Remote-logon permission and service ACLs |
| Previously valid hash fails | Managed-password rotation, target identity and replication |
Finish the chain with a permission check
After one successful service login, inspect only the privileges relevant to the proposed next step. A gMSA used by a privileged service is not necessarily a domain administrator. Follow its group memberships and object rights with SharpHound or BloodyAD, then verify those rights against the current directory.
The durable fix is to narrow the password-reader set and the gMSA’s privileges together. Removing a broad reader group while leaving an alternate readable path can leave the same exposure.
Related learning
How attacks work. Examples use fictional lab values; replace placeholders only with values from the system you are testing.