[00:04.620 --> 00:09.520]  Hi everyone, welcome to the Red Team Village and thank you very much for joining my talk.
[00:09.660 --> 00:15.720]  My name is Petros Koutroumbis and I'm a Red Teamer based in the UK. I have previously worked
[00:15.720 --> 00:21.920]  as a consultant and I have performed a number of purple and red engagements as well as white box
[00:21.920 --> 00:27.920]  attack simulations throughout my career. The key focus of this talk, whose title is
[00:27.920 --> 00:34.200]  having a laugh, is that when we've compromised the user within an Active Directory environment
[00:34.200 --> 00:40.260]  who can modify an organizational unit, we can modify one of its LDAP attributes in order to
[00:40.260 --> 00:46.520]  compromise any user, any computer or user object that belongs to that organizational unit or any
[00:46.520 --> 00:53.180]  of its child OUs. The way we will achieve this is by abusing the way group policy objects are
[00:53.180 --> 01:00.740]  enforced during the GPO update process. First of all, we'll go through a brief introduction to
[01:00.740 --> 01:08.100]  how GPOs work at a high level and we'll also talk about how we can look for weak permissions
[01:08.100 --> 01:14.220]  on organizational units. And lastly, I will demonstrate a new attack vector and how these
[01:14.220 --> 01:20.480]  weak OU permissions can be abused by an attacker. Before we begin talking about GPOs, I would like
[01:20.480 --> 01:26.180]  to mention these guys here for the great research on this topic. Make sure you follow them on
[01:26.180 --> 01:31.440]  Twitter and check out their awesome blog posts. You will definitely learn a lot from them.
[01:32.360 --> 01:38.460]  Okay, so what is a GPO? Microsoft introduced the concept of group policies in order to allow
[01:38.460 --> 01:42.900]  administrators to easily control the settings deployed to clients within an Active Directory
[01:42.900 --> 01:49.500]  environment. GPO settings can only be configured for user and computer accounts and these settings
[01:49.500 --> 01:56.300]  can range from local group memberships to configuring printers, file shares, registry keys,
[01:56.300 --> 02:01.920]  and essentially anything that has to do with the Windows environment. Also, GPOs can be either
[02:01.920 --> 02:07.480]  configured locally or within Active Directory. However, during this presentation we will only
[02:07.480 --> 02:15.120]  talk about Active Directory GPOs. The two main components of a group policy object are the group
[02:15.120 --> 02:22.560]  policy container, also called a GPC, and the group policy template, also known as GPT. Another term
[02:22.560 --> 02:28.340]  you will often see when looking at GPOs is client-side extensions, but this is a bit out of
[02:28.340 --> 02:37.400]  scope for this presentation. So what is the GPC? GPC exists within Active Directory and contains
[02:37.400 --> 02:43.620]  information that is needed by the client, such as the version of the GPO, which client-side extensions
[02:43.620 --> 02:50.180]  are needed to process the GPO content, and where the actual content of the GPO is located. In Active
[02:50.180 --> 02:58.140]  Directory, each GPO is assigned a unique ID, although this is not globally unique. For example, the
[02:58.480 --> 03:04.940]  default domain policy has the same GUID in every Active Directory environment. The GPC part of the
[03:04.940 --> 03:11.660]  GPO can be seen using Active Directory Users and Computers application, or ADAC, by enabling the
[03:11.660 --> 03:16.920]  advanced features in the view menu. In this screenshot, you can see the policies container on the
[03:16.920 --> 03:23.560]  left that includes all the group policies within the domain. Each GPO is identified by its unique
[03:23.560 --> 03:31.540]  ID, and on the right-hand side, you can see that each GPO has a large number of attributes. However,
[03:31.540 --> 03:38.020]  for the purpose of this talk, we will only focus on the GPC file syspath attribute. This attribute
[03:38.020 --> 03:45.720]  contains the location of the group policy template. So, what is the group policy template, you may ask?
[03:45.720 --> 03:52.880]  The GPT contains the actual part of the GPO settings, and is located within the sysfold share
[03:52.880 --> 03:58.820]  of the domain controller. In this slide, you can see an example folder structure of the GPT on the left.
[03:58.920 --> 04:04.640]  We have the sysfold share on the top, and the policies folder under the domain name.
[04:04.640 --> 04:09.460]  Just like the GPC structure we saw earlier, each GPO has a separate folder
[04:10.080 --> 04:19.140]  within the policies folder, named after its unique ID. Also, every GPO folder has a machine and a
[04:19.140 --> 04:27.060]  user directory, which contain computer and user settings, respectively. There is also a GPT.ini
[04:27.060 --> 04:33.220]  file, which contains information about the GPO, such as the version number. Policy settings can
[04:33.220 --> 04:39.480]  be found in different files, and in different formats, such as xml and inf. In this screenshot, you can
[04:39.480 --> 04:47.180]  also see an example GPT.tmpl file on the right, which specifies various settings, such as the
[04:47.180 --> 04:54.100]  minimum password length of eight characters, and a password history size of one. The last thing we
[04:54.100 --> 05:00.340]  need to mention, related to how GPOs work, is the gplink attribute. Each container object, such as an
[05:00.340 --> 05:08.400]  OU, has a gplink attribute. Its value contains an LDAP path pointing to the location of the GPO
[05:08.400 --> 05:15.000]  within AD, as well as the order that the GPOs must be applied, and information regarding the
[05:15.000 --> 05:20.460]  GPO being enforced or not. In this screenshot, you can see the contents of the gplink attribute
[05:20.460 --> 05:26.380]  of the finance OU, and also you can see part of the LDAP path pointing to the GPO
[05:27.200 --> 05:36.060]  assigned to that OU. Okay, so before we go into how we can attack weak OU permissions,
[05:36.060 --> 05:42.900]  we need to understand how GPOs are applied by the GPO client. First of all, the client reads
[05:42.900 --> 05:48.860]  the gplink attribute of all containers in its directory structure. So it will start with a
[05:48.860 --> 05:55.020]  domain, and it will go down the OU hierarchy. The second step is that the client retrieves
[05:55.020 --> 06:00.640]  the number of attributes associated with each GPO, including the gpcfileSysPath attribute,
[06:00.640 --> 06:08.680]  and this is done over LDAP. Then the client connects to the location pointed by the gpcfileSysPath,
[06:08.680 --> 06:15.500]  so it establishes an SMB connection to the SysVault share, where the gpcfileSysPath
[06:15.500 --> 06:22.540]  attribute points at. And then over this SMB connection, it will retrieve and apply the GPO
[06:22.540 --> 06:29.820]  settings. In order to determine the level of access that users and groups have over an OU,
[06:30.080 --> 06:34.760]  a number of permissions can be configured, as with anything in Active Directory.
[06:35.120 --> 06:42.920]  These can be viewed in the security tab within the properties of an OU using ADAC. Although a number
[06:42.920 --> 06:48.080]  of Active Directory rights can be assigned, the ones that would allow us to gain full control over
[06:48.080 --> 06:54.300]  an OU and modify its settings are the ones that you can see here. If we manage to compromise a
[06:54.300 --> 07:01.020]  user who has any of these rights over an OU, then we will be in a position to exploit any objects
[07:01.020 --> 07:07.940]  that are members of that OU. If you want to learn more about those rights, make sure you read
[07:07.940 --> 07:14.600]  the great white paper from SpectreOps, which you can find on the link on the top of the slide.
[07:16.020 --> 07:23.140]  The easiest way to identify weak ACS within an Active Directory environment is by using
[07:23.140 --> 07:31.500]  Bloodhound. Bloodhound is a tool that was released in 2016 and was developed by
[07:31.500 --> 07:39.440]  Waldo, Captain Jesus, and Harmjoy. Bloodhound is a web application that uses graph theory to reveal
[07:39.440 --> 07:44.740]  relationships between Active Directory components. There's an ingestor called Sharphound
[07:45.260 --> 07:50.460]  used to collect the data from the AD environment, which is then loaded onto a Neo4j database
[07:50.460 --> 07:56.520]  for analysis. It can be used from both red and blue teamers in order to identify attack paths
[07:56.520 --> 08:03.280]  that would allow an attacker to compromise the AD environment. And starting from Sharphound 3,
[08:03.280 --> 08:09.860]  which was released a few months ago, Sharphound collects OU permissions,
[08:10.100 --> 08:14.160]  which are helpful for the attack I will describe shortly.
[08:15.720 --> 08:23.060]  So, how can I compromise users and computers? There are three requirements for the attack to
[08:23.060 --> 08:30.700]  work. The first one is that you need permission to edit the LDAP attributes of an OU. The second
[08:30.700 --> 08:36.020]  one is that you need permission to add a computer object in the target domain. And the last
[08:36.020 --> 08:41.700]  requirement is that you need permission to add DNS records in the target domain. Now, the good news
[08:41.700 --> 08:47.880]  for the red teamers and the bad news for blue teamers is that the second and third requirements
[08:48.600 --> 08:53.680]  are allowed by default in AD environments, so they need to be specifically turned off
[08:54.820 --> 09:01.680]  via GPO. So, in default environments where these are not disabled,
[09:02.080 --> 09:06.640]  the only real requirement is that we compromise a user who has permission to edit
[09:06.640 --> 09:14.560]  the LDAP attributes of an OU. So, the easiest way to describe this new attack vector
[09:14.560 --> 09:22.080]  is by using a scenario. In this scenario, the target domain is called contoso.com.
[09:22.080 --> 09:29.220]  The compromised user is called Bob Smith and Bob can modify the finance OU.
[09:29.720 --> 09:35.140]  Bob is also a local administrator on his workstation that is called workstation02.
[09:35.820 --> 09:42.820]  And you can also see the IP address which is 10.1.1.22. I need to note here that
[09:43.700 --> 09:49.840]  the requirement for being a local administrator on the workstation is not a requirement for this
[09:49.840 --> 09:56.880]  attack to work. However, it greatly simplifies things for the purposes of this demo. But we'll
[09:56.880 --> 10:03.840]  go into that more a little later on. And our target, of course, is Alice Jones who is a member
[10:03.840 --> 10:11.040]  of the finance OU. Using SharpHound 3 and collecting the data for this small AD environment,
[10:11.040 --> 10:18.840]  for this demo, you can see that Bob Smith has generic all permission on the finance OU
[10:18.840 --> 10:25.860]  and the finance OU contains the Alice Jones user. Okay, so here you can see a diagram
[10:26.420 --> 10:31.480]  of our ATT&CK demo. We have the ATT&CK's infrastructure on the bottom and the corporate
[10:31.480 --> 10:37.520]  web network on top. Within our ATT&CK's infrastructure, of course, which we control,
[10:37.520 --> 10:43.900]  we have the Cobalt Strike team server and the rogue domain controller for a fake domain that
[10:43.900 --> 10:52.200]  we have created called test.contoso.com. The name of the rogue DC is Atlantic and,
[10:52.200 --> 10:59.460]  of course, the rogue DC and the team server are placed within the same subnet which is 10.2.2.0
[10:59.460 --> 11:07.300]  slash 24 and is completely segregated from the corporate network. On the top, we can see the
[11:07.300 --> 11:16.040]  network and on the left, we have the compromised host which is workstation02 and Bob Smith is
[11:16.040 --> 11:22.360]  logged in there and we have established our C2 channel with this compromised host. On the top,
[11:22.360 --> 11:28.680]  we have the victim computer, workstation01, where Alice Jones, who is a member of the finance OU,
[11:28.680 --> 11:36.320]  is logged in. And lastly, on the right, we have the domain controller for the contoso.com domain.
[11:37.340 --> 11:43.720]  Now, the first thing we need to do for our attack is to add the DNSA record for test.contoso.com,
[11:43.720 --> 11:49.400]  which will point to the IP address of the compromised host of workstation02 and this
[11:49.400 --> 11:59.500]  is going to be 10.1.1.22. Now, as you can see on the left, the compromised host has two DNSA records,
[11:59.500 --> 12:04.900]  workstation02.contoso.com, which was the original one, and test.contoso.com,
[12:04.900 --> 12:10.960]  both pointing to the same IP address. The second step of our attack is to modify the
[12:10.960 --> 12:19.200]  gplink attribute of the finance OU, where Alice is a member of, and point it to test.contoso.com.
[12:19.200 --> 12:28.340]  So, we will modify the LDAPATH of the finance OU gplink attribute and point it to the DNS record
[12:28.340 --> 12:35.100]  that we added on the first step. The third thing we need to do is that we need to add a new
[12:35.100 --> 12:41.420]  computer object called test with the same password as Atlantic. Now, Atlantic, as I said earlier,
[12:41.420 --> 12:47.260]  is the rogue DC that we have in our attackers infrastructure and I will show you a bit later
[12:47.260 --> 12:56.080]  on how you can do that. Now, when the GPO client on the victim computer initiates the GPO refresh
[12:56.080 --> 13:04.620]  cycle, or upon the next login of Alice Jones, it will contact the domain controller and query
[13:04.620 --> 13:12.380]  the gplink attribute of the finance OU. The domain controller will respond with the gplink value that
[13:12.380 --> 13:21.000]  we modified earlier and it will point it at test.contoso.com, which is the compromised host.
[13:21.000 --> 13:26.900]  Now, the victim computer will initiate an LDAP connection to test.contoso.com
[13:27.420 --> 13:36.040]  over on port 389 and we will need to use our Cobalt Strike beacon to initiate a port forwarding
[13:36.040 --> 13:45.860]  and forward the traffic to our rogue DC. The DC will receive the LDAP query and it will respond
[13:46.540 --> 13:55.240]  with the gpc file syspath attribute of the GPO that we have configured. This will point to
[13:56.780 --> 14:04.460]  workstation02.contoso.com slash sysvol and what we need to do now is we need to create a sysvol share
[14:04.460 --> 14:10.660]  on the compromised host and this is where our local admin rights become relevant because you
[14:10.660 --> 14:18.960]  need to be a local admin to be able to create a new share on a Windows workstation. Then the gpc
[14:18.960 --> 14:28.480]  file syspath attribute is read by the victim computer and then an SMB connection is made
[14:28.480 --> 14:36.620]  to workstation02.contoso.com on the sysvol share to retrieve the malicious GPO settings that we have
[14:36.620 --> 14:46.240]  configured. Okay, so let's see how this stack can work step by step. First of all, as we said,
[14:46.240 --> 14:52.500]  we need to add the dnsa record for test.contoso.com and point it to Bob's workstation. We can
[14:52.500 --> 15:03.340]  do that using paramad, invoke dnsupdate, cmdlet and add the dnsa record for test and the ip will
[15:03.340 --> 15:09.840]  be the ip of the compromised host where we have our initial beacon and the rel will be contoso.com.
[15:10.040 --> 15:16.060]  The second step is that since Bob can modify the lwattributes of the finance.ou as we saw
[15:16.060 --> 15:23.480]  from the bloodhound output, we can change its gplink value. We can do that using powerview
[15:23.480 --> 15:31.940]  and get domain object and set domain object to modify the value of the gplink attribute
[15:32.580 --> 15:39.880]  and point it to the malicious gpo we want to push. You can see there in the command from powerview
[15:39.880 --> 15:47.440]  that we have highlighted two things. The first one is a unique id and the second one is that we need
[15:47.440 --> 15:54.600]  to add the dc equals test and point so the LDAP path points to the dnsa record that we added
[15:54.600 --> 15:59.780]  earlier. Now the unique id of the gpo that is highlighted there is something you need to take
[15:59.780 --> 16:04.800]  note of and I will explain how you can get that a bit later on.
[16:06.820 --> 16:12.620]  So the client that is processing the gplink attribute will initiate an LDAP connection over
[16:12.620 --> 16:19.700]  port 389 to test.contoso.com and attempt to retrieve the gpo attributes such as the gpc file
[16:19.700 --> 16:25.660]  cspa, the version number and a number of other things. Now using port forwarding we can open
[16:25.660 --> 16:30.600]  port 389 on Bob's workstation, the one that we compromised, and forward the traffic to the
[16:30.600 --> 16:38.040]  server under our control through our team server. And we can do that in Cobalt Strike using our port
[16:38.040 --> 16:47.040]  wd and the ports that we want to forward. The easiest way to simulate legitimate gpo communication
[16:47.040 --> 16:54.000]  is to create a new fake domain controller for a new fake domain called test.contoso.com.
[16:54.000 --> 17:00.360]  We will call the domain controller of our fake domain atlantic and we will also need to create
[17:00.780 --> 17:08.160]  a malicious gpo and get its associated unique id. This unique id is needed when updating the
[17:08.160 --> 17:16.560]  gplink value that we saw earlier and here we just have a screenshot of our fake domain controller.
[17:16.560 --> 17:23.000]  You can see that it's in the test.contoso.com domain and we have created a gpo called malicious
[17:23.000 --> 17:28.400]  gpo and in the details you can see in which domain is configured and also you can see
[17:28.400 --> 17:38.060]  the unique id of the gpo. So we need to copy that and use it in the gplink update process
[17:38.060 --> 17:43.740]  that we did earlier using PowerView. Now for the purposes of this demo I will only add a new
[17:43.740 --> 17:49.800]  registry key that will be created in the victims host when the malicious gpo is applied. But you
[17:49.800 --> 17:58.700]  can do pretty much anything via gpos. Since the fake dc is within our control, we can run
[17:58.700 --> 18:04.940]  mimikatz and get its machine password. Here you can see that we run logon passwords and we have
[18:04.940 --> 18:11.740]  the long string of characters that is the cleartext machine account password for Atlantic
[18:12.360 --> 18:16.400]  and we need to take a note of that because we are going to need it a bit later on.
[18:17.620 --> 18:23.780]  The next step of our attack is to add a new computer object called test in the target domain.
[18:23.860 --> 18:29.670]  The password of test will need to be exactly the same as Atlantic, the one that we got from
[18:30.140 --> 18:37.140]  mimikatz. When creating the new object we need to make sure that there are a few SPNs that are
[18:37.140 --> 18:43.460]  registered as well. So to do this we can modify PowerMod's new machine account function to include
[18:43.460 --> 18:50.460]  the four SPN records that you see on the bottom of this slide and these are needed for the Kerberos
[18:50.460 --> 18:59.300]  authentication to work. So here we use a modified version of PowerMod. You can just simply modify
[18:59.300 --> 19:06.380]  to include whatever SPN records you want and we just create a new machine account password,
[19:06.460 --> 19:11.380]  a new machine account with the same password as Atlantic and we call this new machine account
[19:11.380 --> 19:18.260]  test. And you can see in the output that this was executed successfully. Now one thing I need
[19:18.260 --> 19:25.100]  to note here is that all the commands that I run in this demo are not considered object safe
[19:25.100 --> 19:32.340]  with today's standards. So there is some use of Parcel and a few other things. You can do pretty
[19:32.340 --> 19:37.040]  much the same without using Parcel. You can write your own tooling. There are other
[19:37.040 --> 19:44.800]  tools out there you can use that will help you remain undetected. However,
[19:44.800 --> 19:48.860]  object was not a consideration for this demo and you can do pretty much the same things
[19:48.860 --> 19:55.940]  through other means. Now when the client retrieves the value of the modified GPLink attribute,
[19:55.940 --> 20:02.100]  it will ask for a TGS, a Technical Grinding Service, to ldub slash test dot contoso dot com,
[20:02.100 --> 20:06.400]  which will be encrypted with the hash of the password for the Atlantic computer we
[20:06.400 --> 20:11.840]  provided earlier. Now when our fake domain controller receives the TGS through the port
[20:11.840 --> 20:17.100]  forwarding, it will be able to decrypt it successfully since it will know the password.
[20:17.880 --> 20:23.680]  And then it will allow the communication to move forward and for the client to request
[20:23.680 --> 20:31.980]  the ldub attributes. So let's do a quick recap so far. First, we added the DNSA record for
[20:31.980 --> 20:38.440]  test.contoso.com to point to the compromised host. Then we modified the GPLink attribute to
[20:38.440 --> 20:46.460]  point to test.contoso.com. Then the GPO client will be forced to make an ldub connection to
[20:46.940 --> 20:57.080]  the ROC-DC via port forwarding port 389 through our C2 channel on the compromised host.
[20:57.860 --> 21:03.020]  The client will then request a number of GPO attributes, such as the gpc file syspath,
[21:03.020 --> 21:09.040]  and the fake domain controller will provide whatever we configure it. And then the malicious
[21:09.040 --> 21:17.680]  GPO in our fake test.contoso.com domain will contain the settings we want to post to the victim.
[21:19.180 --> 21:26.320]  So the next step is that now that we've dealt with the gpc part of the GPO, so the ldub part
[21:26.320 --> 21:33.020]  of the GPO, now we need to deal with the gpt part of the GPO, which is the actual settings.
[21:33.160 --> 21:39.760]  The client will connect over SMB, as we said earlier, to wherever the gpc file syspath
[21:39.760 --> 21:45.760]  attribute points at in order to retrieve the GPO settings. This is where our local admin rights on
[21:45.760 --> 21:51.740]  workstation02 are useful on the compromised host. We can use these rights to create a new shared
[21:51.740 --> 21:57.600]  folder called sysvol and allow members of the authenticated users group to read its contents.
[21:57.600 --> 22:03.380]  Now on Windows, you need to be a local administrator to create a new file share,
[22:03.840 --> 22:09.940]  a new shared folder. So this is where these rights are relevant. However, you can do the
[22:09.940 --> 22:16.860]  same thing even if you are not local admin, although it will need a bit more effort.
[22:19.100 --> 22:24.860]  The next thing is to copy the contents of the sysvol share from our fake domain controller
[22:24.860 --> 22:32.220]  to the sysvol share of the workstation02. That way, we will transfer all the malicious
[22:32.220 --> 22:38.960]  settings we want to push, and the GPO client will be able to retrieve them.
[22:39.480 --> 22:45.140]  The next thing, the last thing we need to do actually, is that we need to modify the existing
[22:45.140 --> 22:52.560]  value of the gpc file sysfile attribute of the malicious GPO within the fake test.contoso.com
[22:52.560 --> 22:59.880]  domain to include the following. First of all, we need to change... so we need to point it essentially
[22:59.880 --> 23:08.440]  to the sysvol share we created on workstation02. So we need to change the location to be
[23:08.440 --> 23:14.480]  workstation02.contoso.com and then point it to the sysvol share and the folder we uploaded
[23:14.480 --> 23:22.380]  with the malicious GPO settings. Now, when the client retrieves the gpc file syspath attribute
[23:22.380 --> 23:27.820]  of the GPO, it will know that the GPO settings for the malicious GPO are located in the sysvol
[23:27.820 --> 23:32.780]  share of workstation02. And upon the next GPO refresh cycle, the new registry key
[23:32.780 --> 23:38.620]  is created for Alice Jones, who is a member of the finance OU, and our attack was successful.
[23:40.100 --> 23:46.900]  So the most important thing to remember about this attack is that we used our rogue dc
[23:46.900 --> 23:53.540]  to host the gpc part of the GPO, so the elda part of the GPO, and then we used the compromised
[23:53.540 --> 23:59.980]  workstation on which we were local admins to create a new sysvol share and essentially host
[23:59.980 --> 24:08.180]  the gpt part of the GPO. Now I will show you a demo of how this attack works and walk you
[24:08.180 --> 24:18.480]  through each step. Here we are on the rogue domain controller, the name is Atlantic, and
[24:18.480 --> 24:24.860]  for the test.contoso.com that we created in our attacking infrastructure, the first thing we do
[24:24.860 --> 24:33.220]  is to create a new group policy object. We are naming it malicious GPO, and then we need to go
[24:33.220 --> 24:39.600]  ahead and modify its settings. So as we said, we can do pretty much everything we want with GPOs.
[24:39.600 --> 24:45.940]  We can assign user rights to a user, we can create immediate tasks, but for the purpose of this demo
[24:45.940 --> 24:53.900]  I will just be creating a new test key and have a value of created by malicious GPO, and this
[24:53.900 --> 25:02.600]  will be created on the victim. The next step is to go to the details of the malicious GPO
[25:02.600 --> 25:08.000]  and as you can see there the GPO is creating the test.contoso.com, which is the fake domain we
[25:08.000 --> 25:13.700]  created, and there you can see the unique ID of the GPO. So we need to take a note of that because
[25:13.700 --> 25:21.450]  we are going to need it later. Next we go to the sysvol share of our fake domain controller,
[25:22.100 --> 25:28.100]  and you can see there the gpt part of the GPO. So we need to copy the entire folder which contains
[25:28.100 --> 25:34.880]  the settings of the GPO we just configured, and we just have to rename the folder to contoso.com,
[25:34.880 --> 25:40.880]  and we need to save that folder because we are also going to need it later. The last step for
[25:40.880 --> 25:46.720]  now on the Rogue DC is that we need to go ahead and run Mimikatz. Of course we can do that because
[25:46.720 --> 25:54.160]  we are local administrators and we run logon passwords to get the long clear text machine
[25:54.160 --> 26:00.120]  account password for Atlantic, and we also need to save that as well. So there are three things
[26:00.120 --> 26:05.820]  here that we need to have. The unique ID of the GPO, the folder that contains the GPO settings,
[26:05.820 --> 26:13.020]  so the gpt part of the GPO, and also the long machine account password in clear text. Here we
[26:13.020 --> 26:18.300]  are on our attacking box and we have our Cobalt Strike instance running, and as you can see we
[26:18.300 --> 26:26.100]  already have established a foothold on Bob Smith's workstation within the victim domain,
[26:26.100 --> 26:32.780]  and the IP address is 10.1.1.22, and as you can also see Bob is a local administrator.
[26:33.760 --> 26:41.260]  First of all we need to call invoke DNS update and we add a DNS A record
[26:41.260 --> 26:52.020]  that points to 10.1.1.22 for the test.contoso.com domain. The next step is to use PowerView and get
[26:52.020 --> 26:59.100]  domain object for the finance OU and then run set domain object to modify its gplink attribute.
[26:59.780 --> 27:08.100]  As you can see we modify the LDAP path to point to the GPO that we just created, so we just have the
[27:08.100 --> 27:13.280]  unique ID there, and then we point it to test.contoso.com as well, which is the
[27:13.600 --> 27:22.120]  new DNS record that we added. Then we are using PowerMod again to add a new machine account
[27:22.800 --> 27:30.760]  with the password we got earlier from Mimikatz, and then we name the computer object test,
[27:31.220 --> 27:34.080]  which has the same password as the Atlantean computer.
[27:34.080 --> 27:38.520]  The next step is to create a sysvol folder on Bob's workstation,
[27:39.300 --> 27:46.740]  and we are using our local admin rights to share that folder and make it a share. The only thing
[27:46.740 --> 27:51.860]  that we omit during this demo is that we need to upload the contents of the contoso.com folder we
[27:51.860 --> 27:57.660]  got from our fake domain controller to the sysvol folder we just created on the workstation.
[27:57.660 --> 28:06.060]  After you've done that, we just make the contents of this folder accessible for authenticated users,
[28:06.340 --> 28:14.920]  and the last thing we need to do before our attack is to create a port forwarding
[28:14.920 --> 28:22.460]  and forward port 389 of the victim computer to our rogue domain controller
[28:22.460 --> 28:25.840]  for the LDAP communication to work fine.
[28:27.240 --> 28:36.080]  Now, before launching our attack, the last step is to go to our rogue domain controller,
[28:36.620 --> 28:44.520]  and we need to close what we did earlier, and we need to open ADAC, Active Directory Users and
[28:44.520 --> 28:52.400]  Computers tool, and go to the policies. Find the policy that we just created, the malicious GPO,
[28:52.460 --> 28:59.540]  using its unique ID, and we just need to modify one of its attributes, and specifically
[28:59.540 --> 29:08.100]  the gpc file syspath attribute, so we can make it point to the sysvol share that we created
[29:08.100 --> 29:14.420]  on the workstation we compromised. So we point it to wrk-stn02.contoso.com
[29:14.420 --> 29:21.920]  slash sysvol slash contoso.com, since we renamed the folder, and we leave the rest as they are.
[29:23.020 --> 29:30.300]  If we go ahead and close all the windows, we go to the workstation where the victim logs in,
[29:30.300 --> 29:34.500]  Alice Jones, who is a member of the finance OU, and as you can see in the registrator,
[29:34.500 --> 29:40.220]  there are no extra keys other than the default ones. Now, upon the next GPO refresh cycle,
[29:40.220 --> 29:47.840]  or the next update, or in this case, we force the update, the GPO update to happen now,
[29:47.840 --> 29:56.620]  when the GPO settings are applied, the malicious GPO settings, as you can see, have been applied,
[29:56.620 --> 30:03.840]  and a new test key has been created with the value of create by malicious GPO,
[30:03.840 --> 30:11.520]  and this means that our attack was successful. Thank you very much. Please contact me if you
[30:11.520 --> 30:16.000]  have any questions. I will be available on the chat, and feel free to...