The delegated Managed Service Account (dMSA) feature was introduced in Windows Server 2025 as a secure replacement for legacy service accounts and to prevent credential attacks like Kerberoasting, but an Akamai researcher discovered a privilege escalation vulnerability in dMSA that could allow an attacker to compromise any user in Active Directory (AD).
In a blog post published today, Akamai researcher Yuval Gordon detailed a dMSA attack that works with default configurations, has low attack complexity, and could affect most organizations that use Active Directory (AD).
“In 91% of the environments we examined, we found users outside the domain admins group that had the required permissions to perform this attack,” Gordon wrote.
“By abusing dMSAs, attackers can take over any principal in the domain,” the researcher said. “All an attacker needs to perform this attack is a benign permission on any organizational unit (OU) in the domain — a permission that often flies under the radar. And the best part: The attack works by default — your domain doesn’t need to use dMSAs at all. As long as the feature exists, which it does in any domain with at least one Windows Server 2025 domain controller (DC), it becomes available.”
Microsoft plans to fix the issue, but no patch is currently available.
Active Directory dMSA Attack Detailed
The blog post goes into great detail on the dMSA migration process, but a key point in the attack development came when the researcher was looking for a way around the limitation that account migration is restricted to Domain Admins, so he simulated a migration by setting two attributes on the dMSA object:
- Write the target account’s Distinguished Name (DN) to msDS-ManagedAccountPrecededByLink
- Set msDS-DelegatedMSAState to value 2 (migration completed)
The effect of those changes was to grant the researcher the full permissions of the superseded account.
“One interesting fact about this ‘simulated migration’ technique, is that it doesn’t require any permissions over the superseded account,” Gordon said. “The only requirement is write permissions over the attributes of a dMSA. Any dMSA.”
Once a dMSA has been marked as preceded by a user, the Key Distribution Center (KDC) “automatically assumes a legitimate migration took place and happily grants our dMSA every single permission that the original user had, as though we are its rightful successor.”
That attack technique, which the researcher named “BadSuccessor,” works on any user, including high-privileged accounts like Domain Admins. “It allows any user who controls a dMSA object to control the entire domain. That’s all it takes. No actual migration. No verification. No oversight.”
One scenario more likely to be available to attackers is to create a new dMSA. When a user creates an object in AD, they have full permissions over all of its attributes, Gordon said: “Therefore, if an attacker can create a new dMSA, they can compromise the entire domain.”
dMSAs are not restricted to the Managed Service Accounts container and can be created in any normal organizational unit (OU). The researcher located an OU on which he had privileges – an OU called “temp” in the example environment – and gave the unprivileged user “weak” permissions to create child objects using the path argument in the accessible OU.
The researcher then granted write access on the two attributes used in the attack, setting msDS-ManagedAccountPrecededByLink to any user or computer’s DN and msDS-DelegatedMSAState to “2” to simulate a completed migration.
“this attack seems to work on all accounts in AD”
Gordon said “this attack seems to work on all accounts in AD. We were unable to find any configuration that would prevent an account from being used as a superseded target.”
They were also able to access credentials with a new structure called KERB-DMSA-KEY-PACKAGE, which includes two fields: current-keys and previous-keys.
When requesting a Ticket Granting Ticket (TGT) for a new dMSA, the researcher found the previous-keys field wasn’t empty. It contained the key corresponding to the password used for his target account during the demo.
“The msDS-ManagedAccountPrecededByLink doesn’t just link the dMSA to the superseded account for permission purposes, it also lets the dMSA inherit its keys,” Gordon said. “This means that this attack can also be used to get the keys of any (or every) user and computer in the domain… Although we have not analyzed the entire implementation, our theory is that this behavior exists to ensure seamless continuity during account migration for the end user’s benefit.”
Microsoft’s Response
Akamai said Microsoft has acknowledged the issue and confirmed its validity, but rated it a Moderate severity vulnerability that doesn’t meet the threshold for immediate servicing.
“While we appreciate Microsoft’s response, we respectfully disagree with the severity assessment,” Gordon wrote. “This vulnerability introduces a previously unknown and high-impact abuse path that makes it possible for any user with CreateChild permissions on an OU to compromise any user in the domain and gain similar power to the Replicating Directory Changes privilege used to perform DCSync attacks.”
Until a patch is released by Microsoft, Akamai recommends limiting the ability to create dMSAs and tightening permissions wherever possible. Akamai created a PowerShell script to help with that.
“This research highlights how even narrowly scoped permissions, often assumed to be low risk, can have far-reaching consequences in Active Directory environments,” Gordon concluded.
