Privilege Escalation by Abusing dMSA: The BadSuccessor Vulnerability [EN]

Executive Summary

On 23.05.2025, a new attack method exploiting the design flaw of the Delegated Managed Service Account (dMSA) feature that comes with Windows Server 2025 was detected and the exploit code was published, by Yuval Gordon from Akamai. This method is called “BadSuccessor” and is classified as a new attack technique in addition to the already-known methods. With this technique, an unprivileged user in the Active Directory environment can log in and take over any administrator account name by abusing the dMSA accounts published by Microsoft. This exploitation technique causes the entire Active Directory environment to be compromised.

Microsoft has not yet released a patch or documentation on vulnerability. Vulnerability detection and mitigation operations can be carried out through the details in the document.

Introduction

Through the technique known as BadSuccessor, disclosed by Akamai security researchers, an attacker can compromise the entire infrastructure in environments utilizing Windows Server 2025 Domain Controllers by leveraging two distinct attack scenarios.

The first scenario allows any unprivileged user or computer account within an Active Directory environment to create a vulnerable dMSA account, provided that it possesses the “Create msDS-DelegatedManagedServiceAccount” or “Create all child objects” permission on any “Container” or “Organizational Unit” object, or holds broadly defined rights encompassing these permissions such as “GenericAll,” “WriteDACL,” “WriteOwner,” or “Owner.”

In the second scenario, an attacker can create a vulnerable dMSA account that already exists in the Active Directory environment, as long as they have permission to write to the “msDS-ManagedAccountPrecededByLink” and “msDS-DelegatedMSAState” attributes of existing dMSA objects. This can also be done if they have broader privileges that include those permissions, such as “GenericWrite,” “GenericAll,” “WriteDACL,” “WriteOwner,” or “Owner.”

The attacker manipulates the “msDS-ManagedAccountPrecededByLink” and “msDS-DelegatedMSAState” attributes, which are the root cause of the vulnerability, to impersonate the identity of a user of his choice, causing the entire Active Directory environment to be compromised.

Vulnerability Detection

The first requirement for exploiting the BadSuccessor vulnerability is the presence of at least one Windows Server 2025 Domain Controller within the Active Directory environment.

The second condition for exploiting the vulnerability is that at least one of the following requirements must be met:

If an unprivileged user has “CreateAny” (permission to create any object), “CreateDMSA” (permission to create DMSA object) or “GenericAll”, “WriteDACL”, “WriteOwner” or “Owner” permissions that allow direct or indirect modification of the object on “Container” and “Organizational Unit” objects.
If an unprivileged user has write access to the “msDS-ManagedAccountPrecededByLink” and “msDS-DelegatedMSAState” attributes of a previously created dMSA object—or holds broader privileges that include such access, such as “GenericWrite,” “GenericAll,” “WriteDACL,” “WriteOwner,” or “Owner”.

In order to identify exploitable assets, the PowerShell script released by the Akamai security team, which can be found at https://github.com/akamai/BadSuccessor/, can be utilized.

The Powershell script checks the “CreateChild”, “GenericAll”, “WriteDACL” and “WriteOwner” permissions on “Organizational Unit” objects and excludes some built-in identities in the Active Directory environment.

The vulnerability controls within the PowerShell script do not cover all permissions that could enable attack vectors, nor do they analyze critical permissions on “Container” objects. Therefore, performing a more comprehensive evaluation will provide greater visibility and allow for the identification of all potential attack paths.

The “Search & Reports” module on the FSProtect interface can be used to detect the relevant vulnerability.

For Windows Server 2025 Domain Controller detection, the query prepared in the video in the related link can be used.
To detect dangerous access permissions that enable attack paths, the query demonstrated in the video at the related link can be used.

Exploitation

As part of the BadSuccessor technique implementation, a computer account must be created. This computer account will later be used to read the password of the dMSA account to be created. The computer account used during exploitation can be created using the PowerMad tool.

Copy to Clipboard

To achieve privilege escalation within the domain, it is necessary either to create a dMSA account or to have write permissions on the msDS-ManagedAccountPrecededByLink and msDS-DelegatedMSAState attributes of an existing dMSA account.

Copy to Clipboard

If the attacker creates the dMSA account, they won’t have permission to change its related attributes at first. So, they need to give themselves write access before they can make any changes.

Copy to Clipboard

After granting write permissions on the necessary attributes, the attacker adds the chosen victim account to the msDS-ManagedAccountPrecededByLink attribute of the dMSA object and updates the msDS-DelegatedMSAState attribute to 2.

Copy to Clipboard

During the creation of the dMSA account, the attacker obtains the TGT ticket associated with the machine account they are using via the PrincipalsAllowedToRetrieveManagedPassword configuration, making this machine account the preferred choice since it has the necessary permissions to read the dMSA object’s password.

Copy to Clipboard

With the obtained TGT ticket, a TGS ticket is requested on behalf of the DMSA account and then the exploitation is completed by using this TGS ticket.

Copy to Clipboard

Mitigation Steps

In order for the relevant vulnerability to be exploited, one of the following conditions must be met:
- If an unprivileged user has CreateAny (permission to create any object), CreateDMSA (permission to create a DMSA object) or GenericAll, WriteDACL permissions which allow direct or indirect modification of the object on Container and Organizational Unit objects
- Permissions of an unprivileged user to write to msDS-ManagedAccountPrecededByLink and msDS-DelegatedMSAState values on a previously created dMSA object or the existence of broader permissions such as GenericWrite, GenericAll, WriteDACL that allow direct or indirect modification of the dMSA object
In order to eliminate the vulnerability, it is necessary to remove the permissions mentioned above, which are defined for unprivileged users on both Container and Organizational Unit objects and dMSA objects that have already been created. The following steps can be applied sequentially to carry out this process.
- Log in to the Domain Controller server and open the Active Directory Users and Computers application.
- Identify the Container, Organizational Unit, or dMSA account that has permissions, then right-click the relevant object and select the Properties button.