BadSuccessor: Default Privilege Risk in Server 2025

The Default Privilege Escalation in Windows Server 2025 You Should Be Scared Of

Imagine giving someone the keys to your house just because they said they were the new owner. That’s essentially what Windows Server 2025 is doing — and it’s called BadSuccessor.

Summary

BadSuccessor is a newly discovered privilege escalation vulnerability in Windows Server 2025 that allows attackers to fully impersonate any Active Directory user — including Domain Admins — without modifying the original account. It exploits a misdesign in the dMSA (delegated Managed Service Account) feature and works in default configurations.

Impact: Total domain compromise
Complexity: Low
Affected: Likely most orgs (91% in tested environments)
Patch: Not yet available

Where It All Began: dMSA and the Idea of Migration

Windows Server 2025 introduced delegated Managed Service Accounts to ease migration pains. When a dMSA replaces a legacy service account, it should inherit everything — permissions, SPNs, delegations, group memberships — to act like a seamless successor.

This inheritance relies on one key attribute:
msDS-ManagedAccountPrecededByLink

When this attribute is set, the KDC (Key Distribution Center) blindly assumes the dMSA is the rightful successor and issues Privilege Attribute Certificates (PACs) containing all the original account’s rights — no verification needed.

Where It All Began: dMSA and the Idea of Migration

Attackers don’t need to perform a real migration. They can simulate one by setting two attributes:

1. msDS-ManagedAccountPrecededByLink → DN of target user (e.g. Administrator)
2. msDS-DelegatedMSAState → 2 (signals migration is complete)

From that point forward, when the dMSA authenticates, it receives a PAC with the target’s SID and group memberships, effectively impersonating them on the network.

Real-World Abuse: From Unprivileged to Domain Admin

There are two main paths an attacker might take:

1. Hijack an existing dMSA
– Modify msDS-ManagedAccountPrecededByLink to point to a privileged user
– Set msDS-DelegatedMSAState to 2
– Authenticate as the dMSA and assume all target privileges

2. Create a new dMSA
– If a user has create permissions on any OU, they can:
• Use PowerShell to create a dMSA in that OU
• Gain full control over it
• Configure the two attributes
• Request a TGT for the dMSA using tools like Rubeus

Boom: The attacker becomes a Domain Admin, with no touch to the original account.

What Makes BadSuccessor So Dangerous?

• No access required to the target user account
• No LDAP writes to the target user
• No group membership changes
• No logs indicating a privilege escalation

The exploit lives entirely in the dMSA object. As long as the KDC sees the msDS-ManagedAccountPrecededByLink, it delivers a PAC with all inherited rights.

Bonus: Credential Leakage

There’s more.

When a TGT is issued to a dMSA, it contains a structure called KERB-DMSA-KEY-PACKAGE, which includes:
– current-keys
– previous-keys

Surprisingly, the previous-keys can sometimes contain the RC4 key of the impersonated account — which means that the attacker might also recover the NTLM hash of the target account.

They get your permissions AND your password hash.

What You Can Do

Until Microsoft ships a patch, you are responsible for mitigating this risk. Here are immediate steps you should take:

Audit:
– Search your domain for any dMSAs (objectClass=msDS-GroupManagedServiceAccount)
– Check which users/groups have write access to dMSAs
– Monitor changes to msDS-ManagedAccountPrecededByLink and msDS-DelegatedMSAState

Restrict:
– Limit creation of dMSAs to trusted admin OUs only
– Avoid delegating Create all child objects or Create msDS-DelegatedManagedServiceAccount to untrusted users
– Deny WriteProperty on msDS-ManagedAccountPrecededByLink where possible

Detect:
– Look for anomalous PACs with mismatched SIDs during logon
– Monitor TGT requests for dMSAs and unexpected group memberships
– Use tools like Wireshark or Rubeus to inspect PACs when necessary

What You Can Do

BadSuccessor is a perfect example of how convenience can backfire when security isn’t baked into the design. The assumption that a migration must be legitimate — without validation — opened the door for one of the most stealthy and devastating privilege escalation attacks in recent memory.

If you manage an AD environment — especially one testing or planning for Windows Server 2025 — this should be at the top of your priority list.