Self, perhaps the most arcane of Windows privileges

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

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

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

--

--

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
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.