Who can reset the CISO’s password?

TL;DR How to determine a list of users who can reset a given user’s password, meaning they could take over that account.

Background

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

In this exercise we are examining how to determine a list of groups and accounts in AD who possess the privileges to reset the CISO’s password in a fictional organization’s Active Directory environment. The question was posed here.

Lab setup

We fire up the VM provided by this vendor, check AD … and find that none of the user accounts have a description set stating it is the CISO.

Get-ADUser -Filter {(Description -Like “*”) -and (Description -NotLike “*Service*”) -and (Description -NotLike “*IT*”) -and (Description -NotLike “*Project*”) } -Properties * | Select-Object Name, Description

So how do we answer this question? Easy, we pick a user and promote them. This fictional org has an OU named Global that is then broken down into regions. For some reason they put the computers and users both in this same OU. Personally I would keep the OUs for workstations and users separate as it makes tracking and setting Group Policy easier. Going into APAC and then South Korea and down to the Seoul OU we find the user Elizabeth Myers. I went with Seoul because it is one of the largest cities in the world, I spent a year working there, and I absolutely loved it.

So to promote Elizabeth Myers to CISO:

Set-ADUser ElizabethMyers -Description “CISO”

Then to verify:

(Get-ADUser -Filter {Description -Like “CISO”} -Prop *).SamAccountName

A little background on rights in AD

This requires a deep dive into Microsoft’s documentation. Additionally we run into the old issue that Microsoft does not use the same name for this right in the GUI as they do in PowerShell.

Here is Active Directory Users and Computers (ADUC) showing the Domain Admins group’s rights on the CISO’s account:

This same information can be found much quicker in Powershell without having to click through a bunch of tabs:

Note; the above method is for those used to using grep in BASH. In PowerShell the preferred method is:

(Get-Acl ((Get-ADUser ElizabethMyers -Properties *).DistinguishedName)).Access | Where {$_.IdentityReference -like “*Domain Admins*”}

Of course an astute reader will notice right away that it says “GenericAll”, which is not listed in ADUC. According to Microsoft’s documentation this means:

“The right to create or delete children, delete a subtree, read and write properties, examine children and the object itself, add and remove the object from the directory, and read or write with an extended right.”

So basically the same thing as “Full Control”, or just having all the rights possible. This is important to note because while the privileges to reset a password is one specific extended right, or a control access right depending on the specific Microsoft documentation one is looking at, obviously if someone has Full Control or GenericAll then they can reset that user’s password. They could also delete the account, or change anything else about it. They could change the attribute for “store password using reversible encryption”, and then grab the plaintext password the next time that user logs in.

Yes, this is still possible. Microsoft stated they left it as an option as “support for applications that use protocols that require the user’s password for authentication”.

This background leads into our next point.

So who can reset the CISO’s password?

There is both a simple and a complex answer to this. The simple answer is this:

Import-Module ActiveDirectory
Set-Location AD:
$user = (Get-ADUser "ElizabethMyers" -Properties *).DistinguishedName
$owner = (Get-Acl $user).owner
Write-Host "$owner owns this object. Owners have implicit privilege to do anything."
((Get-ACL $user).Access | Where {((($_.ActiveDirectoryRights -like "*WriteProperty*") -and (($_.ObjectType -eq "00299570-246d-11d0-a768-00aa006e0529") -or ($_.ObjectType -eq "00000000-0000-0000-0000-000000000000"))) -or ($_.ActiveDirectoryRights -like "*GenericWrite*") -or ($_.ActiveDirectoryRights -like "*GenericAll*")) -and ($_.AccessControlType -eq "Allow")}).IdentityReference | Sort-Object -Unique

(Sidenote; 548 is the well known SID of the Account Operators group.)

This merely looks for who in the ACL on Elizabeth Myer’s account has the specific right to reset the password. However this answer is incomplete for two reasons:

• As we saw above, other rights such as Full Control include resetting the password
• This only lists the groups, not all the accounts nested in them

We can easily list out the nested users, but this still leaves the other rights that affect our CISO’s password.

So how do we get a more holistic answer?

Honestly, I have no idea if this is even possible in the GUI. I had to work up a script to even begin to find this. The reason is that we have to screen for the extended right ‘User-Force-Change-Password’ with GUID = 00299570–246d-11d0-a768–00aa006e0529, GenericAll, WriteDACL (the ability to modify the ACL, aka just give oneself rights), and so on. In the end I just decided that the real question was “So who can screw with the CISO’s account” and screened for all these privileges. I then expanded the groups that had these rights so we get a list of the groups themselves and the users nested in them. I then had to display only the unique names. This is because our lab AD from this vendor was quite messy.

• Multiple groups had the rights in question
• The same users were in multiple groups that had the rights
• Groups that had the rights were nested in other groups that also had the rights

Hence I was getting the same account listed 3 or 4 times in the results. In BASH we could simple pipe to ‘uniq’. PowerShell has something similar with ‘ | Sort-Object -Unique ‘

So without further ado, here is the script I ended up hobbling together:

Import-Module Active Directory
Set-Location AD:
$ErrorActionPreference = "SilentlyContinue"
$User = (Get-ADUser "ElizabethBrown" -Properties *).DistinguishedName
$owner = (Get-Acl $User).owner
Write-Host "$owner owns this object. Owners have implicit privilege to do anything."
$suspects = ((Get-ACL $User).Access | Where {((($_.ActiveDirectoryRights -like "*ExtendedRight*") -and (($_.ObjectType -eq "00299570-246d-11d0-a768-00aa006e0529") -or ($_.ObjectType -eq "00000000-0000-0000-0000-000000000000")) -or ($_.ActiveDirectoryRights -like "*WriteProperty*") -or ($_.ActiveDirectoryRights -like "*GenericWrite*") -or ($_.ActiveDirectoryRights -like "*GenericAll*") -or ($_.ActiveDirectoryRights -like "*WriteDACL*") -or ($_.ActiveDirectoryRights -like "*WriteOwner*")) -and ($_.AccessControlType -like "Allow"))}).IdentityReference
Write-Host "These groups can change the given user's pwd. Nested users in those groups listed below:"
$suspects | Sort-Object -Unique
$suspects | Out-File C:\Temp\suspects.txt -Append
ForEach($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

The bottom line: we get 69 unique groups and users who can screw with the CISO’s account.

This number is only slightly higher due to changes I made as I only added three Domain Admins for training purposes. As stated earlier, this sample AD is quite messy. It does make for a good environment to practice auditing in though.

Sidenote; calling it messy is being generous. Poorly planned, badly architected, and sloppy might be more accurate. Users with Domain Admin are not even using separate privileged accounts. An attacker hardly needs to escalate privileges if they can just phish a Domain Admin directly.

Wrapping up

Well this explanation of enumerating who can screw with a given user account in AD has gotten long enough. Tune in next time for Part III where we will examine what DCSync is, what it means for AD security, and how to determine who has privileges to execute it.

Spoiler: it could mean a total compromise of your entire organization!

References:

https://docs.microsoft.com/en-us/dotnet/api/system.directoryservices.activedirectoryrights?view=dotnet-plat-ext-6.0

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

https://stealthbits.com/blog/compromising-plain-text-passwords-active-directory/

http://www.selfadsi.org/deep-inside/ad-security-descriptors.htm

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