BadSuccessor: Unpatched Microsoft Active Directory attack enables domain takeover – Source: www.csoonline.com

Researchers have discovered a new attack path in Active Directory (AD) environments that use Windows Server 2025 in default configuration. By exploiting the weakness, attackers can compromise any user in the environment leading to a full domain compromise.

“This issue likely affects most organizations that rely on AD,” Akamai researcher Yuval Gordon wrote in a report released today. “In 91% of the environments we examined, we found users outside the domain admins group that had the required permissions to perform this attack.”

The attack takes advantage of a new feature called Delegated Managed Service Accounts (dMSA) that was introduced in Windows Server 2025 as a mitigation to Kerberoasting attacks in which attackers extract hashed service account credentials from AD environments and then perform offline cracking to obtain the plaintext passwords.

The problem Gordon and his team have discovered is that the permission inheritance for dMSA accounts from superseded service accounts was implemented in a way that allows seamless migration and use of previously issued tickets without performing strong enough validation. This opens the possibility for successfully impersonating any user, including domain admins.

“This vulnerability introduces a previously unknown and high-impact abuse path that makes it possible for any user with CreateChild permissions on an OU [organizational unit] to compromise any user in the domain and gain similar power to the Replicating Directory Changes privilege used to perform DCSync attacks,” the Akamai researchers wrote.

Microsoft has acknowledged the issue, but the company rated it at moderate severity and not urgent enough to address with an immediate patch, stating that the risks related to the CreateChild permission had already been documented. Akamai’s researchers disagree with Microsoft’s assessment because no standard industry practices or tools treat this permission as the critical concern this new attack vector makes it to be.

Incomplete dMSA migration tricks AD’s Key Distribution Center

When a dMSA account is created, it inherits the permissions of the service account it replaces. This process, called a migration, involves several steps that update attributes on the dMSA object to indicate which account it supersedes.

The whole point of dMSA is to create accounts that are more secure than traditional service accounts, which are non-human accounts created in AD to be used by applications and services. Such non-human identities have come under increased scrutiny of late as security issues that cyber teams and vendors need to address.

“DMSA allows migration from traditional service accounts to machine accounts with managed and fully randomized keys, while disabling original service account passwords,” Microsoft’s documentation reads.

Some relevant attributes on a dMSA account are msDS-DelegatedMSAState, which indicates whether the migration process is unknown, in progress, or completed; msDS-ManagedAccountPrecededByLink, which indicates the superseded account; and msDS-GroupMSAMembership, which indicates which principals (users, groups, and computers) can authenticate as the account.

Once migration to a dMSA account is complete, any machine that authenticates as the superseded service account will receive from Domain Controller an error indicating that the old account was disabled, along with a KERB-SUPERSEDED-BY-USER field to indicate the dMSA that replaced it. The machine will then retry authentication as the dMSA to obtain an authenticated session ticket that allows them to perform the action.

This is where the Key Distribution Center (KDC) comes into play. In the Kerberos protocol, which AD uses, the KDC ensures secure access to network resources by verifying user identities, granting them access based on their permissions.

Akamai’s researchers noticed that when the KDC generates the Privilege Attribute Certificate (PAC) for the dMSA account it includes the SIDs of the superseded service account and its associated groups, essentially granting the account all the permissions of the replaced account. This is done solely by checking the ManagedAccountPrecededByLink attribute for the superseded account and ascertaining whether the msDS-DelegatedMSAState attribute is set to 2, indicating that migration completed.

The problem? Both these attributes can be arbitrarily modified by an unprivileged user account on any dMSA account they create, meaning that the KDC can be tricked into verifying that a migration for any arbitrary service account has been completed, even if it hasn’t — as outlined below.

“This technique, which we dubbed ‘BadSuccessor,’ works on any user, including Domain Admins,” the Akamai researchers wrote. “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.”

How to abuse dMSAs even in environments that don’t have them

Akamai’s researchers warn that organizations that haven’t created any dMSAs in their AD environments are also not safe because, in addition to being able to abuse an existing dMSA, an attacker can also create one if none exists.

To do this, all they need is access to an unprivileged user with CreateChild permissions in an OU, which allows them to create objects within the OU. According to Akamai, this a common configuration that is viewed as benign and therefore not likely to be monitored or hardened.

By default, dMSA accounts are stored in the Managed Service Accounts (MSA) container, but they can also be created inside OUs by using the path argument. As a result, an unprivileged user with CreateChild permissions in an OU can create a new dMSA, then grant itself write permissions to its attributes since they have ownership.

They can then edit the dMSA’s ManagedAccountPrecededByLink attribute to indicate any account they want to inherit permissions from, like a domain admin, as well as the msDS-DelegatedMSAState to indicate that migration has completed, even if it hasn’t. The last step ensures that authentication on the KDC will result in a PAC and session ticket with all the privileges of the superseded account.

“With just two attribute changes, a humble new object is crowned the successor — and the KDC never questions the bloodline; if the link is there, the privileges are granted,” the Akamai researchers conclude. “We didn’t change a single group membership, didn’t elevate any existing account, and didn’t trip any traditional privilege escalation alerts.”

But it gets worse than just obtaining a session ticket with the targeted account’s privileges. Attackers can also get that account’s encrypted passwords because they are included in the KERB-DMSA-KEYPACKAGE structure as part of the issued ticket in a field called previous-keys.

Since a dMSA is new it shouldn’t have “previous keys,” meaning previous passwords that were encrypted, but it does, and that’s because it also inherits the keys of the superseded account. This is likely done so that session tickets issued in the past, prior to a service account’s migration to dMSA, remain functional and do not cause disruptions.

However, this also enables BadSuccessor to be used to obtain the keys for potentially every user and computer in the domain.

Mitigation

“Although Microsoft states they plan to fix this issue in the future, a patch is not currently available,” the Akamai researchers said. “Therefore, organizations need to take other proactive measures to reduce their exposure to this attack.”

Akamai has created a PowerShell script that enables security teams to identify which principals are allowed to create dMSAs and in which OUs they have access. The researchers advise that this permission should be limited to trusted administrators until Microsoft provides a patch.

The report also includes System Access Control Lists (SACLs) that can be used to log and monitor the creation of new msDSDelegatedManagedServiceAccount objects, modifications to the msDSManagedAccountPrecededByLink attribute and TGTs generated for a dMSA that includes the KERBDMSA-KEY-PACKAGE structure.