Who can execute DCSync in your AD environment?

6 min readJan 20, 2022


Welcome to Part III of our Auditing AD Series.

Part I: 3 warm up questions to get us started

Part II: Who can reset the CISO’s password?

Part III: Who can execute DCSync?

Part IV: Who can modify the Domain Admins group?

Part V: Domain dominance in minutes via ACL abuse (i.e. why auditing AD matters)

Part VI: Why Allow statements matter a LOT more than Deny ones

Part VII: Sneaky persistence via hidden objects in AD

Part VIII: SDDL, what is it, does it matter?

Part IX: Do you know who owns your domain?

Part X: Who can push ransomware via Group Policy?

Part XI: Free ways to simplify auditing AD

Part XII: Sidenote on arcane rights like Self

Part XIII: Sidenote on the ScriptPath right

Part XIV: Self & so called “Effective Permissions”

Part XV: Inheritance Explained & an Example

Part XVI: Summary of our Auditing AD Series

Annex A: Scrubbing Group Policy for local admins

Annex B: What Property Sets in AD are, & why they matter

Annex C: Dangerous Rights & RE GUIDs Cheatsheet

Annex D: Mishky’s Blue Team Auditor

Annex E: Even ChatGPT gets this stuff wrong

Annex F: Get-ADPermission Cheatsheet

Annex G: Mishky’s Red Team Enumerate & Attack tools

This series shows one way to solve the questions posed by a vendor in the AD auditing space using their pre-built AD on their VM. This question comes from here.

I have touched on this in prior blog posts, however this is solely about how to audit for exactly which users in your environment possess the privileges necessary to execute DCSync. Previous posts were more about using DCSync as a prerequisite to generating a Golden Ticket or some mitigations against Mimikatz style attacks in general.

Suffice to say that if an attacker is able to successfully execute DCSync in your AD environment even once this amounts to a complete compromise of your entire organization. AD is the basis of Identity and Access Management. DCSync allows an attacker to pull the NTLM hash of the krbtgt account. This is the only piece of data that is not freely available to all Domain Users that is required to forge Kerberos tickets. If an attacker possesses the krbtgt hash then they can impersonate any account they wish. The damage is not limited solely to one domain if other domains have a trust relationship with it.

Rights required for DCSync

One has to do a deep dive into Microsoft’s documentation to begin to answer this question. Just to make things more confusing, Microsoft uses two different names and a GUID to refer to the same thing. In ADUC they look like the below:

However to work with them in PowerShell we have to check https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/1522b774-6464-41a3-87a5-1e5633c3fbbb and find:

We went over ACLs in Part I of this series and querying the rights and extended rights contained in them in Part II. We also saw that we have to screen for additional rights as well such as GenericAll, WriteDACL, WriteOwner, etc. as these rights would give someone the ability to just give themselves the privileges required to execute DCSync.

How to check

So without further ado here is the script:

#https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/1522b774-6464-41a3-87a5-1e5633c3fbbb$ErrorActionPreference = "SilentlyContinue"
Import-Module ActiveDirectory
Set-Location AD:
#$suspects = ((Get-ACL 'dc=corp,dc=local').Access | Where {($_.ObjectType -Like "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2" -and "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" -and "89e95b76-444d-4c62-991a-0facbeda640c") -and ($_.AccessControlType -eq 'Allow')}).IdentityReference$owner = (Get-Acl (Get-ADDomain).DistinguishedName).owner
Write-Host "$owner owns this object. Owners have implicit privilege to do anything."
$suspects = ((Get-ACL (Get-ADDomain).DistinguishedName).Access | Where {((($_.ActiveDirectoryRights -like "*ExtendedRight*") -and (($_.ObjectType -eq "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2") -or ($_.ObjectType -eq "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2") -or ($_.ObjectType -eq "00000000-0000-0000-0000-000000000000"))) -or ($_.ActiveDirectoryRights -like "*GenericWrite*") -or ($_.ActiveDirectoryRights -like "*GenericAll*") -or ($_.ActiveDirectoryRights -like "*WriteDACL*") -or ($_.ActiveDirectoryRights -like "*WriteOwner*") -and ($_.AccessControlType -eq "Allow"))}).IdentityReferenceWrite-Host "These groups can execute DCSync. Nested users in those groups listed below:"
$suspects | Sort-Object -Unique
$suspects | Out-File C:\Temp\suspects.txt -Append
ForEach($suspect in $suspects)
$temp = ($suspect -split " \ ")[0]
$group = ($temp.Split("\")[1])
$members = (Get-ADGroupMember -Identity $group -Recursive).Name
$members | Out-File C:\Temp\suspects.txt -Append
Get-Content C:\Temp\suspects.txt | Sort-Object -Unique

This VM’s AD is messy

Some of these groups look quite odd being included in this list, so if we want to spot check:

(Get-ACL ‘dc=corp,dc=local’).Access | Where {(($_.ActiveDirectoryRights -like “*GenericAll*”) -or ($_.ActiveDirectoryRights -like “*WriteDACL*”)) -and ($_.AccessControlType -eq ‘Allow’)}

We see odd stuff like the below:

Sean Metcalf, for one, recommends not placing any users or groups under the builtin stuff in AD like Domain Admins. Most SMEs don’t recommend using these builtin groups at all. They also recommend either disabling the builtin Administrator account or using Group Policy to limit it to local only login as a ‘break glass’ access method of last resort. There are several reasons for this, not least among them is that the builtin Administrator, aka SID 500, does not lockout. This is true no matter how many times a bad password is entered and no matter what the account lockout threshold is set to in Group Policy.

However in this corp.local domain we see Domain Admins, Enterprise Admins, etc still in use, users & groups being added to them, and groups being given privileges to change the ACL on the domain root … lots of groups.

This is why so many accounts show up when we check who can execute DCSync in corp.local.

We also see odd stuff like this:

Why explicitly deny WriteDacl on the domain root to a group? Is this because they were nested in a group in AD that gave them excessive rights? If so … why not just remove them from said group? More than likely nesting them in that group gave them other rights they shouldn’t have and may have left them a different escalation path open besides changing the ACL on the domain root. Why risk it?

Wrapping up

This concludes Part III of our series. It is also a lesson in why OUs, groups, and permissions should be setup in AD correctly and in accordance with best practices in the first place. An AD this messy does make for good lab exercises though, so it certainly serves a purpose. My thanks to the vendor who provided it!









I work various IT jobs & like Windows domain security as a hobby. Most of what’s here is my notes from auditing or the lab.