Critical Windows Server 2025 dMSA Vulnerability Enables Active Directory Compromise
Summary:
Akamai researcher Yuval Gordon discovered a privilege escalation vulnerability in Windows Server 2025 that exploits the delegated Managed Service Account feature, allowing attackers to impersonate any user in the Active Directory domain, including highly privileged accounts such as Domain Admins. The vulnerability arises from a design flaw in the dMSA migration process, which is intended to facilitate seamless transitions from legacy service accounts by copying over their permissions and configurations. This mechanism can be abused through a technique Akamai calls BadSuccessor, which relies on setting two attributes on a dMSA object: msDS-ManagedAccountPrecededByLink, which points to the distinguished name of the target user or computer, and msDS-DelegatedMSAState, which is set to simulate a completed migration.
Once these attributes are modified, the Kerberos Key Distribution Center treats the dMSA as the legitimate successor of the target account. The dMSA's Privilege Attribute Certificate is then constructed to include the Security Identifiers and group memberships of the superseded account, allowing the attacker to assume their full privileges. This process occurs without requiring direct access to the original account and without generating typical audit artifacts such as group membership changes or suspicious LDAP writes.
The attack is particularly concerning because it does not require the victim environment to be actively using dMSAs. As long as at least one Windows Server 2025 domain controller exists, the dMSA feature, and by extension, the vulnerability is available. Moreover, attackers do not need pre-existing high privileges. Any user with CreateChild rights on an Organizational Unit, a common and often under-monitored permission, can create a dMSA and fully control its attributes, including those necessary for the attack. The attack works regardless of the sensitivity or privilege level of the target account, including accounts marked as non-delegable or part of Protected Users groups.
Security Officer Comments:
Beyond privilege escalation, this flaw also enables credential compromise. During dMSA authentication, the KDC issues a KERB-DMSA-KEY-PACKAGE structure that includes both current and previous encryption keys. Akamai observed that these “previous keys” can include the RC4-HMAC key of the superseded account, even if that account was never intended to be linked. This stems from the KDC’s attempt to maintain service continuity during legitimate migrations, but in the context of BadSuccessor, it allows an attacker to extract password hashes for any user or computer and reuse them for authentication.
Suggested Corrections:
Until a formal patch is released by Microsoft, defensive efforts should focus on limiting the ability to create dMSAs and tightening permissions wherever possible.
Defenders should identify all principals (users, groups, computers) with permissions to create dMSAs across the domain and limit that permission to trusted administrators only.
To assist with this, Akamai has published a PowerShell script that:
Link(s):
https://thehackernews.com/2025/05/critical-windows-server-2025-dmsa.htm
Akamai researcher Yuval Gordon discovered a privilege escalation vulnerability in Windows Server 2025 that exploits the delegated Managed Service Account feature, allowing attackers to impersonate any user in the Active Directory domain, including highly privileged accounts such as Domain Admins. The vulnerability arises from a design flaw in the dMSA migration process, which is intended to facilitate seamless transitions from legacy service accounts by copying over their permissions and configurations. This mechanism can be abused through a technique Akamai calls BadSuccessor, which relies on setting two attributes on a dMSA object: msDS-ManagedAccountPrecededByLink, which points to the distinguished name of the target user or computer, and msDS-DelegatedMSAState, which is set to simulate a completed migration.
Once these attributes are modified, the Kerberos Key Distribution Center treats the dMSA as the legitimate successor of the target account. The dMSA's Privilege Attribute Certificate is then constructed to include the Security Identifiers and group memberships of the superseded account, allowing the attacker to assume their full privileges. This process occurs without requiring direct access to the original account and without generating typical audit artifacts such as group membership changes or suspicious LDAP writes.
The attack is particularly concerning because it does not require the victim environment to be actively using dMSAs. As long as at least one Windows Server 2025 domain controller exists, the dMSA feature, and by extension, the vulnerability is available. Moreover, attackers do not need pre-existing high privileges. Any user with CreateChild rights on an Organizational Unit, a common and often under-monitored permission, can create a dMSA and fully control its attributes, including those necessary for the attack. The attack works regardless of the sensitivity or privilege level of the target account, including accounts marked as non-delegable or part of Protected Users groups.
Security Officer Comments:
Beyond privilege escalation, this flaw also enables credential compromise. During dMSA authentication, the KDC issues a KERB-DMSA-KEY-PACKAGE structure that includes both current and previous encryption keys. Akamai observed that these “previous keys” can include the RC4-HMAC key of the superseded account, even if that account was never intended to be linked. This stems from the KDC’s attempt to maintain service continuity during legitimate migrations, but in the context of BadSuccessor, it allows an attacker to extract password hashes for any user or computer and reuse them for authentication.
Suggested Corrections:
Until a formal patch is released by Microsoft, defensive efforts should focus on limiting the ability to create dMSAs and tightening permissions wherever possible.
Defenders should identify all principals (users, groups, computers) with permissions to create dMSAs across the domain and limit that permission to trusted administrators only.
To assist with this, Akamai has published a PowerShell script that:
- Enumerates all nondefault principals who can create dMSAs
- Lists the OUs in which each principal has this permission
Link(s):
https://thehackernews.com/2025/05/critical-windows-server-2025-dmsa.htm