TL;DR explanation of the Self right on an AD group and how it can allow a user to add themselves to a group.
Welcome to Part XII 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
Windows privileges are quite granular and can get rather arcane. An example of this is the Self privilege. We have it in the list of DangerousRights to check for, but never really explained why. Google was a bit mixed on exactly what the Self right meant, this was one of the few that even mentioned it. Sean Metcalf touched on it here. Part of the problem seems to be that Microsoft, as they often do, uses “Self” to mean two different things depending on the exact context and uses different terminology depending on whether you’re in the GUI or the CLI.
To be clear, there are two things labeled “Self”. We will
- show the ActiveDirectoryRights “Self” first
- explain why it matters to security
- contrast it with the IdentityReference “Self”
- detour a bit down why that matters given Microsoft’s propensity for leaving legacy crap enabled that impacts security to this day
Enough theory, let’s demo it
We will give a regular old Domain User the Self right with the specific GUID for “self-membership” rights on a group. Self with ObjectType all 0s will grant the same privilege [we tested both].
#Give a user Self over a given group
$victim = (Get-ADGroup “Minions” -Properties *).DistinguishedName
$acl = Get-ACL $victim
$user = New-Object System.Security.Principal.SecurityIdentifier (Get-ADUser -Identity “Mishka”).SID#Allow Self with all 0s (comment this out to use a specific GUID)
#$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $user,”Self”,”ALLOW”,([GUID](“00000000–0000–0000–0000–000000000000”)).guid,”None”,([GUID](“00000000–0000–0000–0000–000000000000”)).guid))#Allow Self with specific GUID (comment this out to use all 0s)
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $user,”Self”,”ALLOW”,([GUID](“bf9679c0–0de6–11d0-a285–00aa003049e2”)).guid,”None”,([GUID](“00000000–0000–0000–0000–000000000000”)).guid))#Apply above ACL rule
Set-ACL $victim $acl
Confirm via the query below:
$root = (Get-ADDomain).DistinguishedName ; (Get-Acl “cn=minions,ou=user accounts,$root”).Access | Where-Object {$_.IdentityReference -like “*mishka*”}
Mishka then just has to jump on a domain workstation and see if she can indeed add herself to the Minions group.
It’s confirmed, Self with ObjectType bf9679c0–0de6–11d0-a285–00aa003049e2 or all 0s does indeed give the IdentityReference listed the privilege to add and/or remove themselves from the group.
This is why we screened for it, but I wanted to confirm it in the lab. Yes, Trimarc’s idea flags it as a DangerousRight.
This Minions group doesn’t have any elevated access in the domain, but the security implications should be obvious. If a group or user has this right on a group like Domain Admins then they effectively can do whatever they want ‘on prem’, and may be able to pivot to Azure AD depending on the exact configuration.
Therefore this is something to be aware of and make sure you are checking for.
Don’t confuse the two different Selfs
We looked at the ActiveDirectoryRights Self above. Microsoft being who they are, they also have an IdentityReference called Self. This is used to refer to rights held by a user or group on themselves, as seen below.
Some screenshots are redacted IOT omit tiny human’s real names.
These specific GUIDs translate to ReadProperty ‘Private Information’ and ExtendedRight ‘Change Password’.
What’s ‘Private Information’? AD has a feature known as Property Sets. By default, everyone can read almost all AD attributes [the obvious exception to this of course are things like the LAPS password on a computer account]. But why is this? The answer lies in Microsoft’s propensity for backwards compatibility. By default AD gives GenericRead to a group called ‘Pre-Windows 2000 Compatible Access’. Who’s in this group? All Authenticated Users of course.
Microsoft helpfully gave this Pre-Windows 2000 Compatibility group permissions on the domain root that inherit on down.
(Get-Acl (Get-ADDomain).DistinguishedName).Access | Where-Object {($_.IdentityReference -like “*Pre-Windows 2000*”) -and ($_.ActiveDirectoryRights -like “*GenericRead*”)}
Authenticated Users on the other hand can only read certain property sets on a given user account; General, Personal, and Public Information.
(Get-Acl “cn=ceo,ou=vips,dc=test,dc=local”).Access | Where-Object {($_.IdentityReference -like “*Authenticated Users*”) -and ($_.ActiveDirectoryRights -like “*ReadProperty*”)}
Yes this is still a thing, in 2022, on DCs running Windows Server 2016, 2019, and 2022 and the domain functional level on 2016 [the most recent]. Microsoft still leaves LLMNR and NetBIOS enabled by default on Windows 11. They still don’t even require SMB signing on workstations by default in 2022. Silly me, I thought zero trust was all the rage these days.
Hence some sources recommend removing Authenticated Users from the Pre-Windows 2000 Compatibility group in order to make the recon stage a bit harder on intruders or malicious insiders. We’ve gone over using Group Policy to disable some of the other legacy crap here.
Summary
I was torn on whether to put this in the Back to the Basics or Auditing AD series. It definitely is not a standalone howto as it makes little sense in isolation. In the end I went with Auditing AD as it is really an expansion pack to the howto ‘Free Ways to Audit AD’.
The Self right is simple enough, but it doesn’t seem to be well known and of course Microsoft being Microsoft they confuse things by using the term for two different things.
References:
Self privilege: https://zflemingg1.gitbook.io/undergrad-tutorials/active-directory-acl-abuse/self
Sean Metcalf on DangerousRights: https://adsecurity.org/?p=3658
ADSI on AD GUIDs: http://www.selfadsi.org/deep-inside/ad-security-descriptors.htm
GUIDs matched to name: https://www.powershellgallery.com/packages/DSACL/1.0.0/Content/DSACL.psm1
Property sets in AD: https://www.varonis.com/blog/active-directory-has-a-privacy-problem
Using AD property sets: https://www.itprotoday.com/compute-engines/using-ad-property-sets#:~:text=A%3A%20AD%20property%20sets%20are,user's%20address%20and%20telephone%20attributes.
NT Authority\Self explained: https://ru-facts.com/what-is-nt-authority-self-permission/
Pre-Windows 2000 Compatibility group: https://www.semperis.com/blog/security-risks-pre-windows-2000-compatibility-windows-2022/#:~:text=As%20the%20name%20implies%2C%20the,the%20more%20granular%20attribute%2Dlevel
