GPO Abuse: “You can’t see me”

by Huy Kha

NOTE:

Someone notice that I’ve used ‘’Everyone’’ in my write-up. This means that computer objects are affected as well, which the GPO won’t process it. A better approach would be ‘’Domain Users’’ — Replace the word ‘’Everyone’’ with ‘‘Domain Users’’’ in my write-up.

Before you read this,

I don’t claim any credits for this blog post. I am pretty sure that someone else already did this way before me. My goal is just to share knowledge with others.

In this blog post. I won’t speak about elevating any kind of privileges, but more remaining hidden in the environment. Which means that you often have to be (already) a Domain Admin to do so.

If you don’t like the post. Feel free to share it in the comments, sorry there’s no thumbs down button.

Introduction

A Group Policy Object is a component of Group Policy that can be used as a resource in Microsoft systems to control user & computer accounts.

Group Policy Object are implemented in an Active Directory system according to various Group Policy settings and can include different configurations such as the password complexity for users, disabling local admin for certain users, and the list goes on.

Which means that you can control anything if you’re able to control a GPO that has been linked somewhere.

Andy Robbins from SpecterOps wrote a great blog post on additional information regarding GPO’s and how they can be abused. I recommend everyone to take a look at it, because it has a lot of useful information.

After searching the internet. I discovered a presentation, again from the guys at SpecterOps, about adding a user to a GPO and giving the WriteDacl permission to backdoor the Default Domain Controllers GPO. Which is a nice one for my inspiration to find other potential ways to backdoor a GPO.

I wanted to share something new regarding a backdoor in a GPO, well at least. I try to. Like I said in the beginning. I’m pretty sure someone else could already have done this in the past.

Need to know

Every OU that has a GPO linked to it. Can be discovered via the attribute that is called gpLink. This is an attribute of the AD Object where the group policy is linked to.

These Group Policy Objects are then placed in the container called Policies.

When creating a new GPO in the Group Policy Management Console. The GPO object will be placed in the CN=Policies.

If you are looking for any inspiration regarding how to configure a ‘’evil’’ GPO as backdoor. Please take a look at this blog post.

Now as an example I’m going to configure that Domain Users is allowed to log on locally to the Domain Controller.

After the evil GPO has been configured properly.

It is time to link it to an OU, so in this case. I’ll pick the Domain Controller as example. We know that the OU=Domain Controllers has the Default Domain Controllers Policy GPO linked to it.

By default the gpLink attribute of the Default Domain Controllers Policy GPO is the following: [LDAP://CN={6AC1786C-016F-11D2-945F-00C04fB984F9}

Our created ‘’evil’’ GPO has the common name (cn)

{FCD40A5F-C0B8–4195–9BF8–932DD4C71BB3}

Not sure if ‘’replace’’ is a good word for this, but lets replace the current GPO of the Domain Controllers to the evil GPO. In this scenario, we’re going to edit the gpLink attribute of the OU=Domain Controllers.

We are going to replace {6AC1786C-016F-11D2–945F-00C04fB984F9} to {FCD40A5F-C0B8–4195–9BF8–932DD4C71BB3}

Here we’re able to see that the gpLink attribute has been changed to something else, which is our evil GPO.

Link enabled means that the Group Policy is linked to the OU — So in this case our policy applies to the objects within the OU.

My ‘’research’’

Not sure if I can call it research, but I just didn’t know how I could describe it. Maybe I should call it a dumbass tutorial?

After replacing the Default Domain Controller Policy GPO to our Backdoor GPO.

It is time to hide our GPO first, by denying read properties for Everyone.

We will get the following results in Group Policy Management Console after we have done that:

BackdoorGPO is disappeared in Group Policy Objects.

Now it is time to ‘’Deny’’ read/write for ‘’Everyone’’ to only the ‘’gpLink’’ attribute at the OU=Domain Controllers for Everyone. Not the entire read properties, just the gpLink attributes.

When we have done that the following results get to show up in the Group Policy Management Console:

In the red, we’re not able to see any GPO linked to the OU=Domain Controllers, because we denied read access for everyone to the gpLinkattribute. Yes, it’s still there of course, but it is remaining hidden.

At Group Policy Management Console, this is the final result of our hiding technique. BackdoorGPO is disappeared from Group Policy Management Console.

So lets say that a Domain Admin is logging on and he wants to make a change for example by adding a new GPO to the OU=Domain Controllers. He or she would not be able to do so. Because we have denied read/writeaccess to the gpLink attribute for Everyone. All the obstacles needs to be disabled first and that starts with being able to discover or see it.

Denying write properties as well for the gpLink attribute allows us to deny someone linking a new GPO to our OU, which could affect the evil GPO that we just created.

This is a pretty difficult to find out, what the root cause are.

Recap

We first have created a backdoor GPO and replaced that one with the Default Domain Controllers Policy at the OU=Domain Controllers

• In this phase we modified the gpLink attribute of it.

• In the second phase we decided to deny read properties for Everyoneat the BackdoorGPO we just created.

• In the third phase we denied read/write access for the specific gpLinkattribute of the OU=Domain Controllers

• Now when taking a look at the gpLink attribute of the OU=Domain Controllers, we get the following result:

But in the reality our hidden GPO is linked to the Domain Controller, but we denied read/write access to it, which means that we can’t see it show up in Group Policy Management Console, and we won’t be able to link a new existing GPO to it, because we also denied write access to it.

Conclusion

Active Directory can be considered as a complex technology for people.

There are different ways to create (different) backdoors that can be easily overlooked by sysadmins.

In my write-up that you’ve just read. We took the Domain Controller as example, but this can also be done on servers or even workstations.

I don’t recommend to do it on the Domain Controller, because that one could look suspicious, but on OU’s such as Servers for example. Might give you a better chance to avoid a investigation.

Besides of all this,

I like the quote from Matt Graeber a lot

So as I told you before in my write-up. I am pretty sure that this has been already done by others, but they might not be interested to write a blog post about it or I’m dumb enough not to find it on the internet.

Make sure that you’re able to answer the following questions:

• Am I aware of how many OU’s I have with a GPO linked to it?
• Am I aware who can create GPO’s and link it to an OU?

How to detect this?

I received some feedback from others on how this specific gpLink attribute could be detected. Yes, I’m pretty sure this can be done on different other ways. But this is what I have for now.

As we have discussed before, the evil GPO needs to be linked first on a OU that has a gpLink attribute.

When ‘’replacing’’ a gpLink attribute of an OU. We are using the Write gpLink Property to do so.

This can be detected through some mechanism in AD, which is called the SACL. According to Microsoft a SACL is the following:

“(SACL) An ACL that controls the generation of audit messages for attempts to access a securable object.”

Now to avoid unnecessary noise in the event log. Select only the Write gpLink attribute.

Now when someone is modifying the gpLink attribute the following event will be generated in the event logs at the DC.

Here we’re able to see the Domain Root was modified. In this example I took the Domain Root (contoso.com) as example.

And last but not least. We are able to identify that the Write Property has been used, which is equal to the 0x20 Access Mask.

About the Author

Author

Bartek Adach

Latest Articles

• Blog2022.12.28Cybersecurity in Education: What Parents, Teachers, and Students Should Know in 2023
• Blog2022.12.15Remembering Leonard Jacobs
• Blog2022.09.30VPN Security: A Pentester's Guide to VPN Vulnerabilities
• Blog2022.08.09AppSec Tales II | Sign-in