Active Directory dMSA Privilege Escalation: “BadSuccessor” Exploit Puts Windows Server 2025 at Risk

Executive Summary

A critical privilege escalation vulnerability in Windows Server 2025 threatens the very core of enterprise identity management: Active Directory (AD). Discovered by Akamai researcher Yuval Gordon, the flaw exploits the newly introduced delegated Managed Service Account (dMSA) feature, allowing attackers to impersonate any AD user - including Domain Admins - using only default permissions. In 91% of analyzed environments, non-privileged users have sufficient rights to carry out the attack. Though Microsoft has acknowledged the issue, no patch is currently available, making proactive defense essential.

Introduction

With the release of Windows Server 2025, Microsoft introduced delegated Managed Service Accounts (dMSAs) - an evolution of gMSAs designed to simplify account transitions and service identity management. However, this convenience comes at a cost.
While investigating the inner workings of dMSA migrations, researchers uncovered a severe privilege escalation flaw. An attacker with low privileges can manipulate dMSAs to impersonate any user in the domain - no actual migration required, no access to the targeted account needed. Worse, this works by default, without dMSAs even being actively used, as long as a Windows Server 2025 domain controller is present.

Understanding Delegated Managed Service Accounts (dMSAs)

dMSAs are designed to replace legacy service accounts in a streamlined manner. During migration, a dMSA inherits permissions and configurations from the account it supersedes. This is managed through specific attributes and a clearly defined workflow involving tools like Start-ADServiceAccountMigration.

The migration flow includes:

• Linking the dMSA to the legacy account via msDS-ManagedAccountPrecededByLink.
• Granting write access to the dMSA’s msDS-GroupMSAMembership attribute.
• Updating status flags like msDS-DelegatedMSAState.

Once migration is complete, the superseded account is disabled, and all systems transparently switch to using the dMSA.

dMSA Authentication Deep Dive

During the migration phase, the Kerberos Key Distribution Center (KDC) issues a special AS-REP response indicating that the original account has been superseded. This triggers a client-side retry using the dMSA. The dMSA then receives a Privilege Attribute Certificate (PAC) containing the SIDs of both itself and the original account - effectively inheriting full permissions.

The "BadSuccessor" Attack Explained

The vulnerability lies in the KDC’s trust of a single attribute: msDS-ManagedAccountPrecededByLink.

By simply setting:

• msDS-ManagedAccountPrecededByLink to the DN of any target account
• msDS-DelegatedMSAState to 2 (completed migration)

An attacker can convince the KDC that the dMSA is a legitimate successor - even without using the official migration process. This results in the dMSA receiving a PAC that grants the same privileges as the target account.

Key Points:

• No permissions are needed on the target account.
• The attack only requires write access to the dMSA (which attackers can create themselves).
• Domain Admins, Protected Users, and Domain Controllers are all vulnerable targets.

Creating and Abusing a Malicious dMSA

Most organizations do not actively monitor or restrict the creation of dMSAs, especially outside the default "Managed Service Accounts" container. If a user has CreateChild rights on an Organizational Unit (OU), they can create a new dMSA and gain full control over it.

Attack flow:

1. Identify an OU with write permissions.
2. Create a dMSA using New-ADServiceAccount.
3. Set msDS-ManagedAccountPrecededByLink to the DN of the desired victim (e.g., a Domain Admin).
4. Set msDS-DelegatedMSAState to 2.

The dMSA is now treated by the domain as the privileged successor, and can request a Ticket Granting Ticket (TGT) using tools like Rubeus. This TGT includes group memberships and privileges of the original account - no detection, no group changes, no alerts.

Beyond Escalation: Credential Theft

Even more troubling, dMSAs can inherit cryptographic keys from the account they claim to succeed. The KERB-DMSA-KEY-PACKAGE returned by the KDC can include RC4-HMAC keys from the original account - potentially exposing user credentials.

Why?
To ensure continuity post-migration. The KDC includes these legacy keys so services using old tickets can still function. Attackers can exploit this behavior to extract passwords of highly privileged users.

Microsoft’s Position

Reported on April 1, 2025, Microsoft acknowledged the issue but rated it Moderate severity, citing the need for specific dMSA write permissions. They referenced KB5008383, which touches on risks of CreateChild permissions.
Akamai strongly disagrees, asserting the flaw enables full domain compromise from permissions often viewed as low risk. Current tooling does not adequately flag dMSA creation as a threat, increasing the vulnerability's stealth.

Detection and Mitigation

Detection:

• Log dMSA Creation (Event ID 5137): Audit for unexpected creation of msDS-DelegatedManagedServiceAccount objects.
• Monitor Attribute Changes (Event ID 5136): Focus on msDS-ManagedAccountPrecededByLink modifications.
• Track dMSA TGTs (Event ID 2946): Look for KERB-DMSA-KEY-PACKAGE data in the Directory Service log.
• Review OU Permissions: Look for overly permissive CreateChild delegations.

Mitigation:

• Restrict dMSA Creation: Limit CreateChild permissions to trusted administrators.
• Audit Privileges: Use PowerShell scripts to enumerate principals with dMSA-related permissions.
• Stay Informed: Monitor Microsoft advisories and patch releases.

Conclusion

The "BadSuccessor" vulnerability is a potent reminder that minor permissions can yield major security risks. The introduction of dMSAs brings operational advantages but opens a dangerous attack surface when improperly controlled.

Until Microsoft issues a patch, defenders must:

• Treat dMSA creation like domain replication or DC promotion.
• Continuously audit and restrict who can create and modify dMSAs.
• Elevate the visibility of seemingly innocuous permissions in AD reviews.

This vulnerability challenges long-standing assumptions about privilege boundaries in Active Directory. Awareness, visibility, and control are now the most powerful tools in your defensive arsenal.

Ref: Akamai Security Blog
Author: Yuval Gordon, Akamai Analyst