dMSA Ouroboros: Self-Sustaining Credential Extraction via Delegated Managed Service Accounts in Windows Server 2025

Indicators

• Unexpected dMSA (delegated Managed Service Account) objects created in Active Directory by non-privileged accounts
• dMSA objects referencing privileged accounts or service accounts via msDS-ManagedAccountPrecededByLink or msDS-SupersededManagedAccountLink attributes
• Credential extraction activity on Windows Server 2025 domain controllers without corresponding Domain Admin logon events
• Unusual or repeated dMSA attribute modifications by standard delegated accounts
• Self-referencing or circular dMSA relationships observable in Active Directory object attributes
• Security Event ID 5137 (object creation) for msDS-DelegatedManagedServiceAccount by non-administrative accounts
• Security Event ID 5136 (attribute modification) on dMSA objects by non-privileged accounts

Likely causes

• Windows Server 2025 introduced dMSA with delegation of creation/management permissions to standard users, creating an exploitable attack surface that does not require Domain Admin privileges
• The dMSA Ouroboros technique abuses the credential migration/supersession mechanism by linking a newly created dMSA to a privileged account via msDS-ManagedAccountPrecededByLink, causing the DC to provision credentials for the privileged account to the attacker-controlled dMSA
• Standard delegated permissions (permission to create dMSA objects in an OU) are sufficient to execute the attack
• The self-sustaining nature arises because the attacker's dMSA can be configured to reference itself or chain references, making it resilient to simple remediation such as deleting the dMSA object

Diagnostic steps

1. Enumerate all dMSA objects in the domain and review their creation timestamps, creators, and linked predecessor accounts
   Identify dMSA objects that may have been created by non-privileged accounts or that reference privileged accounts via supersession attributes, indicating potential Ouroboros exploitation
2. Review Active Directory delegation permissions on all Organizational Units to identify accounts or groups granted rights to create dMSA objects
   Determine the scope of who can create dMSA objects, which represents the minimum privilege level required to execute this attack
3. Inspect msDS-ManagedAccountPrecededByLink and msDS-SupersededManagedAccountLink attributes on all dMSA objects to detect circular or unexpected account linkages
   Identify the self-referencing or privilege-escalating link structure that enables sustained credential extraction without requiring re-exploitation
4. Search Security event logs on domain controllers for dMSA-related creation (Event ID 5137) and modification (Event ID 5136) events generated by non-administrative accounts
   Confirm whether exploitation has occurred and establish a timeline of attacker activity for incident response
5. Verify whether any dMSA objects have been granted logon rights or deployed to systems where credential extraction from LSASS or the KDC response could yield privileged tickets
   Assess the practical impact of any identified Ouroboros-configured dMSA objects and determine which privileged credentials may have been compromised

Resolution path

• 1. IMMEDIATE: Audit and restrict delegated permissions — Remove or tightly scope 'Create dMSA objects' delegation from any OU where it has been granted to non-administrative accounts. Use Active Directory Delegation of Control Wizard or ADSI Edit to review and revoke excess CreateChild permissions for the msDS-DelegatedManagedServiceAccount object class.
• 2. Identify and disable all suspicious dMSA objects — For any dMSA found with unexpected msDS-ManagedAccountPrecededByLink references to privileged accounts, immediately disable: `Disable-ADServiceAccount -Identity '<dMSA SAMAccountName>'` — then delete after forensic review: `Remove-ADServiceAccount -Identity '<dMSA SAMAccountName>'`
• 3. Rotate credentials for any privileged accounts that were referenced by attacker-controlled dMSA objects via supersession/preceded-by links, as those credentials may have been extracted by the domain controller during normal dMSA key derivation.
• 4. Apply principle of least privilege to dMSA management — Ensure dMSA creation rights are restricted exclusively to Domain Admins or a tightly controlled, audited administrative tier. Review and enforce via Group Policy and AD delegation audits.
• 5. Implement alerting on Security Event IDs 5136 and 5137 filtered to dMSA object class changes, and alert on any new dMSA creation by non-tier-0 accounts.

Prevention

• Restrict dMSA creation permissions exclusively to Tier 0 administrative accounts: Audit all Organizational Units for CreateChild delegation on the msDS-DelegatedManagedServiceAccount object class and remove any grants to non-privileged principals.
• Implement continuous monitoring and alerting on Active Directory Security Event IDs 5136 (attribute modification) and 5137 (object creation) filtered to dMSA object class, with automated alerting when the creating account is not a member of Domain Admins or equivalent tier-0 group.
• Apply Zero Trust principles to dMSA lifecycle management: require approval workflows, logging, and periodic attestation for all dMSA objects, including review of msDS-ManagedAccountPrecededByLink and supersession attributes on any existing dMSA objects.
• Evaluate whether dMSA functionality is required in your environment; if not, consider blocking creation via AppLocker/WDAC policies or GPO-enforced ACL hardening on the domain partition.

Tools

• Active Directory PowerShell module (Get-ADServiceAccount, Disable-ADServiceAccount, Remove-ADServiceAccount — dMSA enumeration and management)
• ADSI Edit / LDP.exe (direct inspection of dMSA LDAP attributes including supersession links)
• Active Directory Delegation of Control Wizard (reviewing and revoking OU-level CreateChild permissions)
• Windows Event Viewer / Get-WinEvent (reviewing Security events 5136/5137 for AD object changes)
• SIEM platform (correlating dMSA creation/modification events with account context for detection)

References

• dMSA Ouroboros: Self-Sustaining Credential Extraction in Windows Server 2025 — Huntress Blog