Ouroboros Enables Persistent Credential Extraction from Windows Server 2025 dMSAs

Summary

Researchers describe Ouroboros, an Active Directory technique that uses a planted Shadow Credential and dMSA self-enrollment to extract a superseded account’s NT hash, persisting through password rotation and attacker-account deletion.

Key points

The technique requires an authenticated domain user with delegated CreateChild rights for dMSAs and WriteProperty rights on a target account’s migration-link attributes.
The dMSA creator can use object ownership to gain control, plant a Shadow Credential in msDS-KeyCredentialLink, and add the dMSA’s own SID to msDS-GroupMSAMembership.
The resulting dMSA authenticates via PKINIT and authorizes itself to obtain the superseded account’s credential package, including its NT hash.
Researchers report the chain continued to return the target account’s current hash after password rotation and deletion of the original attacker account.
The technique was tested on fully patched Windows Server 2025; Microsoft classified it as persistence and said it did not meet the bar for immediate servicing.
Researchers recommend auditing delegated CreateChild permissions, monitoring dMSA creation, and checking dMSAs for self-membership and populated msDS-KeyCredentialLink attributes.
The article says deleting the dMSA is necessary for complete remediation because partial changes can be reversed by someone retaining WriteDacl.

Article Details

Attack Vectors: A user with CreateChild permission for dMSA objects on an OU or container and WriteProperty permission on a target account's migration-link attributes creates a dMSA with bidirectional migration links to that account.
The dMSA creator uses object ownership to obtain WriteDacl, grants GenericAll, and writes a Shadow Credential to msDS-KeyCredentialLink for PKINIT authentication independent of the managed password.
The attacker writes the dMSA's own SID into its msDS-GroupMSAMembership, allowing it to authorize its own S4U2Self --dmsa request and retrieve the superseded account's NT hash.
The article reports that the chain can continue after the attacker's account is deleted and that password rotation on the superseded account updates the extracted hash rather than breaking the chain.
Defensive Notes: The article identifies deleting the dMSA object as the effective remediation; clearing msDS-KeyCredentialLink or resetting msDS-GroupMSAMembership alone may be undone by a principal retaining WriteDacl.
Audit CreateChild delegations across OUs and containers, and review dMSAs created by non-admin principals.
Check whether any dMSA's msDS-GroupMSAMembership contains its own SID, and inspect msDS-KeyCredentialLink on dMSA objects for unexpected credentials.
Baseline dMSA objects and their creators, superseded accounts, and configuration.
Monitor Event ID 5136 for changes to msDS-GroupMSAMembership and msDS-KeyCredentialLink, Event ID 4662 for access to dMSA objects with S4U2Self delegation, and Event ID 4768 for PKINIT authentication by dMSA computer accounts.