1 00:00:04,620 --> 00:00:09,520 Hi everyone, welcome to the Red Team Village and thank you very much for joining my talk. 2 00:00:09,660 --> 00:00:14,060 My name is Petros Koutroumbis and I'm a Red Teamer based in the UK. 3 00:00:14,080 --> 00:00:24,160 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. 4 00:00:24,420 --> 00:00:48,180 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. 5 00:00:48,180 --> 00:00:56,600 The way we will achieve this is by abusing the way group policy objects are enforced during the GPO update process. 6 00:00:57,620 --> 00:01:09,800 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. 7 00:01:09,800 --> 00:01:17,220 And lastly, I will demonstrate a new attack vector and how these weak OU permissions can be abused by an attacker. 8 00:01:17,960 --> 00:01:24,740 Before we begin talking about GPOs, I would like to mention these guys here for the great research on this topic. 9 00:01:24,740 --> 00:01:28,920 Make sure you follow them on Twitter and check out their awesome blog posts. 10 00:01:28,920 --> 00:01:31,440 You will definitely learn a lot from them. 11 00:01:32,360 --> 00:01:34,700 Okay, so what is a GPO? 12 00:01:34,700 --> 00:01:44,020 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. 13 00:01:44,340 --> 00:01:59,600 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. 14 00:02:00,040 --> 00:02:04,960 Also, GPOs can be either configured locally or within Active Directory. 15 00:02:05,020 --> 00:02:10,620 However, during this presentation we will only talk about Active Directory GPOs. 16 00:02:11,160 --> 00:02:21,840 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. 17 00:02:21,840 --> 00:02:30,520 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. 18 00:02:31,320 --> 00:02:34,080 So what is the GPC? 19 00:02:34,200 --> 00:02:49,560 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. 20 00:02:49,560 --> 00:02:56,800 In Active Directory, each GPO is assigned a unique ID, although this is not globally unique. 21 00:02:56,820 --> 00:03:03,200 For example, the default domain policy has the same GUID in every Active Directory environment. 22 00:03:03,360 --> 00:03:13,720 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. 23 00:03:13,900 --> 00:03:20,600 In this screenshot, you can see the policies container on the left that includes all the group policies within the domain. 24 00:03:20,840 --> 00:03:30,780 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. 25 00:03:31,080 --> 00:03:37,140 However, for the purpose of this talk, we will only focus on the GPC file syspath attribute. 26 00:03:37,160 --> 00:03:41,600 This attribute contains the location of the group policy template. 27 00:03:42,580 --> 00:03:45,720 So, what is the group policy template, you may ask? 28 00:03:45,720 --> 00:03:54,360 The GPT contains the actual part of the GPO settings, and is located within the sysfold share of the domain controller. 29 00:03:54,480 --> 00:03:58,820 In this slide, you can see an example folder structure of the GPT on the left. 30 00:03:58,920 --> 00:04:04,640 We have the sysfold share on the top, and the policies folder under the domain name. 31 00:04:04,640 --> 00:04:13,620 Just like the GPC structure we saw earlier, each GPO has a separate folder within the policies folder, named after its unique ID. 32 00:04:14,780 --> 00:04:24,480 Also, every GPO folder has a machine and a user directory, which contain computer and user settings, respectively. 33 00:04:24,480 --> 00:04:31,960 There is also a GPT.ini file , which contains information about the GPO, such as the version number. 34 00:04:32,420 --> 00:04:38,280 Policy settings can be found in different files, and in different formats, such as xml and inf. 35 00:04:38,280 --> 00:04:52,200 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. 36 00:04:52,840 --> 00:04:58,500 The last thing we need to mention, related to how GPOs work, is the gplink attribute. 37 00:04:58,580 --> 00:05:02,840 Each container object, such as an OU, has a gplink attribute. 38 00:05:03,020 --> 00:05:17,400 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. 39 00:05:17,560 --> 00:05:29,620 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. 40 00:05:30,800 --> 00:05:40,520 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. 41 00:05:40,940 --> 00:05:47,640 First of all, the client reads the gplink attribute of all containers in its directory structure. 42 00:05:47,640 --> 00:05:52,000 So it will start with a domain , and it will go down the OU hierarchy. 43 00:05:52,000 --> 00:06:02,760 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. 44 00:06:03,420 --> 00:06:17,100 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. 45 00:06:17,100 --> 00:06:23,440 And then over this SMB connection, it will retrieve and apply the GPO settings. 46 00:06:25,120 --> 00:06:34,760 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. 47 00:06:35,120 --> 00:06:41,740 These can be viewed in the security tab within the properties of an OU using ADAC. 48 00:06:41,940 --> 00:06:52,120 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. 49 00:06:52,120 --> 00:07:02,700 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. 50 00:07:02,940 --> 00:07:14,600 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. 51 00:07:16,020 --> 00:07:24,880 The easiest way to identify weak ACS within an Active Directory environment is by using Bloodhound. 52 00:07:24,900 --> 00:07:34,920 Bloodhound is a tool that was released in 2016 and was developed by Waldo, Captain Jesus, and Harmjoy. 53 00:07:34,980 --> 00:07:42,680 Bloodhound is a web application that uses graph theory to reveal relationships between Active Directory components. 54 00:07:42,780 --> 00:07:52,360 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. 55 00:07:52,460 --> 00:08:00,520 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. 56 00:08:00,780 --> 00:08:14,160 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. 57 00:08:15,720 --> 00:08:18,860 So, how can I compromise users and computers? 58 00:08:19,840 --> 00:08:23,700 There are three requirements for the attack to work. 59 00:08:23,700 --> 00:08:29,220 The first one is that you need permission to edit the LDAP attributes of an OU. 60 00:08:29,440 --> 00:08:35,320 The second one is that you need permission to add a computer object in the target domain. 61 00:08:35,420 --> 00:08:40,080 And the last requirement is that you need permission to add DNS records in the target domain. 62 00:08:40,460 --> 00:08:56,780 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. 63 00:08:56,840 --> 00:09:09,420 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. 64 00:09:10,500 --> 00:09:17,580 So, the easiest way to describe this new attack vector is by using a scenario. 65 00:09:18,180 --> 00:09:22,080 In this scenario, the target domain is called contoso.com. 66 00:09:22,080 --> 00:09:29,220 The compromised user is called Bob Smith and Bob can modify the finance OU. 67 00:09:29,720 --> 00:09:35,140 Bob is also a local administrator on his workstation that is called workstation02. 68 00:09:35,820 --> 00:09:41,120 And you can also see the IP address which is 10.1.1.22. 69 00:09:41,360 --> 00:09:51,040 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. 70 00:09:51,040 --> 00:09:55,800 However, it greatly simplifies things for the purposes of this demo. 71 00:09:55,980 --> 00:10:00,620 But we'll go into that more a little later on. 72 00:10:00,620 --> 00:10:05,540 And our target, of course, is Alice Jones who is a member of the finance OU. 73 00:10:05,820 --> 00:10:23,260 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. 74 00:10:23,300 --> 00:10:27,840 Okay, so here you can see a diagram of our ATT&CK demo. 75 00:10:27,840 --> 00:10:33,580 We have the ATT&CK's infrastructure on the bottom and the corporate web network on top. 76 00:10:33,800 --> 00:10:47,320 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. 77 00:10:47,320 --> 00:11:04,840 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. 78 00:11:05,300 --> 00:11:21,400 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. 79 00:11:21,400 --> 00:11:30,320 On the top, we have the victim computer, workstation01, where Alice Jones, who is a member of the finance OU, is logged in. 80 00:11:30,660 --> 00:11:36,320 And lastly, on the right, we have the domain controller for the contoso.com domain. 81 00:11:37,340 --> 00:11:52,400 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. 82 00:11:52,460 --> 00:12:07,640 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. 83 00:12:07,840 --> 00:12:19,200 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. 84 00:12:19,200 --> 00:12:30,740 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. 85 00:12:31,460 --> 00:12:39,800 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. 86 00:12:39,800 --> 00:12:48,840 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. 87 00:12:49,240 --> 00:13:07,900 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. 88 00:13:07,900 --> 00:13:21,000 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. 89 00:13:21,000 --> 00:13:40,180 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. 90 00:13:40,180 --> 00:13:53,500 The DC will receive the LDAP query and it will respond with the gpc file syspath attribute of the GPO that we have configured. 91 00:13:53,600 --> 00:14:17,280 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. 92 00:14:17,340 --> 00:14:38,100 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. 93 00:14:39,260 --> 00:14:43,580 Okay, so let's see how this stack can work step by step. 94 00:14:43,900 --> 00:14:51,820 First of all, as we said, we need to add the dnsa record for test.contoso.com and point it to Bob's workstation. 95 00:14:52,020 --> 00:15:09,840 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. 96 00:15:10,040 --> 00:15:21,680 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. 97 00:15:21,680 --> 00:15:37,220 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. 98 00:15:37,220 --> 00:15:42,800 You can see there in the command from powerview that we have highlighted two things. 99 00:15:42,800 --> 00:15:55,400 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. 100 00:15:55,400 --> 00:16:04,800 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. 101 00:16:06,820 --> 00:16:22,980 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. 102 00:16:23,120 --> 00:16:34,800 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. 103 00:16:35,120 --> 00:16:41,340 And we can do that in Cobalt Strike using our port wd and the ports that we want to forward. 104 00:16:43,400 --> 00:16:54,000 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. 105 00:16:54,000 --> 00:17:05,160 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. 106 00:17:05,160 --> 00:17:16,560 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. 107 00:17:16,560 --> 00:17:31,380 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. 108 00:17:31,380 --> 00:17:40,100 So we need to copy that and use it in the gplink update process that we did earlier using PowerView. 109 00:17:40,100 --> 00:17:49,340 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. 110 00:17:49,340 --> 00:17:53,180 But you can do pretty much anything via gpos. 111 00:17:54,820 --> 00:18:01,340 Since the fake dc is within our control, we can run mimikatz and get its machine password. 112 00:18:01,640 --> 00:18:16,400 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. 113 00:18:17,620 --> 00:18:23,780 The next step of our attack is to add a new computer object called test in the target domain. 114 00:18:23,860 --> 00:18:31,220 The password of test will need to be exactly the same as Atlantic, the one that we got from mimikatz. 115 00:18:31,440 --> 00:18:38,560 When creating the new object we need to make sure that there are a few SPNs that are registered as well. 116 00:18:38,560 --> 00:18:51,900 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. 117 00:18:54,380 --> 00:18:57,560 So here we use a modified version of PowerMod. 118 00:18:57,560 --> 00:19:12,540 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. 119 00:19:12,940 --> 00:19:17,060 And you can see in the output that this was executed successfully. 120 00:19:17,360 --> 00:19:26,880 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. 121 00:19:26,880 --> 00:19:30,760 So there is some use of Parcel and a few other things. 122 00:19:31,160 --> 00:19:34,760 You can do pretty much the same without using Parcel. 123 00:19:34,760 --> 00:19:36,140 You can write your own tooling. 124 00:19:36,140 --> 00:19:42,580 There are other tools out there you can use that will help you remain undetected. 125 00:19:42,960 --> 00:19:50,840 However, object was not a consideration for this demo and you can do pretty much the same things through other means. 126 00:19:51,980 --> 00:20:07,800 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. 127 00:20:07,800 --> 00:20:17,100 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. 128 00:20:17,880 --> 00:20:25,760 And then it will allow the communication to move forward and for the client to request the ldub attributes. 129 00:20:26,680 --> 00:20:29,280 So let's do a quick recap so far. 130 00:20:29,280 --> 00:20:35,240 First, we added the DNSA record for test.contoso.com to point to the compromised host. 131 00:20:35,240 --> 00:20:40,560 Then we modified the GPLink attribute to point to test.contoso.com. 132 00:20:40,560 --> 00:20:57,080 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. 133 00:20:57,860 --> 00:21:07,180 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. 134 00:21:07,860 --> 00:21:17,680 And then the malicious GPO in our fake test.contoso.com domain will contain the settings we want to post to the victim. 135 00:21:19,180 --> 00:21:33,020 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. 136 00:21:33,160 --> 00:21:43,580 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. 137 00:21:43,680 --> 00:21:48,960 This is where our local admin rights on workstation02 are useful on the compromised host. 138 00:21:49,140 --> 00:21:57,600 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. 139 00:21:57,600 --> 00:22:05,120 Now on Windows, you need to be a local administrator to create a new file share, a new shared folder. 140 00:22:05,120 --> 00:22:08,680 So this is where these rights are relevant. 141 00:22:08,680 --> 00:22:16,860 However, you can do the same thing even if you are not local admin, although it will need a bit more effort. 142 00:22:19,100 --> 00:22:28,400 The next thing is to copy the contents of the sysvol share from our fake domain controller to the sysvol share of the workstation02. 143 00:22:28,400 --> 00:22:38,960 That way, we will transfer all the malicious settings we want to push, and the GPO client will be able to retrieve them. 144 00:22:39,480 --> 00:22:55,560 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. 145 00:22:55,560 --> 00:23:04,680 First of all, we need to change... so we need to point it essentially to the sysvol share we created on workstation02. 146 00:23:04,680 --> 00:23:16,660 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. 147 00:23:19,020 --> 00:23:29,840 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. 148 00:23:29,840 --> 00:23:38,620 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. 149 00:23:40,100 --> 00:24:02,880 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. 150 00:24:04,400 --> 00:24:10,300 Now I will show you a demo of how this attack works and walk you through each step. 151 00:24:12,120 --> 00:24:28,360 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. 152 00:24:28,360 --> 00:24:36,240 We are naming it malicious GPO, and then we need to go ahead and modify its settings. 153 00:24:36,420 --> 00:24:39,600 So as we said, we can do pretty much everything we want with GPOs. 154 00:24:39,600 --> 00:24:55,940 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. 155 00:24:57,920 --> 00:25:12,100 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. 156 00:25:12,100 --> 00:25:15,160 So we need to take a note of that because we are going to need it later. 157 00:25:16,380 --> 00:25:25,640 Next we go to the sysvol share of our fake domain controller, and you can see there the gpt part of the GPO. 158 00:25:25,640 --> 00:25:38,820 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. 159 00:25:38,920 --> 00:25:45,220 The last step for now on the Rogue DC is that we need to go ahead and run Mimikatz. 160 00:25:45,220 --> 00:25:59,280 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. 161 00:25:59,280 --> 00:26:01,440 So there are three things here that we need to have. 162 00:26:01,500 --> 00:26:12,400 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. 163 00:26:12,400 --> 00:26:32,780 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. 164 00:26:33,760 --> 00:26:47,340 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. 165 00:26:47,340 --> 00:26:59,100 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. 166 00:26:59,780 --> 00:27:15,700 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. 167 00:27:15,860 --> 00:27:34,080 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. 168 00:27:34,080 --> 00:27:44,600 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. 169 00:27:45,620 --> 00:27:57,660 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. 170 00:27:57,660 --> 00:28:25,840 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. 171 00:28:27,240 --> 00:28:48,440 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. 172 00:28:48,440 --> 00:29:10,120 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. 173 00:29:10,120 --> 00:29:21,920 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. 174 00:29:23,020 --> 00:29:37,500 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. 175 00:29:37,620 --> 00:30:03,840 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, 176 00:30:03,840 --> 00:30:07,000 and this means that our attack was successful. 177 00:30:07,780 --> 00:30:09,600 Thank you very much. 178 00:30:09,660 --> 00:30:12,760 Please contact me if you have any questions. 179 00:30:12,760 --> 00:30:16,000 I will be available on the chat, and feel free to...