BadSuccessor dMSA on Server 2025: Audit OU Rights and Patch

Short answer: BadSuccessor (CVE-2025-53779) abused delegated Managed Service Accounts (dMSAs), new in Windows Server 2025: anyone who could create a dMSA in any OU could link it to a Domain Admin and get that account’s privileges and keys. Microsoft fixed it on August 12, 2025 (KB5063878 for Windows Server 2025, hotpatch KB5064010), and only domains with at least one Server 2025 DC were exposed. Patch every Server 2025 DC, then audit who can create msDS-DelegatedManagedServiceAccount objects and who can write to existing dMSAs, because the technique still works for anyone who controls both a dMSA and the target account.

We ran these commands on 6 October 2026 on a Windows Server 2025 Standard domain controller (build 26100.33438, September 2026 update, Windows PowerShell 5.1) and a Windows 11 Pro member PC in our lab domain contoso.com. Where the lab result differed from the documentation, the page says so.

What BadSuccessor is

Windows Server 2025 introduced the dMSA, a managed service account designed to replace (supersede) a traditional service account. During migration, two attributes link the accounts:

• msDS-ManagedAccountPrecededByLink on the dMSA points to the old service account.
• msDS-SupersededManagedAccountLink on the old account points to the dMSA.

Once migration completes, the dMSA inherits what the old account could access, and the KDC includes the old account’s keys in the dMSA’s key package so services keep working.

Akamai researcher Yuval Gordon found that before the August 2025 fix the KDC trusted a one-way link: set msDS-ManagedAccountPrecededByLink on a dMSA you control to point at any account, mark the migration complete (msDS-DelegatedMSAState = 2), and the next ticket for that dMSA carried the target’s group memberships and keys. The target could be a Domain Admin, and nothing on the target account changed. Creating a dMSA only needed the right to create that object class in some OU, a permission many organisations had delegated widely without realising it.

Microsoft’s advisory for CVE-2025-53779 (Windows Kerberos elevation of privilege, rated Moderate, CVSS 7.2) says an attacker who succeeds could gain domain administrator privileges, and lists the required access as control of msDS-groupMSAMembership and write access to msDS-ManagedAccountPrecededByLink on a dMSA.

Who is exposed

Situation	Risk
No Windows Server 2025 DCs in the domain	Not exploitable for domain compromise; the KDC logic is only on 2025 DCs. Still audit OU rights before you add one.
Server 2025 DC without the August 2025 or later cumulative update	High. Anyone with create-dMSA rights on any OU, or write rights on any dMSA, can take over any account.
Server 2025 DCs fully patched	Reduced. The KDC now requires a mutual link, so the attacker must also control the target account object. That is already a dangerous right, but dMSAs make abusing it quieter (Akamai calls it a replication-free way to pull keys).

MSRC lists Windows Server 2025 and Server 2025 Server Core as the affected products, fixed in build 10.0.26100.4946 (KB5063878) or 10.0.26100.4851 for hotpatched servers (KB5064010). Any later cumulative update includes the fix. Check every DC’s build:

Get-ADDomainController -Filter * |
    Select-Object HostName, OperatingSystem, OperatingSystemVersion |
    Format-Table -AutoSize

# Patch level (run on each DC, or in an RDP session)
(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').UBR

We read the version from Active Directory because remote CIM and PowerShell remoting both failed in our test session (it had no Kerberos credentials to delegate), and this version works from any session. On our lab DC the ACL audit below listed Key Admins, Enterprise Key Admins and Domain Controllers on a brand-new domain; those are built-in, so they are now in the expected list.

Any Server 2025 DC showing a build below 10.0.26100.4946 (or .4851 on hotpatch) needs updating now.

Audit who can create dMSAs

The pre-patch attack started with creating a dMSA, so the first audit is: which non-admin principals have rights on OUs and containers that let them create one? That means CreateChild for the dMSA class (or for all classes), or GenericAll, WriteDacl or WriteOwner, which let someone grant themselves that right.

This read-only script looks up the dMSA class GUID from your schema (so nothing is hard-coded), then checks every OU and container. It needs the ActiveDirectory module, which provides the AD: drive. Run it as a normal domain user with read access; Domain Admin is not required.

Import-Module ActiveDirectory

$schemaNC  = (Get-ADRootDSE).schemaNamingContext
$dmsaClass = Get-ADObject -SearchBase $schemaNC -LDAPFilter '(lDAPDisplayName=msDS-DelegatedManagedServiceAccount)' -Properties schemaIDGUID
if (-not $dmsaClass) { Write-Warning 'dMSA class not in schema: no Server 2025 schema update yet.'; return }
$dmsaGuid  = [guid]$dmsaClass.schemaIDGUID
$anyGuid   = [guid]::Empty

# Principals that are expected to have these rights; extend for your environment
$expected = 'Domain Admins|Enterprise Admins|Administrators|SYSTEM|Account Operators|ENTERPRISE DOMAIN CONTROLLERS|Key Admins|Enterprise Key Admins|Domain Controllers|CREATOR OWNER'

$targets = @(Get-ADOrganizationalUnit -Filter * | Select-Object -ExpandProperty DistinguishedName) +
           @(Get-ADObject -LDAPFilter '(objectClass=container)' -SearchScope OneLevel | Select-Object -ExpandProperty DistinguishedName)

$findings = foreach ($dn in $targets) {
    $acl = Get-Acl -Path ("AD:\" + $dn)
    foreach ($ace in $acl.Access) {
        if ($ace.AccessControlType -ne 'Allow') { continue }
        if ($ace.IdentityReference.Value -match $expected) { continue }
        $r = $ace.ActiveDirectoryRights.ToString()
        $createDmsa = ($r -match 'CreateChild') -and ($ace.ObjectType -eq $dmsaGuid -or $ace.ObjectType -eq $anyGuid)
        $takeover   = $r -match 'GenericAll|WriteDacl|WriteOwner'
        if ($createDmsa -or $takeover) {
            [pscustomobject]@{
                Location  = $dn
                Principal = $ace.IdentityReference.Value
                Rights    = $r
                Inherited = $ace.IsInherited
            }
        }
    }
}
$findings | Sort-Object Principal, Location | Export-Csv .\dmsa-create-rights.csv -NoTypeInformation
$findings | Group-Object Principal | Sort-Object Count -Descending | Format-Table Count, Name -AutoSize

Review every principal in the output. Typical findings are helpdesk groups with full control on user OUs, old migration or provisioning service accounts, and “Authenticated Users” or “Everyone” entries left on legacy OUs. Some will be legitimate delegations (for example, a provisioning account that creates users), but very few people need to create dMSAs.

Audit existing dMSAs and their links

First confirm the exact attribute names in your schema. Akamai’s research uses msDS-SupersededManagedAccountLink for the back-link on the superseded account, while Microsoft’s dMSA overview spells it msDS-SupersededManagedServiceAccountLink; your schema is the authority:

Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
    -LDAPFilter '(|(lDAPDisplayName=msDS-Superseded*)(lDAPDisplayName=msDS-ManagedAccountPrecededByLink)(lDAPDisplayName=msDS-DelegatedMSAState))' `
    -Properties lDAPDisplayName | Select-Object -ExpandProperty lDAPDisplayName

Next, list every dMSA, its migration state and what it supersedes. After the patch, abuse requires a mutual link, so also list accounts that point back to a dMSA (adjust the back-link attribute name if your schema output differs):

# All dMSAs, their state and the account each one supersedes
Get-ADObject -LDAPFilter '(objectClass=msDS-DelegatedManagedServiceAccount)' `
    -Properties whenCreated, msDS-DelegatedMSAState, msDS-ManagedAccountPrecededByLink |
    Select-Object Name, whenCreated, msDS-DelegatedMSAState,
        @{n='Supersedes';e={ $_.'msDS-ManagedAccountPrecededByLink' -join '; ' }} |
    Format-Table -AutoSize

# Accounts that link to a dMSA (the other half of a mutual link)
Get-ADObject -LDAPFilter '(msDS-SupersededManagedAccountLink=*)' `
    -Properties msDS-SupersededManagedAccountLink, msDS-SupersededServiceAccountState |
    Select-Object Name, ObjectClass, msDS-SupersededServiceAccountState,
        @{n='LinkedDmsa';e={ $_.'msDS-SupersededManagedAccountLink' -join '; ' }}

Per Microsoft’s dMSA documentation, msDS-DelegatedMSAState is 1 while migration is in progress, 2 when complete, and 3 for a standalone dMSA. Red flags:

• A dMSA whose Supersedes value is a privileged account (Domain Admins member, krbtgt, a Tier 0 server) that no one planned to migrate.
• A dMSA you did not create, especially in a user or workstation OU.
• A completed link where the superseded account is still enabled. Microsoft’s migration process disables the old account when migration completes.

Check who can write to each dMSA as well: (Get-Acl "AD:\<dMSA DN>").Access, looking for non-admins with GenericAll, GenericWrite, WriteProperty or WriteDacl.

Remove excess rights and monitor

Changing OU permissions can break delegated tasks (helpdesk password resets, provisioning tools). Export the current ACL first (Get-Acl "AD:\<OU DN>" | Export-Clixml), change one delegation at a time, and test the affected team’s normal work afterwards.

• Remove CreateChild for all classes where a group only needs to create users or computers; delegate those specific classes instead. See delegate password reset in AD for a least-privilege pattern.
• Remove GenericAll, WriteDacl and WriteOwner from non-admin principals on OUs; these let a holder grant themselves anything.
• Delete dMSAs that nobody owns, after confirming no service uses them (check Security-Kerberos operational events 307-309 on member servers; that log is disabled by default).
• Add SACL auditing for creation of msDS-DelegatedManagedServiceAccount objects and for writes to msDS-ManagedAccountPrecededByLink and msDS-SupersededManagedAccountLink. With Directory Service Changes auditing on, these show up as events 5137 (object created) and 5136 (object modified) on DCs; see AD audit policy.

Check that it worked

1. Every Server 2025 DC reports build 10.0.26100.4946 or later (or .4851 or later on hotpatch).
2. Rerunning the OU audit shows only principals you have deliberately approved.
3. Every dMSA has a known owner, and every superseded link is part of a planned migration.
4. A test object creation of a dMSA in a monitored OU produces a 5137 event on the DC.

Official documentation: MSRC: CVE-2025-53779 · Delegated Managed Service Accounts overview · Setting up delegated Managed Service Accounts · Akamai: analysing the BadSuccessor patch

Related: Group Managed Service Accounts (gMSA): Complete Windows Server 2025 Guide · Delegate Password Reset in Active Directory: Secure 5-Step Helpdesk Setup · Active Directory Audit Policy: DC Settings and 35 Key Event IDs · Install and promote a Windows Server 2025 domain controller step by step · Raise AD Functional Level Safely: Forest and Domain

See also: Reset krbtgt Password Safely: Two Resets, Replication and RODCs · Kerberos RC4 Removal: Find and Fix RC4 Accounts (2026) · Kerberos RC4 Audit Script: Find RC4 Accounts and Tickets

Frequently asked questions