Consider your organization’s Active Directory as a secure control center. Access is managed through identity cards, each one programmed with permissions that reflect an individual’s role. Senior staff hold cards that unlock highly sensitive systems, such as those responsible for identity management and access to critical data. To ease role transitions, a process is introduced that allows a person to request a new identity card if they claim to be taking over someone else’s position. Crucially, with BadSuccessor, no one checks if the claim is valid. The system simply issues a new card with the same level of access as the original.
This is effectively how Delegated Managed Service Accounts, or dMSAs, function in Windows Server 2025. Intended to simplify service account transitions, the mechanism is vulnerable to misuse. An attacker with basic permissions, such as the ability to create objects within an Organizational Unit (OU), can create a new dMSA. They can then configure it to point to a privileged account using the msDS-ManagedAccountPrecededByLink attribute, and mark the transition as complete by setting msDS-DelegatedMsaState.
Active Directory’s Key Distribution Center accepts this configuration without validation. It treats the new account as a legitimate successor and issues Kerberos tickets with the full rights of the privileged user. The original account remains unchanged, and the attacker operates through a separate identity that holds the same power.
Attack workflow and mitigation strategies
Let’s look at how this attack path would appear in your environment and see if there is anything you need to reconfigure or monitor for. Remember this is related to dMSAs introduced in Microsoft Windows Server 2025, so if you have a single DC on Microsoft Windows Server 2025 (not the functional domain level) you will be vulnerable.
Reconnaissance and OU permission discovery
In the initial phase of the attack, the attacker identifies Organizational Units where they have the necessary permissions, such as CreateChild or WriteDACL. These rights allow the attacker to create or modify directory objects within that OU.
Initial indicators of compromise at this stage will be unusual access patterns involving the ntSecurityDescriptor attribute, as well as the enumeration of OU Access Control Lists (ACLs) by users who do not typically perform these operations. These activities suggest that a user may be evaluating where they have sufficient access to begin privilege escalation.
Mitigation at this stage is minimal, but involves performing regular audits of all OU permissions and ensuring only trusted accounts are granted rights to create or modify objects. Applying the principle of least privilege across all OUs helps to reduce the risk of this kind of reconnaissance leading to exploitation.
Creation of malicious dMSA
Once the attacker has identified a suitable OU, they proceed to create a Delegated Managed Service Account object within it. This object may be msDS-GroupManagedServiceAccount, which is typically reserved for managed services and should not be created arbitrarily.
The creation of these objects by non-administrative users is a strong indicator of compromise. Event ID 5137 will show evidence of this behaviour as it logs the creation of new Active Directory objects.
Mitigation at this stage is much more impactful. You should ensure that the ability to create dMSAs is strictly limited to a designated group of administrative accounts. Monitoring tools should be configured to detect and alert on the creation of service accounts, particularly when the action is performed by unexpected users or from unusual locations.
Linking dMSA to privileged account
The attacker then links the newly created dMSA to a privileged account by setting the msDS-ManagedAccountPrecededByLink attribute to reference that account. They also update msDS-DelegatedMsaState to a value of “2” to indicate that a migration has been completed.
Indicators of compromise at this stage include unauthorized modifications to these attributes by non-administrative users. Event ID 5136 will show evidence of this behavior as it logs attribute modifications in Active Directory.
Mitigation for this stage involves implementing strict Access Control Lists to prevent unauthorized users from modifying sensitive attributes. Security teams should also regularly review attribute changes, especially those affecting accounts with elevated privileges.
Privilege escalation and lateral movement
With the dMSA now linked to a high-privilege identity, the attacker can use it to request Kerberos tickets. This allows them to effectively impersonate the linked privileged account without needing to compromise the original credentials directly.
Key indicators at this stage include Event ID 4769, which records Ticket Granting Service (TGS) requests from service accounts. Unusual authentication patterns or ticket requests by accounts not typically associated with privileged operations should be treated with suspicion.
To defend against this, organizations should deploy robust monitoring solutions that can detect anomalies in Kerberos ticket requests. Additionally, implementing a tiered administrative model helps contain the potential for lateral movement by segregating access across different trust levels.
Breaking the attack chain
As we have shown, there are several effective points of intervention that can be used to prevent a successful BadSuccessor attack. Auditing and restricting OU permissions ensure that only necessary accounts have the ability to create or modify directory objects. Controlling the creation of dMSAs by limiting the rights to a trusted subset of administrative accounts adds another layer of defense.
It is also critical to protect sensitive attributes such as msDS-ManagedAccountPrecededByLink and msDS-DelegatedMsaState through carefully defined ACLs. Finally, security teams should utilise Security Information and Event Management (SIEM) systems to monitor authentication patterns continuously and generate alerts when deviations from normal behaviour are detected.
Key takeaways
A method to prevent Kerberoasting was implemented with Microsoft Server 2025, which inadvertently has given attackers a new Kerberoasting method called BadSuccessor.
The BadSuccessor vulnerability works when a trusted but low-level employee declares they are succeeding a highly privileged user and are granted access as if they truly were that person. They do not steal the original account. They create a new one, and the system accepts it without question.
Until this is addressed by Microsoft, the most effective defense is to restrict who can request such successor access and to closely monitor who has been issued elevated privileges.
Triage your AD
If you have concerns you may be vulnerable to this attack, there is a PowerShell script that will help identify vulnerable accounts. Below is a link to the GitHub repository where the script can be found, but as always with code, review and confirm you understand what is does before running it: https://github.com/akamai/BadSuccessor/tree/main
