A newly discovered vulnerability in Windows Server 2025, dubbed “BadSuccessor”, is raising serious alarms in the cybersecurity community. The flaw targets a recently introduced feature called delegated Managed Service Accounts (dMSAs). It allows attackers to escalate privileges and impersonate virtually any user in Active Directory. This includes highly privileged accounts.
Discovered by researchers at Akamai, this unpatched vulnerability affects environments running the preview version of Windows Server 2025 and poses a significant threat to enterprise networks.
What Are dMSAs, and Why Are They Vulnerable?
Microsoft introduced delegated Managed Service Accounts (dMSAs) in Windows Server 2025 to ease the transition away from legacy service accounts. The goal was to allow newer, more secure accounts to inherit permissions from older service accounts during a phased migration.
However, the implementation of dMSAs contains a major flaw. During the Kerberos authentication process, the Key Distribution Center (KDC) issues a Privilege Attribute Certificate (PAC) that includes not only the dMSA’s own security identifier (SID), but also the SIDs of the legacy account it’s replacing, along with its group memberships.
This setup, meant to facilitate smooth migration, can be abused by attackers to simulate a migration, without ever needing permission to access the original account.
How the BadSuccessor Vulnerability Exploit Works
The exploit relies on a relatively simple chain of actions:
- An attacker needs write permissions on the attributes of a dMSA object—something that, according to Akamai, is surprisingly common in many organizations.
- They modify the msDS-ManagedAccountPrecededByLink attribute of the dMSA to point to a target user (e.g., a domain admin or privileged service account).
- Kerberos authentication, the KDC treats this as a legitimate account migration and grants the dMSA all the permissions of the target account.
- The attacker can then operate under elevated privileges, potentially compromising the entire domain.
Crucially, this attack does not require any access to the targeted account itself, only to the dMSA.
Scope and Impact
This vulnerability doesn’t just affect organizations actively using dMSAs. Akamai’s analysis of real-world Active Directory environments showed that 91% of environments had users outside of the Domain Admins group with sufficient permissions to perform this attack.
That means even if your organization isn’t actively using dMSAs, you could still be vulnerable if the feature is enabled and permissions haven’t been locked down.
For attackers, this represents a low-effort, high-reward escalation path. For defenders, it’s another privilege escalation vector that bypasses traditional security boundaries.
Microsoft’s Response
Microsoft has acknowledged the BadSuccessor vulnerability but has classified it as “moderate severity”. This designation has surprised some in the security community given the impact.
Currently, no patch is available, and Microsoft has stated that the issue does not meet the bar for immediate servicing. A fix is reportedly in development, but no timeline has been publicly confirmed.
How to Protect Your Environment
While waiting for a patch from Microsoft, organizations can take immediate steps to mitigate the risk:
Restrict dMSA Creation and Permissions
Limit who can create or modify dMSA accounts. Avoid granting excessive privileges on Organizational Units (OUs).
Audit OU Permissions
Check for users with “CreateChild” or similar permissions that could allow dMSA creation or modification. Audit dMSAs to ensure they’re not misconfigured or exposed.
Use Detection Tools
Akamai has released a PowerShell script that scans your environment for potential exposure. You can use it to identify who can create or manipulate dMSAs and what OUs they can affect.
Final Thoughts
The BadSuccessor vulnerability is a stark reminder that new features can introduce new risks, especially in complex environments like Active Directory. With no official fix available yet, the best defense is proactive auditing, hardening permissions, and monitoring for abnormal behavior involving service accounts.
Organizations should not wait for a patch. Instead, they should treat this vulnerability as a critical misconfiguration risk and act swiftly to lock down dMSA access and usage.
