Active Directory (AD) is a directory service developed by Microsoft for Windows domain networks. It is a central system that stores and manages information about users, computers, and other resources within a network. Among the many challenges AD aims to address is the secure and efficient management of service accounts, special accounts used by applications or services to interact with system resources. A delegated Managed Service Account (dMSAs) is a new type of service account in Active Directory introduced in Windows Server 2025, that is generally created to replace an existing legacy service account.

Recently, Akamai researcher Yuval Gordon has discovered a privilege escalation vulnerability in Windows Server 2025, named “Badsuccessor”, that allows attackers to compromise any user in AD by exploiting a flaw in the dMSA migration process. Since a patch is not currently available, organizations need to take other proactive measures to reduce their exposure to this attack.

In today’s article, we’ll analyze how the vulnerability works, why it is dangerous, and what mitigation measures can be implemented while awaiting an official patch.



Daily Term
Can you guess today’s cybersecurity word in 6 tries?
Play now

Vulnerability Analysis

Delegated Managed Service Accounts offer a way to delegate the creation and management of service accounts to non-administrative users without granting them excessive privileges over the entire directory. When a dMSA is created to replace an existing legacy service account, it can “inherit” the permissions of the legacy account by performing a migration process.

Akamai discovered that during the dMSA Kerberos authentication phase, the Privilege Attribute Certificate (PAC) included in the ticket-granting ticket - issued by the Key Distribution Center (KDC) - contains not only the dMSA’s security identifier (SID) but also the SIDs of the legacy service account it replaces and all its associated groups. This inheritance of permissions between accounts can lead to a privilege escalation scenario. Indeed, an attacker may mimic the dMSA migration process to compromise any user, including domain administrators, gaining equivalent privileges and potentially compromising the entire domain, even in environments where dMSAs are not actively used. As long as the feature exists, which it does in any domain with at least one Windows Server 2025 domain controller (DC), it becomes available.

This technique does not require any permissions over the replaced account but only write permissions over the attributes of any dMSA. An attacker can simulate a migration from any existing user account by creating a dMSA and setting specific attributes, namely msDS-ManagedAccountPrecededByLink and msDS-DelegatedMSAState. Once a dMSA is flagged as being preceded by a specific user, the KDC automatically treats it as if a legitimate migration has occurred, granting the dMSA all the original user’s permissions as if it were the rightful successor.

Full attack flow, showing all steps needed to have a BadSuccessorv (source: Akamai’s report)



Proof of Concept (PoC)

Two separate proof-of-concept (PoC) exploits have been publicly released targeting the BadSuccessor vulnerability in the dMSA feature of Windows Server 2025.
The first PoC is fully implemented in .NET and is available at the following link. If exploited successfully, it allows stealthy privilege escalation and persistence within Active Directory environments, requiring nothing more than a Kerberos ticket.

The second PoC, named SharpSuccessor, is also written in .NET. It demonstrates how a low-privileged user with CreateChild permissions on any Organizational Unit (OU) in the domain can escalate their privileges to that of a domain administrator.



Detection and Mitigation

To detect possible exploitation of this attack, organizations should:

  • Audit dMSA creation (Event ID 5137), paying special attention to accounts that are not typically responsible for service account creation.
  • Monitor attribute modifications (Event ID 5136). In particular, monitor modifications to the msDS-ManagedAccountPrecededByLink attribute.
  • Track dMSA authentication attempts (Event ID 2946).
  • Review permissions to create dMSAs across the domain.

Until Microsoft releases an official patch, defensive measures should prioritize limiting the creation of dMSAs and restricting permissions to create dMSAs exclusively to trusted administrators. Akamai has also provided a PowerShell script that enumerates all non-default identities who can create dMSAs and which Organizational Units (OUs) are affected.



Conclusion

The BadSuccessor vulnerability demonstrates that even security-focused features, like delegated Managed Service Accounts (dMSAs), can introduce unexpected risks if not carefully designed or managed. By exploiting the way Active Directory handles dMSA migrations, attackers can escalate privileges across an entire domain, potentially compromising critical systems and data. While awaiting an official patch, it is crucial to proactively review and tighten permissions around dMSA creation and management to reduce the risk of an attack.