An associated blog post covering this BOF can be found at: https://specterops.io/blog/2025/10/20/the-near-return-of-the-king-account-takeover-using-the-badsuccessor-technique/
Shortly after the release of Yuval Gordon’s (YuG0rd) BadSuccessor dMSA privilege escalation vector, Microsoft issued a patch fixing the flawed logic in how the Key Distribution Center (KDC) acknowledged Delegated Managed Service Account (dMSA) migration, but the patch did not protect sensitive writeable attributes when a dMSA object is controlled by the current user. In a follow-up blog post from Yuval, he noted that the technique could still be utilized for account takeover on principals in which we control their object properties, like a Shadow Credentials or Resource-Based Constrained Delegation (RBCD) attack. Except with this particular account takeover mechanism, user specific objects can be taken over without AD CS in the target environment, where Shadow Credentials requires AD CS and RBCD can only takeover computer accounts.
This motivated me to not only update my previous tooling in .NET for dMSA abuse titled SharpSuccessor but also create some additional tooling for executing this attack in a stealthy manner during Red Team Operations.
Introducing BadTakeover, a Beacon Object File (BOF) for performing account takeover using the BadSuccessor technique. Using a write primitive over a target object, in addition to the CreateChild edge over an Organizational Unit (OU), it’s possible to impersonate the target object for account takeover via requesting a ticket for the newly created dMSA.
The BOF takes the following parameter values and data types:
| Data Type | Value |
|---|---|
| String | Target OU to write the malicious dMSA |
| String | The name of the new dMSA to create |
| String | The Security ID (SID) of your current context |
| String | The target user objects DN |
| String | The current domain - Ex: ludus.domain |
Execution of the BOF in an Apollo agent as an example is shown below:
Unfortunately for requesting the dMSA ticket, dMSA authentication has not been implemented into BOF related Kerberos repositories such as Kerbeus-BOF or nanorobeus, meaning that unfortunately to request the ticket impersonating a target principal you'll still be required to execute Rubeus (.NET assembly). I hope in the future an established Kerberos BOF respository will expand their asktgs functionality to support dMSA authentication once Windows Server 2025 is more popular in corporate environments.
Requesting the dMSA ticket can be done using the same command as specified in the SharpSuccessor repo:
Rubeus.exe asktgs /targetuser:attacker_dmsa$ /service:krbtgt/ludus.domain /opsec /dmsa /nowrap /ptt /ticket:doIFTDCCB.....
With this ticket in memory, you inherit the privileges of the target account configured on the dMSA object. In our case, we're impersonating an account in the Domain Admins group, allowing us full control of the Domain Controller.
