{"id":3271,"date":"2025-05-21T17:26:49","date_gmt":"2025-05-21T17:26:49","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=3271"},"modified":"2025-05-21T17:26:49","modified_gmt":"2025-05-21T17:26:49","slug":"badsuccessor-unpatched-microsoft-active-directory-attack-enables-domain-takeover","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=3271","title":{"rendered":"BadSuccessor: Unpatched Microsoft Active Directory attack enables domain takeover"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

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.<\/p>\n

\u201cThis issue likely affects most organizations that rely on AD,\u201d Akamai researcher Yuval Gordon wrote in a report released today<\/a>. \u201cIn 91% of the environments we examined, we found users outside the domain admins group that had the required permissions to perform this attack.\u201d<\/p>\n

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

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.<\/p>\n

\u201cThis 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,\u201d the Akamai researchers wrote.<\/p>\n

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<\/a>. Akamai\u2019s researchers disagree with Microsoft\u2019s assessment because no standard industry practices or tools treat this permission as the critical concern this new attack vector makes it to be.<\/p>\n

Incomplete dMSA migration tricks AD\u2019s Key Distribution Center<\/h2>\n

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.<\/p>\n

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<\/a> have come under increased scrutiny of late as security issues that cyber teams and vendors need to address<\/a>.<\/p>\n

\u201cDMSA allows migration from traditional service accounts to machine accounts with managed and fully randomized keys, while disabling original service account passwords,\u201d Microsoft\u2019s documentation reads.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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

Akamai\u2019s 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.<\/p>\n

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\u2019t \u2014 as outlined below.<\/p>\n

\u201cThis technique, which we dubbed \u2018BadSuccessor,\u2019 works on any user, including Domain Admins,\u201d the Akamai researchers wrote. \u201cIt allows any user who controls a dMSA object to control the entire domain. That\u2019s all it takes. No actual migration. No verification. No oversight.\u201d<\/p>\n

How to abuse dMSAs even in environments that don\u2019t have them<\/h2>\n

Akamai\u2019s researchers warn that organizations that haven\u2019t 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

They can then edit the dMSA\u2019s 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\u2019t. 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.<\/p>\n

\u201cWith just two attribute changes, a humble new object is crowned the successor \u2014 and the KDC never questions the bloodline; if the link is there, the privileges are granted,\u201d the Akamai researchers conclude. \u201cWe didn\u2019t change a single group membership, didn\u2019t elevate any existing account, and didn\u2019t trip any traditional privilege escalation alerts.\u201d<\/p>\n

Extracting credentials is also possible<\/h2>\n

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

Since a dMSA is new it shouldn\u2019t have \u201cprevious keys,\u201d meaning previous passwords that were encrypted, but it does, and that\u2019s 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\u2019s migration to dMSA, remain functional and do not cause disruptions.<\/p>\n

However, this also enables BadSuccessor to be used to obtain the keys for potentially every user and computer in the domain.<\/p>\n

Mitigation<\/h2>\n

\u201cAlthough Microsoft states they plan to fix this issue in the future, a patch is not currently available,\u201d the Akamai researchers said. \u201cTherefore, organizations need to take other proactive measures to reduce their exposure to this attack.\u201d<\/p>\n

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.<\/p>\n

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.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

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. \u201cThis issue likely affects most organizations that rely on AD,\u201d Akamai researcher Yuval Gordon wrote in a […]<\/p>\n","protected":false},"author":0,"featured_media":3272,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-3271","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/3271"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3271"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/3271\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/3272"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3271"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3271"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3271"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}