# dMSA Ouroboros: Self-Sustaining Credential Extraction in Windows Server 2025

A standard domain user with CreateChild and WriteProperty creates a dMSA that authorizes itself via GroupMSAMembership and a planted Shadow Credential, extracting the superseded account's NT hash indefinitely.

- Payout: Research
- Severity: high
- Program: Windows Server
- Credited: Huntress
- Disclosed: 2026-05-04
- Write-up quality: 9/10
- Original: https://www.huntress.com/blog/dmsa-ouroboros-credential-extraction-windows-server-2025
- Library page: https://bugbountylibrary.com/r/blog%3Ahuntress-com-blog-dmsa-ouroboros-credential-extraction-windows-server-2025
- Tags: domain:infra impact:data-leak impact:privesc kind:research platform:threat-intel sev:high tech:windows technique:chained technique:source-review vuln:access-control vuln:auth-bypass vuln:privilege-escalation

**Target:** Active Directory dMSA (msDS-DelegatedManagedServiceAccount) objects on Windows Server 2025 DC
**Root cause:** The KDC does not prevent a dMSA's own SID from appearing in its msDS-GroupMSAMembership, and the dMSA defaultSecurityDescriptor does not restrict writes to msDS-KeyCredentialLink, so the object can authenticate itself via PKINIT and authorize its own KERB-DMSA-KEY-PACKAGE issuance.
**Steps:**
1. As a user with CreateChild on an OU and WriteProperty on target's migration-link attributes, create dMSA `dmsa-adriana` with `svc-ouroboros` as superseded account, setting both `msDS-ManagedAccountPrecededByLink` and `msDS-SupersededManagedAccountLink` (satisfies CVE-2025-53779 bidirectional check)
2. As object Owner, use implicit WriteDacl to grant self GenericAll on the dMSA
3. Write an X.509 cert to `msDS-KeyCredentialLink` (Shadow Credential), keep the .pfx
4. Write the dMSA's own SID into `msDS-GroupMSAMembership` using expanded specific rights `A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;` (NOT `GA`, which yields KDC_ERR_POLICY); use System.DirectoryServices.ActiveDirectorySecurity for correct binary format
5. PKINIT authenticate as the dMSA with the planted cert (UnPAC-the-hash)
6. Request TGT via `S4U2Self --dmsa` against itself; KDC returns KERB-DMSA-KEY-PACKAGE with superseded account's NT hash
7. Verify extracted RC4 matches DCSync of target; repeat after password rotation to get refreshed hash
**How found:** Systematic audit of the SELF principal (S-1-5-10) across the AD schema to find self-writable attributes crossing security boundaries; narrowed to dMSA class inheriting from computer, where creator becomes Owner -> WriteDacl -> GenericAll, exposing msDS-KeyCredentialLink and msDS-GroupMSAMembership. SDDL format discovered by testing GA vs expanded rights.
**Exploitation:** Attacker with delegated CreateChild and WriteProperty creates a dMSA linked to a high-value service account, plants a Shadow Credential for password-independent PKINIT auth, and self-enrolls the dMSA's SID in GroupMSAMembership. The dMSA then authenticates and authorizes itself, returning the superseded account's current NT hash on every S4U2Self --dmsa request. Chain survives password rotation, attacker account deletion, and locks Domain Admins out of remediation.
**Escalation:** Extracted NT hash of a high-value service account enables lateral movement; self-referential loop removes attacker account from runtime chain, making persistence self-sustaining and undetectable by current tooling.
**Insight:** Audit SELF-writable and creator-owned attributes on new AD object classes: object ownership grants implicit WriteDacl, and any self-writable attribute feeding an authorization decision (like GroupMSAMembership) can be turned into a self-authorizing loop. Also test whether KDC authorization checks expand generic rights (GA) vs specific rights — they may not.