Home

Published

- 11 min read

BadSuccessor: Unmasking a Critical Privilege Escalation in Active Directory

By William OGOU
BadSuccessor Active Directory Privilege Escalation Windows Server 2025 dMSA CVE-2025 Cybersecurity Akamai
img of BadSuccessor: Unmasking a Critical Privilege Escalation in Active Directory

Active Directory (AD) remains the backbone of identity and access management for countless organizations worldwide. Its security is paramount, yet new vulnerabilities continue to emerge, often in unexpected places.

Recently, a novel and alarming privilege escalation technique dubbed “BadSuccessor” has come to light, specifically targeting a new feature in Windows Server 2025: delegated Managed Service Accounts (dMSAs).

This vulnerability, if exploited, could allow attackers with minimal permissions to gain control over any user account in Active Directory, including highly privileged Domain Admins, often without modifying the target object or triggering traditional alerts.

Discovered by Akamai researcher Yuval Gordon, BadSuccessor poses a significant threat due to its potential for widespread disruption, its ease of exploitation under default configurations, and the current lack of an official patch from Microsoft. This post will dissect the BadSuccessor vulnerability, drawing on insights from Akamai’s research, SOC Prime’s detection strategies, and Tenable’s analysis, to provide a comprehensive understanding for cybersecurity practitioners.

Understanding the Foundation: What are Delegated Managed Service Accounts (dMSAs)?

Before diving into the exploit, it’s essential to understand the legitimate feature being abused. Microsoft introduced dMSAs in Windows Server 2025 as an enhancement to group Managed Service Accounts (gMSAs). A key design goal for dMSAs was to simplify the transition from traditional, non-managed service accounts by enabling a seamless “migration” process. This involves marking existing non-managed accounts as “predecessors” to newly created dMSAs.

The migration flow is intended to allow a dMSA to “inherit” the permissions and context of the legacy account it’s replacing. This tight coupling, particularly how the Key Distribution Center (KDC) handles authentication and Privilege Attribute Certificates (PACs) for these dMSAs, is where the BadSuccessor vulnerability takes root. The critical point is that this feature is available by default in any domain with at least one Windows Server 2025 domain controller, even if the organization isn’t actively using dMSAs.

The Core of the Vulnerability: How BadSuccessor Works

The BadSuccessor attack cleverly abuses the intended dMSA migration mechanism. Instead of performing a legitimate migration (which is a privileged operation restricted to Domain Admins), an attacker can “simulate” this migration by manipulating just two attributes on a dMSA object they control. This grants the dMSA the full permissions and PAC details of any targeted user, effectively making the dMSA an “unintended heir” to the target’s privileges.

The Two Key Attributes:

  • msDS-ManagedAccountPrecededByLink: This attribute on the dMSA object is meant to store the Distinguished Name (DN) of the superseded (original) account during a migration. In the BadSuccessor attack, the attacker sets this attribute to the DN of their desired target account (e.g., a Domain Administrator).
  • msDS-DelegatedMSAState: This attribute indicates the migration status of the dMSA. By setting this to 2 (“migration completed”), the attacker signals to the KDC that the (fake) migration is finalized.

The Deceptive “Simulated Migration”:

When an attacker has control over a dMSA object (either by having permissions to modify an existing one or, more commonly, by creating a new dMSA in an Organizational Unit (OU) where they have Create all child objects or the specific Create msDS-DelegatedManagedServiceAccount rights), they can:

  1. Set the msDS-ManagedAccountPrecededByLink on their dMSA to point to the victim account.
  2. Set the msDS-DelegatedMSAState on their dMSA to 2.

That’s it. No actual migration process needs to be invoked, no validation from the target account is required, and no direct modification of the target account occurs.

KDC Deception and PAC Inheritance:

Once these attributes are set, the Key Distribution Center (KDC) is tricked. When the attacker authenticates using this maliciously configured dMSA:

  • The KDC sees the msDS-ManagedAccountPrecededByLink pointing to the target (e.g., Domain Admin).
  • It sees the msDS-DelegatedMSAState as “migration completed.”
  • The KDC then assumes a legitimate migration has occurred and constructs the Privilege Attribute Certificate (PAC) for the dMSA’s Kerberos ticket based solely on this link.

This PAC will include not only the dMSA’s SID but critically, the SIDs of the “superseded” account (the victim) and all of its associated group memberships (e.g., Domain Admins, Enterprise Admins).

The dMSA effectively inherits all permissions of the targeted user without any oversight or standard migration prerequisites. Akamai’s research found that “in 91% of the environments we examined, non-admin users had the required permissions to perform the attack,” primarily the ability to create child objects in an OU.

Beyond Impersonation: BadSuccessor and Credential Theft

The BadSuccessor attack doesn’t just stop at privilege escalation through impersonation. The way dMSA authentication is designed provides another avenue for attackers: potentially compromising the credentials (or at least their NTLM hash equivalent) of the superseded account.

When a Ticket Granting Ticket (TGT) is requested for a dMSA, the KDC includes a new structure called KERB-DMSA-KEY-PACKAGE. This package contains fields for current-keys (of the dMSA itself) and, significantly, previous-keys. Akamai’s investigation revealed a startling behavior:

  • Even for a newly created dMSA (which shouldn’t have any “previous” keys), the previous-keys field in the KERB-DMSA-KEY-PACKAGE can be populated with key material derived from the account linked via msDS-ManagedAccountPrecededByLink.
  • Specifically, if the superseded account defaults to using RC4-HMAC (common for user accounts without explicitly configured encryption types), its RC4 key (which is its NTLM hash) can appear in this previous-keys structure.

Why does this happen? This behavior appears to be a design choice by Microsoft to ensure service continuity during dMSA migration. If services still hold tickets encrypted with the old account’s keys, the new dMSA needs to be able to decrypt them. By providing the old account’s keys within the dMSA’s TGT package, the dMSA can effectively use them.

For an attacker, this means that by performing the BadSuccessor attribute manipulation, they might not only gain the privileges of the target but also obtain the target’s NTLM hash, allowing for pass-the-hash attacks or offline password cracking.

The Impact: A Low-Complexity, High-Impact Threat

The BadSuccessor vulnerability is particularly dangerous because:

  • It works by default: As long as a Windows Server 2025 Domain Controller is present in the domain, the dMSA feature and this vulnerability path are available. Active use of dMSAs by the organization is not a prerequisite.
  • Low permission requirements for attackers: The ability to create objects in an OU is a common, often overlooked, permission.
  • Stealth: The attack doesn’t modify the target user object directly, making it less likely to trigger alerts focused on changes to privileged accounts. Traditional privilege escalation alerts might be bypassed.
  • Full Domain Compromise: Attackers can target any account, including Domain Admins or the krbtgt account, leading to complete domain takeover.
  • Bypasses Traditional Barriers: It sidesteps typical administrative controls and approval mechanisms for privilege changes.

While Microsoft has acknowledged the issue and assessed it as “Moderate severity,” stating it doesn’t meet the threshold for immediate servicing (as of the research publication dates), many in the security community, including the Akamai researchers, express respectful disagreement due to the ease of exploitation and its severe implications.

Detecting BadSuccessor Attacks: What to Look For

Given the current absence of a patch, detection and proactive mitigation are crucial. Security teams should focus on monitoring specific activities and configurations:

  • Audit dMSA Creation (Event ID 5137):
    • Configure a System Access Control List (SACL) to log the creation of new msDS-DelegatedManagedServiceAccount objects (Event ID 5137).
    • Pay special attention to creations by accounts not typically responsible for service account management. SOC Prime highlights the importance of this for early detection.
  • Monitor Attribute Modifications to msDS-ManagedAccountPrecededByLink (Event ID 5136):
    • Configure a SACL to log modifications to the msDS-ManagedAccountPrecededByLink attribute. Changes to this attribute are a strong indicator of attempted or successful BadSuccessor abuse.
  • Track dMSA Authentication (Event ID 2946 - Directory Service Log):
    • When a TGT is generated for a dMSA and includes the KERB-DMSA-KEY-PACKAGE structure (indicative of dMSA-specific authentication that might involve the BadSuccessor technique), the Domain Controller logs Event ID 2946.
    • The “Group Managed Service Account Object” field will show the DN of the dMSA being authenticated. Frequent or unexpected 2946 events involving unusual dMSAs should be investigated thoroughly.
  • Review Permissions on OUs and Containers:
    • Regularly audit who has permissions to create child objects (specifically msDS-DelegatedManagedServiceAccount objects) within OUs. This is often the entry point for attackers.
    • Akamai has released a PowerShell script, Get-BadSuccessorOUPermissions.ps1, available on their BadSuccessor GitHub repository, which helps defenders identify which non-default principals have permissions to create dMSAs and in which OUs.
  • Leverage Specialized Detection Content:
    • SOC Prime Platform: Offers relevant detection rules aligned with MITRE ATT&CK® for various SIEM, EDR, and Data Lake solutions. Their “badsuccessor” tag in the Threat Detection Marketplace can help locate these.
    • Uncoder AI (from SOC Prime): Can be used to translate threat reports (like Akamai’s on BadSuccessor) into visual attack flows and generate detection queries, aiding in proactive threat hunting beyond simple IOCs.
    • Tenable Identity Exposure: Tenable has released an Indicator of Exposure (IoE) for BadSuccessor (as of v3.95 of their product) to help customers identify potential risks.

Mitigation Strategies: Hardening Your Active Directory

Until an official patch from Microsoft is available, organizations must focus on proactive measures:

  • Restrict dMSA Creation Rights: This is the most critical mitigation.
    • Identify all principals (users, groups, computers) with permissions to create dMSAs across the domain.
    • Limit this permission strictly to trusted administrators only. The principle of least privilege is key.
  • Tighten OU Permissions: Scrutinize and reduce overly permissive delegations on OUs, especially the “Create all child objects” right.
  • Monitor for Abuse: Implement the detection strategies outlined above diligently.
  • Stay Informed: Keep an eye on updates from Microsoft regarding a patch and further guidance from security researchers. Akamai, Tenable, and SOC Prime are valuable resources.
  • Consider Domain Functional Level (Limited Mitigation): While the attack works as long as one Windows Server 2025 DC is present, Tenable’s telemetry found that (as of their reporting) only a small percentage (0.7%) of AD domains had at least one Windows Server 2025 DC. This might offer a temporary reprieve for some but is not a long-term solution.

Microsoft has stated their engineering teams are working on a patch. The mitigation guidance will likely be updated once more technical details or a patch becomes available.

Conclusion: A Wake-Up Call for Active Directory Security

The BadSuccessor vulnerability is a stark reminder of how new features, even those designed with good intentions like simplifying service account management, can introduce unforeseen and critical security risks. It highlights that attackers are creative and adept at finding abuse paths in complex systems, often leveraging seemingly benign or overlooked permissions.

The fact that this attack works by default in environments with just one Windows Server 2025 domain controller, and that common permissions allow its execution by non-admin users, elevates its severity significantly. Organizations must treat the ability to create or control dMSA objects with the same level of scrutiny as other highly sensitive administrative operations.

Until a patch is released, proactive detection and stringent permission management are the primary defenses against this potent new threat to Active Directory.

To further enhance your cloud security and implement Zero Trust, contact me on LinkedIn Profile or [email protected].

BadSuccessor Vulnerability FAQ:

  • What is the BadSuccessor vulnerability? BadSuccessor is a privilege escalation vulnerability in Microsoft Active Directory, specifically affecting the delegated Managed Service Account (dMSA) feature introduced in Windows Server 2025. It allows an attacker to gain the permissions of any user in AD, including Domain Admins, by manipulating attributes on a dMSA object they control.
  • Why is BadSuccessor considered critical? It’s critical because it allows for a full domain compromise with relatively low initial permissions (often just the ability to create objects in an Organizational Unit). It bypasses traditional administrative barriers, doesn’t directly modify the target account, and works by default if a Windows Server 2025 DC is present.
  • How is the BadSuccessor attack exploited? An attacker exploits it by creating or gaining control of a dMSA object. They then set the msDS-ManagedAccountPrecededByLink attribute to point to the target victim’s account and the msDS-DelegatedMSAState attribute to ‘2’ (migration completed). This tricks the Key Distribution Center (KDC) into granting the dMSA the victim’s privileges.
  • When was BadSuccessor disclosed and is there a patch? BadSuccessor was disclosed by Akamai researcher Yuval Gordon around May 2025. As of the initial disclosures (May/June 2025), Microsoft had acknowledged the issue but had not released an official patch, assessing it as “Moderate” severity.
  • Who is affected by the BadSuccessor vulnerability? Any Active Directory domain that includes at least one Windows Server 2025 domain controller is potentially affected, as the dMSA feature is enabled by default. The ease of exploitation depends on how OU permissions for object creation are configured.

Relevant Resource List: