{"id":6685,"date":"2025-05-27T16:47:40","date_gmt":"2025-05-27T21:47:40","guid":{"rendered":"https:\/\/cyberassurancenow.com\/?p=6685"},"modified":"2025-06-25T12:17:50","modified_gmt":"2025-06-25T17:17:50","slug":"badsuccessor-the-default-privilege-escalation-in-windows-server-2025-you-should-be-scared-of","status":"publish","type":"post","link":"https:\/\/cyberassurancenow.com\/index.php\/2025\/05\/27\/badsuccessor-the-default-privilege-escalation-in-windows-server-2025-you-should-be-scared-of\/","title":{"rendered":"BadSuccessor: Default Privilege Risk in Server 2025"},"content":{"rendered":"

[vc_row][vc_column][vc_column_text css=””]<\/p>\n

The Default Privilege Escalation in Windows Server 2025 You Should Be Scared Of<\/h3>\n

[\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]Imagine giving someone the keys to your house just because they said they were the new owner. That\u2019s essentially what Windows Server 2025 is doing \u2014 and it\u2019s called BadSuccessor.[\/vc_column_text][vc_empty_space height=”40px”][vc_column_text css=””]<\/p>\n

Summary<\/h4>\n

[\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]BadSuccessor is a newly discovered privilege escalation vulnerability in Windows Server 2025 that allows attackers to fully impersonate any Active Directory user \u2014 including Domain Admins \u2014 without modifying the original account. It exploits a misdesign in the dMSA (delegated Managed Service Account) feature and works in default configurations.[\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]Impact:<\/strong> Total domain compromise
\nComplexity:<\/strong> Low
\nAffected:<\/strong> Likely most orgs (91% in tested environments)
\nPatch:<\/strong> Not yet available[\/vc_column_text][vc_empty_space height=”40px”][vc_column_text css=””]<\/p>\n

Where It All Began: dMSA and the Idea of Migration<\/h4>\n

[\/vc_column_text][vc_column_text css=””]Windows Server 2025 introduced delegated Managed Service Accounts to ease migration pains. When a dMSA replaces a legacy service account, it should inherit everything \u2014 permissions, SPNs, delegations, group memberships \u2014 to act like a seamless successor.[\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]This inheritance relies on one key attribute:
\nmsDS-ManagedAccountPrecededByLink[\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]When this attribute is set, the KDC (Key Distribution Center) blindly assumes the dMSA is the rightful successor and issues Privilege Attribute Certificates (PACs) containing all the original account\u2019s rights \u2014 no verification needed.[\/vc_column_text][vc_empty_space height=”40px”][vc_column_text css=””]<\/p>\n

Where It All Began: dMSA and the Idea of Migration<\/h4>\n

[\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]Attackers don\u2019t need to perform a real migration. They can simulate one by setting two attributes:[\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]1. msDS-ManagedAccountPrecededByLink \u2192 DN of target user (e.g. Administrator)
\n2. msDS-DelegatedMSAState \u2192 2 (signals migration is complete)[\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]From that point forward, when the dMSA authenticates, it receives a PAC with the target\u2019s SID and group memberships, effectively impersonating them on the network.[\/vc_column_text][vc_empty_space height=”40px”][vc_column_text css=””]<\/p>\n

Real-World Abuse: From Unprivileged to Domain Admin<\/h4>\n

[\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]There are two main paths an attacker might take:[\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]1. Hijack an existing dMSA
\n– Modify msDS-ManagedAccountPrecededByLink to point to a privileged user
\n– Set msDS-DelegatedMSAState to 2
\n– Authenticate as the dMSA and assume all target privileges[\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]2. Create a new dMSA
\n– If a user has create permissions on any OU, they can:
\n\u2022 Use PowerShell to create a dMSA in that OU
\n\u2022 Gain full control over it
\n\u2022 Configure the two attributes
\n\u2022 Request a TGT for the dMSA using tools like Rubeus[\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]Boom: The attacker becomes a Domain Admin, with no touch to the original account.[\/vc_column_text][vc_empty_space height=”40px”][vc_column_text css=””]<\/p>\n

What Makes BadSuccessor So Dangerous?<\/h4>\n

[\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]<\/p>\n

    \n
  • No access required to the target user account<\/li>\n
  • No LDAP writes to the target user<\/li>\n
  • No group membership changes<\/li>\n
  • No logs indicating a privilege escalation<\/li>\n<\/ul>\n

    [\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]The exploit lives entirely in the dMSA object. As long as the KDC sees the msDS-ManagedAccountPrecededByLink, it delivers a PAC with all inherited rights.[\/vc_column_text][vc_empty_space height=”40px”][vc_column_text css=””]<\/p>\n

    Bonus: Credential Leakage<\/h4>\n

    [\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]There\u2019s more.[\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]When a TGT is issued to a dMSA, it contains a structure called KERB-DMSA-KEY-PACKAGE, which includes:
    \n– current-keys
    \n– previous-keys[\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]Surprisingly, the previous-keys can sometimes contain the RC4 key of the impersonated account \u2014 which means that the attacker might also recover the NTLM hash of the target account.[\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]They get your permissions AND your password hash.[\/vc_column_text][vc_empty_space height=”40px”][vc_column_text css=””]<\/p>\n

    What You Can Do<\/h4>\n

    [\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]Until Microsoft ships a patch, you are responsible for mitigating this risk. Here are immediate steps you should take:[\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]Audit:<\/strong>
    \n– Search your domain for any dMSAs (objectClass=msDS-GroupManagedServiceAccount)
    \n– Check which users\/groups have write access to dMSAs
    \n– Monitor changes to msDS-ManagedAccountPrecededByLink and msDS-DelegatedMSAState[\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]Restrict:<\/strong>
    \n– Limit creation of dMSAs to trusted admin OUs only
    \n– Avoid delegating Create all child objects or Create msDS-DelegatedManagedServiceAccount to untrusted users
    \n– Deny WriteProperty on msDS-ManagedAccountPrecededByLink where possible[\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]Detect:<\/strong>
    \n– Look for anomalous PACs with mismatched SIDs during logon
    \n– Monitor TGT requests for dMSAs and unexpected group memberships
    \n– Use tools like Wireshark or Rubeus to inspect PACs when necessary[\/vc_column_text][vc_empty_space height=”40px”][vc_column_text css=””]<\/p>\n

    What You Can Do<\/h4>\n

    [\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]BadSuccessor is a perfect example of how convenience can backfire when security isn\u2019t baked into the design. The assumption that a migration must be legitimate \u2014 without validation \u2014 opened the door for one of the most stealthy and devastating privilege escalation attacks in recent memory.[\/vc_column_text][vc_empty_space height=”10px”][vc_column_text css=””]If you manage an AD environment \u2014 especially one testing or planning for Windows Server 2025 \u2014 this should be at the top of your priority list.[\/vc_column_text][\/vc_column][\/vc_row]<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"

    Imagine giving someone the keys to your house just because they said they were the new owner. That\u2019s essentially what Windows Server 2025 is doing \u2014 and it\u2019s called BadSuccessor.<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[70],"tags":[],"class_list":["post-6685","post","type-post","status-publish","format-standard","hentry","category-cybersecurity"],"_links":{"self":[{"href":"https:\/\/cyberassurancenow.com\/index.php\/wp-json\/wp\/v2\/posts\/6685","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cyberassurancenow.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cyberassurancenow.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cyberassurancenow.com\/index.php\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/cyberassurancenow.com\/index.php\/wp-json\/wp\/v2\/comments?post=6685"}],"version-history":[{"count":11,"href":"https:\/\/cyberassurancenow.com\/index.php\/wp-json\/wp\/v2\/posts\/6685\/revisions"}],"predecessor-version":[{"id":6696,"href":"https:\/\/cyberassurancenow.com\/index.php\/wp-json\/wp\/v2\/posts\/6685\/revisions\/6696"}],"wp:attachment":[{"href":"https:\/\/cyberassurancenow.com\/index.php\/wp-json\/wp\/v2\/media?parent=6685"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cyberassurancenow.com\/index.php\/wp-json\/wp\/v2\/categories?post=6685"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cyberassurancenow.com\/index.php\/wp-json\/wp\/v2\/tags?post=6685"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}