BadSuccessor Threat in Windows Server 2025: How to Detect and Defend Against Privilege Escalation in AD

Background: The Evolution of Service Account Security​

The need for secure, manageable service accounts has haunted Windows administrators for decades. Traditional service accounts—often simple user or computer accounts assigned broad permissions—have made enterprises vulnerable: static passwords, dangerous privilege sprawl, and little auditability have facilitated countless breaches.

Microsoft answered this challenge with Managed Service Accounts (MSAs) in Windows Server 2008 R2, followed by group Managed Service Accounts (gMSAs), which introduced:

• Automated password rotation
• Per-account, machine-based usage scoping
• Reduced need for privileged human intervention

Yet, despite these advances, migrating legacy accounts remained a challenge, especially for complex environments or tightly integrated applications. Windows Server 2025 builds on this legacy by debuting Delegated Managed Service Accounts (dMSAs)—accounts designed specifically to facilitate smooth service account migration with minimal interruption. While well-intentioned, the security model around dMSA creation and attribute manipulation was missed by many blue teams, setting the stage for BadSuccessor.

Understanding Delegated Managed Service Accounts in Active Directory​

What Are dMSAs?​

dMSAs are a new object type within Active Directory intended to temporarily coexist with legacy service accounts during staged migrations. When a dMSA is provisioned:

• An admin creates a dMSA, referencing the legacy service account via msDS-ManagedAccountPrecededByLink.
• The migration process is kicked off, updating the state attributes (msDS-DelegatedMSAState).
• The account is promoted to “complete,” the original account is disabled, and all authentication/permission requests flow through the dMSA, inheriting the predecessor’s permissions.

This process allows organizations to seamlessly transition services—the dMSA masks the credential swap while maintaining operational continuity.

Intended Security Benefits​

By design, dMSAs should:

• Remove manual credential management for service accounts
• Prevent service downtime or access loss during migration
• Ensure permissions are restricted to the minimum necessary for each step

However, the delegation and permission model, particularly for who can create or modify these account objects and their critical attributes, has become a dangerous blind spot.

The BadSuccessor Vulnerability: Anatomy of a Modern Attack​

Mechanism of the Attack​

BadSuccessor is not merely a vulnerability in code—it is a systemic weakness in Active Directory privilege delegation. The flaw arises because any account with create or modify privileges over dMSA objects in a given Organizational Unit (OU) can essentially stage a fake migration:

• The attacker creates a dMSA object in an OU where they hold sufficient rights.
• They manually set msDS-ManagedAccountPrecededByLink to point to a victim account (including high-privilege accounts like Domain Admin).
• They set msDS-DelegatedMSAState to mimic migration completion.
• Upon authenticating as the dMSA, the attacker inherits all effective permissions of the targeted account, with privileges accorded by the Key Distribution Center.

Crucially, these steps do not require full administrative privilege—just “Create all child objects” or explicit dMSA creation rights on any OU.

Tools Fueling Attacker Productivity​

Publicly available PowerShell modules and red team frameworks now automate BadSuccessor exploitation, notably:

• SharpSuccessor – An open-source proof-of-concept that orchestrates the entire attack chain through scripted attribute manipulation.
• Pentest-Tools-Collection BadSuccessor Module – Performs both enumeration (to find vulnerable accounts/OUs) and exploitation in one workflow.

Even novice attackers can now hunt for, and weaponize, wrongly-delegated permissions against unpatched domains.

Technical Deep Dive: Migration, Exploitation, and Real-World Impact​

The Migration Workflow—Legitimate vs. Malicious​

Legitimate dMSA Migration:

• Admin creates a dMSA object with reference links to legacy account.
• Migration begins (msDS-DelegatedMSAState = 1).
• Admin completes migration (msDS-DelegatedMSAState = 2; account disables predecessor).
• Services transparently authenticate as dMSA, retaining legacy permissions.

BadSuccessor Attack:

• Adversary creates a rogue dMSA in a less protected OU.
• Sets preceding link to chosen victim.
• Directly sets migration state to “complete” (msDS-DelegatedMSAState = 2).
• Gains the ability to fully impersonate the chosen principal—including Domain Admin if targeted.

The technical distinction is razor-thin; the difference between an authorized migration and a subversive takeover hinges entirely on who has permission to modify dMSA attributes.

Domain Compromise Scenarios​

Once an attacker claims victim privileges, the threat rapidly escalates:

• Use of Rubeus (and similar tools) enables ticket harvesting and reuse, including domain Kerberos Ticket Granting Ticket (TGT) acquisition.
• Attackers can access highly sensitive network shares, escalate to Domain Controller operations, or move laterally across the environment—all under the guise of a legitimate account.

No legacy service account is safe if even a single OU has lax permissions on dMSA creation or attribute modification. The magnitude of the threat cannot be overstated for large or complex Active Directory deployments.

Detection and Response: Recognizing the Signs of BadSuccessor​

Auditing and Logging Essentials​

The primary line of defense is monitoring specific Active Directory events:

• Event ID 5137: Creation of dMSA objects
• Event ID 5136: Modification of critical attributes—especially msDS-ManagedAccountPrecededByLink
• Event ID 2946: Kerberos TGT issued for dMSA
• Event ID 4662: Object operations, including CreateChild access and direct attribute changes

Combined, these logs can be leveraged to:

• Detect dMSA creation or attribute modification by unauthorized users (especially non-admin accounts)
• Correlate dMSA lifecycle events with workstation names, source IPs, and logon types for investigation
• Distinguish legitimate migrations (done by protected admin roles) from suspicious or unprivileged operations

Continuous logging and the implementation of fine-grained audit policies are prerequisites for any meaningful detection effort.

Advanced Detection Tactics​

Security teams can deploy custom queries (such as those developed by Unit 42’s Managed Threat Hunting team) for hunter-style threat searches:

• Correlate Event ID 4741 (computer account creation) with Event ID 4662 (object creation on dMSA)
• Use Event ID 4624 to enrich suspicious account creation/modification events with source information
• Filter and flag cases where privileged dMSA migration actions are performed by non-admin users, outside of bread-and-butter admin workstations

Modern XDR and SIEM platforms, such as Palo Alto Networks Cortex XDR and XSIAM, now incorporate detection logic for BadSuccessor—raising alerts for rare machine account creation and anomalous dMSA manipulation patterns.

Mitigation Strategies: Proactive Defense in Depth​

Immediate Actions​

Addressing BadSuccessor risks before a patch is available requires deliberate, layered controls:

• Audit and restrict delegation: Review all OUs; remove “Create all child objects” rights from non-admin principals, particularly over Managed Service Accounts containers.
• Granular permissions management: Explicitly limit who can create or modify dMSAs to trusted administrative groups.
• Mandatory auditing: Enable detailed object access auditing within Active Directory and ensure thorough event log collection and retention policies are in place.
• Detection and alerting: Deploy custom rules in SIEM/SOAR systems to trigger on suspicious dMSA creations or attribute changes outside of maintenance windows or known migrations.

Longer-Term Recommendations​

As organizations await a formal fix from Microsoft, they should also:

• Stay current on threat intelligence: Review security advisories regularly, especially around Windows Server 2025 and Active Directory.
• Penetration testing and red teaming: Simulate BadSuccessor and other privilege escalation techniques within internal or third-party assessment cycles.
• User and privilege hygiene: Maintain a minimal privilege model; monitor for deviation from least-privilege principles at the level of OUs and service account management.

The Need for Immediate Attention​

Given the speed of automated tool proliferation and the strategic value of AD compromise, BadSuccessor should be treated as an active, high-priority threat. Large organizations, managed security providers, and cloud-integrated enterprises are especially at risk, as attackers may scan widely for vulnerable OUs or configuration drift.

Why This Risk Is So Difficult to Stamp Out​

Strengths of the Technique​

• Exploits native, intended functionality in the dMSA migration workflow, making detection and prevention highly nuanced
• Lowers attack pre-requisites: No need for full admin; just certain delegated rights in an often-overlooked OU
• Rapid weaponization through open-source attack toolkits, reducing time from discovery to exploitation

Challenges in Mitigation​

• Complex AD environments: Large organizations may have hundreds or thousands of OUs, each with their own, sometimes legacy, delegation.
• Lack of awareness: Even seasoned admins may assume that default dMSA permissions provide adequate security, missing custom or inherited rights.
• Indistinguishable footprints: Attribution can be difficult, as malicious dMSA migrations closely mirror legitimate transitions in event logs.

Potential Risks and Broader Implications​

• Full domain compromise: A single mistake in OU permissioning can compromise the security of entire organizations.
• Lateral movement and persistence: Once a dMSA is established, attackers can blend into business-as-usual workflows, making detection almost impossible until it’s too late.
• No available patch: Defenders cannot rely on vendor fixes and must instead embrace operational rigor and active defense.

Palo Alto Networks and Vendor Protections​

Organizations leveraging advanced EDR and XDR suites, especially Palo Alto Networks Cortex XDR and XSIAM, benefit from pre-built analytics capable of catching many BadSuccessor activity patterns—assuming auditing is enabled. These platforms:

• Build behavioral baselines for domain changes
• Surface anomalous or rare account manipulation activity
• Integrate identity analytics for credential-based attack detection

In addition, seeking out managed detection and response (MDR) services with explicit experience in AD threat hunting can fill gaps for overburdened or under-resourced IT and security departments.

The Road Ahead: Staying Ahead of Attackers​

BadSuccessor is a textbook example of how new features, even those meant to advance security and automation, can inadvertently undermine enterprise defenses if implemented without holistic risk assessment. As attackers continue to target Active Directory—the “keys to the kingdom” for most enterprise environments—every security team must treat dMSA permissions and auditing as critical control points.

Vigilance, aggressive auditing, and rapid incident response are the only defenses for now. Security leaders should:

• Conduct regular entitlement reviews on all AD OUs and containers
• Ensure complete audit coverage for all dMSA and high-privilege accounts
• Integrate BadSuccessor hunting into routine threat detection procedures

Until Microsoft ships an official patch, and likely beyond, human vigilance and operational discipline remain the best weapons in this new front of Active Directory security. Whether BadSuccessor becomes the next “Golden Ticket” attack or is quickly contained will depend on how rapidly defenses adapt on the ground. For now, the race is on—and the stakes for neglecting dMSA security have never been higher.