Home Blog dMSA Ouroboros: Self-Sustaining Credential Extraction in Windows Server 2025 Published: May 4, 2026 dMSA Ouroboros: Self-Sustaining Credential Extraction in Windows Server 2025 By: Andrew Schwartz Table of Contents Introduction Background: BadSuccessor and Golden dMSA Understanding the dMSA Security Model The research question The two findings The Ouroboros chain: Seven stages Why remediation fails Golden dMSA vs dMSA Ouroboros Operational reality Proposed BloodHound edges Detection guidance Recommended fixes Microsoft's response Our position Disclosure timeline TL;DR: This companion blog, created in partnership with security researchers at Akamai, unpacks dMSA Ouroboros, a self-sustaining credential extraction technique in Windows Server 2025. After you read their blog , come back here for what it means in practice: a user with CreateChild on any OU or container and WriteProperty on a target account can create a dMSA that extracts the target's NT hash, persists through password rotation, survives the original attacker's account deletion, and locks out Domain Admins from remediation. Six commands. Fully patched Windows Server 2025. Introduction Windows Server 2025 introduced delegated Managed Service Accounts (dMSAs) with a redesigned security model that removes the password retrieval primitive and replaces it with a KDC-mediated authorization flow. The design is genuinely better than gMSA: you cannot read a managed password from the directory, and access to the superseded account's credentials is gated through a separate authorization check. This post introduces Ouroboros , a self-sustaining persistence technique that turns these same semantics against the defender. Rather than bypassing a single validation, Ouroboros engineers a configuration where the dMSA continuously satisfies both authorization gates on its own: it authenticates as itself via a planted Shadow Credential and authorizes itself to receive the superseded account's credentials by writing its own SID into GroupMSAMembership. Once the loop is closed, the original attacker account is no longer part of the chain. The rest of the post builds the precise mental model for these checks, then walks through the Ouroboros chain and how defenders should respond. Background: BadSuccessor and Golden dMSA Two teams found dMSA issues before this research. BadSuccessor (Yuval Gordon, Akamai, 2025) showed that CreateChild on any OU or container was sufficient to create a dMSA with an arbitrary superseded account target. The original attack used one-sided link manipulation to trick the KDC into issuing the target's credentials. Microsoft patched this as CVE-2025-53779 by adding KDC-side validation requiring bidirectional links: both msDS-ManagedAccountPrecededByLink on the dMSA and msDS-ManagedAccountSucceededByLink on the target must exist before the KDC will issue the KERB-DMSA-KEY-PACKAGE . Golden dMSA (Adi Malyanker, Semperis, July 2025) demonstrated that possession of the KDS root key allows brute-forcing dMSA managed passwords because the ManagedPasswordId structure has only 1,024 possible time-based combinations. Microsoft did not assign a CVE, responding that the KDS root key is only accessible to Domain Admins, Enterprise Admins, and SYSTEM, and that these features were never intended to protect against DC compromise. What Microsoft patched post-BadSuccessor : The KDC now validates bidirectional linking before issuing credential material. One-sided links no longer work. However, the patch does not prevent a low-privilege user from creating legitimate bidirectional links if they have the right delegated permissions. It also does not address what happens after the dMSA is created: who can write to the dMSA's security-relevant attributes, and what the KDC does when the dMSA tries to authorize itself. That is where Ouroboros begins. Understanding the dMSA Security Model To understand why Ouroboros works, you need to understand what Microsoft actually changed with dMSA compared to gMSA. The redesign touches two areas, and both matter. Gate 1: Password retrieval is removed With gMSA, msDS-ManagedPassword is a constructed attribute. The DC computes the managed password blob on demand, and if you can read it, you can derive reusable authentication material. The entire gMSA threat model comes down to "who can read this attribute." dMSA intentionally removes that retrieval workflow. The attribute still exists on dMSA objects, but it is effectively unusable: it is denied by default in the defaultSecurityDescriptor , and there is an additional DC-side validation that blocks LDAP reads regardless of ACL. The practical outcome is what Microsoft claims: you cannot retrieve the password for a dMSA from AD. This is a real improvement. The classic gMSA attack path—compromise a principal in msDS-GroupMSAMembership , read the blob, derive the keys—does not work against dMSA. Gate 2: GroupMSAMembership gates operation, not retrieval For gMSA, msDS-GroupMSAMembership is commonly thought of as "who is allowed to retrieve the password." For dMSA, the attribute's meaning shifts: it becomes an authorization gate for who is allowed to operate as the account. Specifically, it controls who can obtain a TGT for the dMSA through the S4U2Self --dmsa flow and receive the KERB-DMSA-KEY-PACKAGE containing the superseded account's credentials. This is also where Credential Guard fits into the picture. If endpoints protect Kerberos material properly, stealing and reusing dMSA credentials becomes harder than the classic "read a blob from AD" pattern. The security model assumes that authentication material is protected in use, and that the authorization gate in GroupMSAMembership controls who enters the flow in the first place. The critical nuance: Two separate gates This leads to an important distinction that most people miss: being able to authenticate as the dMSA is not the same as inheriting the superseded identity. Because dMSA is designed for migration, the dMSA identity by itself is not always the target. The value comes from the superseded user's privileges. The KDC treats these as separate checks: you can authenticate as the dMSA and still not receive the superseded account's PAC and keys unless you go through the dMSA flow by requesting a TGT that satisfies msDS-GroupMSAMembership . So, for an attacker to persistently extract the superseded account's credentials, they need to continuously satisfy both conditions: Authenticate as the dMSA (get a TGT for the dMSA identity) Be authorized in GroupMSAMembership (so the KDC issues the KERB-DMSA-KEY-PACKAGE with the superseded account's material) If either gate fails, the chain breaks. Password rotation should invalidate authentication material. Remediation should remove the attacker from GroupMSAMembership. Credential Guard should protect tickets in memory. Ouroboros defeats all three by making the dMSA satisfy both gates for itself, permanently, without any external principal in the loop. The research question This did not start as dMSA research. The starting point was a systematic audit of the SELF principal ( S-1-5-10 ) across the Active Directory schema. SELF is the identity that resolves to "the object itself." When an ACE grants SELF a write permission, any security principal can perform that action on its own AD object. Users updating their phone numbers, computers writing their DNS names. Standard AD behavior since Windows 2000. The question was: which self-writable attributes cross a security boundary? Most are benign ( telephoneNumber , displayName ). Several are not. The audit produced multiple MSRC submissions across different attack surfaces. Two were closed (data hiding in DA-writable attributes, msTSHomeDirectory coercion) because they required admin-level access and did not cross a meaningful security boundary. The ones that survived the bar all shared a pattern: a self-writable attribute feeds into a system that makes authorization decisions, and nobody was monitoring the write. The dMSA findings emerged when examining what happens after a dMSA is created by a non-admin user. The dMSA class ( msDS-DelegatedManagedServiceAccount , OID 1.2.840.113556.1.5.302 ) inherits from the computer class ( subClassOf: computer ). It has its own defaultSecurityDescriptor that adds deny ACEs for password read and password change, plus Creator Owner write ACEs for dNSHostName , servicePrincipalName , displayName , and sAMAccountName . But it inherits SELF-write ACEs from the computer class, and more importantly, the creator becomes the Owner of the object. Ownership gives WriteDacl . WriteDacl gives you the ability to grant yourself GenericAll . And GenericAll gives write access to every attribute on the object, including msDS-KeyCredentialLink and msDS-GroupMSAMembership . The two findings Finding 1: GroupMSAMembership self-referencing The KDC does not prevent a dMSA's own SID from appearing in its msDS-GroupMSAMembership security descriptor. There is no validation that says "a dMSA cannot authorize itself to retrieve its own credentials." An attacker with write access to GroupMSAMembership can add the dMSA's SID, and from that point forward, the dMSA can perform S4U2Self --dmsa against itself and receive the KERB-DMSA-KEY-PACKAGE containing the superseded account's NT hash. This is the core of the self-referential loop. The dMSA asks the KDC for its own credential package, the KDC checks GroupMSAMembership, finds the dMSA's SID, and approves the request. A secondary effect: GroupMSAMembership also functions as an exclusion mechanism. If the attacker writes an SD that only contains the dMSA's SID and their own SID, Domain Admins are locked out. We verified this: DA tony.soprano received KDC_ERR_POLICY ("Requested start time is later than end time") when attempting S4U2Self --dmsa against a dMSA where he was not listed in GroupMSAMembership. This was tested with a password-derived TGT, confirming it is KDC-level enforcement,