A critical vulnerability has recently been discovered in Windows Server 2025 that could allow attackers to take control of any account within Active Directory (AD).
According to a security researcher at Akamai, the issue is related to a new feature called delegated Managed Service Accounts (dMSA). This feature, introduced with Windows Server 2025, is enabled by default and remarkably easy to exploit.
In simple terms, this flaw allows a non-privileged user to abuse the dMSA mechanism to escalate permissions and compromise the entire directory. Alarmingly, this is not an isolated scenario: the Akamai team found that in 91% of the environments they analyzed, there was at least one non-administrative user with the necessary permissions to launch this type of attack.
What’s especially striking is that the attack leverages a feature that was ironically designed to improve security. dMSAs are intended to replace outdated and vulnerable service accounts as a defense against known attack methods like Kerberoasting. However, this security tool has instead opened a new door for attackers.
The security team has named this technique “BadSuccessor”, referring to the fact that this new feature—meant to succeed traditional service accounts—has turned out to be a problematic successor.
According to Microsoft’s own documentation, dMSAs can either be created as new accounts or used to replace existing service accounts. When a dMSA replaces an old account, it blocks authentication using the previous password and redirects the entire authentication process through the Local Security Authority (LSA).
The most concerning aspect is that during this migration process, the dMSA automatically detects which devices the old account was used on. This means it fully inherits previous access and permissions in Active Directory, making it easier for attackers to abuse the system if they manage to manipulate the process.
Read more: Edit on Windows: New Command Line Text Editor
How a Simulated Migration with dMSA Can Grant Full Domain Access
The core issue lies in how Kerberos authentication behaves when using a dMSA (delegated Managed Service Account). During this process, the Privilege Attribute Certificate (PAC) embedded in the Kerberos ticket—which serves as proof of identity—not only contains the Security Identifier (SID) of the dMSA, but also includes the SID of the original service account being replaced... along with all the SIDs of its associated groups.
What does that mean?
It means that when someone simulates a service account migration using a dMSA, they can inherit all the permissions of the original account—even if that account belonged to a domain administrator. What’s more troubling is that this trick can be used even in environments where dMSA is not actively deployed. The mere presence of the functionality, if misconfigured, is enough to pose a risk.
A particularly alarming detail is that attackers don’t need control over the original account to carry out this attack. The only requirement is permission to modify specific attributes on any dMSA. In other words, if a user has that access in just one Organizational Unit (OU), they have a foothold.
Once a dMSA is marked as the successor of another user, the Domain Controller (KDC) assumes a legitimate migration has occurred and automatically grants the dMSA all the privileges of the predecessor account. It’s as if the system says: “Oh, you're the new one in charge—here are the keys to the house.”
Microsoft’s Response and Risk Classification
Although this issue was reported to Microsoft on April 1, 2025, the company has classified it as a moderate-severity issue and has not yet released an immediate fix. Their reasoning is that exploiting this vulnerability requires specific permissions on dMSA objects, making it a privilege escalation vector rather than a direct entry point. Nonetheless, a fix is said to be in development.
Mitigation Steps
Since no official patch is available yet, the best temporary mitigation is to limit the ability to create dMSAs as much as possible. Additional recommendations include:
-
Auditing and hardening permissions on Organizational Units (OUs), especially those related to account creation and management.
-
Identifying users with CreateChild permissions in OUs to prevent unauthorized dMSA creation.
A PowerShell script has also been shared to help administrators identify who can create dMSAs and in which OUs this capability exists. This is a critical step to take before a malicious actor does.