Full Report
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.
Analysis Summary
# Vulnerability: Active Directory Delegated Managed Service Account (dMSA) Key Inheritance Abuse
## CVE Details
- CVE ID: **Not explicitly provided in the text.** (This research appears to detail a newly disclosed technique that may not have an assigned CVE at the time of reporting.)
- CVSS Score: **Not explicitly provided in the text.**
- CWE: Not explicitly provided, but relates to improper access control or insecure configuration management.
## Affected Systems
- Products: Microsoft Active Directory (Focusing on Delegated Managed Service Accounts (dMSA) functionality).
- Versions: Not explicitly detailed, but relates to any version supporting dMSA functionality where the `msDS-ManagedAccountPrecededByLink` attribute behavior is present.
- Configurations: Environments where an attacker has at least **CreateChild permissions on an Organizational Unit (OU)** that allows the creation of dMSAs.
## Vulnerability Description
Researchers discovered that when creating a new dMSA linked to a superseded account (via synchronization or migration), the new dMSA inherits encryption keys belonging to the prior account through the `msDS-ManagedAccountPrecededByLink` attribute. Specifically, the `msDS-ManagedAccountPrecededByLink` field, when present in the `KEY-PACKAGE`, allows the dMSA to inherit the `previous-keys`. This inherited key corresponds to the password used by the target account during the demonstration/migration process. This unintended key inheritance effectively allows an attacker with limited permissions (CreateChild on an OU) to gain access to the keys of **any or every user and computer in the domain**, mimicking the capability of a DCSync attack.
## Exploitation
- Status: **PoC available** (Research and demonstration performed by Akamai researchers).
- Complexity: **Low/Medium** (Requires specific permissions—CreateChild on an OU—but the key inheritance mechanism appears to be a systematic oversight).
- Attack Vector: **Network** (If the attacker can interact with AD to execute the dMSA provisioning/linking).
## Impact
- Confidentiality: **High** (Ability to compromise domain credentials/keys allows access to sensitive information).
- Integrity: **High** (Ability to impersonate domain users/machines).
- Availability: **Medium/High** (Successful compromise can lead to widespread service disruption or system takeover).
## Remediation
### Patches
- **None explicitly listed.** Microsoft has acknowledged the issue but rated it Moderate severity, suggesting an immediate patch is not yet scheduled or released at the time of this reporting.
### Workarounds
1. **Limit `CreateChild` Permissions:** Restrict the ability to create dMSAs by strictly auditing and tightening permissions on Organizational Units (OUs). The vulnerability hinges on an attacker possessing the `CreateChild` permission on an OU.
2. **Monitoring and Auditing:** Closely monitor the creation and configuration of dMSAs and any unusual key inheritance patterns.
3. **Apply PowerShell Script:** Akamai provided a PowerShell script to help administrators manage and tighten permissions related to dMSA creation (Specific details on the script's function are implied but not detailed here).
## Detection
- **Indicators of Compromise:** Look for unusual inheritance of key material associated with new or linked dMSAs, specifically checking the `KEY-PACKAGE` structure linked via `msDS-ManagedAccountPrecededByLink`.
- **Detection Methods and Tools:** Implement stringent auditing of permissions granting `CreateChild` rights within Active Directory in relation to OUs that host DMSA objects. Leverage AD auditing tools to watch for suspicious privilege escalation activities mimicking DCSync post-dMSA creation.
## References
- Vendor advisory: Microsoft acknowledged the validity of the finding.
- Research Source: Akamai research detailed the technique.
- Relevant links:
- https://thecyberexpress.com/active-directory-dmsa-attack/