Who can execute DCSync in your AD environment?


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: Who owns your domain?

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: https://blog.paramountdefenses.com/2020/06/active-directory-security-lab-virtual-machine.html . This question comes from: https://blog.paramountdefenses.com/2020/07/how-to-mitigate-risk-of-mimikatz-dcsync.html .

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 (https://happycamper84.medium.com/generating-a-golden-ticket-in-the-lab-4740efa22f34) or some mitigations against Mimikatz style attacks in general (https://happycamper84.medium.com/mitigating-mimikatz-d9441eaaf20c).

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 work or the lab.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Understanding Tor — The anonymity network

BlackRose: 1 Walkthrough (Vulnhub)

{UPDATE} wARships - Fleet Battles in AR Hack Free Resources Generator

{UPDATE} Shoot n Merge Hack Free Resources Generator

Protecting My Digital Privacy

Airdrop Alert: Airdrop of 100,000,000 QYU tokens Total Reward: $42,000,000 worth of QYU

Sleep on a Memory Foam for ImprovedLeisure. https://t.co/CCXpvDvs4z

{UPDATE} Grand Miami Sniper Gang Hack Free Resources Generator

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


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

More from Medium

How to Migrate DHCP Service from Cisco Core Switch to Server 2022 — ICT Fella

SAP Event Mesh: Multitenant Sample Scenario 1

Oracle Cloud Infrastructure Logging and Alert: Rapid smoke testing of config and alerts

Introducing Migrate365