TL;DR Handy list of Dangerous Rights, what they are, why they matter, & their related GUIDs.
Welcome to the annexes 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
Background
‘Dangerous Rights’ isn’t our term, we borrowed it from Trimarc or Sean Metcalf awhile back when we borrowed their idea regarding querying AD CS. (I have since learned that the term was originally coined by Jake Hildreth at Trimarc.) The term refers to AD rights that can give a user or group the ability to take over another account. Needless to say an attacker would then enumerate rights held by that account and possibly repeat the process until they gain Domain Admin level permissions, if the domain is poorly configured.
We combined Trimarc’s idea with Get-ADUserNestedGroups for the Red Team version of our tool that finds Dangerous Rights. Hence it
- Checks all nested groups
- Checks things like Authenticated Users, Domain Users, etc just in case
- Doesn’t trip Defender
- Only requires Get-ADUserNestedGroups and the AD PowerShell module
- Can be run on any domain workstation as a mere Domain User, no local admin required.
We posted the Red Team version here. The Blue Team version is here.
The Blue Team version checks for any Dangerous Rights held by any non-whitelisted users or groups.
We use the verbiage as seen in PowerShell for these rights, here and throughout pretty much all of our howtos. Microsoft being Microsoft, they use different terms depending on if you’re in the GUI using something like Active Directory Users & Computers (ADUC), reading documentation on Microsoft Learn, etc. We use PowerShell’s terms both for clarity and because that is how we query them.
I included a table at the very bottom of this cheatsheet showing rights as they appear in SDDL, the GUI, and PowerShell. I didn’t see a useful table like it on Google, so I pieced one together from Microsoft documentation.
Dangerous Rights
These are almost always dangerous:
- GenericAll (grants all privileges)
- WriteDACL (grants one the right to give oneself privileges)
- WriteOwner (grants the right to seize ownership, and then give oneself privileges)
- GenericWrite (Functionally the same thing as WriteProperty with ObjectType all 0s)
The rights listed below along with related GUIDs are dangerous with specific ObjectTypes:
WriteProperty
WriteProperty grants the right to modify attributes, many of which have security implications.
+---------------------------------+--------------------------------------+
| Attribute | GUID |
+---------------------------------+--------------------------------------+
| All | 00000000–0000–0000–0000–000000000000 |
| gPLink (link a GPO to an OU) | f30e3bbe-9ff0–11d1-b603–0000f80367c1 |
| Member (add users to a group) | bf9679c0–0de6–11d0-a285–00aa003049e2 |
| Membership Property Set | bc0ac240–79a9–11d0–9020–00c04fc2d4cf |
| ScriptPath (run logon script) | bf9679a8–0de6–11d0-a285–00aa003049e2 |
+-------------------------------------------+----------------------------+
ExtendedRight
If a user or group holds both Replication related ExtendedRights on the domain root then they can execute DCSync and pull all the NTLM hashes from AD.
If a user or group holds the ResetPassword ExtendedRight on a given user account then they can reset that user’s password, no knowledge of that user’s prior password required. In other words they could take over that account and begin impersonating that user.
The certificate rights can be dangerous given certain misconfigurations in AD CS.
+--------------------------------+--------------------------------------+
| Right | GUID |
+--------------------------------+--------------------------------------+
| All | 00000000–0000–0000–0000–000000000000 |
| ResetPassword | 00299570–246d-11d0-a768–00aa006e0529 |
| DS-Replication-Get-Changes | 1131f6aa-9c07–11d1-f79f-00c04fc2dcd2 |
| DS-Replication-Get-Changes-All | 1131f6ad-9c07–11d1-f79f-00c04fc2dcd2 |
| Certificate-AutoEnrollment | a05b8cc2-17bc-4802-a710-e7c15ab866a2 |
| Certificate-Enrollment | 0e10c968-78fb-11d2-90d4-00c04f79dc55 |
+--------------------------------+--------------------------------------+
Self
Self is also called ‘Validated Write’, depending on the specific documentation. Self with either ObjectType all 0s or the specified GUID for ‘self-membership’ allows one to add oneself to a given group.
+------------------+--------------------------------------+
| Right | GUID |
+------------------+--------------------------------------+
| All | 00000000–0000–0000–0000–000000000000 |
| Self-membership | bf9679c0–0de6–11d0-a285–00aa003049e2 |
+------------------+--------------------------------------+
Rights specific to OUs
- Delete (self-explanatory)
- DeleteChild (delete the items in the OU)
- CreateChild (create items, aka users, in the OU)
- DeleteTree (self-explanatory)
Inheritance
+-----------------+--------------------------------------------------+
| InheritanceType | Applies |
+-----------------+--------------------------------------------------+
| None | only to the OU |
| Descendents | only to the objects in the OU, not the OU itself |
| All | to the OU and the objects in it |
+-----------------+--------------------------------------------------+
+----------------------+--------------------------------------+
| InheritedObjectType | GUID |
+----------------------+--------------------------------------+
| Organizational Units | bf967aa5-0de6-11d0-a285-00aa003049e2 |
| Computer | bf967a86-0de6-11d0-a285-00aa003049e2 |
| User | bf967aba-0de6-11d0-a285-00aa003049e2 |
| Groups | bf967a9c-0de6-11d0-a285-00aa003049e2 |
| Contacts | 5cb41ed0-0e4c-11d0-a286-00aa003049e2 |
+----------------------+--------------------------------------+
InheritanceType & InheritedObjectType make a lot more sense with a concrete example.
This snippet gives the Service Desk group rights to reset passwords and re-enable user accounts in the VIPs OU:
Import-Module ActiveDirectory
Set-Location AD:
$ADRoot = (Get-ADDomain).DistinguishedName
#Give a group Password reset & re-enable over a given OU
$victim = (Get-ADOrganizationalUnit "ou=VIPs,$ADRoot" -Properties *).DistinguishedName
$acl = Get-ACL $victim
$user = New-Object System.Security.Principal.SecurityIdentifier (Get-ADGroup -Identity "Service Desk").SID
#Allow specific password reset
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $user,"ExtendedRight","ALLOW",([GUID]("00299570–246d-11d0-a768–00aa006e0529")).guid,"Descendents",([GUID]("bf967aba-0de6–11d0-a285–00aa003049e2")).guid))
#Allow specific WriteProperty on the Enabled attribute
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $user,"WriteProperty","ALLOW",([GUID]("a8df73f2-c5ea-11d1-bbcb-0080c76670c0")).guid,"Descendents",([GUID]("bf967aba-0de6–11d0-a285–00aa003049e2")).guid))
#Apply above ACL rules
Set-ACL $victim $aclConfirm & see the result in PowerShell:
We did a howto on why inheritance matters from a security perspective back in Part XV of this series.
SDDL mapped to GUI & PowerShell
We did a deep dive into what SDDL is and if you even need to care back in Part VIII.
Summary
There’s nothing new here that wasn’t covered earlier in the Auditing AD Series or our Get-Acl & Set-Acl cheatsheets. I just wanted to put a list of Dangerous Rights together in one place, along with all the related GUIDs, as a quick reference.
Always remember that in AD objects can act on other objects. It is vitally important to thoroughly audit a messy domain that you may have inherited from a prior sysadmin and cleanup their Misconfiguration Debt. If you don’t then sooner or later an attacker will phish a user, get a foothold, enumerate, escalate, and then something like ransomware tends to follow.
References
Get-ADUserNestedGroups: http://blog.tofte-it.dk/powershell-get-all-nested-groups-for-a-user-in-active-directory/
Self, aka Validate Writes: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/20504d60-43ec-458f-bc7a-754eb64446df
ScriptPath: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-ada3/c640630e-23ff-44e7-886f-16df9574039e
Selfadsi table of GUIDs: http://www.selfadsi.org/deep-inside/ad-security-descriptors.htm
Handy table of GUIDs: https://www.powershellgallery.com/packages/DSACL/1.0.0/Content/DSACL.psm1
Ascii Table easy creation: https://ozh.github.io/ascii-tables/
Abusing WriteDACL on AD CS templates: https://github.com/daem0nc0re/Abusing_Weak_ACL_on_Certificate_Templates?tab=readme-ov-file#abusing-writedacl-ace
