BadSuccessor dMSA Privilege Escalation: How Low-Privilege Users Become Domain Admin

BadSuccessor dMSA privilege escalation — publicly named BadSuccessor by Akamai — is a technique that abuses delegated Managed Service Accounts (dMSA), a feature introduced in Windows Server 2025, to let a low-privileged user impersonate any account in the domain, up to and including Domain Admin. It was documented by Akamai researcher Yuval Gordon in May 2025 and assigned CVE-2025-53779; Microsoft shipped a fix in the August 12, 2025 security update (KB5064010).

This article explains the mechanism, why it affects such a large share of real environments, and how to detect and remediate it — including what the patch actually changed and what public research says is still worth watching afterward.

For adjacent Active Directory escalation paths, see Kerberos Delegation Attacks: From Unconstrained to RBCD Abuse and ACL Abuse and DCSync: The Silent Paths to Domain Admin. BadSuccessor is a distinct mechanism from both — it doesn't touch an existing account's ACL or delegation settings; it abuses object creation rights on an OU to fabricate a new one. It also shares a family resemblance with Shadow Credentials: Abusing msDS-KeyCredentialLink in Active Directory — both escalate privilege by writing to an identity-linking attribute rather than by cracking a credential.

What Is BadSuccessor dMSA Privilege Escalation?

Delegated Managed Service Accounts (dMSA) are a Windows Server 2025 feature designed to let organizations migrate legacy service accounts to a managed, password-less identity model without re-provisioning every dependency. Part of that migration design includes a "succession" mechanism: a dMSA can be linked to an older account it is meant to replace, and Active Directory carries over some of that account's access during the transition.

Why dMSA Exists in the First Place

Microsoft designed dMSA to solve a real operational problem: legacy standalone service accounts often carry static, rarely-rotated passwords and broad standing privileges because migrating them to a managed identity model traditionally meant re-provisioning every dependent application. dMSA's succession model — link the new managed account to the old one it replaces — was meant to make that migration close to transparent. BadSuccessor abuses the trust built into that transparency rather than a bug in password handling itself.

The BadSuccessor Mechanism

According to Akamai's original research (corroborated by Unit 42, Semperis, and Tarlogic), the attack abuses two dMSA attributes that the KDC trusts without cross-checking during the "migration" it represents:

• msDS-ManagedAccountPrecededByLink — a distinguished-name (DN) link to the account the dMSA is meant to be "succeeding." Public research describes the pre-patch KDC as building the account's Privilege Attribute Certificate (PAC) from whatever DN sits in this field, without verifying that a real migration relationship exists.
• msDS-DelegatedMSAState — the migration state (0 = none, 1 = in progress, 2 = completed).

Step by Step: How the Pre-Patch Attack Worked

1. The attacker identifies an OU or container where they hold CreateChild rights — per Akamai's testing, a permission that is both common and rarely audited closely.
2. The attacker creates a new dMSA object in that OU.
3. The attacker writes the target account's DN (for example, a Domain Admin) into msDS-ManagedAccountPrecededByLink.
4. The attacker sets msDS-DelegatedMSAState to 2 ("completed"), marking the fabricated migration as finished.
5. Public write-ups describe the pre-patch KDC then treating every subsequent authentication as the dMSA as if it were a continuation of the target account's identity — building the PAC with the target's SIDs and group memberships, without the target account ever being modified.

Akamai's own testing reported that 91% of the environments it examined had at least one non-admin user with sufficient rights to pull this off, largely because OU-level CreateChild delegation is common and rarely audited closely.

Impact of the August 2025 Patch

Microsoft's August 12, 2025 update (KB5064010, CVE-2025-53779) changed how kdcsvc.dll validates the succession relationship: ticket issuance now requires the linkage to reflect a genuine mutual pairing rather than accepting a one-sided msDS-ManagedAccountPrecededByLink write. Simply pointing a newly created dMSA at a privileged account, as described above, no longer yields an impersonation ticket after the update.

Microsoft's Severity Assessment

MSRC initially assessed the disclosed issue as not meeting the bar for immediate servicing and rated it moderate severity when Akamai first reported it; it shipped as a regular fix in the August 2025 Patch Tuesday cycle rather than as an out-of-band release. Microsoft's current assessment rates exploitation as "less likely," and public reporting at publication time does not describe confirmed in-the-wild exploitation.

What Research Says About the Patch

Akamai's own follow-up research ("BadSuccessor Is Dead, Long Live BadSuccessor(?)") and a subsequent community write-up from AlteredSecurity ("BetterSuccessor") both describe the patch as closing the straightforward one-sided-link path while noting that dMSA-related abuse research has continued in narrower scenarios. This article does not reproduce those follow-on techniques; treat the patch as substantially — not necessarily completely — closing the original BadSuccessor path, and prioritize the detection and delegation-hardening steps below regardless of patch status.

Why It's So Widespread

BadSuccessor is unusual among AD privilege-escalation techniques because it doesn't require a misconfiguration in the traditional sense. It works against the default dMSA permission model once a Windows Server 2025 DC exists in the domain. The actual exposure comes from how broadly CreateChild rights on OUs and containers tend to be delegated in real environments — often to help-desk groups, application teams, or legacy delegation grants that were never revisited. Public research from Semperis and Unit 42 both point to the same root cause: OU and domain-root delegation practices that are broader than intended, not a single missing patch. Environments that follow a tiered administration model with tightly scoped OU delegation are far less exposed than environments where "Create All Child Objects" was granted broadly for convenience during a past migration or help-desk rollout.

This connects directly to a pattern covered in Active Directory Attack Paths: the riskiest exposures are rarely a single critical bug — they're accumulated delegation and permission grants that nobody has re-reviewed since they were set.

Detection

Remediation

1. Patch First

Apply the August 12, 2025 security update (KB5064010 / CVE-2025-53779) to every Windows Server 2025 domain controller.

2. Audit and Restrict CreateChild Delegation

Review OU and domain-root permissions for accounts and groups that can create objects — particularly msDS-DelegatedManagedServiceAccount objects — and remove delegation that isn't actively needed. This is the control that determines whether the attack path exists at all, independent of patch status.

3. Enable SACL-Based Auditing

Configure auditing for dMSA object creation (Event ID 5137) and for modifications to msDS-ManagedAccountPrecededByLink / msDS-DelegatedMSAState (Event ID 5136), and alert on any such change made by a non-privileged account.

4. Inventory Existing dMSAs

Confirm every dMSA in the domain corresponds to a legitimate, expected migration, and review the msDS-ManagedAccountPrecededByLink value on each one.

# Inventory all dMSA objects and their succession link, for manual review
Get-ADServiceAccount -Filter "ObjectClass -eq 'msDS-DelegatedManagedServiceAccount'" -Properties msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState |
  Select-Object Name, msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState

How EtcSec Detects This

EtcSec's AD vulnerability catalogue includes a dedicated check, BADSUCCESSOR_DMSA_ESCALATION, that flags this dMSA escalation risk. Because the root exposure is delegation breadth rather than a single misconfigured object, EtcSec also surfaces DELEGATION_PRIVILEGE findings — broad OU or domain-root delegation grants — as the underlying condition that makes BadSuccessor viable in a given environment, independent of whether a Windows Server 2025 DC is present yet. Teams already tracking privileged-access sprawl with Privileged Access Drift Active Directory: How Admin Rights Creep Back After Audits are looking at the same underlying problem — unreviewed delegation — from a different angle.

Primary References

• Akamai: BadSuccessor — Abusing dMSA to Escalate Privileges in Active Directory
• Akamai: BadSuccessor Is Dead, Long Live BadSuccessor(?)
• Microsoft Security Update Guide: CVE-2025-53779
• NVD: CVE-2025-53779
• Help Net Security: Microsoft fixes "BadSuccessor" Kerberos vulnerability (CVE-2025-53779)
• Unit 42 (Palo Alto Networks): When Good Accounts Go Bad — Exploiting Delegated Managed Service Accounts in Active Directory
• Semperis: BadSuccessor — How to Detect and Mitigate dMSA Privilege Escalation
• Tarlogic: BadSuccessor — Escalating Privilege Using dMSA Abuse in Active Directory
• AlteredSecurity: BetterSuccessor — Still Abusing dMSA for Privilege Escalation (BadSuccessor After Patch)