The delegated Managed Service Account (dMSA) feature, introduced in Windows Server 2025, was designed as a secure alternative to legacy service accounts, aiming to mitigate credential attacks such as Kerberoasting. However, a recent discovery by Akamai researcher Yuval Gordon has unveiled a significant privilege escalation vulnerability within the dMSA framework. This flaw could enable an attacker to compromise any user within an Active Directory (AD) environment.
In a detailed blog post, Gordon elaborated on the mechanics of the dMSA attack, which operates effectively under default configurations and possesses low complexity, making it a potential threat for a vast majority of organizations utilizing Active Directory. “In 91% of the environments we examined, we found users outside the domain admins group that had the required permissions to perform this attack,” he noted.
Gordon emphasized the alarming simplicity of the exploit: “By abusing dMSAs, attackers can take over any principal in the domain. 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.” He further explained that the attack is viable by default, as the mere presence of the dMSA feature in any domain with at least one Windows Server 2025 domain controller makes it accessible.
Active Directory dMSA Attack Detailed
The blog post meticulously outlines the dMSA migration process, highlighting a pivotal moment in the attack’s development. Gordon sought a workaround for the limitation that restricts account migration to Domain Admins. He simulated a migration by modifying two attributes on the dMSA object:
- Writing the target account’s Distinguished Name (DN) to msDS-ManagedAccountPrecededByLink
- Setting msDS-DelegatedMSAState to value 2 (indicating migration completion)
This manipulation granted Gordon 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,” he stated. “The only requirement is write permissions over the attributes of a dMSA. Any dMSA.”
Once a dMSA is marked as preceded by a user, the Key Distribution Center (KDC) automatically assumes a legitimate migration has occurred, thereby granting the dMSA every permission that the original user possessed. This technique, dubbed “BadSuccessor,” can be executed on any user, including those with high privileges 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.”
Gordon pointed out that a more accessible scenario for attackers might involve creating a new dMSA. When a user generates an object in AD, they have full permissions over all its attributes. “Therefore, if an attacker can create a new dMSA, they can compromise the entire domain,” he cautioned.
Importantly, dMSAs are not confined to the Managed Service Accounts container; they can be established in any standard organizational unit (OU). Gordon identified an OU where he had privileges, named “temp,” and granted himself “weak” permissions to create child objects. He then modified 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 remarked. “We were unable to find any configuration that would prevent an account from being used as a superseded target.”
Additionally, the researchers accessed credentials through a new structure called KERB-DMSA-KEY-PACKAGE, which includes fields for current and previous keys. During the request for a Ticket Granting Ticket (TGT) for a new dMSA, Gordon discovered that the previous-keys field was not empty; it contained the key corresponding to the password of his target account during the demonstration. “The msDS-ManagedAccountPrecededByLink doesn’t just link the dMSA to the superseded account for permission purposes; it also allows the dMSA to inherit its keys,” he explained. “This means that this attack can also be used to obtain the keys of any (or every) user and computer in the domain.”
Microsoft’s Response
Akamai reported that Microsoft has acknowledged the vulnerability and confirmed its validity, although it has categorized it as a Moderate severity issue that does not warrant immediate servicing. “While we appreciate Microsoft’s response, we respectfully disagree with the severity assessment,” Gordon stated. “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.”
In the interim, until a patch is released by Microsoft, Akamai advises organizations to limit the ability to create dMSAs and tighten permissions wherever feasible. To assist with this, Akamai has developed a PowerShell script. “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.
Related
Media Disclaimer: This report is based on internal and external research obtained through various means. The information provided is for reference purposes only, and users bear full responsibility for their reliance on it. The Cyber Express assumes no liability for the accuracy or consequences of using this information.
