Hi everyone, welcome to the Red Team Village and thank you very much for joining my talk.
My name is Petros Koutroumbis and I'm a Red Teamer based in the UK. I have previously worked
as a consultant and I have performed a number of purple and red engagements as well as white box
attack simulations throughout my career. The key focus of this talk, whose title is
having a laugh, is that when we've compromised the user within an Active Directory environment
who can modify an organizational unit, we can modify one of its LDAP attributes in order to
compromise any user, any computer or user object that belongs to that organizational unit or any
of its child OUs. The way we will achieve this is by abusing the way group policy objects are
enforced during the GPO update process. First of all, we'll go through a brief introduction to
how GPOs work at a high level and we'll also talk about how we can look for weak permissions
on organizational units. And lastly, I will demonstrate a new attack vector and how these
weak OU permissions can be abused by an attacker. Before we begin talking about GPOs, I would like
to mention these guys here for the great research on this topic. Make sure you follow them on
Twitter and check out their awesome blog posts. You will definitely learn a lot from them.
Okay, so what is a GPO? Microsoft introduced the concept of group policies in order to allow
administrators to easily control the settings deployed to clients within an Active Directory
environment. GPO settings can only be configured for user and computer accounts and these settings
can range from local group memberships to configuring printers, file shares, registry keys,
and essentially anything that has to do with the Windows environment. Also, GPOs can be either
configured locally or within Active Directory. However, during this presentation we will only
talk about Active Directory GPOs. The two main components of a group policy object are the group
policy container, also called a GPC, and the group policy template, also known as GPT. Another term
you will often see when looking at GPOs is client-side extensions, but this is a bit out of
scope for this presentation. So what is the GPC? GPC exists within Active Directory and contains
information that is needed by the client, such as the version of the GPO, which client-side extensions
are needed to process the GPO content, and where the actual content of the GPO is located. In Active
Directory, each GPO is assigned a unique ID, although this is not globally unique. For example, the
default domain policy has the same GUID in every Active Directory environment. The GPC part of the
GPO can be seen using Active Directory Users and Computers application, or ADAC, by enabling the
advanced features in the view menu. In this screenshot, you can see the policies container on the
left that includes all the group policies within the domain. Each GPO is identified by its unique
ID, and on the right-hand side, you can see that each GPO has a large number of attributes. However,
for the purpose of this talk, we will only focus on the GPC file syspath attribute. This attribute
contains the location of the group policy template. So, what is the group policy template, you may ask?
The GPT contains the actual part of the GPO settings, and is located within the sysfold share
of the domain controller. In this slide, you can see an example folder structure of the GPT on the left.
We have the sysfold share on the top, and the policies folder under the domain name.
Just like the GPC structure we saw earlier, each GPO has a separate folder
within the policies folder, named after its unique ID. Also, every GPO folder has a machine and a
user directory, which contain computer and user settings, respectively. There is also a GPT.ini
file, which contains information about the GPO, such as the version number. Policy settings can
be found in different files, and in different formats, such as xml and inf. In this screenshot, you can
also see an example GPT.tmpl file on the right, which specifies various settings, such as the
minimum password length of eight characters, and a password history size of one. The last thing we
need to mention, related to how GPOs work, is the gplink attribute. Each container object, such as an
OU, has a gplink attribute. Its value contains an LDAP path pointing to the location of the GPO
within AD, as well as the order that the GPOs must be applied, and information regarding the
GPO being enforced or not. In this screenshot, you can see the contents of the gplink attribute
of the finance OU, and also you can see part of the LDAP path pointing to the GPO
assigned to that OU. Okay, so before we go into how we can attack weak OU permissions,
we need to understand how GPOs are applied by the GPO client. First of all, the client reads
the gplink attribute of all containers in its directory structure. So it will start with a
domain, and it will go down the OU hierarchy. The second step is that the client retrieves
the number of attributes associated with each GPO, including the gpcfileSysPath attribute,
and this is done over LDAP. Then the client connects to the location pointed by the gpcfileSysPath,
so it establishes an SMB connection to the SysVault share, where the gpcfileSysPath
attribute points at. And then over this SMB connection, it will retrieve and apply the GPO
settings. In order to determine the level of access that users and groups have over an OU,
a number of permissions can be configured, as with anything in Active Directory.
These can be viewed in the security tab within the properties of an OU using ADAC. Although a number
of Active Directory rights can be assigned, the ones that would allow us to gain full control over
an OU and modify its settings are the ones that you can see here. If we manage to compromise a
user who has any of these rights over an OU, then we will be in a position to exploit any objects
that are members of that OU. If you want to learn more about those rights, make sure you read
the great white paper from SpectreOps, which you can find on the link on the top of the slide.
The easiest way to identify weak ACS within an Active Directory environment is by using
Bloodhound. Bloodhound is a tool that was released in 2016 and was developed by
Waldo, Captain Jesus, and Harmjoy. Bloodhound is a web application that uses graph theory to reveal
relationships between Active Directory components. There's an ingestor called Sharphound
used to collect the data from the AD environment, which is then loaded onto a Neo4j database
for analysis. It can be used from both red and blue teamers in order to identify attack paths
that would allow an attacker to compromise the AD environment. And starting from Sharphound 3,
which was released a few months ago, Sharphound collects OU permissions,
which are helpful for the attack I will describe shortly.
So, how can I compromise users and computers? There are three requirements for the attack to
work. The first one is that you need permission to edit the LDAP attributes of an OU. The second
one is that you need permission to add a computer object in the target domain. And the last
requirement is that you need permission to add DNS records in the target domain. Now, the good news
for the red teamers and the bad news for blue teamers is that the second and third requirements
are allowed by default in AD environments, so they need to be specifically turned off
via GPO. So, in default environments where these are not disabled,
the only real requirement is that we compromise a user who has permission to edit
the LDAP attributes of an OU. So, the easiest way to describe this new attack vector
is by using a scenario. In this scenario, the target domain is called contoso.com.
The compromised user is called Bob Smith and Bob can modify the finance OU.
Bob is also a local administrator on his workstation that is called workstation02.
And you can also see the IP address which is 10.1.1.22. I need to note here that
the requirement for being a local administrator on the workstation is not a requirement for this
attack to work. However, it greatly simplifies things for the purposes of this demo. But we'll
go into that more a little later on. And our target, of course, is Alice Jones who is a member
of the finance OU. Using SharpHound 3 and collecting the data for this small AD environment,
for this demo, you can see that Bob Smith has generic all permission on the finance OU
and the finance OU contains the Alice Jones user. Okay, so here you can see a diagram
of our ATT&CK demo. We have the ATT&CK's infrastructure on the bottom and the corporate
web network on top. Within our ATT&CK's infrastructure, of course, which we control,
we have the Cobalt Strike team server and the rogue domain controller for a fake domain that
we have created called test.contoso.com. The name of the rogue DC is Atlantic and,
of course, the rogue DC and the team server are placed within the same subnet which is 10.2.2.0
slash 24 and is completely segregated from the corporate network. On the top, we can see the
network and on the left, we have the compromised host which is workstation02 and Bob Smith is
logged in there and we have established our C2 channel with this compromised host. On the top,
we have the victim computer, workstation01, where Alice Jones, who is a member of the finance OU,
is logged in. And lastly, on the right, we have the domain controller for the contoso.com domain.
Now, the first thing we need to do for our attack is to add the DNSA record for test.contoso.com,
which will point to the IP address of the compromised host of workstation02 and this
is going to be 10.1.1.22. Now, as you can see on the left, the compromised host has two DNSA records,
workstation02.contoso.com, which was the original one, and test.contoso.com,
both pointing to the same IP address. The second step of our attack is to modify the
gplink attribute of the finance OU, where Alice is a member of, and point it to test.contoso.com.
So, we will modify the LDAPATH of the finance OU gplink attribute and point it to the DNS record
that we added on the first step. The third thing we need to do is that we need to add a new
computer object called test with the same password as Atlantic. Now, Atlantic, as I said earlier,
is the rogue DC that we have in our attackers infrastructure and I will show you a bit later
on how you can do that. Now, when the GPO client on the victim computer initiates the GPO refresh
cycle, or upon the next login of Alice Jones, it will contact the domain controller and query
the gplink attribute of the finance OU. The domain controller will respond with the gplink value that
we modified earlier and it will point it at test.contoso.com, which is the compromised host.
Now, the victim computer will initiate an LDAP connection to test.contoso.com
over on port 389 and we will need to use our Cobalt Strike beacon to initiate a port forwarding
and forward the traffic to our rogue DC. The DC will receive the LDAP query and it will respond
with the gpc file syspath attribute of the GPO that we have configured. This will point to
workstation02.contoso.com slash sysvol and what we need to do now is we need to create a sysvol share
on the compromised host and this is where our local admin rights become relevant because you
need to be a local admin to be able to create a new share on a Windows workstation. Then the gpc
file syspath attribute is read by the victim computer and then an SMB connection is made
to workstation02.contoso.com on the sysvol share to retrieve the malicious GPO settings that we have
configured. Okay, so let's see how this stack can work step by step. First of all, as we said,
we need to add the dnsa record for test.contoso.com and point it to Bob's workstation. We can
do that using paramad, invoke dnsupdate, cmdlet and add the dnsa record for test and the ip will
be the ip of the compromised host where we have our initial beacon and the rel will be contoso.com.
The second step is that since Bob can modify the lwattributes of the finance.ou as we saw
from the bloodhound output, we can change its gplink value. We can do that using powerview
and get domain object and set domain object to modify the value of the gplink attribute
and point it to the malicious gpo we want to push. You can see there in the command from powerview
that we have highlighted two things. The first one is a unique id and the second one is that we need
to add the dc equals test and point so the LDAP path points to the dnsa record that we added
earlier. Now the unique id of the gpo that is highlighted there is something you need to take
note of and I will explain how you can get that a bit later on.
So the client that is processing the gplink attribute will initiate an LDAP connection over
port 389 to test.contoso.com and attempt to retrieve the gpo attributes such as the gpc file
cspa, the version number and a number of other things. Now using port forwarding we can open
port 389 on Bob's workstation, the one that we compromised, and forward the traffic to the
server under our control through our team server. And we can do that in Cobalt Strike using our port
wd and the ports that we want to forward. The easiest way to simulate legitimate gpo communication
is to create a new fake domain controller for a new fake domain called test.contoso.com.
We will call the domain controller of our fake domain atlantic and we will also need to create
a malicious gpo and get its associated unique id. This unique id is needed when updating the
gplink value that we saw earlier and here we just have a screenshot of our fake domain controller.
You can see that it's in the test.contoso.com domain and we have created a gpo called malicious
gpo and in the details you can see in which domain is configured and also you can see
the unique id of the gpo. So we need to copy that and use it in the gplink update process
that we did earlier using PowerView. Now for the purposes of this demo I will only add a new
registry key that will be created in the victims host when the malicious gpo is applied. But you
can do pretty much anything via gpos. Since the fake dc is within our control, we can run
mimikatz and get its machine password. Here you can see that we run logon passwords and we have
the long string of characters that is the cleartext machine account password for Atlantic
and we need to take a note of that because we are going to need it a bit later on.
The next step of our attack is to add a new computer object called test in the target domain.
The password of test will need to be exactly the same as Atlantic, the one that we got from
mimikatz. When creating the new object we need to make sure that there are a few SPNs that are
registered as well. So to do this we can modify PowerMod's new machine account function to include
the four SPN records that you see on the bottom of this slide and these are needed for the Kerberos
authentication to work. So here we use a modified version of PowerMod. You can just simply modify
to include whatever SPN records you want and we just create a new machine account password,
a new machine account with the same password as Atlantic and we call this new machine account
test. And you can see in the output that this was executed successfully. Now one thing I need
to note here is that all the commands that I run in this demo are not considered object safe
with today's standards. So there is some use of Parcel and a few other things. You can do pretty
much the same without using Parcel. You can write your own tooling. There are other
tools out there you can use that will help you remain undetected. However,
object was not a consideration for this demo and you can do pretty much the same things
through other means. Now when the client retrieves the value of the modified GPLink attribute,
it will ask for a TGS, a Technical Grinding Service, to ldub slash test dot contoso dot com,
which will be encrypted with the hash of the password for the Atlantic computer we
provided earlier. Now when our fake domain controller receives the TGS through the port
forwarding, it will be able to decrypt it successfully since it will know the password.
And then it will allow the communication to move forward and for the client to request
the ldub attributes. So let's do a quick recap so far. First, we added the DNSA record for
test.contoso.com to point to the compromised host. Then we modified the GPLink attribute to
point to test.contoso.com. Then the GPO client will be forced to make an ldub connection to
the ROC-DC via port forwarding port 389 through our C2 channel on the compromised host.
The client will then request a number of GPO attributes, such as the gpc file syspath,
and the fake domain controller will provide whatever we configure it. And then the malicious
GPO in our fake test.contoso.com domain will contain the settings we want to post to the victim.
So the next step is that now that we've dealt with the gpc part of the GPO, so the ldub part
of the GPO, now we need to deal with the gpt part of the GPO, which is the actual settings.
The client will connect over SMB, as we said earlier, to wherever the gpc file syspath
attribute points at in order to retrieve the GPO settings. This is where our local admin rights on
workstation02 are useful on the compromised host. We can use these rights to create a new shared
folder called sysvol and allow members of the authenticated users group to read its contents.
Now on Windows, you need to be a local administrator to create a new file share,
a new shared folder. So this is where these rights are relevant. However, you can do the
same thing even if you are not local admin, although it will need a bit more effort.
The next thing is to copy the contents of the sysvol share from our fake domain controller
to the sysvol share of the workstation02. That way, we will transfer all the malicious
settings we want to push, and the GPO client will be able to retrieve them.
The next thing, the last thing we need to do actually, is that we need to modify the existing
value of the gpc file sysfile attribute of the malicious GPO within the fake test.contoso.com
domain to include the following. First of all, we need to change... so we need to point it essentially
to the sysvol share we created on workstation02. So we need to change the location to be
workstation02.contoso.com and then point it to the sysvol share and the folder we uploaded
with the malicious GPO settings. Now, when the client retrieves the gpc file syspath attribute
of the GPO, it will know that the GPO settings for the malicious GPO are located in the sysvol
share of workstation02. And upon the next GPO refresh cycle, the new registry key
is created for Alice Jones, who is a member of the finance OU, and our attack was successful.
So the most important thing to remember about this attack is that we used our rogue dc
to host the gpc part of the GPO, so the elda part of the GPO, and then we used the compromised
workstation on which we were local admins to create a new sysvol share and essentially host
the gpt part of the GPO. Now I will show you a demo of how this attack works and walk you
through each step. Here we are on the rogue domain controller, the name is Atlantic, and
for the test.contoso.com that we created in our attacking infrastructure, the first thing we do
is to create a new group policy object. We are naming it malicious GPO, and then we need to go
ahead and modify its settings. So as we said, we can do pretty much everything we want with GPOs.
We can assign user rights to a user, we can create immediate tasks, but for the purpose of this demo
I will just be creating a new test key and have a value of created by malicious GPO, and this
will be created on the victim. The next step is to go to the details of the malicious GPO
and as you can see there the GPO is creating the test.contoso.com, which is the fake domain we
created, and there you can see the unique ID of the GPO. So we need to take a note of that because
we are going to need it later. Next we go to the sysvol share of our fake domain controller,
and you can see there the gpt part of the GPO. So we need to copy the entire folder which contains
the settings of the GPO we just configured, and we just have to rename the folder to contoso.com,
and we need to save that folder because we are also going to need it later. The last step for
now on the Rogue DC is that we need to go ahead and run Mimikatz. Of course we can do that because
we are local administrators and we run logon passwords to get the long clear text machine
account password for Atlantic, and we also need to save that as well. So there are three things
here that we need to have. The unique ID of the GPO, the folder that contains the GPO settings,
so the gpt part of the GPO, and also the long machine account password in clear text. Here we
are on our attacking box and we have our Cobalt Strike instance running, and as you can see we
already have established a foothold on Bob Smith's workstation within the victim domain,
and the IP address is 10.1.1.22, and as you can also see Bob is a local administrator.
First of all we need to call invoke DNS update and we add a DNS A record
that points to 10.1.1.22 for the test.contoso.com domain. The next step is to use PowerView and get
domain object for the finance OU and then run set domain object to modify its gplink attribute.
As you can see we modify the LDAP path to point to the GPO that we just created, so we just have the
unique ID there, and then we point it to test.contoso.com as well, which is the
new DNS record that we added. Then we are using PowerMod again to add a new machine account
with the password we got earlier from Mimikatz, and then we name the computer object test,
which has the same password as the Atlantean computer.
The next step is to create a sysvol folder on Bob's workstation,
and we are using our local admin rights to share that folder and make it a share. The only thing
that we omit during this demo is that we need to upload the contents of the contoso.com folder we
got from our fake domain controller to the sysvol folder we just created on the workstation.
After you've done that, we just make the contents of this folder accessible for authenticated users,
and the last thing we need to do before our attack is to create a port forwarding
and forward port 389 of the victim computer to our rogue domain controller
for the LDAP communication to work fine.
Now, before launching our attack, the last step is to go to our rogue domain controller,
and we need to close what we did earlier, and we need to open ADAC, Active Directory Users and
Computers tool, and go to the policies. Find the policy that we just created, the malicious GPO,
using its unique ID, and we just need to modify one of its attributes, and specifically
the gpc file syspath attribute, so we can make it point to the sysvol share that we created
on the workstation we compromised. So we point it to wrk-stn02.contoso.com
slash sysvol slash contoso.com, since we renamed the folder, and we leave the rest as they are.
If we go ahead and close all the windows, we go to the workstation where the victim logs in,
Alice Jones, who is a member of the finance OU, and as you can see in the registrator,
there are no extra keys other than the default ones. Now, upon the next GPO refresh cycle,
or the next update, or in this case, we force the update, the GPO update to happen now,
when the GPO settings are applied, the malicious GPO settings, as you can see, have been applied,
and a new test key has been created with the value of create by malicious GPO,
and this means that our attack was successful. Thank you very much. Please contact me if you
have any questions. I will be available on the chat, and feel free to...