Inside BadSuccessor: Privilege Escalation via dMSA in Windows Server 2025

Following our initial coverage of BadSuccessor, this technical breakdown dissects the inner workings of a critical privilege escalation vulnerability in Windows Server 2025.

BadSuccessor is a critical privilege escalation vulnerability affecting Windows Server 2025’s delegated Managed Service Account (dmSA) feature.

This technical deep dive, researched and authored by Senior Hive Member Ibai Castells, follows our initial Swarm Intelligence alert published in May 2025.

This vulnerability allows attackers to escalate privileges and potentially compromise entire Active Directory domains by exploiting Kerberos ticketing mechanisms and the new KERB-DMSA-KEY-PACKAGE structure.

Our analysis confirms that this vulnerability poses a significant threat to enterprise environments, particularly given that 91 percent of real-world domains have non-admin users who already possess the necessary CreateChild or write rights on at least one Organizational Unit (OU), making this attack path trivial to execute in most cases.

Vulnerability Overview

Technical Background

The BadSuccessor vulnerability, originally disclosed by Akamai researcher Yuval Gordon, exploits a design flaw in Windows Server 2025’s dMSA implementation. This vulnerability allows attackers to manipulate two critical attributes:

  • msDS-ManagedAccountPrecededByLink
  • msDS-DelegatedMSAState

By setting these attributes on any dMSA object (existing or newly created), an attacker can convince the Kerberos Distribution Center (KDC) to issue tickets carrying the Security Identifiers (SIDs) of high-privilege users, effectively “succeeding” them without ever touching the target account’s groups or credentials.

More specifically, when an attacker sets the msDS-DelegatedMSAState to a value of 2, it indicates that an account migration has occurred. This migration triggers key and privilege inheritance onto the dMSA from the targeted domain principal, allowing the attacker with control over the dMSA to retrieve credential material and authenticate as that target account.

Attack Prerequisites

The attack requires one of the following conditions:

  • Access to an existing dMSA account
  • Appropriate privileges such as CreateChild, GenericAll, WriteDACL, or WriteOwner on an Organizational Unit (OU) in the domain
  • Write permissions on existing dMSA objects

Risk Assessment

Microsoft has classified BadSuccessor as “moderate” severity and plans a future patch, but no fix is currently available. Organizations must rely on compensating controls until a patch is released. Our assessment elevates this to high risk for enterprise environments due to:

  • A wide attack surface (91% of domains vulnerable out-of-the-box)
  • Zero-to-hero privilege escalation potential
  • No current patch available
  • Difficulty in detection without proper monitoring; existing rules are unlikely to detect the attack.


Technical Analysis

Attack Chain Overview

The BadSuccessor attack follows a multi-stage process:

  1. Reconnaissance: Enumerate writable Organizational Units
  2. dMSA Creation: Create or modify delegated managed service accounts
  3. Privilege Linking: Associate dMSA with high-privilege accounts (simulating the migration)
  4. Ticket Manipulation: Leverage Kerberos ticketing to obtain elevated access
  5. Credential Extraction: Dump credentials via KERB-DMSA-KEY-PACKAGE

Phase 1: Environmental Reconnaissance

The attack begins by identifying vulnerable OUs where the current user has write permissions. Attackers scan Active Directory to locate OUs with insufficient access restrictions.

Phase 1: Environmental Reconnaissance

Phase 2: dMSA Object Manipulation

Once a target OU is identified, the attacker creates a new msDS-DelegatedManagedServiceAccount object or modifies an existing one. Key attributes configured include:

  • msDS-DelegatedMSAState: Set to 2 (active state)
  • msDS-ManagedAccountPrecededByLink: Points to the target high-privilege user DN
  • msDS-ManagedPasswordInterval: Password rotation interval
  • userAccountControl: Workstation trust account flags
  • msDS-SupportedEncryptionTypes: Kerberos encryption types

Phase 3: Kerberos Ticket Exploitation

The exploitation leverages Kerberos ticket-granting mechanisms:

  1. Obtain TGT for the principal with dMSA retrieval permissionsa. First, find the LUID
    b. Now, dump their TGT
  2. Request TGS for the dMSA account using the TGT
  3. Use the dMSA TGS to request additional service tickets with elevated privileges

Phase 4: Credential Access and Lateral Movement

With elevated tickets, attackers can access high-value resources and perform lateral movement across the domain.

dMSA Credential Dumping via KERB-DMSA-KEY-PACKAGE

Understanding KERB-DMSA-KEY-PACKAGE

When you request a TGT for a dMSA, it comes with a new structure called KERB-DMSA-KEY-PACKAGE. This structure includes two fields: current-keys and previous-keys.

According to Microsoft documentation, these are supposed to contain keys related to the current and previous password of the dMSA. More specifically, these are the keys for the account that it has “migrated,” the one set in the msDS-ManagedAccountPrecededByLink attribute.

Credential Extraction Process

The KERB-DMSA-KEY-PACKAGE structure can be exploited to extract credential material:

  1. TGT Acquisition: Request a Ticket Granting Ticket for the dMSA account
  2. Package Extraction: Parse the KERB-DMSA-KEY-PACKAGE from the TGT response
  3. Key Retrieval: Extract current and previous password keys from the package
  4. Credential Reconstruction: Use extracted keys to reconstruct usable credentials

Technical Implementation

At a high level, this would be the process to turn this attack path into a credential dumper similar to the infamous secretsdump.py:

var domain  = GetCurrentDomain();
string dn   = domain.DistinguishedName;
string dns  = domain.DnsRoot;
string gmsaDN = $"CN=covertswarm_dmsa,CN=Managed Service Accounts,{dn}"; //OU
var principals = new List();
principals.AddRange( QueryAD("(objectClass=user)")     );
principals.AddRange( QueryAD("(objectClass=computer)") );
foreach (var p in principals)
    {
        //-------------------------------
        // Update gMSA attribute
        //-------------------------------
        ReplaceAttributeValue(
            distinguishedName : gmsaDN,
            attribute         : "msDS-ManagedAccountPrecededByLink",
            newValue          : p.DistinguishedName
        );
        //-------------------------------
        // 4-B  Call Rubeus to request
        //      a TGS for the gMSA (or implement your TGS logic here)
        //-------------------------------
        string rubeusOut = RunProcess(
            file : "Rubeus.exe",
            args : $"asktgs /targetuser:mydmsa$ /service:\"krbtgt/{dns}\" /opsec /dmsa /nowrap /ticket:{kirbi}"
        );
        //-------------------------------
        // 4-C  Scrape the RC4 key from
        //      Rubeus’ output
        //-------------------------------
        string rc4 = Regex
            .Match(rubeusOut, @"Previous Keys for .* \$: \(rc4_hmac\) ([A-F0-9]{32})")
            .Groups[1]
            .Value;
        //-------------------------------
        // 4-D  Show   samAccountName:RC4
        //-------------------------------
        Console.WriteLine($"{p.SamAccountName}:{rc4}");
    }

The extracted keys can be:

  • Used directly for authentication
  • Cracked offline to obtain plaintext passwords
  • Leveraged for pass-the-hash attacks
  • Stored for persistent access

Detection Opportunities

Credential dumping via KERB-DMSA-KEY-PACKAGE generates specific Event IDs:

  • Event ID 2946: dMSA authentication events with caller SID S-1-5-7
  • Event ID 4769: Service ticket requests for dMSA accounts
  • Event ID 4624: Logon events using extracted credentials

Vulnerability Assessment Checklist

Organizations should perform the following checks to determine their exposure to BadSuccessor:

1. Windows Server 2025 Presence Assessment

  • Inventory all domain controllers in the environment
  • Identify any Windows Server 2025 domain controllers
  • Check Active Directory schema version for dMSA support
  • Document forest and domain functional levels

2. dMSA Configuration Audit

  • Enumerate existing dMSA objects in Active Directory
  • Review msDS-DelegatedMSAState attribute values
  • Audit msDS-ManagedAccountPrecededByLink configurations
  • Verify msDS-GroupMSAMembership security descriptors

3. Organizational Unit Permissions Review

  • Audit CreateChild permissions on all OUs
  • Review write permissions for non-administrative users
  • Identify OUs with overprivileged access
  • Document users/groups with OU write access

4. Monitoring and Logging Assessment

  • Verify Event ID 5137 logging for object creation
  • Confirm Event ID 5136 logging for attribute changes
  • Check Event ID 2946 logging for dMSA authentication
  • Test SACL configurations for critical attributes
  • Detection & monitoring strategies

Event-Based Detection

Implement logging and monitoring for:

dMSA Object Creation

  • Event ID 5137: Directory service object creation
  • Filter for msDS-DelegatedManagedServiceAccount object class
  • Alert on creation by non-standard service accounts

Critical Attribute Modifications

  • Event ID 5136: Directory service object modification
  • Monitor changes to msDS-ManagedAccountPrecededByLink
  • Monitor changes to msDS-DelegatedMSAState
  • Configure SACLs on sensitive dMSA objects

dMSA Authentication Events

  • Event ID 2946: dMSA authentication with KERB-DMSA-KEY-PACKAGE
  • Caller SID field showing S-1-5-7
  • Unexpected or unauthorized dMSA authentications

Behavioural analysis

Monitor for suspicious patterns:

  • Rapid dMSA object creation followed by privilege escalation attempts
  • Unusual Kerberos ticket requests for newly created dMSA accounts
  • Service ticket requests to high-value targets from dMSA principals
  • Off-hours or anomalous authentication patterns for dMSA accounts

Network-Based Detection

Implement network monitoring for:

  • Abnormal Kerberos AS-REQ/AS-REP traffic patterns
  • TGS-REQ requests for dMSA accounts from unexpected sources
  • Lateral movement indicators following dMSA authentication events

Mitigation Strategies

Immediate Actions

  1. Audit Current Environment
    • Use the Akamai BadSuccessor Checker to assess vulnerability exposure
    • Identify all existing dMSA objects and their configurations
    • Review OU permissions and identify overprivileged accounts
  2. Implement Access Controls
    • Restrict CreateChild and write permissions on OUs to trusted administrators only
    • Remove unnecessary write permissions from standard user accounts
    • Implement principle of least privilege for service accounts
  3. Enable Enhanced Monitoring
    • Configure SACLs for critical dMSA attributes
    • Enable comprehensive directory service logging
    • Implement real-time alerting for suspicious dMSA activities

Proof of Concept and Tools

CovertSwarm Research Tools

Our team has developed and validated exploitation tools:

Conclusion and Recommendations

The BadSuccessor vulnerability represents a significant threat to Active Directory environments running Windows Server 2025. The combination of widespread vulnerable configurations and the absence of an official patch creates an urgent need for proactive defensive measures.

References and Additional Resources

Related Posts