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:

1. Authenticate as the dMSA (get a TGT for the dMSA identity)

2. 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, not a tooling artifact.

Finding 2: Missing access control on msDS-KeyCredentialLink for dMSAs

The dMSA defaultSecurityDescriptor adds explicit deny ACEs for password operations but does not restrict writes to msDS-KeyCredentialLink. Any principal with GenericAll or WriteProperty on the dMSA (obtainable by the creator through the Owner -> WriteDacl -> GenericAll chain) can plant a Shadow Credential.

A Shadow Credential is an X.509 certificate written to msDS-KeyCredentialLink that enables PKINIT authentication. Once planted, the certificate provides an authentication path that is completely independent of the dMSA's managed password. The managed password can rotate on schedule; the certificate still works. Credential Guard, which Microsoft positions as a key security enhancement for dMSA deployments, protects the managed password in memory. It cannot protect against an authentication path that bypasses the managed password entirely and authenticates via a planted certificate through PKINIT.

Figure 1: The dMSA Ouroboros attack chain. Stages 1-4 (orange) require the attacker's credentials. After Stage 4, the loop is self-sustaining (green). The dMSA authenticates and authorizes itself indefinitely without any external principal.

The Ouroboros chain: Seven stages

Before the chain begins, silvio.dante is a standard domain user. His only group memberships are three lab roles in OU=Soprano Crew. None of the privileged AD groups (Domain Admins, Account Operators, Enterprise Admins) are present. Everything that follows is reachable from this starting position.

Figure 2: silvio.dante's group membership. No Domain Admins, no Account Operators, no Enterprise Admins.

silvio.dante has exactly two delegated rights. The first is CreateChild for the dMSA object class on OU=Soprano Crew, which lets him create dMSAs in that OU. The second is WriteProperty on svc-ouroboros for the three migration-link attributes (msDS-SupersededServiceAccountState, msDS-ManagedAccountPrecededByLink, msDS-SupersededManagedAccountLink), which lets him set the migration link to the superseded account. These two delegations are the entire BadSuccessor prerequisite. Nothing else in the chain requires elevated rights.

Figure 3: silvio.dante's delegated rights. Top: CreateChild on OU=Soprano Crew (object class GUID 0feb936f... = msDS-DelegatedManagedServiceAccount). Bottom: WriteProperty on svc-ouroboros for the three migration-link attributes.

Stage 1 - Create dMSA with bidirectional link

From this position, silvio creates dmsa-adriana with svc-ouroboros set as the superseded account. The chain takes over from there.

Figure 4: dMSA creation by silvio.dante, a standard domain user with delegated CreateChild on OU=Soprano Crew. The dMSA lands in the OU silvio has rights on, not the Managed Service Accounts container. Output piped through head -2 to show only the creation and impersonation steps.

Both msDS-ManagedAccountPrecededByLink (forward) and msDS-SupersededManagedAccountLink (back-link) are set. This satisfies the CVE-2025-53779 patch requirement. The attacker automatically becomes Owner of the new object.

Stage 2 - Grant GenericAll via ownership chain

As Owner, the attacker has implicit WriteDacl. Use this to grant GenericAll:

Figure 5: Silvio grants himself GenericAll on dmsa-adriana. As the object's creator and owner, he already has implicit WriteDAC and could modify the DACL at will — this step makes the permission explicit for downstream tooling.

Stage 3 - Plant Shadow Credential

Write an X.509 certificate to msDS-KeyCredentialLink. The dMSA's defaultSecurityDescriptor denies password read/change but does not restrict this attribute:

Figure 6: Silvio plants a Shadow Credential on dmsa-adriana. The public key is written to msDS-KeyCredentialLink, and silvio keeps the corresponding .pfx. From this point on, he can authenticate as the dMSA via PKINIT, independent of any password, group membership, or his own account remaining active.

Output: PFX file saved as dmsa-adriana.pfx.

Stage 4 - GroupMSAMembership self-enrollment (The critical step)

This is the heart of the Ouroboros. Write the dMSA's own SID into its msDS-GroupMSAMembership, authorizing it to retrieve its own KERB-DMSA-KEY-PACKAGE.

The SDDL Gotcha: The SDDL must use expanded specific rights (CCDCLCSWRPWPDTLOCRSDRCWDWO), NOT the Generic All shorthand (GA). The KDC's authorization check does not map generic rights to specific rights. Using GA results in KDC_ERR_POLICY. Using expanded rights succeeds.

We discovered this by writing the same logical permissions in both forms and watching one work and the other fail. A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;; authenticated. A;;GA;;; failed with KDC_ERR_POLICY. The KDC does not expand generic rights to specific rights during the dMSA authorization check.

The fix: use System.DirectoryServices.ActiveDirectorySecurity (not System.Security.AccessControl.RawSecurityDescriptor). The former correctly produces the expanded binary format.

Figure 7: Silvio writes msDS-GroupMSAMembership on dmsa-adriana from Kali via LDAPS. The membership grants the dMSA flow to two principals: Silvio himself and the dMSA. With the dMSA in its own membership list, the chain becomes self-authorizing, and Silvio's account is no longer required for the loop to close.

Figure 8: Verified from the DC: the membership Silvio wrote from Kali landed correctly. Two expanded-form ACEs, the second granting the dMSA authority over its own credential issuance.

After this step, the chain is self-sustaining. No external user account is needed.

Stage 5 - PKINIT authentication

Authenticate as the dMSA using the planted certificate:

Figure 9: PKINIT authentication as dmsa-adriana using the planted certificate. Cert in, hash out. Yes, this is UnPAC-the-hash. I know. I know.

Stage 6 - S4U2Self --dmsa (Self-authorized extraction)

The dMSA requests its own KERB-DMSA-KEY-PACKAGE:

Figure 10: The dMSA asks the KDC for its own keys. The KDC obliges, and the previous-keys line is svc-ouroboros's NT hash. The snake has eaten its own tail.

Stage 7 - NT hash extracted

The KDC checks GroupMSAMembership, finds the dMSA's own SID, approves the request, and returns the KERB-DMSA-KEY-PACKAGE containing the superseded account's RC4 (NT hash).

Figure 11: The hash from the dMSA flow (bdfb66498271947e40b00394086dbc76) matches what DCSync returns for svc-ouroboros. Same hash, two sources, no shared dependency. The credential extraction is real.

A note on terminology: "previous keys" refers to the keys that preceded the dMSA in the migration chain, from the dMSA's perspective. Depending on whether the dMSA's password has rotated since the migration, these resolve to either the superseded user's current keys (no rotation yet) or the dMSA's actual previous keys (rotation occurred). Either way, password rotation on the superseded account does not break the extraction. It updates the extracted hash on the next S4U2Self request.

The snake has eaten its own tail.

Why remediation fails

Password rotation

The dMSA's managed password rotates on schedule. Doesn't matter. The Shadow Credential authenticates via PKINIT, which is entirely independent of the managed password. The certificate persists until explicitly removed from msDS-KeyCredentialLink.

Rotation of the superseded account's password also doesn't break the chain. As noted in Stage 7, the KDC repopulates the KERB-DMSA-KEY-PACKAGE with the superseded account's current credentials on every request. We verified this on dmsa-adriana/svc-ouroboros: the initial extraction returned RC4 bdfb66498271947e40b00394086dbc76. We then reset svc-ouroboros's password.

Figure 12: svc-ouroboros's password was reset on the DC. The new pwdLastSet timestamp confirms the rotation took effect.

The next dMSA extraction returned RC4 0dd62b698ae591f86e6a40d73420820a, matching DCSync of the rotated account.

Figure 13: Verification of rotation survival. The dMSA flow returned a new previous-keys RC4 (0dd62b...), which DCSync confirms is svc-ouroboros's current NT hash. The extraction tracks the live state of the superseded account; rotating the password just refreshes what gets extracted.

Attacker account deletion

We deleted silvio.dante from the directory. Authentication attempts as silvio failed because the account no longer existed. The Ouroboros chain continued to function: Certipy authenticated as dmsa-adriana via PKINIT using the planted certificate, and badS4U2self returned svc-ouroboros's current NT hash. silvio is not referenced anywhere in the runtime chain. The dMSA authenticates with its own certificate and authorizes itself through its own GroupMSAMembership.

Figure 14: silvio.dante has been deleted from Active Directory

Figure 15: bloodyAD binds as silvio fails with SEC_E_LOGON_DENIED. The account is gone.

Figures 16 (top) & 17: silvio is gone. PKINIT auth succeeds (top), and the S4U2Self extraction returns svc-ouroboros's NT hash (bottom). The attacker's account state is irrelevant.

The chain lives!

The only effective remediation

Delete the dMSA object entirely. Partial fixes (clearing msDS-KeyCredentialLink, resetting msDS-GroupMSAMembership) can be undone by anyone retaining WriteDacl on the object. A complete cleanup must remove the dMSA itself. The attacker must also be identified first, which requires scanning for Shadow Credentials on msDS-DelegatedManagedServiceAccount objects, a class not covered by any current defensive tooling.

There is no partial remediation. You delete the dMSA, or the chain stays alive.

Golden dMSA vs dMSA Ouroboros

Operational reality

Difficulty to execute

The tooling is six commands. The PoC is copy-paste simple. But that's deceptive. The hard part isn't running the commands. It's getting to the starting position and knowing what you're looking at.

You need to understand AD delegation models well enough to identify who has CreateChild on any OU or container, know what WriteProperty on a target account means and how to find accounts you have that permission on, and grasp what a dMSA is, what PKINIT is, what S4U2Self does, and what GroupMSAMembership controls. If any step fails, like the SDDL format issue we hit, you're dead in the water without solid AD internals knowledge.

Skill level: intermediate AD tradecraft. Someone comfortable with BloodHound, Certipy, and bloodyAD could pull it off. Without that foundation, the chain falls apart at the first unexpected error.

This is NOT a quick way to get DA

Ouroboros is explicitly not privilege escalation to DA. It's a credential extraction and persistence mechanism. You're not becoming DA—you're stealing the NT hash of whatever account the dMSA is paired with. If that account happens to be a DA, then yes. But you need WriteProperty on that specific account first.

The realistic scenario: you've compromised a service desk account or provisioning system with delegated rights, CreateChild somewhere in the directory, and WriteProperty on service accounts in their scope of responsibility. You extract creds from a high-value service account -- maybe one with constrained delegation to a DC, maybe one in a privileged group. It's lateral movement and persistence, not direct escalation.

Where this really shines

Pentests (time-boxed, demonstrate impact): Probably overkill. You're better off resetting the target password directly and screenshotting the DA session.

Red teams (simulate real adversary, test detection): This is gold. Plant the dMSA, wait two weeks, come back through the certificate. Test whether the SOC detects dMSA creation, Shadow Credential writes, or S4U2Self with the --dmsa flag. Most SIEMs aren't tuned for any of this.

Actual adversaries (APT, ransomware): This is the nightmare scenario. Low noise, self-sustaining, survives incident response. If an attacker plants this during initial access and the IR team doesn't specifically hunt for rogue dMSAs, the attacker maintains persistent access indefinitely.

Proposed BloodHound edges (For the community <3)

The Ouroboros maps naturally to BloodHound's graph model. Here are the edges that should exist in a Server 2025 environment:

Edge 1: CreateDMSA — CreateChild for the dMSA object class on any OU or container. BloodHound already tracks CreateChild but doesn't specifically flag dMSA-class CreateChild as a high-value target.

Edge 2: BadSuccessor — Composite edge from a principal that has BOTH CreateChild on an OU/container AND WriteProperty on a target account's migration-link attributes. This is the "can migrate" relationship.

Edge 3: OuroborosSelfEnroll — Once a principal has Owner or GenericAll on a dMSA, they can write the dMSA's own SID into GroupMSAMembership, allowing the dMSA to authorize itself. This is the self-referential edge: the dMSA points back to itself as a valid GroupMSAMembership member.

Figure 18: Three proposed BloodHound edges for Ouroboros, layered on the native AD primitives they compose. CreateDMSA: a refinement of CreateChild that flags dMSA-class creation as high-value. BadSuccessor: a composite from a principal who holds CreateChild on a container and WriteProperty on a target's migration-link attributes. Neither alone is sufficient. OuroborosSelfEnroll: the self-referential edge available to a principal with Owner or GenericAll on a dMSA, who can write the dMSA's own SID into msDS-GroupMSAMembership.

The query that should light up every SOC: "Find all principals that have CreateChild on any OU or container AND WriteProperty on any user or service account." That's your blast radius -- every account reachable through that combination is a potential Ouroboros target.

Detection queries BloodHound could surface:

• "Find all dMSAs where GroupMSAMembership contains the dMSA's own SID" -- that's a live Ouroboros. Zero legitimate reason for that to exist.

• "Find all dMSAs with msDS-KeyCredentialLink populated" -- possible Shadow Credential persistence.

• "Find all dMSAs where msDS-ManagedAccountPrecededByLink targets a high-value account" -- active targeting of privileged accounts.

Three layers of detection: the capability (who CAN do this), the activity (who HAS done this), and the persistence (which dMSAs are self-enrolled with Shadow Credentials).

Detection guidance

Event log indicators

Why detection is hard

Every individual operation looks normal in isolation. dMSA creation is a standard administrative action. Shadow Credential writes happen during Windows Hello provisioning. GroupMSAMembership changes happen during legitimate dMSA setup. The malicious signal is the combination, and most SIEMs do not correlate across these event types.

High-confidence detection rules

1. Any dMSA where GroupMSAMembership contains the dMSA's own SID. Zero false positive rate. No legitimate configuration requires this.

2. dMSA creation by non-admin principals. Most dMSAs should be created by privileged service management tooling, not helpdesk accounts.

3. msDS-KeyCredentialLink populated on dMSA objects. dMSAs use managed passwords. Certificate-based authentication on a dMSA is suspicious by default.

4. Baseline your dMSA inventory. Know how many exist, who created them, what they supersede. Rogue dMSAs are obvious when you have a baseline.

Recommended fixes

For defenders (now)

1. Audit CreateChild delegations across all OUs and containers, not just the MSA container.

2. Monitor for new dMSA objects created by non-admin principals.

3. Query all existing dMSAs and check whether their own SID appears in msDS-GroupMSAMembership.

4. Check msDS-KeyCredentialLink on all dMSA objects for planted Shadow Credentials.

Microsoft's response

We submitted two reports to MSRC. This section documents the full exchange so readers can evaluate the reasoning on both sides.

Case 1: dMSA Ouroboros (VULN-173664 / MSRC Case 107173)

February 10, 2026 -- Submission. The report described both findings (GroupMSAMembership self-referencing and Shadow Credential bypass) as a combined chain, with full PoC on a patched Server 2025 DC (KB5072725, KB5073379), test environment details, and recommended remediation.

February 11 -- Case opened. MSRC assigned Case 107173 and asked us to submit separate reports for each finding so they could track fixes and bounty independently. We complied (see Case 2 below).

February 17 -- Status check. We asked for an update.

February 17 -- MSRC response. Will from MSRC confirmed the engineering team was discussing the report and expected an answer within a few days.

March 10 -- Case closed. MSRC closed the case:

"We have completed our investigation and determined that this issue does not meet the bar for servicing.

REASON: The repro steps require quite a lot of stars to align:

• Must have access to a domain user's account. <
• Domain user must have CreateChild delegation on an OU.
• Domain user must have WriteProperty on the service account that they are targeting.
• Must have access to a domain-joined machine with RSAT-AD-PowerShell."
  
  

March 10 -- Our appeal. We responded the same day:

"I respectfully request that VULN-173664 be re-evaluated in light of CVE-2025-53779 (BadSuccessor), which was serviced for an attack on the same dMSA migration surface with equivalent prerequisites.

The closure reasoning states that exploitation requires:

• Access to a domain user's account
• CreateChild delegation on an OU
• WriteProperty on the target service account
• Access to a domain-joined machine with RSAT-AD-PowerShell

I want to address this directly: every prerequisite listed above applies equally to vulnerabilities that MSRC has serviced, patched, and assigned CVEs. These are not "stars aligning" -- they are the standard prerequisites for an entire class of Active Directory attacks that Microsoft has consistently treated as serviceable:

• CVE-2025-53779 (BadSuccessor): CreateChild on an OU. Same dMSA attack surface. Akamai confirmed 91% of environments have non-admin users with these permissions.
• CVE-2022-26923 (Certifried): GenericWrite on a computer object's dNSHostName. Patched. CVSS 8.8.
• CVE-2021-42278 / CVE-2021-42287 (noPac): Machine account creation + sAMAccountName write. Patched. CVSS 8.8.
• Shadow Credentials: GenericWrite on msDS-KeyCredentialLink. Serviced.
• RBCD abuse: GenericWrite on msDS-AllowedToActOnBehalfOfOtherIdentity. Serviced.

The prerequisite for every one of these is GenericWrite on an AD object. This is the same prerequisite as our finding. GenericWrite misconfiguration is not a hypothetical edge case -- it is the single most common finding in Active Directory security assessments. Tools like BloodHound, which Microsoft has acknowledged and integrated into its own security guidance, exist specifically because these delegations are pervasive in enterprise environments. Every DACL-based attack path that BloodHound identifies -- Shadow Credentials, RBCD, Targeted Kerberoasting, Constrained Delegation abuse, noPac, Certifried -- requires the same GenericWrite or CreateChild prerequisite that is being cited here as disqualifying.

If this prerequisite disqualifies a finding from servicing, then Shadow Credentials, RBCD, noPac, Certifried, and BadSuccessor should never have been patched either. MSRC cannot service an entire category of DACL-based attacks and then close a new finding on the same attack surface by characterizing those same prerequisites as exceptional.

Additionally, listing "access to RSAT-AD-PowerShell" as a prerequisite is not meaningful. Our PoC uses Python with ldap3 over a network socket. The same operations work from ldapsearch, SharpLDAP, bloodyAD, or raw LDAP from any Linux box on the network. Tool availability has never been a security boundary in Microsoft's threat model, and including it inflates the apparent prerequisite count.

The dMSA Ouroboros exploits the same msDS-ManagedAccountPrecededByLink and msDS-DelegatedMSAState attributes as BadSuccessor, through a different manipulation sequence that achieves equivalent privilege escalation. Closing this finding while CVE-2025-53779 was serviced for the same attack surface, with the same prerequisites, applies an inconsistent standard.

I'm requesting this case be re-opened and evaluated using the same criteria applied to CVE-2025-53779."

March 16 -- MSRC escalation. Will responded:

"I will have a discussion with the engineer that conducted the assessment regarding your concerns and get back to you soon."

March 19 -- MSRC substantive response. MSRC provided a detailed follow-up that engaged directly with the appeal. We are reproducing it in full because it is a thoughtful response that deserves to be read completely:

"Thank you for the detailed follow-up. We acknowledge that our earlier response was rough, and it's reasonable that this led to frustration. We appreciate the care you've taken in articulating your concerns.
Authentication is implied in the described attack. This is not a disqualifier, but it does affect severity assessment. From a risk-model perspective, starting from an anonymous or unauthenticated position would be significantly worse. If this behavior were possible anonymously, it would most certainly receive a severity higher than Moderate.
The attack requires an authenticated domain user and relies on delegated permissions. While CreateChild does introduce some flexibility, this permission ideally should not be broadly granted, and we have documentation supporting that position. Additionally, WriteProperty can be inherited by the owning account in scenarios where a child object is created (for example, via CreateChild).
Tooling is not a meaningful barrier here; attackers are generally expected to bring their own tooling, so the specific tools used do not materially change the assessment.
Overall, there are assumptions about typical environments and their inherent vulnerability that make it difficult for us to assess the impact of this case as Important.
This behavior does not constitute an elevation of privilege. Rather, it represents a persistence mechanism that is not dissimilar to existing techniques such as Shadow Credentials. This is a key distinction between this issue and other vulnerabilities you referenced, including BadSuccessor, noPac, and Certifried, which demonstrated direct elevation-of-privilege outcomes.
To address the comparison directly: while this issue and BadSuccessor share a similar attack surface, the impact of the two are very different.
We also recognize the ambiguity around authentication mechanisms provided to dMSA accounts and appreciate this being raised. As it stands, this does not meet the bar for immediate servicing."

Several things are worth noting about this response. MSRC acknowledged that their initial closure was rough. They conceded the tooling point ("attackers are generally expected to bring their own tooling"). They demonstrated understanding of the ownership chain ("WriteProperty can be inherited by the owning account in scenarios where a child object is created"). And they left the door open for reassessment.

The core disagreement is classification. MSRC views Ouroboros as a persistence mechanism comparable to existing Shadow Credential abuse. Our view is that existing Shadow Credential abuse does not produce self-sustaining loops that survive attacker account deletion, lock out Domain Admins from remediation, and automatically track password rotations on the target account. The "persistence" label is technically accurate but understates the practical impact.

Case 2: Shadow Credentials bypass (VULN-173807 / MSRC Case 107235)

February 11, 2026 -- Submission. Filed per MSRC's request to split the original report. This report described the Shadow Credential bypass as an independent finding: the dMSA defaultSecurityDescriptor includes explicit deny rules for password read and password change but does not restrict writes to msDS-KeyCredentialLink. Any principal with WriteProperty or GenericAll can plant a certificate that provides permanent PKINIT authentication, defeating the core security property of managed accounts and rendering Credential Guard irrelevant.

The report also documented the inherited SELF-write surface from the computer class: beyond msDS-KeyCredentialLink, a dMSA authenticating as itself can write to msDS-AllowedToActOnBehalfOfOtherIdentity (RBCD), servicePrincipalName, dNSHostName, ms-TPM-Tpm-Information-For-Computer, the Personal Information property set (71 attributes), Web Information property set, and Private Information property set (msPKI credential roaming attributes). This inherited surface is broader than what the dMSA defaultSecurityDescriptor was designed to expose.

February 12 -- Case opened. MSRC assigned Case 107235.

February 23 -- Case closed. MSRC closed the case:

"You reported a security feature bypass affecting dMSA objects in active directory. This was confirmed to be related to MSRC 107173."

This is a reasonable administrative decision given that we originally submitted them together. However, the Shadow Credential bypass is independently exploitable: any principal that can write to a dMSA's msDS-KeyCredentialLink gains permanent authentication as that dMSA, regardless of GroupMSAMembership configuration. It did not receive independent evaluation.

Our position

We respect MSRC's process and appreciate the substantive engagement in the March 19 response. We understand the distinction they are drawing between persistence and elevation of privilege.

We disagree with the outcome for one reason: the practical impact to defenders is the same regardless of classification. A standard domain user starting from commonly delegated permissions (91% of environments per Akamai's research) can produce a self-sustaining credential extraction mechanism that survives password rotation, survives attacker account deletion, locks out Domain Admins from remediation, renders Credential Guard ineffective, and automatically returns the target's current NT hash on every extraction. No current defensive tooling detects it.

We are publishing this research so that defenders can detect and respond to this technique now.

Disclosure timeline

Acknowledgments

• Yuval Gordon (Akamai), whose BadSuccessor research is the foundation this work builds on. He read the post end to end, left detailed review comments, and was a sounding board for this and other dMSA research throughout. The MSRC report is meaningfully better for it.

• CravateRouge for bloodyAD

• Oliver Lyak (ly4k) for Certipy

• kerbad project for badS4U2self

• Fortra for impacket

• Team Huntress: Thanks to Adam Bienvenu, Aaron Deal, Lizzie Danielson, and Lindsey O’Donnell-Welch for their help in reviewing this post.