Do You Know Who Owns Your Domain?

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

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:

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

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:

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

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.

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:

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:

Then just feed your list into a query:

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:

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

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.

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

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.