How to Block BadSuccessor: The Good, Bad, and Ugly of dMSA Migration

Key findings

• BadSuccessor, a privilege escalation technique that exploits delegated Managed Service Accounts (dMSAs), presents high risk to organizations using even one Windows Server 2025 domain controller (DC). The technique can be used to impersonate any account in Active Directory (AD)— even Domain Admins, the KRBTGT account, or any other high-privileged enabled or disabled account.
• Semperis Senior Incident Response Lead Jorge de Almeida Pinto discovered a way to completely block the dMSA migration use case, which effectively prevents attackers from misusing a dMSA to potentially take over an AD domain.
• The solution is configured in the AD schema and should be applied to every AD forest.
• This risk mitigation can be implemented until Microsoft has released a patch to mitigate the vulnerability.

Until Windows Server 2025, AD and Windows supported standalone Managed Service Accounts (sMSAs) and group Managed Service Accounts (gMSAs). Windows Server 2025 introduces a new type of managed service account: delegated Managed Service Accounts.

This new account type is designed to enhance credential management of user-based service accounts by supporting migration from the legacy service account to a dMSA.

Researchers at Akamai¹ discovered that attackers can easily create and configure a dMSA, then abuse it to impersonate any authenticatable security principal in AD. They named the attack technique BadSuccessor.

In this blog post, we provide a detailed introduction and information for mitigating the vulnerability, including PowerShell code to implement the suggested solution to block the migration use case.

Why do you need to block BadSuccessor?

When used as intended, dMSA migration officially supports only legacy service accounts as the source (account type user). However, the BadSuccessor attack works with any authenticatable account type as the source, including, computer accounts, sMSAs, gMSAs, and even dMSAs. In addition, it doesn’t matter whether the source account is enabled or disabled.

The only components needed to execute this attack are:

• At least one writable 2025 DC
• One (vulnerable) dMSA and the correct tooling

In addition, the attack does not need to take place on Windows Server 2025.

The core of the BadSuccessor attack starts with the ability to either create a new dMSA or control an existing dMSA. Thus, delegation of control of any existing AD domain requires immediate review and action.²

Given the potential for complete AD domain compromise, you should take steps to mitigate this risk as soon as you’ve introduced your first Windows Server 2025 writable DC—even if you’re not yet using dMSAs.

How to detect BadSuccessor: Indicators of exposure and compromise

Microsoft has not yet provided a patch to mitigate this vulnerability. Semperis has added detection capabilities in Directory Services Protector (DSP) to defend against BadSuccessor. The DSP platform has been enhanced with one new indicator of exposure (IOE) and three new indicators of compromise (IOCs) focused on enabling the detection and mitigation of malicious activity involving dMSAs.

What are dMSA use cases?

Microsoft designed the dMSA for one specific, hard-to-solve use case that many organizations have today. In practice a dMSA supports two use cases.

Because of the multiple use cases, any dMSA has a state that determines how the dMSA is used and that is recorded in the attribute msDS-DelegatedMSAState.

The supported states are:

• 0: Unused (this state is the default when undefined)
• 1: Migration use—started
• 2: Migration use—completed
• 3: Native use

A dMSA can be used like you use a gMSA. In that case, the state of the dMSA will be 3, meaning it is used natively.

The dMSA was designed to support the migration of a legacy service account to a dMSA for better and enhanced credential management without impacting the functionality of a service, application, or scheduled task that uses the legacy service account. Better and enhanced credential management technically means more frequent and automated password rotation using a stronger and very complex password.

The migration from the legacy service account to the dMSA is initiated by an admin. The state of both the legacy service account and the dMSA changes to 1—migration started. Once the admin completes the migration and the state of both the legacy service account and the dMSA changes to 2—migration completed—the specific configuration of the legacy service account itself is migrated to the dMSA. However, group memberships of the legacy service account are not migrated to the dMSA and remain with the legacy service account.

During the first migration state, the system automatically discovers where the legacy service account is being used and configures the dMSA accordingly. In the second migration state, when the system tries to authenticate using the (disabled) legacy service account, the dMSA takes over the authentication.

When the dMSA takes over authentication, the Windows Server 2025 domain controller merges the Privileged Attribute Certificate (PAC) of the legacy service account and the PAC of the dMSA into one PAC containing all combined group memberships and other applicable objectSIDs. The dMSA therefore inherits all user rights, permissions, and access so that it can supersede the legacy service account without impact to the service, application, or scheduled task.

The good: dMSA succession as intended

The following PowerShell cmdlets are available for the migration of a legacy service account to a dMSA.

PowerShell CMDlet	Action
Start-ADServiceAccountMigration	Initiate the migration of the legacy service account to the dMSA. This state transitions from initial to started. Can be executed only when the state is 0.
Complete-ADServiceAccountMigration	Complete the migration of the legacy service account to the dMSA. Transitions from started to completed. Can be executed only when the state is 1.
Undo-ADServiceAccountMigration	Undo the last migration step and revert to the previous step. Transitions from completed to started or from started to initial. Can be executed only when the state is either 1 or 2.
Reset-ADServiceAccountMigration	Reset the migration to the initial state, undoing everything. Transitions from either completed or started to initial. Can be executed only when the state is either 1 or 2.

Depending on the PowerShell cmdlet being used, an operational attribute with input data is used against the RootDSE of a writable DC. When that happens, multiple simultaneous actions are executed against both the target legacy service account and the target dMSA. The PowerShell cmdlets or the operational attribute can be used only by members of the Domain Admins group.

For a better understanding of what each PowerShell cmdlet does, here is a more detailed description of the actions.

When using Start-ADServiceAccountMigration, the following actions are being executed by the system:

• On the legacy service account:
  • Set msDS-SupersededServiceAccountState to 1
  • Set msDS-SupersededManagedAccountLink to the DN of the targeted dMSA
• On the dMSA:
  • Set msDS-DelegatedMSAState to 1
  • Set msDS-ManagedAccountPrecededByLink to the DN of the targeted legacy service account
  • Assign read permissions to the targeted legacy service account on all attributes of the targeted dMSA
  • Assign write permissions to the targeted legacy service account on the attribute msDS-GroupMSAMembership of the targeted dMSA

When using Complete-ADServiceAccountMigration, the following actions are being executed by the system:

• On the legacy service account:
  • Set msDS-SupersededServiceAccountState to 2
  • Disable the account
• On the dMSA:
  • Set msDS-DelegatedMSAState to 2
  • Remove the previously assigned read permissions to the targeted legacy service account from all attributes of the dMSA
  • Remove the previously assigned write permissions to the targeted legacy service account from the attribute msDS-GroupMSAMembership of the dMSA
• From the legacy service account to the dMSA, move the following configurations:
  • Service Principal Names (SPNs)
  • Allowed To Delegate To List
  • Resource Based Constrained Delegation
  • Assigned Authentication Policy
  • Assigned Authentication Silo
  • Trusted Authentication For Delegation UAC Bit

When using Reset-ADServiceAccountMigration, all the actions executed by either Start-ADServiceAccountMigration or Complete-ADServiceAccountMigration are undone, and both the legacy service account and the dMSA revert to their initial state.

When using Undo-ADServiceAccountMigration, all the actions executed by either Start-ADServiceAccountMigration or Complete-ADServiceAccountMigration are undone and both the legacy service account and the dMSA revert to the state before execution of, respectively, Start-ADServiceAccountMigration or Complete-ADServiceAccountMigration. Technically this means either of the following transitions:

• From completed to started
• From started to initial

The bad and the ugly: dMSA abuse

As the Akamai researchers discovered, the attributes of the legacy service account and the dMSA involved in the migration are not protected from regular LDAP writes. Anyone with at least Write Property permission on the attributes of the dMSA—or any other permission that can lead to that permission—can write data. Unfortunately, this loophole invalidates the protections implemented through the PowerShell cmdlet and the operational attribute under the hood.

In addition, in terms of validation, the authenticating Windows Server 2025 writable DC appears to only consider two attributes of the dMSA and nothing from the legacy service account. If the msDS-DelegatedMSAState of the dMSA is set to 2 (and it doesn’t even matter how it got to that state), the DC will check which account is specified in the msDS-ManagedAccountPrecededByLink attribute.

With that information, and assuming the requesting account (normally a computer account, but it can be anything) has permissions to request the password or keys from the dMSA, the authenticating Windows Server 2025 writable DC merges the Privileged Attribute Certificate (PAC) of the legacy service account and the dMSA into one PAC. The DC then issues that merged PAC in a TGS-REP to the requesting account.

The Distinguished Name (DN) of the account in the msDS-ManagedAccountPrecededByLink attribute can be anything—and BadSuccessor fully exploits this vulnerability.

Using administrative tiering helps to hide and protect your high-privileged accounts (users, services, computers, sMSAs, gMSAs, dMSAs). The focus here is in “hiding” the high-privileged accounts so that their DN isn’t visible to any low-privileged account. It’s also important to note that the DN of high-privileged accounts should also not be easily guessable.

This attack can quickly become a very ugly successor.

If an attacker knows the DN of the default domain Administrator account (CN=administrator,CN=Users, DC=<DOMAIN>,DC=<TLD>) or the KRBTGT account (CN=krbtgt,CN=Users,DC=<DOMAIN>,DC=<TLD>), they can misuse the controlled dMSA to completely take over the AD domain, and ultimately the AD forest.

REMARK: The KRBTGT account can be moved into a protected and hidden tiering model—but Microsoft does not recommend moving it.³

REMARK: The Administrator account can be moved into a protected and hidden tiering model. It is also OK to rename it.⁴

If you do decide to move the default domain Administrator account or the KRBTGT account into the administrative tiering structure, make sure to put both in a separate OU (i.e., not combined with other accounts) and grant access to that OU to only Tier-0 admin accounts.

How to block successors

Looking at the current inner workings of a dMSA from a “good successor” and “bad and ugly successor,” the goals of my research were to:

• A: Support all described use cases
• B: Allow and support the good successor
• C: Block the bad and ugly successor

The regular LDAP writes, as described for the bad and ugly successor, require the actor to have specific permissions on a dMSA. The use of the PowerShell cmdlets requires the actor to have membership in Domain Admins.

As I noted earlier, the PowerShell cmdlets perform different actions against the legacy service account and the dMSA, leveraging an operational attribute with input data.

With these thoughts, I reviewed the AD schema—specifically the schema definition of the msDS-ManagedAccountPrecededByLink attribute as it controls which account is being migrated (officially) or attacked (Figure 1).

Although the attribute msDS-DelegatedMSAState plays an important part, it must still be managed by executing a regular LDAP write to be able to set the state of the dMSA to 3 when using it natively rather than for migration purposes.

Looking at the definition of the attribute displayed, my intention was to block regular LDAP writes and support operational attribute writes. With that in mind, the property systemOnly stood out, as I hoped it would achieve the goal of the research. That attribute cannot be changed like any other regular attribute. A feature on the DC must first be enabled to support a special write action and then disabled again. The intention of the block is to prevent regular WRITE, while still allowing READ.

Let’s go through this step by step.

Figure 2 shows the check of the configuration of the dMSA dMSA.weak.⁵ That dMSA has its initial state and no account is linked to it (i.e., no account is displayed).

The attacker sets the state of dMSA.weak to 2, configures a linked account (the default domain administrator, which was renamed in this AD to ADM.TEC) and adds themself as the account allowed to retrieve the password/keys of the dMSA⁶ (Figure 3). In this case, the action is possible because the attacker has an account that is a member of the legacy Account Operators group.

Next, we check the configuration of dMSA.weak⁵ (Figure 4).

The dMSA now has the completed migration state 2, has an account linked to it, and the attacker is allowed to retrieve the password/keys of the dMSA. Using RUBEUS, for example, the attack can be initiated against the dMSA and especially the linked account.

Next, we remove the previous configuration⁶ and validate that it was indeed removed⁵ (Figure 5 and Figure 6).

Now we can view the state of the block⁷ (Figure 7).

Next, we enable the block for the migration scenario⁸ (Figure 8).

Again, we confirm by viewing the state of the block⁷ (Figure 9).

The attacker now tries again⁶ to:

• Set the state of dMSA.weak to 2
• Configure a linked account (again the renamed default domain administrator)
• Add themself as the account allowed to retrieve the password/keys of the dMSA (Figure 10).

Now, the transaction fails to complete as the attacker is not allowed to write the DN of the linked account.
Goal C achieved!

Now, let’s again check the configuration of dMSA.weak⁵ (Figure11).

Because the complete transaction failed, nothing was changed. If the attributes were written individually, all would have succeeded, except for the write to the msDS-ManagedAccountPrecededByLink attribute. Nothing is displayed as it does not have a value.

With the block enabled, using the official way to migrate a legacy service account to a dMSA also fails (Figure 12). This is unfortunate. There is light at the end of the tunnel though!

The block is about preventing writes against the msDS-ManagedAccountPrecededByLink attribute. Looking at the official PowerShell cmdlets for the migration, only the cmdlets Start-ADServiceAccountMigration and Reset-ADServiceAccountMigration write to that attribute. The cmdlet Undo-ADServiceAccountMigration also writes to that attribute when undoing the step from started to initial. In other transitions, there is no write needed or executed to that attribute.

Goals A and B: partially achieved.

Next, we disable the block for the migration scenario⁹ (Figure 13).

Now, we again view the state of the block⁷ (Figure 14).

Now, when the attacker tries⁶ to:

• Set the state of dMSA.weak to 2
• Configure a linked account (again the renamed default domain administrator)
• Add themself as the account allowed to retrieve the password/keys of the dMSA

—they succeed because again the block is gone (Figure 15).

Now, when we check the configuration of dMSA.weak⁵ (Figure 16), we see the attacker has the completed migration state 2, has an account linked to the dMSA, and is allowed to retrieve the password/keys of the dMSA.

With the block disabled, we can also use the official method to successfully initiate, complete, and reset the migration of a legacy service account to a dMSA (Figure 17). For this example, another legacy service account and dMSA was used, and the migration was executed by a Domain Admin account.

Blocking BadSuccessor requires hands-on management

With this solution, it’s possible to block the dMSA migration scenario and therefore any misuse.

We still encourage organizations to proactively review their delegation model² and act accordingly to mitigate any risk. In this context, the focus of the review is around the creation and management of dMSAs in any AD domain.

Organizations with the desire to either upgrade to Windows Server 2025 AD or install a new Windows Server 2025 AD can implement this solution to mitigate the risks of an attack until Microsoft has released a patch.

Implementing the block on the migration scenario is done in the AD schema, and the change is reversible: You can set it to block⁸ and at a later stage, set to unblock⁷. That means multiple management approaches are possible.

Your organization may implement this block because there is no desire to use dMSAs for the migration scenario.

If your organization desires to use dMSAs for the migration scenario, you can still implement the block to protect AD. Any time you want to initiate the migration of an account, you can remove the block upfront and reimplement it afterwards. You can complete the migration of an account with or without the block in place.

Using this approach, it’s possible to achieve goals A, B, and C.

Even if you implement a block, Semperis DSP’s IOEs and IOCs help enable close monitoring of dMSA creation, management, and authentication events as well as attribute modifications.

Learn more about the dangers of excessive privileges in AD

• Why You Should Pay Attention to Excessive Privilege in Active Directory
• What is Unconstrained Delegation? | Semperis Identity Attack Catalog
• What Is Active Directory Security? | Semperis AD Guides

Endnotes

1. BadSuccessor: Abusing dMSA to Escalate Privileges in Active Directory
2. (2025-05-25) Reviewing Your Delegation Model Before Introducing W2K25 DCs And Enhancing Security (Due To “BadSuccessor”)
3. Microsoft Learn: KRBTGT account attributes
4. Microsoft Learn: Administrator account
5. Bad Successor – VIEW DATA IN ATTRIBUTES “msDS-groupMSAMembership”, “msDS-DelegatedMSAState”, “msDS-ManagedAccountPrecededByLink”
6. Bad Successor – WRITE DATA INTO ATTRIBUTES “msDS-groupMSAMembership”, “msDS-DelegatedMSAState”, “msDS-ManagedAccountPrecededByLink”
7. Bad Successor – VIEW STATE OF BLOCK
8. Bad Successor – ADDING/ENABLING BLOCK
9. Bad Successor – REMOVING/DISABLING BLOCK

DISCLAIMER

This content is provided for educational and informational purposes only. It is intended to promote awareness and responsible remediation of security vulnerabilities that may exist on systems you own or are authorized to test. Unauthorized use of this information for malicious purposes, exploitation, or unlawful access is strictly prohibited. Semperis does not endorse or condone any illegal activity and disclaims any liability arising from misuse of the material. Additionally, Semperis does not guarantee the accuracy or completeness of the content and assumes no liability for any damages resulting from its use.