TL;DR ownership, Domain Admins, and so called “effective permissions”. This stuff is not as hard as some claim. This shows how ownership trumps so called “effective permissions”.
Welcome to Part X of our Back to the Basics Series!
Part I: NTDS.dit vs SAM
Part II: Ownership Matters
Part III: Recovering from a Crash
Part IV: Setting up a Simple Honeypot Account
Part V: Automating DC Deployment
Part VI: Sometimes it’s the dumbest thing
Part VII: Merry Christmas, macros, & Base64
Part VIII: Why old 0 Days make great teaching tools
Part IX: PowerShell & PS1s without PowerShell.exe
Part X: Ownership & so called “effective permissions”
Part XI: Windows Event Forwarding & SACLs
Part XII: Poorly planned honeypots & other Bad Ideas
Part XIII: Setting up a simple honey token
Part XIV: Smartcards and Pass-the-Hash
Part XV: Forwarding logs to Sentinel & basic alerts
Part XVI: Automating VM deployments in Hyper-V
Part XVII: Migrating the lab from ESXi to Hyper-V
Background
We already ran a 15 part series on auditing privilege delegation in AD, however this example from a vendor is so bad that we decided to run a lab project on it. This case doesn’t even involve delegation; our sample user is a Domain Admin in this scenario. To top it all off, this comes from their marketing material on their website.
That’s not the worst part though. We would not have bothered with this writeup for that. We have already covered such things in numerous other prior scenarios that were proposed by the vendor. The kicker is that they tend to pretend that this stuff is much more complicated than it is. They have an expensive product to sell, so maybe that explains it. However here at test.local we prefer to explain things and walk through them step by step. We don’t have anything to sell.
The scenario
Quoting from here:
“Assume that a user John Doe is a member of Domain Admins.
Next, assume that the following is the complete ACL protecting the CEO’s domain user account in Active Directory -
Explicit Deny Helpdesk Team All Extended Rights
Explicit Allow Domain Admins Full Control
Question: Will John Doe be able to reset the CEO’s password?
Popular Answer: Yes. (If you rely on a permissions analysis tool to make this determination, you’ll always get Yes for an answer.)
Correct Answer: It depends on whether or not John Doe is also a member of the Helpdesk Team. If he is, the answer is No.”
The error
We have already covered this. John can simply remove the Deny statement, or they can leave the Helpdesk group, or … well you get the picture.
The scenario II
“Assume that a user John Doe is a member of Domain Admins and the Helpdesk Team, and that Helpdesk Team is in turn a member of IT Contractors, which is a member of Global Admins.
Now assume that the following is the complete ACL protecting the CEO’s domain user account in Active Directory -
Inherited Deny Helpdesk Team All Extended Rights
Inherited Allow Global Admins Reset Password
Explicit Deny IT Contractors Special
Explicit Allow Domain Admins Full Control
Question: Will John Doe be able to reset the CEO’s password?
Correct Answer: To answer this question, we need to take into account the collective impact of all the permissions in the ACL. In other words, we will need to determine effective permissions.”
The error, again
They’ll just leave the other groups, or remove the Deny statements, or …
Let’s make this interesting
We’ll stop boring our readers to tears and spice things up. Let’s just
- Leave our sample user in Domain Admins
- Disable inheritance on the CEO’s account
- Change the owner of the CEO’s account to a random Domain User
- Remove all ACEs from the CEO’s DACL
- Put a Deny Domain Admins GenericAll on the CEO’s account
This will mean only the Domain User who owns the account can take action on the CEO’s account, right? Let’s setup our scenario and find out.
Setup the scenario
Here at test.local our adorable little Global Admin has three accounts:
- Her Global Admin in AAD [Redacted as she uses her real name there]
- Her Domain Admin in AD [Mishky]
- Her Domain User that is synced [Mishka]
We will be using her Domain Admin and Domain User accounts here.
If you want to follow along it helps to have two different VMs up; a domain workstation with the Domain User logged on and a DC with the Domain Admin logged on.
First disable inheritance on the CEO’s account:
#Disable Inheritance
$ACL = Get-Acl (Get-ADUser "CEO").DistinguishedName
$ACL.SetAccessRuleProtection($true,$true)
Set-Acl -Path "AD:\cn=CEO,ou=VIPs,dc=test,dc=local" -AclObject $ACLChange the owner to Mishka, a mere Domain User:
#Change the owner
$target = (Get-ADUser "CEO").DistinguishedName
$ACL = Get-Acl (Get-ADUser "CEO").DistinguishedName
$user = New-Object System.Security.Principal.SecurityIdentifier (Get-ADUser -Identity "mishka").SID
$ACL.SetOwner($user)
Set-Acl $target -AclObject $ACLRemove all ACEs, in other words blank out the DACL:
$target = (Get-ADUser "CEO").DistinguishedName
#Collect the current ACL
$ACL = Get-Acl (Get-ADUser "CEO").DistinguishedName
#Loop each access permission in the ACL
ForEach ($access in $ACL.Access)
{
$ACL.RemoveAccessRule($access)
}
#Set the ACL Back to the AD Object
Set-Acl $target -AclObject $ACLDeny Domain Admins GenericAll (run this as Mishka the Domain User)
Import-Module ActiveDirectory
Set-Location AD:
#Deny a group GenericAll
$target = (Get-ADUser "CEO").DistinguishedName
$ACL = Get-Acl (Get-ADUser "CEO").DistinguishedName
$user = New-Object System.Security.Principal.SecurityIdentifier (Get-ADGroup -Identity "Domain Admins").SID
$ACL.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $user,"GenericAll","DENY",([GUID]("00000000–0000–0000–0000–000000000000")).guid,"None",([GUID]("00000000–0000–0000–0000–000000000000")).guid))
Set-ACL $target $ACLPlease note that the above will throw a weird error in PowerShell telling you that it can’t find the AD Object “CEO”. This is because no one has read access to it currently. It will show up in the GUI tool Active Directory Users & Computers (ADUC) however. Mishka can view & change the ACL in that tool and/or she can also do so using dsacls. Readers of these howtos will recall that we walked through using icacls to tweak NTFS permissions when we had ownership and the DACL was blank. Dsacls is basically the AD version of the NTFS tool icacls.
whoami
dsacls "cn=ceo,ou=vips,dc=test,dc=local" /D test\'domain admins':GA
dsacls "cn=ceo,ou=vips,dc=test,dc=local"
Abuse the scenario
Setting that up was an interesting learning experience. Now let’s get to the fun part. Mishka, a mere Domain User, is now the owner of the CEO’s account and the DACL only contains one ACE; a Deny GenericAll [aka Full Control] for Domain Admins.
So Domain Admins can’t reset the CEO’s password right? Right?
Or can they?
whoami
dsacls "cn=ceo,ou=vips,dc=test,dc=local" /takeownership
dsacls "cn=ceo,ou=vips,dc=test,dc=local" /R test\'domain admins'
#Clone a known good ACL to a screwed up one
$KnownGood = Get-Acl -Path (Get-ADUser "CIO").DistinguishedName
Set-Acl -Path (Get-ADUser "CEO").DistinguishedName -AclObject $KnownGood
Now let’s see if our Domain Admin can reset the CEO’s password.
Set-ADAccountPassword “CEO” -Reset -NewPassword (ConvertTo-SecureString -AsPlainText “ParamountDefenses00!!” -Force)
Huh, look at that.
Sidenote on dsacls/icacls
These old cmd.exe tools are really clunky and have obscure syntax. The part of this entire lab project that took me the most time by far was chasing down and trial & erroring a solution using dsacls. I could have done this in the GUI with ADUC in no time, but then where’s the fun in that? Besides, what if an attacker only had CLI access?
I can see why that vendor likes to pretend that dsacls and ADUC are the only free & builtin tools for this. Doing so feeds into their narrative that this is really hard to do, so you should just buy their tool.
However it’s not the early 00s anymore. Microsoft isn’t the same company anymore. There’s better TTPs now. That said, I’d bet you’ll still find attackers happily using dsacls and icacls. Hence it’s good for auditors, system administrators, and cyber folks in general to be aware of them.
Summary
I’ll update the Get-Acl and Set-Acl cheatsheets later to show how to seize ownership with icacls and dsacls. This was actually a good hands on the keyboard learning experience in seizing ownership and then fixing a FUBARed DACL. Thanks to the vendor for offering up a nonsensical example so we had this to work with?
A local admin on a file server can seize ownership of files & folders and fix the DACL regardless of what someone puts in the DACL. A Domain Admin can seize ownership of an AD object and fix the DACL regardless of what someone puts in the DACL.
If a group should not have a given privilege then do not put an Allow in the DACL. If a user should not have a given privilege then do not put them in a group that has been delegated it, or has it by default. Sure you could try to setup a tangled web of conflicting Allows, Denys, group memberships, etc … but that course of action is likely to only make your Misconfiguration Debt worse. It’s also likely to leave gaps that a clever attacker can slink through.
We have said this before, I know. Apparently it bears repeating.
Lastly, we only ran this scenario because it was in the marketing material of a vendor who sells an AD auditing tool. It’s a daft scenario, I know. It’s ridiculous, I know. You’d never see this in ‘The Real World’ … I hope. Regardless, it’s their scenario.
Stay safe out there, and follow best practices. They’re part of IT 101 for a reason.
References
dsacls syntax: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc771151(v=ws.11)
PowerShell & dsacls: https://community.spiceworks.com/topic/1245325-changing-owner-on-ad-objects-via-powershell-or-dsacls
Take ownership with dcacls: https://social.technet.microsoft.com/Forums/en-US/ecd26d0b-47d1-4b80-b71d-7f3a77362e1e/dsaclsexe-and-the-impact-of-takeownership?forum=winserverDS
Disable inheritance on an AD object: https://stackoverflow.com/questions/31721221/disable-inheritance-and-manually-apply-permissions-when-creating-a-folder-in-pow
Set-ADAccountPassword: https://learn.microsoft.com/en-us/powershell/module/activedirectory/set-adaccountpassword?view=windowsserver2022-ps
