← All posts

BadSuccessor: The dMSA Privilege Escalation Hiding in Windows Server 2025

Delegated Managed Service Accounts introduce a new AD privilege-escalation path (BadSuccessor). Here is how it works, why standard tooling misses it, and how to audit for it.

Every few years Active Directory ships a feature meant to make service accounts safer and, in the process, opens a new road to Domain Admin. Windows Server 2025 introduced Delegated Managed Service Accounts (dMSA) — an evolution of gMSA designed to replace legacy service accounts and neutralize Kerberoasting. It is a genuinely good idea. But the migration machinery behind it created a privilege-escalation primitive that researchers named BadSuccessor, and it works from a starting point most defenders consider harmless: the ability to create objects in a single Organizational Unit.

What a dMSA actually is

A dMSA is a new AD object class (msDS-DelegatedManagedServiceAccount) that binds a service identity to specific machines. Unlike a gMSA, a dMSA can formally supersede an existing account through a supported migration flow. That migration is the crux of the problem. When you mark a dMSA as the successor of another account, Windows treats the dMSA as if it inherits the security context of the account it replaced — including its group memberships — so that services keep working after the swap.

The key attributes are:

The BadSuccessor primitive

Here is the uncomfortable part: the KDC honors that "preceded by" relationship when it issues a Kerberos PAC, but it does not verify that a real, approved migration ever took place. If an attacker can create a dMSA and set those two attributes to point at a privileged victim — say a Domain Admin — the KDC will happily mint a ticket whose PAC carries the victim's SIDs.

Crucially, the attacker does not need any control over the victim account. No write access to the DA, no password, no reset. They only need the right to create a dMSA object in an OU. In default installs, a surprising number of delegated helpdesk and server-team roles have exactly that — Create Child on an OU, or explicit rights over msDS-DelegatedManagedServiceAccount objects.

The escalation isn't "I compromised an admin." It's "I own one unremarkable OU, and AD will manufacture an admin for me."

The attack chain is short:

  1. Find an OU where you can create objects (or specifically create dMSAs).
  2. Create a new dMSA in that OU.
  3. Set msDS-ManagedAccountPrecededByLink to the DN of a privileged account and flip msDS-DelegatedMSAState to 2.
  4. Request a TGT for the dMSA. The PAC now contains the victim's group SIDs — including Domain Admins.

Why standard tooling misses it

This path is invisible to most of the checks security teams already run. BloodHound edges historically modeled ACL abuse against existing principals; BadSuccessor abuses the right to create a new one, so a clean BloodHound graph can still be exploitable. Kerberoasting detections look for weak SPNs and RC4 — irrelevant here, because no cracking happens. And privileged-group monitoring watches membership of Domain Admins, but the victim is never added to any group; the SID injection happens transiently inside a ticket, at authentication time.

In other words, three of the most common AD detections all shrug at this. The signal that matters is the creation of a dMSA object and any write to its migration-link attributes — an event class almost nobody was watching before 2025 because the object type did not exist.

How to audit for it

The good news is that the exposure is entirely enumerable ahead of time. Start by finding who can create dMSAs where. A quick inventory of existing dMSAs and their supersede links:

Get-ADObject -LDAPFilter "(objectClass=msDS-DelegatedManagedServiceAccount)" `
  -Properties msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState |
  Select-Object Name, msDS-DelegatedMSAState, msDS-ManagedAccountPrecededByLink

Then look for the real risk: OUs where non-tier-0 principals hold Create Child for the dMSA object class. Review OU ACLs and flag any CreateChild right granted to helpdesk, server-admin, or automation groups:

Get-ADOrganizationalUnit -Filter * | ForEach-Object {
  (Get-Acl "AD:$($_.DistinguishedName)").Access |
    Where-Object { $_.ActiveDirectoryRights -match 'CreateChild' } |
    Select-Object @{n='OU';e={$_.DistinguishedName}}, IdentityReference, ObjectType
}

For detection, enable directory-service change auditing (Event ID 5137 for object creation, 5136 for attribute modification) and alert on any dMSA creation or any write to msDS-ManagedAccountPrecededByLink outside your approved migration process. On domain controllers, ensure the "Audit Directory Service Changes" advanced policy is on and SACLs cover the relevant object class.

Hardening steps

Where WinSentinel fits

BadSuccessor is a configuration-and-delegation problem, which is exactly what a host-level audit catches before an attacker does. On any domain controller or domain-joined server, WinSentinel's Active Directory and privilege modules enumerate delegated create rights, surface OUs where non-tier-0 principals can spawn service-account objects, and confirm that directory-service change auditing is actually recording object creation and attribute writes — turning "we think our OU delegation is fine" into an evidenced finding. Every module runs at full power on a single machine on the Free tier, with no limits.

For organizations, the Pro tier rolls those findings up across the fleet: the central node aggregates dMSA-exposure and delegation-drift results from every joined server, so a newly over-delegated OU on one domain controller shows up as a fleet-wide alert instead of a finding buried on one box. When the next AD feature quietly ships a new escalation path, that rollup is the difference between catching it in an audit and reading about it in an incident report.