BetterSuccessor: Still abusing dMSA for Privilege Escalation (BadSuccessor after patch)

Introduction to dMSA

With the introduction of Windows Server 2025, there have been many new changes and features to look at from new structs of LSASS, Credential Guard, PPL updates to even domain-level stuff such as TGT delegation updates, LAPS v2 and most importantly, the topic of this blog, delegated Managed Service Accounts (dMSA). These changes introduce new challenges and also new avenues when Red Teaming Windows Server 2025.

dMSA - Quick Primer:

dMSA accounts are very similar to gMSA accounts, however they expand on their capabilities. If you have no idea what gMSA accounts (or any managed service accounts) are, Microsoft’s article is a good place to start. Unlike traditional service accounts, managed service accounts (gMSA/dMSAs) don't require manual password management since AD automatically handles it. One key feature of dMSAs in particular is the ability to migrate existing non-managed service accounts by seamlessly converting them into dMSAs.

Microsoft’s documentation as follows:

A dMSA is typically created to replace an existing legacy service account. To enable a seamless transition, a dMSA can “inherit” the permissions of the legacy account by performing a migration process. This migration flow tightly couples the dMSA to the superseded account; that is, the original account they’re meant to replace.

Basically, Microsoft introduced group managed service accounts (gMSA) so that risks related to user accounts being used as service accounts, Kerberoasting, credential theft and so on can be resolved. However, the case with gMSA is that you ideally need to create a new gMSA and then run your service under it. dMSA - (introduced in Server 2025) - on the other hand, resolves this problem. In case of dMSA, you get all the benefits of a gMSA, but you also get the benefit of simply promoting a legacy user account (which might have been used to run some service such as DOMAIN/sqlsvc) to a managed service account.

BadSuccessor Bug

Yuval Gordon, on May 21^st 2025 released a Proof-of-Concept bug abuse, relating to dMSA. This bug allowed compromising any user in the AD, simply by having the ability to create a dMSA account. All an attacker needed was an OU with CreateChild permissions, which would allow them to create a dMSA account. Once this account is created, an attacker can use specific attributes, namely msDS-GroupMSAMembership and msDS-ManagedAccountPrecededByLink on the dMSA account, to impersonate any user (yes, including domain admins) in the domain. A full view of the vulnerability can be found in the article by Gordon himself on bad successor technique.

A high-level overview of the attack is as follows:

To exploit the bug, SharpSuccessor can be used. The tool exploits the dMSA vulnerability by using the CreateChild rights of a user to create and weaponize a dMSA account.

Following that, we can use Rubeus to generate a TGT to impersonate the user we have mentioned in the msDS-ManagedAccountPrecededByLink attribute of the dMSA account (such as a domain admin).

Microsoft’s response

The bug was reported to Microsoft on April 1^st 2025. As per the article, this bug was reported to Microsoft. It was rated as a moderate severity vulnerability. To exploit the bug, an attacker needs specific permissions on the dMSA object, OR needs to have CreateChild permission on an OU whose risks are already discussed in KB5008383

The Patch

Following the response by Microsoft was a subsequent “patch” of the vulnerability. On August 12^th, 2025, Microsoft released a fix for the vulnerability for the Domain Controllers. Post-patch this vulnerability had stopped working. Kindly note that it is worth ensuring that all Domain Controllers are updated to 26100.4946+ on Windows Server 2025 to avoid exposure to the BadSuccessor dMSA vulnerability. For Red Teamers, it is worth checking if the domain controller is pre-26100.4946, which could often lead to an easy full-domain compromise.

PS C:\Users\Administrator> $cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'; "$($cv.CurrentBuild).$($cv.UBR)"

How did Microsoft patch this bug?

Even though there is no official available information on exactly how this patch was deployed and what was changed in the operating systems. Post-patch, even if the attacker has a CreateChild permission on an OU and creates a weaponized dMSA account (or already has the control of a dMSA account) and weaponizes it by editing its msDS-GroupMSAMembership and msDS-ManagedAccountPrecededByLink attributes, once a dMSA ticket (TGT) is requested, the KDC will simply deny it.

Is it Over?

Even though we cannot get the impersonation ticket, this does not mean that the bad successor technique to exploit a dMSA is completely dead. Even after the patch, an ideally placed attacker can perform OPSEC-safe and considerably stealthy lateral movement with this technique.

It is obvious that the "oomph" factor of the bug has been patched. However, with a bit of patch diffing and updates from Gordon, we can find out how this bug can still be abused by an ideally placed attacker.

Reincarnation of the bug

In Gordon’s latest article dated Aug 27, 2025), where he discusses the August patch for dMSA, there are 2 major takeaways for the bug and it’s patch.

Takeaway 1:

That led us to look at the KDC itself. Changes in kdcsvc.dll force the KDC to validate the relationship at ticket time. A one-way link from dMSA to the target no longer works.

Takeaway 2:

Credential and privilege acquisition (shadow credentials alternative) Today, If an attacker controls a target principal (e.g., has GenericWrite on a user or computer), they can compromise it either by adding a shadow credential, or by performing a targeted Kerberoasting attack. BadSuccessor opens a new attack path if an attacker controls a dMSA, they can perform a mutual pairing and request a ticket for the dMSA. This allows them to: - Act with the target’s effective privileges while using the dMSA identity (useful when the target account is closely monitored) - Obtain the target’s keys from the dMSA key package, which is faster and more reliable than adding an SPN and Kerberoasting (which is user-only, crack-dependent, and noisier) - Shift telemetry so the attack will only generate logs on dMSA↔target link edits and Ticket Granting Ticket (TGT) issuance to the dMSA

Takeaway 1 let us know what the patch in kdcsvc.dll exactly does.

Instead of blindly trusting the msDS-GroupMSAMembership and msDS-ManagedAccountPrecededByLink attributes of the dMSA object, this time, during the time of the ticket issue, the KDC also checks msDS-SupersededManagedAccountLink and msDS-SupersededServiceAccountState, and only issues the ticket if both attributes check out.

Takeaway 2 on the other hand gives us an insight on Primitive 1 which lets us know exactly how we can exploit this "bug" post-patch, with an ideally placed attacker.

Lab and Abuse

Altered Security Researchers were able to recreate the bug post-patch. This attack will be available in Advanced Red Team Lab (CRTE) for bootcamp users in February 2026 and for on-demand users by end of April 2026.

In this lab, we are inside an Active Directory Environment with patched (post-August 12) Windows Server 2025 domain controllers and clients.

To test out the bug, we have already given a user (namely studentuser1) CreateChild permission on an OU called DMSAHolder:

We will be trying to compromise the user DMSAManager who has DCSync rights over the domain:

Using the privilege of studentuser1, we first start off by creating and weaponizing a dMSA account called attacker_dmsa$ whose msDS-ManagedAccountPrecededByLink attribute will hold the DN (distinguishedname) of the DMSAManager user. Use SharpSuccessor for this with the command:

C:\AD\Tools> SharpSuccessor.exe add /impersonate:DMSAManager /path:"OU=DMSAHolder,DC=us,DC=techcorp,DC=local" /account:studentuser1 /name:attacker_dMSA

Once the weaponized dMSA account is created, we can try and follow the old steps of exploiting this bug by first using tgtdeleg module of Rubeus to get a TGT for studentuser1 (this can also be done using the asktgt module of Rubeus if we have the credentials):

C:\AD\Tools> Rubeus.exe tgtdeleg /nowrap

And then try requesting the impersonation ticket with Rubeus:

C:\AD\Tools> Rubeus.exe asktgs /targetuser:attacker_dmsa$ /service:krbtgt/US.TECHCORP.LOCAL /opsec /dmsa /nowrap /ptt /ticket:doIFTDCCB.....

However, we get the following error:

This is expected. The KDC checks the attributes of the account mentioned in msDS-ManagedAccountPrecededByLink attribute and then sees the DN of DMSAManager account. However, when it then proceeds to check the msDS-SupersededManagedAccountLink attribute of the DMSAManager account, it does not find a reference to the attacker_dmsa$ dMSA account. As this check fails, the KDC refuses to issue the impersonation ticket and the bug fails.

Circumvention:

Before we start the circumvention of this bug, we can first have a look at the dMSA object itself: 

Notice that msDS-GroupMSAMembership and msDS-ManagedAccountPrecededByLink attributes are correctly set as discussed before. This means that, to complete the mutual pairing, we need enough permissions to write to the msDS-SupersededManagedAccountLink and msDS-ManagedAccountPrecededByLink attributes of the account that we want to impersonate as (in this case DMSAManager). For the setup of this lab, we have also given GenericWrite permission to studentuser1 on the DMSAManager account:

This makes our attack path quite convenient. With this permission, we can edit both the attributes of the account that we want to impersonate:

once that is done, we can now request an impersonation ticket for the user DMSAManager using the dMSA account (attacker_dmsa) (also created by studentuser1 because he has CreateChild rights over DMSAHolder OU). Requesting the impersonation ticket (this is the same step where we got KRB_ERR_GENERIC post August patch):

And Voila! The KDC cross-checks the attributes, and the request succeeds. Finally, we can request a ticket for any service. In this case, because we want to perform a DCSync using the DMSAManager account, we will ask for an LDAP service ticket on the US-DC machine with the following command:

C:\AD\Tools> Rubeus.exe /user:attacker_dmsa$ /service:LDAP/US-DC.US.TECHCORP.LOCAL /opsec /dmsa /nowrap /ptt /ticket:doIF2DCCBdS...

With the ticket injected in memory, now is the time to perform DCSync using a tool of choice, we have used DS Internals (you can also use mimikatz/safetykatz/etc.):

All this can be confusing, so for simplicity a high level overview of the exploitation technique is as follows:

Mitigations

Lock down creation:

Limit who can CreateChild on OUs that host service accounts; move dMSA creation into controlled workflows.

Eliminate easy pairings:

Regularly review and remove unnecessary GenericWrite on high-value users/computers.

Monitor the four attributes:

Alert on changes to msDS-GroupMSAMembership, msDS-ManagedAccountPrecededByLink, msDS-SupersededManagedAccountLink, and msDS-SupersededServiceAccountState especially when the editor is not your service account pipeline.

Hunt for unusual tickets:

Flag TGT/TGS activity where a dMSA receives a TGT and quickly requests LDAP/host tickets to DCs (Event IDs 4768/4769) outside normal service behavior.

Tier and isolate: 

Treat dMSAs as Tier-0 assets; apply constrained scopes, minimal rights, and strict lifecycle management.

Additional Resources and References

Useful references for dMSA research: dMSA: Microsoft's official documentation of Delegated Managed Service Accounts.

gMSA: Microsoft's official documentation of Group Managed Service Accounts.

Yuval Gordon: Security Researcher at Akamai, reporter of Bad Successor technique.

Bad Successor dMSA technique: Technique to abuse dMSA for domain compromise, article written by Yuval Gordon (now patched).

dMSA exploitation post-patch: Gordon's latest article on abusing dMSA post-patch

KB5008383: Microsoft's official article discussing dangers of CreateChild permission on an OU.

SharpSuccessor: Tool to automate creation and weaponization of a dMSA account

Rubeus: C# toolset for raw Kerberos interaction and abuses.

Rubeus (DMSA support): Rubeus pull request for dMSA authentication support.

Conclusion

Microsoft’s August 12, 2025 patch closed the “one-way link” path: kdcsvc.dll now validates both sides of the relationship during ticket issuance, so simply pointing a dMSA at a high-value target no longer yields an impersonation TGT. But that doesn’t make dMSA a non-issue.

As our lab shows, an attacker who can both create/weaponize a dMSA and write to the target principal can complete the mutual pairing and quietly operate with the target’s effective privileges shifting telemetry and avoiding some of the noise of classic shadow-creds or roast-based paths. In other words: the splashy part of BadSuccessor is gone, the primitive remains. dMSA has become another privilege amplifier that rewards “good” positioning (CreateChild on an OU + GenericWrite on a target). Treat it with the same rigor you apply to RBCD, shadow credentials, and gMSA hygiene.

---

Thank You for reading this detailed blog post on weaponizing dMSA. If you have any questions or feedback, feel free to reach out!

Posted by:

Shaunak Khosla

Security Researcher at AlteredSecurity