Background
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 -AppendForEach($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!
References:
https://stealthbits.com/blog/what-is-dcsync-an-introduction/
https://medium.com/@markmotig/brute-forcing-sid-500-in-active-directory-c9eb7c01a8a6
