[German]Recently, security researchers have pointed out a potential vulnerability lurking in the delegated Managed Service Accounts (dMSAs) newly introduced in Windows Server 2025. By abusing dMSAs, attackers can take over any principal in the domain. A security researcher is critical of the fact that Microsoft is waiting with a patch. And a developer has created a .NET PoC that can be used to test the vulnerability – here is an addendum.
BadSuccessor: dMSA AD privilege elevation
Microsoft has introduced delegated managed service accounts (dMSAs) in Windows Server 2025. A dMSA is a new type of service account in Active Directory (AD) that extends the capabilities of gMSAs (Group Managed Service Accounts).
A dMSA is usually created to replace an existing service account. A dMSA enables existing unmanaged service accounts to be migrated by seamlessly converting them into dMSAs. To enable a seamless transition, a dMSA can "inherit" the permissions of the old account during the migration process. The migration closely links the dMSA to the replaced account.
By analyzing the migration process in Windows Server 2025, Akamai security researcher Yuval Gordon has discovered a vulnerability that allows attackers to compromise any user in the Active Directory (AD).
The attack, called BadSuccessor, exploits the Delegated Managed Service Account (dMSA) feature, which was introduced in Windows Server 2025, works with the default configuration and is easy to implement. I described the whole thing in the blog post BadSuccessor: Abusing dMSA to elevate privileges in Active Directory.
Criticism of Microsoft's behavior
Security expert Florian Roth has massively criticized Microsoft's behavior at BadSuccessor in the following tweet.
Roth sees the case as proof that the ecosystem is pretty broken in this area. A privilege escalation vulnerability is reported, Microsoft confirms that the vulnerability is real, but classifies it as moderate and intends to patch it at some point in the future. The tool Rubeus already supports the abuse of the above vulnerability.
His conclusions and assumptions: Microsoft either can no longer assess bugs, or has stopped caring about on-prem AD (because Entra ID is what they want to sell). And the security experts have decided to disclose, even though this would be a major strike.
I can kind of understand both sides here: Microsoft probably has to adhere to certain rules that determine whether something needs to be patched immediately. And I can understand the security researchers who don't feel they are being taken seriously and are publishing their findings. On the other hand, Microsoft's communication also seems to have gone extremely badly.
I think it would have been possible to postpone the release if a patch had been announced for summer 2025. I am currently facing a similar dilemma after a blog reader reported a potential vulnerability in a dental practice software. The state data protection officer investigated and received the answer "no problem, must be taken into account when setting up". I can't reach the reader and the matter is still being clarified by the state data protection officer. Let's see when I disclose what and to what extent.
At the end of the day, according to Florian Roth, none of the parties involved (Microsoft, the Akamai security researchers who published this) look good and there are only losers. As Roth concludes his philippic: "The only good thing is that Windows Server 2025 is not yet widespread, so the scope of the damage in the real world is limited today." As mentioned in the first post and subsequently in the commentary, Windows Server 2025 also has to run as a DC, which is further limiting.
SharpSuccessor: BadSuccessor in .NET
Last weekend I came across the following tweet, where Logan Goins presented his .NET version of a BadSuccessor exploit, called SharpSuccessor.
SharpSuccessor is a .NET Proof of Concept (POC) provided on GitHub, to demonstrate the exploitation of the BadSuccessor attack described by Yuval Gordon (@YuG0rd) of Akamai. A user with low privileges and CreateChild permissions for any organizational unit (OU) in the Active Directory domain can elevate their privileges to domain administrator.
