BadSuccessor
BadSuccessor?
Recent security research at Akamai revealed a critical vulnerability in Windows Server 2025 known as BadSuccessor. Any Active Directory environment with at least one Windows Server 2025 Domain Controller may be affected. This issue enables a low‑privileged attacker to obtain Domain Admin–level privileges without modifying privileged accounts or triggering typical security alerts.
The vulnerability stems from abuse of the Delegated Managed Service Account (dMSA) migration mechanism. An attacker who can create and control a dMSA can manually configure the msDS-ManagedAccountPrecededByLink attribute to reference a highly privileged account (such as Administrator) and set msDS-DelegatedMSAState to 2. When authentication occurs, the Key Distribution Center (KDC) incorrectly processes this migration relationship and inserts the referenced account’s SID into the Kerberos PAC.
The Kerberos PAC (Privilege Attribute Certificate) is the authorization data embedded within a Kerberos ticket. It contains the identity and privilege information that Windows services rely on to determine what the authenticated principal is allowed to access, including security identifiers (SIDs) and group memberships. Services typically trust the PAC contents without performing a fresh authorization lookup in Active Directory. In this vulnerability, the KDC constructs the PAC using the privileged account referenced in the migration attribute rather than the actual authenticating identity. As a result, the issued ticket carries the security context of the privileged account, causing services to treat the attacker‑controlled dMSA as that account and enabling effective privilege escalation.
The only prerequisite for exploitation is the ability to create child objects within an Organizational Unit (OU), allowing the attacker to create and manage a dMSA.
You can read the full technical blog from Akamai.
Introduction
Over the past few days, I explored the BadSuccessor attack through vulnerable environments. After extensive research and experimentation, I identified multiple practical exploitation paths. This article documents those approaches and explains how they can be leveraged in real attack scenarios.
Below are three different ways to exploit this vulnerability.
Method 1 — Normal Way
This method uses an existing domain user account that has permission to create dMSAs in an OU.
Setup
Request Tickets Using Rubeus
You can later use that ticket to perform DCSync with mimikatz or secretsdump.py
Method 2 — Machine Way
You also use a newly created computer account to request the dMSA TGT. This is possible when MachineAccountQuota > 0.
Setup
Request Tickets (Rubeus)
Method 3 — Previous Way
When you request a TGT for a dMSA, the KDC also issues a KERB-DMSA-KEY-PACKAGE structure. This structure contains current-keys (the dMSA's keys) and previous-keys (the superseded account's NTLM hash which is in our case the Administrator hash). This allows you to extract the hash of any account in the domain.
Option A: Using Rubeus #PR 204
Unfortunately, the developers of Rubeus are not giving the tool sufficient attention; as there is an open pull request #204 on Rubeus repoistory since May 2025, if you use the updated Rubeus PR, it automatically parses the previous keys from the ticket.
Option B: Rubeus without #PR 204
You can use standard Rubeus with debug flag to get the base64 output of the KDC reply that contains KERB-DMSA-KEY-PACKAGE:
The output will be messy, search for TGS request successful and copy the base64 under it.
go to an ASN.1 decoder like https://lapo.it/asn1js
You will see many hashes, which are current keys and previous keys, the last one is the previous key which is the Admin hash
Option C: Dumping the Entire Domain via dMSASync.py
You can use this script to automate this to loop through every user and computer, set them as the predecessor, and extract their previous-keys.
Setup & Execution:
Last updated