A dangerous privilege escalation vulnerability nestled inside Windows Server 2025’s delegated Managed Service Account (dMSA) architecture hands attackers a trivially exploitable path to full Active Directory compromise. Dubbed BadSuccessor by Akamai researcher Yuval Gordon, the flaw weaponizes routine delegated permissions—the kind handed to help desk staff and automation scripts—to create rogue service accounts that impersonate Domain Admins. With a publicly available proof-of-concept tool already automating every step, enterprise defenders are scrambling to audit thousands of organizational units before adversaries act.

The Flaw That Upends Least Privilege

At first glance, delegated Managed Service Accounts look like a security win. Microsoft designed them to let applications authenticate without hardcoding credentials, handling password rotation automatically. But the implementation in Windows Server 2025 introduces a critical oversight: an attacker with just CreateChild rights on any Organizational Unit (OU) can craft a dMSA that steals the identity of a highly privileged account.

The attack manipulates two Active Directory attributes—msDS-ManagedAccountPrecededByLink and msDS-DelegatedMSAState. By setting a “successor” relationship to a target account like “Administrator,” the rogue dMSA inherits identical Kerberos privileges. The kicker? The attacker doesn’t need to touch the target account, modify its group memberships, or even know its password.

This flips a foundational assumption on its head. Most organizations treat OU-level CreateChild rights as low-risk, delegating them broadly so staff can provision users and computers. Yet BadSuccessor turns that delegation into a stealthy Domain Admin backdoor.

Anatomy of an Attack: How SharpSuccessor Works

The open-source utility SharpSuccessor condenses the exploit chain into a few commands. Its developer explicitly warns it is “for authorized security testing only,” but the tool’s very existence erases the skill barrier.

Step 1: Forge a weaponized dMSA
Using SharpSuccessor, an attacker with CreateChild rights over an OU creates a new dMSA that impersonates a high-value target. The command is straightforward:
SharpSuccessor.exe add /impersonate:Administrator /path:“ou=test,dc=lab,dc=lan” /account:jdoe /name:attacker_dMSA

The resulting object looks like a legitimate service account but carries the same Kerberos encryption keys as the Administrator.

Step 2: Grab a Ticket Granting Ticket
Next, the attacker executes a well-known Kerberos delegation trick with Rubeus:
Rubeus.exe tgtdeleg /nowrap
This extracts a forwardable TGT for the machine account, a standard technique in most AD attack playbooks.

Step 3: Bootstrap to the target’s privileges
By requesting a service ticket for the weaponized dMSA and instructing the domain controller to use the dMSA key, the attacker obtains a ticket that impersonates the Administrator:
Rubeus.exe asktgs /targetuser:attacker_dmsa$ /service:krbtgt/lab.lan /opsec /dmsa /nowrap /ptt /ticket:[base64_ticket]

Step 4: Access domain controllers and more
With that ticket, the attacker can now request access to any service the targeted account—Administrator—would have. A common follow-up is retrieving a CIFS ticket for a domain controller, granting full SMB access:
Rubeus.exe asktgs /user:attacker_dmsa$ /service:cifs/[DC_FQDN] /opsec /dmsa /nowrap /ptt

From there, exfiltrating the NTDS.dit file, deploying ransomware, or establishing persistence is trivial. The entire chain requires only the initial CreateChild permission—no privileged account compromise, no credential theft, no lateral movement in the traditional sense.

Why 91% of Environments Are at Risk

Akamai’s research reveals a staggering statistic: in 91% of assessed Active Directory domains, a non-administrative user already holds enough delegated rights to execute BadSuccessor. That includes accounts belonging to service desk technicians, junior IT admins, or even automation service accounts granted OU management rights for routine tasks.

“This isn’t a theoretical corner case,” Gordon wrote in the technical analysis. “The attack leverages permissions that are, by design, widely distributed in most enterprise directories.”

Even organizations that have never knowingly adopted dMSAs remain vulnerable. The attack surface exists as long as at least one domain controller runs Windows Server 2025, because the exploitation path relies on new Kerberos extensions introduced in that release. A single upgraded DC opens the door, even if every other server remains on older builds.

Moreover, the attack blends with normal Kerberos traffic. The ticket requests use the “dMSA” flag—a legitimate parameter—making detection based solely on event logs extremely challenging. Privileged Access Management (PAM) solutions and multi-factor authentication provide no direct protection, as the initial foothold bypasses credential boundaries entirely.

Microsoft’s “Moderate Severity” Rating Draws Fire

Microsoft has officially acknowledged BadSuccessor but classified it as moderate severity, arguing that delegated OU permissions should already be tightly controlled. In a statement, the company advised customers to “limit dMSA creation rights and audit delegated OU permissions” rather than issuing an emergency patch.

That posture has infuriated enterprise admins. “Moderate severity? This is a recipe for disaster,” wrote one senior engineer on WindowsForum.com. “We have hundreds of OUs with delegated creation rights for help desk teams. Auditing and revoking those overnight without breaking business processes is nearly impossible.”

The classification also contrasts sharply with historical precedent. Microsoft has previously patched privilege escalation bugs that required far more difficult preconditions with a higher severity rating. The availability of SharpSuccessor, which automates the entire exploit chain, arguably elevates the risk to critical.

As of publication, no security update exists for Windows Server 2025. Administrators are left with compensating controls that demand rigorous auditing and real-time monitoring—tasks that strain already overburdened security teams.

The New Reality of AD Delegation Risk

BadSuccessor exposes a systemic weakness in Active Directory’s delegation model. For decades, organizations have granted CreateChild, WriteProperty, and similar rights over OUs to streamline operations. The assumption was that these rights, while powerful within their scope, didn’t constitute a domain compromise vector. That assumption is now destroyed.

“Every OU delegation has just become a potential Domain Admin backdoor,” said a cybersecurity consultant speaking at a recent industry conference. “Even a read-only help desk account that can create computer objects in a specific OU is technically a BadSuccessor candidate, if that OU is within the dMSA creation scope.”

The ripple effects extend beyond immediate exploitation. Attackers can use BadSuccessor to establish persistence that survives password rotations and account restructuring. A rogue dMSA with Administrative privileges can be hidden in obscure OUs, triggering alerts only when it’s too late.

How to Defend Yourself (Before Microsoft Acts)

Without a patch, defense hinges on proactive auditing and aggressive permission tightening. Akamai has released a PowerShell script—Get-BadSuccessorOUPermissions.ps—that enumerates every OU where non-administrative users hold CreateChild or WriteProperty rights. Running this immediately is the first step.

Three layers of mitigation stand out:

  • Lock down dMSA creation: Restrict the ability to create dMSA objects to a dedicated, highly privileged group. Normal IT staff should never have this right, regardless of OU delegation patterns. Use Group Policy to enforce these restrictions centrally.
  • Tiered administration: Ensure that all privileged operations—including AD administration—are performed only from hardened, isolated workstations (PAWs). A help desk technician compromised on their daily laptop should never be able to reach AD management tools.
  • Real-time change monitoring: Deploy AD auditing solutions that can alert on new dMSA objects, especially those created in OUs that historically haven’t used managed service accounts. Look for anomalies in the msDS-DelegatedMSAState attribute; suspicious rapid changes should trigger immediate investigation.

Additionally, security teams should emulate the attack in a lab. Running SharpSuccessor against a replica domain validates detection rules and provides visceral understanding of the threat. Red team exercises that simulate BadSuccessor can harden defenses far faster than any policy memo.

Beyond the Patch: A Call for Architectural Change

BadSuccessor isn’t simply a bug to be fixed; it’s a symptom of a deeper design tension. Active Directory’s flexibility—which allowed OU-level delegation to flourish—is also its greatest weakness when new attack surfaces emerge. As Windows Server continues to evolve, security architects must treat every delegation as a potential liability.

The incident reinforces the need for continuous permission auditing, not just during annual reviews. Tools that map effective permissions across the entire directory and visualize escalation paths should become standard issue. Moreover, the conversation about dMSA architecture must extend to Microsoft’s engineering teams: the notion that a CreateChild right can be abused to impersonate a Domain Admin is a design flaw that demands a fundamental rethink of how service accounts handle impersonation.

In the meantime, the clock is ticking. SharpSuccessor is out in the wild. Attackers don’t wait for convenient patching windows. Enterprises that don’t audit their OU delegations today may find themselves tomorrow’s cautionary tale.