golden-dmsa-gmsa.md (12317B)
1 --- 2 title: "Golden gMSA/dMSA Attack (Offline Derivation of Managed Service Account Passwords)" 3 section: "Windows" 4 sectionSlug: "windows-hardening" 5 sourcePath: "src/windows-hardening/active-directory-methodology/golden-dmsa-gmsa.md" 6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/windows-hardening/active-directory-methodology/golden-dmsa-gmsa.md" 7 sha: "188de82beb54e70956b2952367a0af91d26758b8" 8 isIndex: false 9 modified: true 10 license: "CC-BY-NC-4.0" 11 --- 12 13 # Golden gMSA/dMSA Attack (Offline Derivation of Managed Service Account Passwords) 14 15 ## Overview 16 17 Windows Managed Service Accounts are domain principals intended to run services without an administrator handling a long-lived password: 18 19 1. **gMSA** (group Managed Service Account) can be used by the computers authorised through `msDS-GroupMSAMembership` / `PrincipalsAllowedToRetrieveManagedPassword`. 20 2. **dMSA** (delegated Managed Service Account) was introduced in **Windows Server 2025**. It binds normal authentication to authorised machine identities and can replace a legacy service account through a migration workflow. 21 22 Do not confuse **Golden dMSA** with **BadSuccessor**. Golden dMSA requires compromise of KDS root-key material and derives managed-account keys; [BadSuccessor](/hacktricks/windows-hardening/active-directory-methodology/badsuccessor-dmsa-migration-abuse) instead abuses control of a dMSA object and its migration attributes. 23 24 A DC does not store an independently generated clear-text password for every gMSA. It derives the account password from a **KDS root key**, a time-indexed Group Key Distribution Protocol (GKDI) key, and the account SID. The root-key objects are `msKds-ProvRootKey` objects below `CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,...`; the sensitive value is `msKds-RootKeyData`. `msDS-ManagedPasswordId` is **not a GUID**: it is a binary key identifier containing the KDS root-key GUID, the GKDI `L0`/`L1`/`L2` indexes, and domain/forest metadata. The DC applies the KDF with the label `GMSA PASSWORD` and the binary SID as context, then exposes an `MSDS-MANAGEDPASSWORD_BLOB` only to principals authorised to retrieve a gMSA password.<sup>[[2]](#references)</sup> 25 26 A dMSA normally differs operationally: its secret is meant to remain on the DC and the KDC issues credentials to an authorised machine. However, dMSAs reuse the underlying KDS/GKDI password derivation. Golden dMSA reconstructs that secret directly and therefore bypasses the intended machine-bound flow and Credential Guard on the service host.<sup>[[1]](#references)</sup> 27 28 ## Golden gMSA / Golden dMSA Attack 29 30 After extracting a KDS root key, an attacker can derive passwords for accounts tied to that key without reading `msDS-ManagedPassword`. This bypasses the per-account password-retrieval ACL and survives ordinary managed-password rotations while the compromised root key remains in use. For gMSAs, the readable `msDS-ManagedPasswordId` normally supplies the exact key identifier. For ACL-restricted dMSAs, Golden dMSA reduces the missing identifier to only **1,024 candidates**.<sup>[[1]](#references)[[2]](#references)</sup> 31 32 ### Prerequisites 33 34 * The relevant KDS root-key object, usually obtained with Enterprise Admin / forest-root Domain Admin rights, `SYSTEM` on a DC, or from an exposed DC database or backup.<sup>[[1]](#references)[[2]](#references)</sup> 35 * The target account's SID, DNS domain, forest name, and `sAMAccountName`.<sup>[[1]](#references)[[2]](#references)</sup> 36 * For direct gMSA computation, its base64-encoded `msDS-ManagedPasswordId`; for Golden dMSA this can instead be guessed.<sup>[[1]](#references)[[2]](#references)</sup> 37 * An x64 Windows host with .NET Framework 4.7.2 for [`GoldenDMSA`](https://github.com/Semperis/GoldenDMSA).<sup>[[3]](#references)</sup> 38 39 ### Phase 1 - Extract the KDS root key 40 41 `GoldenDMSA` and [`GoldenGMSA`](https://github.com/Semperis/GoldenGMSA) export the root-key object fields as a base64 blob. Without a domain argument, the tools query the forest root and require suitable privileged directory access. With the domain/forest argument, `SYSTEM` on a DC can query that DC's local Configuration naming-context replica.<sup>[[1]](#references)[[2]](#references)</sup> 42 43 ```batch 44 :: GoldenDMSA: Enterprise Admin, or SYSTEM on a DC with --domain 45 GoldendMSA.exe kds 46 GoldendMSA.exe kds -g KDS_ROOT_KEY_GUID 47 GoldendMSA.exe kds --domain child.example.local 48 49 :: GoldenGMSA equivalents 50 GoldenGMSA.exe kdsinfo 51 GoldenGMSA.exe kdsinfo --guid KDS_ROOT_KEY_GUID 52 ``` 53 54 Record both the root-key GUID and the base64 root-key blob. A registry `SECURITY`/`SYSTEM` hive export is not by itself the KDS root key: the authoritative material is in the AD Configuration partition.<sup>[[1]](#references)[[2]](#references)</sup> 55 56 ### Phase 2 - Enumerate gMSA / dMSA objects 57 58 For gMSAs, obtain `sAMAccountName`, `objectSid`, and the binary `msDS-ManagedPasswordId`. The latter is normally readable even when the caller is not allowed to retrieve `msDS-ManagedPassword`.<sup>[[2]](#references)</sup> 59 60 ```powershell 61 Get-ADServiceAccount -Filter * -Properties objectSid,msDS-ManagedPasswordId | 62 Select-Object sAMAccountName,objectSid,msDS-ManagedPasswordId 63 64 GoldenGMSA.exe gmsainfo --domain example.local 65 ``` 66 67 A dMSA's default ACL can prevent low-privileged LDAP enumeration. `GoldenDMSA info` can either query LDAP or enumerate candidate RIDs and resolve SIDs through `LsaLookupSids` over `\PIPE\lsarpc`, then distinguish dMSAs from computer accounts and gMSAs.<sup>[[1]](#references)[[3]](#references)</sup> 68 69 ```batch 70 GoldendMSA.exe info -d example.local -m ldap 71 GoldendMSA.exe info -d example.local -m brute -u alice -p PASSWORD -o EXAMPLE -r 5000 72 ``` 73 74 ### Phase 3 - Reconstruct or guess `msDS-ManagedPasswordId` 75 76 The key identifier includes `L0Index`, `L1Index`, and `L2Index`, not an account-creation timestamp followed by random bits. Semperis found that the password-generation path does not consume the candidate `L0Index`, while `L1Index` and `L2Index` are each limited to values `0..31`. Consequently, an attacker who knows the root-key GUID, domain, forest, and SID can construct all `32 * 32 = 1,024` candidate identifiers.<sup>[[1]](#references)</sup> 77 78 ```batch 79 :: Write 1,024 base64 ManagedPasswordId candidates to KDS_ROOT_KEY_GUID.txt 80 GoldendMSA.exe wordlist -s DMSA_SID -d example.local -f example.local -k KDS_ROOT_KEY_GUID 81 82 :: Derive and validate candidates; -t caches the successful TGT 83 GoldendMSA.exe bruteforce -s DMSA_SID -i KDS_ROOT_KEY_GUID -k KDS_ROOT_KEY_BASE64 -d example.local -u svc_dmsa$ -t 84 ``` 85 86 The derivations are offline, but identifying the live candidate usually requires authentication attempts. This can produce a burst of failed Kerberos pre-authentication or NTLM validation before the valid key is found. For AES Kerberos keys, the managed-account salt used by the tool is `UPPERCASE.DNS.DOMAIN` + `host` + the lower-case account UPN without the trailing `$` (for example, `EXAMPLE.LOCALhostsvc_dmsa.example.local`).<sup>[[1]](#references)</sup> 87 88 ### Phase 4 - Compute and use the password 89 90 If the exact identifier is known, compute the 256-byte password buffer and convert it to NTLM/AES material. The base64 value printed by these tools is the encoded password buffer, **not** the LDAP `MSDS-MANAGEDPASSWORD_BLOB` itself.<sup>[[2]](#references)[[3]](#references)</sup> 91 92 ```batch 93 GoldendMSA.exe compute -s ACCOUNT_SID -k KDS_ROOT_KEY_BASE64 -d example.local -m MANAGED_PASSWORD_ID_BASE64 94 GoldendMSA.exe convert -d example.local -u svc_account$ -p BASE64_PASSWORD 95 96 GoldenGMSA.exe compute --sid ACCOUNT_SID --kdskey KDS_ROOT_KEY_BASE64 --pwdid MANAGED_PASSWORD_ID_BASE64 97 ``` 98 99 The NTLM result can be used where NTLM is accepted; the AES key can be used for overpass-the-hash / TGT requests where the managed account is AES-only. This gives the privileges, SPNs, delegation configuration, and resource access of the compromised managed service account without adding the attacker's machine to `PrincipalsAllowedToRetrieveManagedPassword`.<sup>[[1]](#references)[[2]](#references)</sup> 100 101 ### Cross-domain Configuration-partition abuse 102 103 KDS root-key objects live in the forest Configuration naming context, which is replicated to DCs in child domains. Consequently, `SYSTEM` on a child-domain DC can read the forest-root KDS material from the child DC's local replica, even though child Domain Admins cannot read the object from a forest-root DC directly. If the attacker can also read a parent-domain gMSA's `msDS-ManagedPasswordId`, GoldenGMSA can calculate that parent account's password; SID filtering does not prevent this cryptographic attack.<sup>[[5]](#references)</sup> 104 105 ```batch 106 :: Run as SYSTEM on a child.example.local DC 107 GoldenGMSA.exe kdsinfo --forest child.example.local 108 109 :: Query target metadata in the parent, then combine both inputs 110 GoldenGMSA.exe gmsainfo --domain example.local 111 GoldenGMSA.exe compute --sid PARENT_GMSA_SID --domain example.local --forest child.example.local 112 ``` 113 114 ## Detection, Containment and Recovery 115 116 * Configure a SACL on the **Master Root Keys** container, inherited by `msKds-ProvRootKey` objects, for successful reads of `msKds-RootKeyData`. With Directory Service Access auditing enabled, an online extraction produces Security event **4662**; investigate subjects that are not expected DCs or Tier-0 operators. Also audit changes to these SACLs and root-key object ACLs.<sup>[[1]](#references)[[2]](#references)[[4]](#references)</sup> 117 * A child-to-parent attack reads the KDS object from the compromised child DC's local replica, so the forest-root domain might not observe that read. In the parent domain, audit successful reads of `msDS-ManagedPasswordId` (schema GUID `0e78295a-c6d3-0a40-b491-d62251ffa0a6`) on `msDS-GroupManagedServiceAccount` objects and investigate reads by principals from another domain.<sup>[[5]](#references)</sup> 118 * Correlate KDS-object access with unusual logons by managed accounts and bursts of Kerberos/NTLM failures for `$`-suffixed service accounts. Offline computation after prior database/backup theft is not visible to a live DC.<sup>[[1]](#references)[[3]](#references)</sup> 119 * Ordinary password rotation is not sufficient after root-key exposure. Microsoft's current recovery procedure creates a new KDS root key, restarts KDS on all relevant DCs, and moves affected accounts to that key. If the exposure scope/time is unknown and waiting for a safe roll is unacceptable, replace every gMSA that used the compromised key; if the scope is known, Microsoft documents an authoritative-restore workflow to force safe rolling. Validate the new key GUID in `msDS-ManagedPasswordId` before deleting the old key.<sup>[[4]](#references)</sup> 120 * Treat DC database and backup access, Configuration-partition replication, and KDS root-key administration as Tier-0. Reducing `ManagedPasswordIntervalInDays` limits some recovery windows but does not revoke an already compromised root key.<sup>[[4]](#references)</sup> 121 122 ## Tooling 123 124 * [`Semperis/GoldenDMSA`](https://github.com/Semperis/GoldenDMSA) - dMSA/gMSA enumeration, identifier generation, 1,024-candidate validation, password computation, and NTLM/AES conversion.<sup>[[3]](#references)</sup> 125 * [`Semperis/GoldenGMSA`](https://github.com/Semperis/GoldenGMSA/) - gMSA/KDS enumeration and online, offline, and cross-domain password computation.<sup>[[2]](#references)</sup> 126 * [`Rubeus`](https://github.com/GhostPack/Rubeus) and [`Impacket`](https://github.com/fortra/impacket) - use or validate the derived NTLM/AES keys in authorised testing. 127 128 129 ## References 130 131 - [1] [Golden dMSA - authentication bypass for delegated Managed Service Accounts](https://www.semperis.com/blog/golden-dmsa-what-is-dmsa-authentication-bypass/) 132 - [2] [gMSA Active Directory Attacks](https://www.semperis.com/blog/golden-gmsa-attack/) 133 - [3] [Semperis/GoldenDMSA GitHub repository](https://github.com/Semperis/GoldenDMSA) 134 - [4] [Microsoft - How to recover from a Golden gMSA attack](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/recover-from-golden-gmsa-attack) 135 - [5] [SID filter as security boundary between domains? Part 5 - Golden gMSA trust attack](https://itm8.com/articles/sid-filter-as-security-boundary-between-domains-part-5)