BadSuccessor After the Patch: What Windows Server 2025 dMSA Privilege Escalation Still Gets You

BadSuccessor, the delegated Managed Service Account (dMSA) privilege escalation technique in Windows Server 2025 Active Directory, is often still described as an unpatched, open door to Domain Admin. That is no longer accurate. Microsoft shipped a real fix for the core escalation path in the August 2025 security release as CVE-2025-53779, and it closed the specific attack that made BadSuccessor famous: creating a dMSA and pointing it at any target account, including Domain Admins, with nothing more than ordinary OU create-child permissions. What is still true, and what most summaries skip, is that the underlying technique did not disappear. Security researchers at Akamai, who originally discovered BadSuccessor, published a post-patch analysis showing the same dMSA mechanics still work as a credential extraction and lateral movement primitive once an attacker already holds a foothold. If your domain runs Windows Server 2025 domain controllers with dMSAs in use or even just available, this is worth twenty minutes of your time today.

What dMSAs are and why BadSuccessor worked in the first place

Delegated Managed Service Accounts are a Windows Server 2025 feature meant to make migrating legacy service accounts to managed accounts easier. Part of that migration story involves two linked attributes: msDS-ManagedAccountPrecededByLink, set on the new dMSA to point at the account it is replacing, and msDS-ManagedAccountSucceededByLink, set on the original account to point back at the dMSA. When both links agree, the Key Distribution Center treats the dMSA as the legitimate successor and issues it a Kerberos ticket carrying the predecessor’s effective group memberships and privileges.

Before the patch, the KDC only checked the forward link on the dMSA itself. An attacker with permission to create a dMSA in some ordinary OU, a right that is far more commonly delegated than most administrators realize, could set msDS-ManagedAccountPrecededByLink to point at a Domain Admin account they did not otherwise have any rights over. No write access to the target account was required. The KDC issued a ticket with Domain Admin privileges anyway. That is the escalation Akamai researcher Yuval Gordon disclosed in May 2025, and it is what made BadSuccessor a from-nothing domain takeover in vulnerable environments.

What Microsoft’s patch actually changed

CVE-2025-53779 changed the validation logic inside kdcsvc.dll. The KDC now requires a genuine bidirectional link before it will issue a KERB-DMSA-KEY-PACKAGE: the dMSA’s msDS-ManagedAccountPrecededByLink must point at the target, and the target’s own msDS-ManagedAccountSucceededByLink must point back at the dMSA. Setting the second link requires actual write access to the target account, which is a much higher bar than the OU create-child permission that made the original attack trivial. For the specific from-nothing privilege escalation scenario, the patch does what it was supposed to do.

What still works after the patch

Akamai’s follow-up research, published after analyzing the patched behavior, found that the dMSA mechanism still functions as a useful primitive once an attacker already has GenericWrite or equivalent write access on a target account, which is a common outcome of routine lateral movement rather than a from-nothing scenario. With that access, an attacker can set both link attributes to establish a valid mutual pairing, then request a ticket for the dMSA and extract the target’s Kerberos keys directly from the resulting key package. In practice this turns dMSA pairing into a credential theft and persistence technique for attackers who are already partway into a domain, rather than a technique for getting in from zero. Security vendors and Microsoft have reportedly differed on how seriously to weigh this residual risk, but the mechanics are not disputed: a patched domain controller will still issue a valid dMSA key package to a properly mutually linked pair, and that package still contains usable key material for the linked target.

The practical takeaway is that dMSA creation and linking should be treated as a Tier-0-adjacent operation in any domain running Windows Server 2025 domain controllers, not a routine service account task delegated broadly, patched or not.

Detecting dMSA abuse in your environment

Three event IDs matter here, and none of them are enabled by SACL auditing by default:

• Event ID 5137 (directory service object creation), logged when a new msDS-DelegatedManagedServiceAccount object is created. Configure a SACL on the OUs where dMSAs are permitted so every creation is logged, then alert on creation anywhere else.
• Event ID 5136 (directory service object modification), logged when msDS-ManagedAccountPrecededByLink or msDS-ManagedAccountSucceededByLink is set or changed. A SACL covering these two attributes specifically is the single highest-value detection control described here, since legitimate migration activity involving these attributes should be rare and predictable, while abuse requires touching them.
• Event ID 2946, logged by the domain controller when a TGT containing a KERB-DMSA-KEY-PACKAGE is issued. Check the Caller SID field on this event: a value of S-1-5-7 (Anonymous Logon) appearing where you would expect a real security principal is a documented anomaly associated with dMSA abuse attempts and is worth an immediate alert on its own.

None of this requires third-party tooling to get started, native Windows Event Forwarding plus a SACL on the relevant OUs and attributes is enough for detection coverage, though dedicated AD monitoring tools can simplify ongoing alerting.

Mitigation checklist

• Apply the August 2025 security update (CVE-2025-53779) to every Windows Server 2025 domain controller if you have not already, this is a baseline requirement, not optional hardening.
• Audit who can create child objects in every OU in the domain. The permission to create a dMSA is the permission that made the original attack possible, and it is frequently granted more broadly than administrators expect, sometimes inherited from old delegation decisions nobody remembers making.
• Restrict GenericWrite and equivalent broad write permissions on privileged accounts specifically, since that is now the prerequisite for the post-patch credential extraction path.
• Configure SACLs on dMSA-related object creation and on the two linking attributes, and route the resulting events to a SIEM or log pipeline you actually watch.
• Treat any dMSA found outside an OU explicitly designated for service account migration as suspicious until proven otherwise.

Frequently asked questions

Is BadSuccessor still exploitable if I am fully patched?
The original from-nothing escalation path is closed by CVE-2025-53779. The dMSA linking mechanism can still be used for credential extraction and persistence by an attacker who already has write access to a target account through some other means, which is why detection and OU permission hygiene still matter on patched domain controllers.

Do I need to disable dMSAs entirely to be safe?
No. dMSAs are a legitimate, useful feature for service account migration. The realistic response is restricting who can create them and who holds write access to the accounts they might be linked to, combined with the SACL-based detection covered above, not disabling the feature outright.

How do I check whether my domain controllers have the August 2025 update installed?
Check the installed update history on each domain controller against Microsoft’s security update guide entry for CVE-2025-53779, or query installed KB numbers with Get-HotFix and compare against the specific KB listed for your Windows Server 2025 build in Microsoft’s advisory.