One Second and You're a Domain Admin. Why Microsoft Can't Protect Its Own Windows Server
Microsoft released a patch that fixed nothing.
Microsoft released a patch that fixed nothing.
At the DEF CON 2025 conference, experts from Akamai presented research on a critical vulnerability in Windows Server 2025 dubbed BadSuccessor (CVE-2025-53779). This vulnerability allows low-privileged users to instantly escalate their privileges to Domain Admin.
The issue was rooted in the mechanism for handling a new type of account—delegated Managed Service Accounts (dMSA). The vulnerability allowed an attacker to link a controlled dMSA to any account in Active Directory, including protected and highly privileged ones. Subsequently, the Key Distribution Center (KDC) service would perceive the dMSA as the "successor" to the target account, including its privileges in the PAC (Privilege Attribute Certificate) and handing over Kerberos keys.
A particularly dangerous aspect was that exploitation only required control over any Organizational Unit (OU) in the domain. An attacker could create a dMSA in such an OU and establish a link to the target account without using any third-party tools or modifying group policies. The KDC would fully accept this configuration without validating the legitimacy of the link.
A few days after Akamai's disclosure, Microsoft assigned the vulnerability the identifier CVE-2025-53779 and released a patch. The update did not block the link attribute itself but made changes to the kdcsvc.dll component, causing the KDC service to start verifying the reciprocity of the link between the dMSA and the target account. Now, to obtain a Kerberos ticket, the dMSA and its "predecessor" must reference each other, as happens during a genuine account migration via migrateADServiceAccount. The one-way binding that previously allowed for instant privilege escalation no longer works. However, as the researchers discovered, this does not mean the method has been completely neutralized.
Despite eliminating the direct escalation path, the BadSuccessor technique remains dangerous because the core of the vulnerability—the lack of control over the link attribute—is still present. This allows BadSuccessor to be used in two new scenarios that are of interest to attackers and pose a threat to defended infrastructure.
The first scenario is the theft of privileges and credentials (an alternative to "shadow" credentials). If an attacker already has control over both a dMSA and a target account, they can link them together, obtain a Kerberos ticket for the dMSA, and thereby act on behalf of the victim while using a different entity. This method avoids suspicious activity from the compromised account and helps evade monitoring systems. Furthermore, Kerberos keys are extracted faster and with less effort than in Kerberoasting attacks, as there's no need to add SPNs or brute-force passwords.
The second scenario is an alternative to DCSync for extracting keys in already compromised domains. In such conditions, an attacker can use a dMSA to obtain tickets with the keys of any accounts without sending replication requests to the Domain Controller. This lowers the probability of detection, as standard DCSync signatures do not trigger on this approach.
To detect potential BadSuccessor usage after installing the patch, it is recommended to enable auditing of changes to dMSA attributes and monitor events related to dMSA password retrieval or anomalous linking of active users to dMSAs. Situations where a previously disabled account is suddenly linked to a new dMSA, as well as repeated requests for a dMSA password over a short period, are considered suspicious.
Protective measures include installing the patch for CVE-2025-53779 on all Windows Server 2025 domain controllers, as well as reviewing and restricting access rights to OUs, containers, and dMSA objects. Only Tier 0 administrators should have the ability to manage dMSAs and their migration attributes.
Experts emphasize that the BadSuccessor problem is not just a flaw but a vulnerable architectural technique that may remain relevant even after a specific exploit is patched. As with many other AD vulnerabilities, closing one loophole does not mean attackers won't find another path based on the same mechanisms.