Contents
Executive summary
- Akamai researchers analyzed Microsoft’s patch for the vulnerability known as BadSuccessor (CVE-2025-53779) to assess its effectiveness.
- We concluded that while the patch was effective in mitigating a significant part of the risk associated with BadSuccessor, the technique lives on and remains relevant in certain scenarios.
- In this blog post, we detail two techniques that rely on the same principles of BadSuccessor and can enable attackers to dump credentials and compromise user accounts.
At DEF CON 2025, we presented the story of BadSuccessor — an Active Directory (AD) vulnerability that abuses Windows Server 2025’s new account type: delegated Managed Service Account (dMSA). The vulnerability lets a low-privileged user climb straight to Domain Admin.
Less than a week later, Microsoft assigned the identifier CVE-2025-53779 to the vulnerability and shipped a patch. The direct escalation path is closed.
In this blog post, we will analyze the patch, explain what changed, what didn’t, and show that while BadSuccessor no longer provides instant escalation, its underlying mechanics still matter.
If you missed the origin story, read our previous BadSuccessor blog post.
What BadSuccessor was (pre-patch)
BadSuccessor abused dMSA — a Windows Server 2025 account type meant to simplify service account management. When a controlled dMSA was linked to any account in AD, the Key Distribution Center (KDC) treated the dMSA as the successor during authentication.
That single link did two dangerous things at once: It merged the target account’s effective privileges into the dMSA’s Privilege Attribute Certificate (PAC), and it returned a dMSA key package that included the target’s Kerberos keys (credentials). No group changes, no exotic tooling — just a quiet link and built-in Windows utilities.
Critically, the bar was low: Control over any Organizational Unit (OU) was enough. An attacker could create a dMSA there and link it to any target — even domain controllers, Domain Admins, Protected Users, or accounts marked “sensitive and cannot be delegated”— and immediately compromise them.
For a deeper dive and to watch a demo, see our previous BadSuccessor blog post.
Microsoft’s patch for CVE-2025-53779
Prior to the patch, our assumption was simple: The core bug was that you didn’t have to perform a real migration via the rootDSE migrateADServiceAccount operation — you could just edit the link attributes on a dMSA and the KDC would accept it.
We expected Microsoft to protect that attribute so only the proper migration path could set it, which would prevent “simulated” migrations.
After installing the patch, we tried the obvious test: As a user who controls a dMSA, I wrote the link attribute exactly as before. The write still succeeded — no new protection on the attribute — and I could link a dMSA to any account. But when I authenticated as the dMSA to “inherit” the target’s privileges and keys, the KDC refused to issue a ticket (Figure).
The error when authenticating a dMSA with a one-sided link — failure occurs at ticket issuance
That led us to look at the KDC itself. Changes in kdcsvc.dll force the KDC to validate the relationship at ticket time. A one-way link from dMSA to the target no longer works.
In our test, the only way to obtain a valid ticket for a dMSA that is linked to another account post-patch was to make the link mutual: The target must also reference the dMSA, mirroring what a real migration produces. So, unlike before, “succeeding” now requires controlling the account’s object itself — not just the dMSA.
That means that the patch enforcement was implemented in the KDC’s validation, not into directory-side protections on the attribute. The attribute can still be written, but the KDC won’t honor it unless the pairing looks like a legitimate migration.
Another interesting fact is that migration still works even if the target account remains enabled (whereas the formal migration flow disables it on completion).
What BadSuccessor is (post-patch)
Although the vulnerability can be patched, BadSuccessor still lives on as a technique; that is, the KDC’s verification removes the pre-patch escalation path, but doesn’t mitigate the entire problem.
Because the patch didn’t introduce any protection to the link attribute, an attacker can still inherit another account by linking a controlled dMSA and a target account.
This fact enables (at least) two practical primitives that defenders should expect and monitor:
- Credential and privilege acquisition
- Targeted credentials dump in already-owned domains
Primitive 1 — Credential and privilege acquisition (shadow credentials alternative)
Today, If an attacker controls a target principal (e.g., has GenericWrite on a user or computer), they can compromise it either by adding a shadow credential, or by performing a targeted Kerberoasting attack.
BadSuccessor opens a new attack path — if an attacker controls a dMSA, they can perform a mutual pairing and request a ticket for the dMSA. This allows them to:
- Act with the target’s effective privileges while using the dMSA identity (useful when the target account is closely monitored)
- Obtain the target’s keys from the dMSA key package, which is faster and more reliable than adding an SPN and Kerberoasting (which is user-only, crack-dependent, and noisier)
- Shift telemetry so the attack will only generate logs on dMSA↔target link edits and Ticket Granting Ticket (TGT) issuance to the dMSA
Primitive 2 — Targeted credentials dump in already-owned domains (DCSync alternative)
In an already-compromised domain, BadSuccessor provides a way to dump principals’ keys through normal ticket issuance. This is not a replacement for DCSync, but rather a different path with different signals that may evade existing detections.
How BadSuccessor exploitation can be detected after the patch
BadSuccessor can still be exploited through two different primitives after Microsoft's patch was issued. To detect potential activity, try either:
- System access control lists (SACLs): Audit the creation of dMSAs and changes to the migration link attributes on both sides — the dMSA’s link and the superseded/preceding account’s link
- Behavioral tells:
- Repeated log entries indicating a dMSA password has been fetched in a short window
- An enabled user appearing to be linked to a dMSA (should be unusual)
- A previously disabled user getting linked to a new dMSA
For more detailed detection guidance, read our previous BadSuccessor blog post.
Mitigation
- Patch first. Update your Windows Server 2025 domain controllers for CVE-2025-53779.
- Reduce the attack surface. Review permissions on OUs, containers, and dMSA objects themselves. Tighten delegations and remove broad rights so that only Tier 0 admins can create or modify dMSAs and their migration link attributes.
Conclusion
Microsoft closed the direct escalation path by requiring a mutual pairing that looks like a real migration; a one-sided link no longer results in privileges or keys. But BadSuccessor has always been more than a bug — it’s a technique. This is a growing problem within the industry — a door closes on a vulnerability, but a threat actor can still get in through the keyhole.
BadSuccessor persists post-patch as (1) a credential and privilege acquisition primitive when an attacker controls a target principal and a dMSA, and (2) a replication-free path to dump secrets in already-owned domains.
These outcomes aren’t novel — there are other ways to achieve both. However, they each come with different requirements and telemetry, which is why an attacker might prefer BadSuccessor.
A final note
A brief note on dMSA itself: In my view, post-patch dMSA is a strong addition to AD security. Used as intended, it improves service-account hygiene and reduces long-lived secrets. I’ll share more on dMSA and why I think it is such a great addition in a follow-up blog post. Stay tuned!
Tags
