How Many Angels Can Dance on the Head of a Pin?

Rich
7 min readJan 18, 2022

TL;DR Mostly academic lab exercise finding the answer to 3 questions posed by a random cybersecurity product vendor RE enumerating AD ACEs, groups, and ACLs.

Background

Welcome to Part I 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.

As anyone who has read one or two posts on here knows, one of my hobbies is screwing around with Windows domain security in the lab. I particularly like demoing an attack that takes advantage of Windows default settings and then show how to mitigate it. I have ended up doing a bit of auditing as well, which has led into using PowerShell to automate querying AD. AD is after all a database.

In that spirit, I wanted to tackle some questions posed by a vendor in the AD auditing space here. Obviously they would prefer that you use their tool, however it is not free and it is much more educational to find the answers yourself. The answers are to be found in the AD environment that is included on the VM they provide here. (Please note that my numbers will be a bit high due to the fact that I had added some users, groups, OUs, GPOs, etc already.)

CW6 Google and Sean Metcalf’s information was used heavily in this lab exercise. It was actually a decent exercise for practicing PowerShell syntax and querying in general.

So without further ado, here are the questions:

The Challenge

(Questions came from: https://blog.paramountdefenses.com/2020/06/active-directory-security-permissions-ananlysis-and-tools.html)

1. Exactly how many security permissions (ACEs) are there domain-wide in the corp.local domain?

PS AD:\> (Get-Acl (Get-ADObject -Filter *)).Access.Count

182205

2. Exactly how many members does the Domain Admins security group have?

Directly in Domain Admins:

PS AD:\> (Get-ADGroupMember -Identity “Domain Admins”).Count

6

Domain Admins & nested groups/users:

PS AD:\> (Get-ADGroupMember -Identity “Domain Admins” -Recursive).Count

16

3. Exactly how many security permissions in the ACL protecting the Domain Admins security group directly or indirectly impact “Write Property — Member” permissions?

((Get-ACL ‘cn=domain admins,cn=users,dc=corp,dc=local’).Access | Where {($_.ActiveDirectoryRights -like “*WriteProperty*”) -and (($_.ObjectType -eq “bf9679c0–0de6–11d0-a285–00aa003049e2”) -or ($_.ObjectType -eq "bc0ac240–79a9–11d0–9020–00c04fc2d4cf") -or ($_.ObjectType -eq “00000000–0000–0000–0000–000000000000”)) -or ($_.ActiveDirectoryRights -like “*GenericWrite*”) -or ($_.ActiveDirectoryRights -like “*GenericAll*”)}).count

10

In case it’s a trick question again, include other rights that indirectly impact “WriteProperty”:

((Get-ACL $DN).Access | Where {((($_.ActiveDirectoryRights -like "*WriteProperty*") -and (($_.ObjectType -eq "bf9679c0-0de6-11d0-a285-00aa003049e2") -or ($_.ObjectType -eq "bc0ac240–79a9–11d0–9020–00c04fc2d4cf") -or ($_.ObjectType -eq "00000000-0000-0000-0000-000000000000"))) -or ($_.ActiveDirectoryRights -like "*GenericWrite*") -or ($_.ActiveDirectoryRights -like "*GenericAll*") -or ($_.ActiveDirectoryRights -like "*WriteDACL*") -or ($_.ActiveDirectoryRights -like "*WriteOwner*") -or (($_.ActiveDirectoryRights -like "*Self*") -and (($_.ObjectType -eq "bf9679c0-0de6-11d0-a285-00aa003049e2") -or ($_.ObjectType -eq "00000000-0000-0000-0000-000000000000"))))}).Count

11

How to get the answers:

Question 1

The first question prompted the title of this post. I mean, asking how many total ACEs are in a Windows domain is a bit like asking how many stop signs are in NYC. It’s a purely academic exercise. That said, this is how I got to the number. I couldn’t find this anywhere on Google, so I think it is worth explaining.

Everything in Active Directory is called an object. It could be a user, computer, group, OU, whatever. Normally when I am conducting an audit for one of our sub-organizations I would run a function for them that, among other things, tells them how many total users and computers they have in their org. For example to get total users in an OU:

(Get-ADUser -Filter * -SearchBase “ou=suborg,dc=corp,dc=local”).Count

Since everything in AD is an object and since every object has an ACL we know that the total number of ACLs in AD is equal to the total number of objects. ‘(Get-Acl X).Access’ will show the ACL of Object X in AD including all the ACEs. Therefore we can find all ACEs by showing all Objects ACLs and then just getting a count, therefore:

(Get-Acl (Get-ADObject -Filter *)).Access.Count

Question 2

The second question might be a trick, so I listed two answers. The first is simply the number of users and groups directly in the group Domain Admins. The second answer is the total number of users and groups, including those nested in a group which is a member of the group Domain Admins. Finding all the members of all the nested groups can be accomplished by simply adding ‘-Recursive’ to ‘Get-ADGroupMember’

Question 3

I give this particular vendor credit here as I had not really messed around with auditing ACLs before. Our higher org established the groups, OUs, ACLs, and so on. We would only make sure our users are compliant and approve their requests for membership in groups. ‘Get-Acl’ is the key PowerShell cmdlet here. You have to make sure you navigate to AD first though, otherwise PowerShell thinks that you are checking the ACLs of files & folders on the Hard Drive. The easy way to do this in a script is:

PS C:\> Import-Module ActiveDirectoryPS C:\> Set-Location AD:

I settled on this tactic, particularly in scripts, after getting weird errors RE the AD Module in PS. I found that by running an AD command first PS would automatically import the AD module and everything worked fine.

Your typical ACL will list groups that are allowed to take an action on the AD Object that the ACL applies to. Microsoft does not recommend giving rights directly to a user account, for obvious reasons. A sample ACL looks like the below:

ACLs get unnecessarily complicated because Microsoft uses different terms for the same right depending on whether you check in PowerShell as above or in the GUI as below:

Additionally there are Extended Rights or Control Access Rights. The term changes depending on which part of Microsoft’s documentation you are looking at. A given right, such as the ones required to execute DCSync, have two different names and a GUID by which to refer to them, again depending on the exact MS documentation and whether you are operating in the GUI or PowerShell.

Lastly, I ran a check for additional rights since I believe this was a trick question. After all, if someone was given Full Control, aka GenericAll, rights on Domain Admins then they could easily perform a WriteProperty. Likewise if they held WriteDACL privileges then they could change the ACL and give themselves WriteProperty. The list goes on, hence I added some additional checks.

Wrapping up

Well this writeup has gotten long enough. In future posts I will dive into how to find the answer to more questions posed by this vendor. This turned into a 6 part series already, and I’m working on Part VII. ACLs can quickly become a complicated topic.

Tune in next time for queries that find who can reset the CISO’s password and who can execute DCSync.

References:

https://docs.microsoft.com/en-us/windows/win32/ad/how-access-control-works-in-active-directory-domain-services

https://www.pcwdld.com/active-directory-guide#wbounce-modal

https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-acls-aces

https://www.exploit-db.com/docs/48298

https://book.hacktricks.xyz/windows/active-directory-methodology/acl-persistence-abuse

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/1522b774-6464-41a3-87a5-1e5633c3fbbb

https://www.active-directory-security.com/2014/06/Active-Directory-Account-Password-Security-101-For-Regulatory-Compliance-Auditors-The-Difference-Between-Change-Password-and-Reset-Password.html

https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups

--

--

Rich

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.