 Hi, everyone. Welcome to the Red Team Village. And thank you very much for joining my talk. My name is Petrus Kudrumbis, 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 All You 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 or use. 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 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 six-path 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's 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 the password history size of one. The last thing we need to mention related to how GPOs work is the GPLIN attribute. Each container object, such as an OU, has a GPLIN 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 GPLIN 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 GPLIN 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 GPC file CSPATH attribute, and this is done over LDAP. Then the client connects to the location pointed by the GPC file CSPATH, so it establishes an SMB connection to the CSVOL share where the GPC file CSPATH attribute points out. 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 group 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 writes can be assigned, the ones that would allow us to gain full control over an OU and modified settings are the ones that you can see here. If we manage to compromise a user who has any of these writes 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 writes, 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 WIC 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 SAP HUN 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 attack demo. We have the attackers infrastructure on the bottom and the corporate network on top. Within our attackers 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 corporate network and on the left, we have the compromise host, which is Workstation 02 and Bob Smith is logged in there and we have established our C2 channel with this compromise host. On the top, we have the victim computer, Workstation 01, 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 DNA record for test.contoso.com, which will point to the IP address of the compromise host of Workstation 02 and this is going to be 10.1.1.22. Now, as you can see on the left, the compromise host has two DNA records, Workstation 02.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 GP link attribute of the Finance OU, where Alice is a member of and pointed to test.contoso.com. So, we will modify the LDAPATH of the Finance OU GP link attribute and pointed 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 GP link attribute of the Finance OU. The domain controller will respond with the GP link value that we modified earlier and it will point it at test.contoso.com, which is the compromise 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 the 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 CISPAT attribute of the GPO that we have configured. This will point to workstation02.contoso.com slash CISVOL. And what we need to do now is we need to create a CISVOL share on the compromise 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 CISPATH attribute is read by the victim computer. And then the NSMB connection is made to workstation02.contoso.com on the CISVOL share to retrieve the malicious GPO settings that we have configured. Okay, so let's see how this attack can work step by step. First of all, as we said, we need to add the DNS A record for test.contoso.com and point it to Bob's workstation. We can do that using PowerMod, invoke DNS update, commandlet and add the DNS A record for test. And the IP will be the IP of the compromise host where we have our initial beacon and the realm will be contoso.com. The second step is that since Bob can modify the LW attributes of the finance OU as we saw from the bloodhound output, we can change its GPLINK value. We can do that using PowerView and getDomainObject and setDomainObject 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 other path points to the DNS A record that we added earlier. Now, the unique ID of the GPO that is highlighted there is something you need to take a 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 the 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 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 on the victim's 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 mimicads and get its machine password. Here you can see that we run login passwords and we have the long string of characters that is the clear text 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 mimicads. 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 Opset 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, you can do, there are other tools out there you can use that will help you remain undetected. However, Opset 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 ZP link attribute, it will ask for a TGS, a technique running service to LDAPs last test.contoso.com which will be encrypted with the hash of the password for the Atlantic computer we provide 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 LDAP 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 GP link attribute to point to test.contoso.com. Then the GPO client will be forced to make an LDAP connection to the ROG 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 c-spath 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 LDAP 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 c-spath attribute points at in order to retrieve the GPO settings. This is where our local admin rights on Workstation 02 are useful on the compromised host. We can use these rights to create a new shared folder called sysfold 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 would need some a bit more effort. The next thing is to copy the contents of the sysfold share from our fake domain controller to the sysfold share of the Workstation 02. 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 c-spath 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 sysfold share we created on Workstation 02. So, we need to change the location to be Workstation 02.contoso.com and then point it to the sysfold share and the folder we uploaded with the malicious GPO settings. Now, when the client retrieves the GPC file c-spath attribute of the GPO, it will know that the GPO settings for the malicious GPO are located in the sysfold share of Workstation 02 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 LDA part of the GPO and then we use the compromise Workstation on which we were local admins to create a new sysfold 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 its step. Here we are on the rogue domain controller. The name is Atlantic and for the test.contoso.com we created in our attacking infrastructure. The first thing we do is to create a new group policy object. We are naming it a 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 gonna need it later. Next, we go to the sysfold 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 Mimicads. 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 setting, 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 GP link 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 Mimicats and then we name the computer object test, which has the same password as the Atlantean computer. The next step is to create a sysfold 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 sysfold 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's, of the victim computer to our rogue domain controller for the elder 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 sysfold share that we created on the workstation we compromised. So we pointed to wrksdn02.contoso.com slash sysfold 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 register, 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 forced 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 will be available on the chat and feel free to.