The BadSuccessor Patch Killed the One-Sided Link. Mutual Pairing Still Leaks the Target’s Kerberos Keys

Akamai disclosed BadSuccessor in May 2025; Microsoft shipped the fix — CVE-2025-53779 — with the August 2025 Patch Tuesday, and it does what it says: a one-sided link from an attacker’s delegated Managed Service Account to your domain admin no longer mints a Kerberos ticket. What the patch did not do is retire the technique. An attacker who can create and configure a dMSA (or otherwise controls an existing one) and holds GenericWrite on a target principal can forge the mutual pairing the patched KDC now demands, authenticate as the dMSA, and receive reusable Kerberos key material for that account in the dMSA key package. That is a targeted, replication-free alternative to DCSync for selected principals — a different telemetry signature — and if your detection is still watching the single attribute the original writeups told you to watch, it misses the post-patch variant.

TL;DR

• The August 2025 patch (CVE-2025-53779) killed BadSuccessor’s one-sided dMSA link, but the technique survives: an attacker who controls a dMSA and can write a target’s migration-link attributes forges the mutual pairing the patched KDC now demands, authenticates as the dMSA, and pulls reusable Kerberos key material for the target from its key package.
• The post-patch variant is a targeted, replication-free alternative to DCSync (per-principal, not domain-wide bulk) that never touches the DRS replication interface, so detection built solely on catching DsGetNCChanges from a non-DC source walks right past it.
• The gating permissions shifted from ‘CreateChild on any OU, any target’ to CreateChild (to stand up the dMSA) plus GenericWrite on the specific high-value principal — narrower, but GenericWrite is the standard payoff of routine ACL-abuse chains BloodHound already flags.
• The original detection guidance is now incomplete: scoping Event 5136 to msDS-ManagedAccountPrecededByLink alone catches the original path but misses the reciprocal writes on the target (msDS-SupersededManagedAccountLink, msDS-SupersededServiceAccountState) — monitor the full set, adding msDS-GroupMSAMembership and treating msDS-DelegatedMSAState as a fifth. Apply the SACLs to the directory objects, enable the audit policy on every DC, and collect the events from every DC — three separate steps, not one.
• Patch and least privilege are separate required controls: the CVE patch closes the original arbitrary-target escalation, and least privilege closes the surviving mutual-pairing path. A domain gains this surface once a Windows Server 2025 DC is promoted into it, so audit CreateChild delegations and strip stray GenericWrite on Tier 0 principals before promoting the first 2025 DC into it.

So the useful question in 2026 is not “did we patch BadSuccessor.” Most shops did. The question is whether your directory-service auditing moved to the target side of the pairing, because that is where the surviving primitive writes.

What the patch actually changed

Quick recap of the original, because the surviving variant only makes sense against it. Delegated Managed Service Accounts are new in Windows Server 2025 — a migration successor to gMSAs, meant to let you retire a legacy service account cleanly and carry its Kerberos identity forward. Akamai’s Yuval Gordon found that pre-patch, the KDC would build a dMSA’s PAC entirely from whatever account was named in msDS-ManagedAccountPrecededByLink, with msDS-DelegatedMSAState set to 2 (migration complete). Set both attributes, authenticate, and the KDC hands you a ticket carrying the superseded account’s SIDs, plus a key package with its keys. No group change, no password reset on the victim, no logon from the impersonated user. The only thing you needed was the right to create a dMSA — Create msDS-DelegatedManagedServiceAccount or plain Create all child objects on any OU. Akamai found that in 91% of the environments they examined, users outside Domain Admins held exactly that on at least one OU.

The fix hardened kdcsvc.dll. Per Akamai’s post-patch analysis, the KDC now validates the relationship at ticket-issuance time: a one-way link no longer produces privileges or keys. The target account has to reciprocally reference the dMSA — the patched KDC checks for a mutual pairing that looks like a genuine migration before it will build the PAC from the linked account. Microsoft did not lock the attributes down at the directory level. They are still writable. The gate is in the KDC’s validation logic, which matters a great deal for what comes next.

The primitive that survived

Altered Security’s BetterSuccessor writeup is the clearest public treatment of the post-patch path. The mutual pairing the KDC now insists on is not a cryptographic proof of anything — it is two attributes on the target object (msDS-SupersededManagedAccountLink and msDS-SupersededServiceAccountState) that reciprocate the dMSA’s link. If you can write those, you satisfy the check.

Which means the permission that gates the surviving attack shifted. Pre-patch you needed CreateChild on an OU and nothing on the victim. Post-patch you need CreateChild on an OU to stand up the dMSA and GenericWrite (or equivalent property-write) on the specific principal you want to impersonate. That is a real narrowing from the pre-patch “any user, any target.” But GenericWrite on a high-value account is not exotic. It is the standard payoff of a hundred ACL-abuse chains: a nested group with write rights, a helpdesk delegation that was scoped too wide in 2019 and never revisited, a shadow-admin relationship that BloodHound has been flagging in your environment for years and nobody closed.

What you get once the pairing is in place: authenticate as the dMSA, and the key package exposes reusable Kerberos key material for the superseded account. Altered Security notes this is “faster and more reliable than adding an SPN” — you read the actual keys instead of Kerberoasting a weak service password. In an already-compromised domain, that turns dMSA key extraction into a targeted, per-principal secrets path that never calls the DRS replication interface DCSync rides on — Akamai is explicit it’s a different-prerequisites alternative for selected accounts, not a substitute for DCSync’s domain-wide bulk replication. If your entire “someone is dumping credentials” detection strategy is built on catching DsGetNCChanges from a non-DC source, this walks around it.

Where the detection has to sit now

You need Audit Directory Service Changes enabled — Advanced Audit Policy, DS Access subcategory — on every domain controller, and you need the SACLs in place, because directory service change auditing produces nothing without an audit ACE on the object. That second half is the part most environments get wrong. The GPO knob gets flipped, everyone assumes coverage, and the object-level SACL that actually generates the events was never applied. Verify it on the object, not in the policy.

The event set, per Palo Alto Unit 42:

• 5137 — dMSA object created
• 5136 — a monitored attribute was modified
• 2946 — dMSA TGT issuance activity (validate the event fields and collection channel on your patched Server 2025 build; commonly the Directory Service log, not Security)
• 4662 — object access, the fallback when 5136 coverage is patchy

The mistake carried over from the original guidance is scoping 5136 to msDS-ManagedAccountPrecededByLink alone. That is the attribute on the dMSA. The post-patch pairing writes msDS-SupersededManagedAccountLink and msDS-SupersededServiceAccountState on the target — an enabled, ordinary user or service account that has no business ever being a migration source. Watch those two attributes on principals, and you catch the mutual-pairing forge that the single-attribute rule sails past.

In Splunk terms, if you have the Windows TA parsing WinEventLog:Security:

EventCode=5136 AttributeLDAPDisplayName IN
  ("msDS-GroupMSAMembership",
   "msDS-ManagedAccountPrecededByLink",
   "msDS-SupersededManagedAccountLink",
   "msDS-SupersededServiceAccountState",
   "msDS-DelegatedMSAState")

The signal-to-noise here is genuinely good, which is rare. In an environment not actively running dMSA migrations, writes to these attributes should be rare — a high-fidelity alert you can route straight to a queue instead of a dashboard. The correlation that tightens it: msDS-SupersededServiceAccountState being written directly to 2 (completed) on a target, or msDS-DelegatedMSAState jumping to 2 without ever passing through 1, and the write coming from a principal that is not in your Tier 0 migration group. A real migration runs Start-ADServiceAccountMigration and walks the state machine (state 1 in progress, 2 at completion); the forge skips steps. Treat that skipped state as enrichment, not proof on its own: an attacker can deliberately write state 1 before 2 to mimic a real migration, and audit, forwarding, replication, or retention gaps can make a legitimate transition look like it skipped 1. Lean on it inside the create–pair–authenticate correlation below, not as a standalone verdict. Chain it forward, too: a freshly-created dMSA (5137) that pairs to a target (5136), then receives a TGT (2946/4768) and immediately requests ldap/ or host/ service tickets (4769) to a DC, is the post-pairing authentication burst Altered Security flags — the pairing write and the ticket requests inside one short window is the high-confidence sequence.

The 4662 trap. If your 5136 coverage has gaps and you fall back to EventCode=4662 with access mask 0x20 (write property), do not deploy that unscoped. Unscoped write-property auditing on directory objects is one of the classic SOC firehoses — broad directory-object SACLs cause routine administrative, application, and directory operations to generate large volumes of 4662 events (how much depends on which rights, object classes, and access patterns you audited). You have to scope it to the dMSA attribute GUIDs (their schemaIDGUIDs) or it is useless. Two of them, per Unit 42, are msDS-ManagedAccountPrecededByLink = a0945b2b-57a2-43bd-b327-4d112a4e8bd1 and msDS-DelegatedMSAState = 2f5c138a-bd38-4016-88b4-0ec87cbb4919 — but those are the original dMSA-side attributes. Do not assume they cover the reciprocal target-side writes this post is about. For post-patch coverage you also need the schemaIDGUIDs for msDS-SupersededManagedAccountLink, msDS-SupersededServiceAccountState, and msDS-GroupMSAMembership, and you should resolve those from your own schema partition rather than trust a hardcoded value:

$schemaNC = (Get-ADRootDSE).schemaNamingContext
@(
    'msDS-GroupMSAMembership',
    'msDS-ManagedAccountPrecededByLink',
    'msDS-SupersededManagedAccountLink',
    'msDS-SupersededServiceAccountState',
    'msDS-DelegatedMSAState'
) | ForEach-Object {
    Get-ADObject -SearchBase $schemaNC -LDAPFilter "(lDAPDisplayName=$_)" `
        -Properties lDAPDisplayName, schemaIDGUID |
        Select-Object lDAPDisplayName, @{ Name = 'SchemaIDGUID'; Expression = { [guid]$_.schemaIDGUID } }
}

Filter 4662’s Properties field on the resolved GUID set and it becomes tractable. Skip that step and the first week buries the analyst who owns the queue.

A few telemetry realities before you trust the rule. The events fire on whichever DC processed the write, so partial audit coverage means an attacker who can pick a DC picks the quiet one — coverage has to be all-DC or it is a colander. Event 2946 lives in the Directory Service channel, which a lot of forwarder configs simply do not collect; check your inputs.conf before assuming you have TGT-issuance visibility. And time skew across DCs will scatter the create-then-pair-then-authenticate sequence across your index if your hosts are drifting, so the correlation window wants to be minutes, not seconds.

Which environments this actually applies to

The gate is a Windows Server 2025 DC. dMSAs are a 2025 feature; the KDC-side behavior that issues these tickets requires a 2025 KDC in the path. A domain with no 2025 DC cannot be hit with this today — the attribute writes may succeed after a schema extension, but no ticket issues without a 2025 KDC in that domain to build the PAC. That is real breathing room, and a lot of shops in mid-2026 are still running domains at the Windows Server 2016 functional level, with DC fleets built mostly of 2019 and 2022 systems and no 2025 DC in sight. (Note the terminology: 2019 and 2022 never introduced their own functional levels — 2016 is the highest until 2025’s.)

The moment one 2025 DC is promoted into a domain, that domain gains the exposure, because a client that can discover and reach that Windows Server 2025 DC can use it for the dMSA authentication path (Microsoft’s own prerequisite is a discoverable 2025 DC). Scope this per domain, not per forest — a 2025 DC in lab.corp.example.com does not, merely by existing, expose principals in corp.example.com; each domain’s DC population is evaluated on its own. So the risk trigger is the promotion of a single 2025 DC into a domain you care about — including the one a project team stood up for testing and forgot to tell anyone about. Before you promote the first one, get the auditing and SACLs in ahead of the DC, not after.

Control mapping and the fix that matters most

Detection is the backstop; the primitive dies on the permission side. The post-patch attack needs two grants — CreateChild on an OU and GenericWrite on the target — and both are ACL problems you can find with BloodHound and close with dsacls today, before you own a single 2025 DC. Patch the DCs — the fix closes the original arbitrary-target escalation and is not optional. But the mutual-pairing variant is a separate least-privilege failure that the CVE patch does not attempt to eliminate, and the attacker who has read the same post-patch writeups you have is looking at your OU delegations, not your build number.

Sources

• BadSuccessor: Abusing dMSA to escalate privileges in Active Directory (Akamai)
• BadSuccessor is dead, long live BadSuccessor(?) — analyzing the patch (Akamai)
• BetterSuccessor: Still abusing dMSA for privilege escalation after the patch (Altered Security)
• When good accounts go bad: Exploiting delegated Managed Service Accounts (Palo Alto Unit 42)
• Microsoft fixes “BadSuccessor” Kerberos vulnerability (CVE-2025-53779) (Help Net Security)
• BadSuccessor (CVE-2025-53779) technique persists despite Microsoft patch (Security Online)
• Frequently asked questions about BadSuccessor (Tenable)

This post was engineered and validated through a multi-agent AI workflow — drafted, adversarially reviewed by several independent models, checked against primary sources, and given a human review before publishing. See an inaccuracy, or found this useful? Leave a comment below — corrections and feedback are read and shape what comes next.