Active Directory Under Fire: The "BadSuccessor" dMSA Exploit in Windows Server 2025

Overview

Microsoft’s push toward modern identity and service account management has brought us features like gMSAs and now dMSAs (Delegated Managed Service Accounts), introduced in Windows Server 2025. Designed to reduce the security risks of traditional service accounts, dMSAs promised to simplify credential management and improve least privilege enforcement.

But a recent discovery by researchers at Akamai has revealed a critical flaw in how dMSAs are implemented. Dubbed "BadSuccessor", this exploit allows attackers to escalate privileges and take over entire Active Directory domains with surprisingly limited permissions.

In this post, we break down the mechanics of the exploit, its real-world impact, and how organizations can defend themselves.

How It Works

At the heart of the exploit lies a flawed assumption in the Key Distribution Center (KDC) logic when handling dMSA migrations.

When migrating from a standard user or service account to a dMSA, Windows Server 2025 uses the msDS-ManagedAccountPrecededBy and msDS-ManagedAccountPrecededByLink attributes to track which identity the new account replaces.

Here’s what happens under the hood:

  1. KDC Trusts the Link: When a dMSA has the msDS-ManagedAccountPrecededByLink attribute set to reference another account (e.g., a domain admin), the KDC automatically grants the dMSA the same access and permissions as the referenced account.
  2. No Real Migration Required: Critically, there’s no validation that a true migration is happening. An attacker can create a dMSA from scratch, link it to a privileged account using the attribute, and trick the system into granting elevated rights.
  3. Standard Permissions Exploited: Attackers don’t need domain admin rights. In most environments, Write access on an Organizational Unit (OU) is sufficient to exploit this vulnerability.

The flaw is not due to code injection, memory corruption, or brute force — it’s simply broken trust logic built into how Windows Server 2025 handles dMSA relationships.

Risks and Impact

  • Full Domain Takeover: Once a dMSA impersonates a high-privilege account, it can obtain a Kerberos ticket with elevated privileges, leading to full domain compromise.
  • Low Detection Rate: The attack doesn’t alter group memberships or modify system binaries. Most traditional SIEM or EDR tools will miss it unless explicitly configured to monitor dMSA changes.
  • Default Vulnerability: Even domains that don’t use dMSAs are at risk. The exploit stems from how the system interprets the link attributes — not from whether dMSAs are actively deployed.
  • Mass Exposure: Akamai’s research found that 91% of domains surveyed had at least one user outside the Domain Admin group with enough privileges to execute this attack.

Real-Life Example: Simulated Attack by Akamai

In a simulated environment, Akamai researchers demonstrated how:

  1. An attacker with control of a standard service account (e.g., svc-print) creates a new dMSA in an OU where they have write access.
  2. The attacker sets msDS-ManagedAccountPrecededByLink to point to Administrator.
  3. The KDC issues tickets to the dMSA as if it were the original Administrator account.
  4. Using these tickets, the attacker then accesses critical systems, modifies GPOs, dumps AD databases, and exfiltrates credentials — without ever touching the original account or alerting SIEM tools.

Prevention & Mitigation Methods

1. Audit and Restrict OU Permissions

  • Use PowerShell or third-party tools to identify users/groups with Create Child or Write Property permissions on OUs.
  • Remove unnecessary delegation where possible, especially for service accounts.

2. Monitor dMSA Creation and Attribute Changes

  • Track and alert on creation/modification of objects with:
    • msDS-ManagedAccountPrecededBy
    • msDS-ManagedAccountPrecededByLink
  • Tools like Microsoft Defender for Identity or custom Splunk/ELK rules can help.

3. Apply Conditional Access and Authentication Hardening

  • Even if a dMSA gains rights, restricting access via conditional policies can limit impact.
  • Avoid allowing high-privilege access from unmanaged devices or unknown locations.

4. Wait for Patch — But Don’t Wait to Act

  • Microsoft has classified the issue as “moderate” severity, stating it does not meet the criteria for out-of-band patching.
  • This means organizations are on their own for now — a dangerous gap for such a high-impact flaw.

Conclusion

The “BadSuccessor” exploit is a stark reminder that even well-intentioned security features like dMSAs can introduce critical vulnerabilities if not carefully vetted. With minimal permissions, attackers can inherit elevated access and operate stealthily within even hardened AD environments.

Organizations using or planning to adopt Windows Server 2025 must review their Active Directory delegation policies immediately, tighten OU-level permissions, and implement strict monitoring for dMSA activity.

Until Microsoft issues an official fix, prevention relies entirely on good hygiene, least-privilege enforcement, and proactive monitoring.

If you’re unsure whether your environment is at risk or need help assessing exposure, consider conducting a rapid AD audit or engaging a trusted security partner.