start	end	text
4620	9520	Hi everyone, welcome to the Red Team Village and thank you very much for joining my talk.
9660	15720	My name is Petros Koutroumbis and I'm a Red Teamer based in the UK. I have previously worked
15720	21920	as a consultant and I have performed a number of purple and red engagements as well as white box
21920	27920	attack simulations throughout my career. The key focus of this talk, whose title is
27920	34200	having a laugh, is that when we've compromised the user within an Active Directory environment
34200	40260	who can modify an organizational unit, we can modify one of its LDAP attributes in order to
40260	46520	compromise any user, any computer or user object that belongs to that organizational unit or any
46520	53180	of its child OUs. The way we will achieve this is by abusing the way group policy objects are
53180	60740	enforced during the GPO update process. First of all, we'll go through a brief introduction to
60740	68100	how GPOs work at a high level and we'll also talk about how we can look for weak permissions
68100	74220	on organizational units. And lastly, I will demonstrate a new attack vector and how these
74220	80480	weak OU permissions can be abused by an attacker. Before we begin talking about GPOs, I would like
80480	86180	to mention these guys here for the great research on this topic. Make sure you follow them on
86180	91440	Twitter and check out their awesome blog posts. You will definitely learn a lot from them.
92360	98460	Okay, so what is a GPO? Microsoft introduced the concept of group policies in order to allow
98460	102900	administrators to easily control the settings deployed to clients within an Active Directory
102900	109500	environment. GPO settings can only be configured for user and computer accounts and these settings
109500	116300	can range from local group memberships to configuring printers, file shares, registry keys,
116300	121920	and essentially anything that has to do with the Windows environment. Also, GPOs can be either
121920	127480	configured locally or within Active Directory. However, during this presentation we will only
127480	135120	talk about Active Directory GPOs. The two main components of a group policy object are the group
135120	142560	policy container, also called a GPC, and the group policy template, also known as GPT. Another term
142560	148340	you will often see when looking at GPOs is client-side extensions, but this is a bit out of
148340	157400	scope for this presentation. So what is the GPC? GPC exists within Active Directory and contains
157400	163620	information that is needed by the client, such as the version of the GPO, which client-side extensions
163620	170180	are needed to process the GPO content, and where the actual content of the GPO is located. In Active
170180	178140	Directory, each GPO is assigned a unique ID, although this is not globally unique. For example, the
178480	184940	default domain policy has the same GUID in every Active Directory environment. The GPC part of the
184940	191660	GPO can be seen using Active Directory Users and Computers application, or ADAC, by enabling the
191660	196920	advanced features in the view menu. In this screenshot, you can see the policies container on the
196920	203560	left that includes all the group policies within the domain. Each GPO is identified by its unique
203560	211540	ID, and on the right-hand side, you can see that each GPO has a large number of attributes. However,
211540	218020	for the purpose of this talk, we will only focus on the GPC file syspath attribute. This attribute
218020	225720	contains the location of the group policy template. So, what is the group policy template, you may ask?
225720	232880	The GPT contains the actual part of the GPO settings, and is located within the sysfold share
232880	238820	of the domain controller. In this slide, you can see an example folder structure of the GPT on the left.
238920	244640	We have the sysfold share on the top, and the policies folder under the domain name.
244640	249460	Just like the GPC structure we saw earlier, each GPO has a separate folder
250080	259140	within the policies folder, named after its unique ID. Also, every GPO folder has a machine and a
259140	267060	user directory, which contain computer and user settings, respectively. There is also a GPT.ini
267060	273220	file, which contains information about the GPO, such as the version number. Policy settings can
273220	279480	be found in different files, and in different formats, such as xml and inf. In this screenshot, you can
279480	287180	also see an example GPT.tmpl file on the right, which specifies various settings, such as the
287180	294100	minimum password length of eight characters, and a password history size of one. The last thing we
294100	300340	need to mention, related to how GPOs work, is the gplink attribute. Each container object, such as an
300340	308400	OU, has a gplink attribute. Its value contains an LDAP path pointing to the location of the GPO
308400	315000	within AD, as well as the order that the GPOs must be applied, and information regarding the
315000	320460	GPO being enforced or not. In this screenshot, you can see the contents of the gplink attribute
320460	326380	of the finance OU, and also you can see part of the LDAP path pointing to the GPO
327200	336060	assigned to that OU. Okay, so before we go into how we can attack weak OU permissions,
336060	342900	we need to understand how GPOs are applied by the GPO client. First of all, the client reads
342900	348860	the gplink attribute of all containers in its directory structure. So it will start with a
348860	355020	domain, and it will go down the OU hierarchy. The second step is that the client retrieves
355020	360640	the number of attributes associated with each GPO, including the gpcfileSysPath attribute,
360640	368680	and this is done over LDAP. Then the client connects to the location pointed by the gpcfileSysPath,
368680	375500	so it establishes an SMB connection to the SysVault share, where the gpcfileSysPath
375500	382540	attribute points at. And then over this SMB connection, it will retrieve and apply the GPO
382540	389820	settings. In order to determine the level of access that users and groups have over an OU,
390080	394760	a number of permissions can be configured, as with anything in Active Directory.
395120	402920	These can be viewed in the security tab within the properties of an OU using ADAC. Although a number
402920	408080	of Active Directory rights can be assigned, the ones that would allow us to gain full control over
408080	414300	an OU and modify its settings are the ones that you can see here. If we manage to compromise a
414300	421020	user who has any of these rights over an OU, then we will be in a position to exploit any objects
421020	427940	that are members of that OU. If you want to learn more about those rights, make sure you read
427940	434600	the great white paper from SpectreOps, which you can find on the link on the top of the slide.
436020	443140	The easiest way to identify weak ACS within an Active Directory environment is by using
443140	451500	Bloodhound. Bloodhound is a tool that was released in 2016 and was developed by
451500	459440	Waldo, Captain Jesus, and Harmjoy. Bloodhound is a web application that uses graph theory to reveal
459440	464740	relationships between Active Directory components. There's an ingestor called Sharphound
465260	470460	used to collect the data from the AD environment, which is then loaded onto a Neo4j database
470460	476520	for analysis. It can be used from both red and blue teamers in order to identify attack paths
476520	483280	that would allow an attacker to compromise the AD environment. And starting from Sharphound 3,
483280	489860	which was released a few months ago, Sharphound collects OU permissions,
490100	494160	which are helpful for the attack I will describe shortly.
495720	503060	So, how can I compromise users and computers? There are three requirements for the attack to
503060	510700	work. The first one is that you need permission to edit the LDAP attributes of an OU. The second
510700	516020	one is that you need permission to add a computer object in the target domain. And the last
516020	521700	requirement is that you need permission to add DNS records in the target domain. Now, the good news
521700	527880	for the red teamers and the bad news for blue teamers is that the second and third requirements
528600	533680	are allowed by default in AD environments, so they need to be specifically turned off
534820	541680	via GPO. So, in default environments where these are not disabled,
542080	546640	the only real requirement is that we compromise a user who has permission to edit
546640	554560	the LDAP attributes of an OU. So, the easiest way to describe this new attack vector
554560	562080	is by using a scenario. In this scenario, the target domain is called contoso.com.
562080	569220	The compromised user is called Bob Smith and Bob can modify the finance OU.
569720	575140	Bob is also a local administrator on his workstation that is called workstation02.
575820	582820	And you can also see the IP address which is 10.1.1.22. I need to note here that
583700	589840	the requirement for being a local administrator on the workstation is not a requirement for this
589840	596880	attack to work. However, it greatly simplifies things for the purposes of this demo. But we'll
596880	603840	go into that more a little later on. And our target, of course, is Alice Jones who is a member
603840	611040	of the finance OU. Using SharpHound 3 and collecting the data for this small AD environment,
611040	618840	for this demo, you can see that Bob Smith has generic all permission on the finance OU
618840	625860	and the finance OU contains the Alice Jones user. Okay, so here you can see a diagram
626420	631480	of our ATT&CK demo. We have the ATT&CK's infrastructure on the bottom and the corporate
631480	637520	web network on top. Within our ATT&CK's infrastructure, of course, which we control,
637520	643900	we have the Cobalt Strike team server and the rogue domain controller for a fake domain that
643900	652200	we have created called test.contoso.com. The name of the rogue DC is Atlantic and,
652200	659460	of course, the rogue DC and the team server are placed within the same subnet which is 10.2.2.0
659460	667300	slash 24 and is completely segregated from the corporate network. On the top, we can see the
667300	676040	network and on the left, we have the compromised host which is workstation02 and Bob Smith is
676040	682360	logged in there and we have established our C2 channel with this compromised host. On the top,
682360	688680	we have the victim computer, workstation01, where Alice Jones, who is a member of the finance OU,
688680	696320	is logged in. And lastly, on the right, we have the domain controller for the contoso.com domain.
697340	703720	Now, the first thing we need to do for our attack is to add the DNSA record for test.contoso.com,
703720	709400	which will point to the IP address of the compromised host of workstation02 and this
709400	719500	is going to be 10.1.1.22. Now, as you can see on the left, the compromised host has two DNSA records,
719500	724900	workstation02.contoso.com, which was the original one, and test.contoso.com,
724900	730960	both pointing to the same IP address. The second step of our attack is to modify the
730960	739200	gplink attribute of the finance OU, where Alice is a member of, and point it to test.contoso.com.
739200	748340	So, we will modify the LDAPATH of the finance OU gplink attribute and point it to the DNS record
748340	755100	that we added on the first step. The third thing we need to do is that we need to add a new
755100	761420	computer object called test with the same password as Atlantic. Now, Atlantic, as I said earlier,
761420	767260	is the rogue DC that we have in our attackers infrastructure and I will show you a bit later
767260	776080	on how you can do that. Now, when the GPO client on the victim computer initiates the GPO refresh
776080	784620	cycle, or upon the next login of Alice Jones, it will contact the domain controller and query
784620	792380	the gplink attribute of the finance OU. The domain controller will respond with the gplink value that
792380	801000	we modified earlier and it will point it at test.contoso.com, which is the compromised host.
801000	806900	Now, the victim computer will initiate an LDAP connection to test.contoso.com
807420	816040	over on port 389 and we will need to use our Cobalt Strike beacon to initiate a port forwarding
816040	825860	and forward the traffic to our rogue DC. The DC will receive the LDAP query and it will respond
826540	835240	with the gpc file syspath attribute of the GPO that we have configured. This will point to
836780	844460	workstation02.contoso.com slash sysvol and what we need to do now is we need to create a sysvol share
844460	850660	on the compromised host and this is where our local admin rights become relevant because you
850660	858960	need to be a local admin to be able to create a new share on a Windows workstation. Then the gpc
858960	868480	file syspath attribute is read by the victim computer and then an SMB connection is made
868480	876620	to workstation02.contoso.com on the sysvol share to retrieve the malicious GPO settings that we have
876620	886240	configured. Okay, so let's see how this stack can work step by step. First of all, as we said,
886240	892500	we need to add the dnsa record for test.contoso.com and point it to Bob's workstation. We can
892500	903340	do that using paramad, invoke dnsupdate, cmdlet and add the dnsa record for test and the ip will
903340	909840	be the ip of the compromised host where we have our initial beacon and the rel will be contoso.com.
910040	916060	The second step is that since Bob can modify the lwattributes of the finance.ou as we saw
916060	923480	from the bloodhound output, we can change its gplink value. We can do that using powerview
923480	931940	and get domain object and set domain object to modify the value of the gplink attribute
932580	939880	and point it to the malicious gpo we want to push. You can see there in the command from powerview
939880	947440	that we have highlighted two things. The first one is a unique id and the second one is that we need
947440	954600	to add the dc equals test and point so the LDAP path points to the dnsa record that we added
954600	959780	earlier. Now the unique id of the gpo that is highlighted there is something you need to take
959780	964800	note of and I will explain how you can get that a bit later on.
966820	972620	So the client that is processing the gplink attribute will initiate an LDAP connection over
972620	979700	port 389 to test.contoso.com and attempt to retrieve the gpo attributes such as the gpc file
979700	985660	cspa, the version number and a number of other things. Now using port forwarding we can open
985660	990600	port 389 on Bob's workstation, the one that we compromised, and forward the traffic to the
990600	998040	server under our control through our team server. And we can do that in Cobalt Strike using our port
998040	1007040	wd and the ports that we want to forward. The easiest way to simulate legitimate gpo communication
1007040	1014000	is to create a new fake domain controller for a new fake domain called test.contoso.com.
1014000	1020360	We will call the domain controller of our fake domain atlantic and we will also need to create
1020780	1028160	a malicious gpo and get its associated unique id. This unique id is needed when updating the
1028160	1036560	gplink value that we saw earlier and here we just have a screenshot of our fake domain controller.
1036560	1043000	You can see that it's in the test.contoso.com domain and we have created a gpo called malicious
1043000	1048400	gpo and in the details you can see in which domain is configured and also you can see
1048400	1058060	the unique id of the gpo. So we need to copy that and use it in the gplink update process
1058060	1063740	that we did earlier using PowerView. Now for the purposes of this demo I will only add a new
1063740	1069800	registry key that will be created in the victims host when the malicious gpo is applied. But you
1069800	1078700	can do pretty much anything via gpos. Since the fake dc is within our control, we can run
1078700	1084940	mimikatz and get its machine password. Here you can see that we run logon passwords and we have
1084940	1091740	the long string of characters that is the cleartext machine account password for Atlantic
1092360	1096400	and we need to take a note of that because we are going to need it a bit later on.
1097620	1103780	The next step of our attack is to add a new computer object called test in the target domain.
1103860	1109670	The password of test will need to be exactly the same as Atlantic, the one that we got from
1110140	1117140	mimikatz. When creating the new object we need to make sure that there are a few SPNs that are
1117140	1123460	registered as well. So to do this we can modify PowerMod's new machine account function to include
1123460	1130460	the four SPN records that you see on the bottom of this slide and these are needed for the Kerberos
1130460	1139300	authentication to work. So here we use a modified version of PowerMod. You can just simply modify
1139300	1146380	to include whatever SPN records you want and we just create a new machine account password,
1146460	1151380	a new machine account with the same password as Atlantic and we call this new machine account
1151380	1158260	test. And you can see in the output that this was executed successfully. Now one thing I need
1158260	1165100	to note here is that all the commands that I run in this demo are not considered object safe
1165100	1172340	with today's standards. So there is some use of Parcel and a few other things. You can do pretty
1172340	1177040	much the same without using Parcel. You can write your own tooling. There are other
1177040	1184800	tools out there you can use that will help you remain undetected. However,
1184800	1188860	object was not a consideration for this demo and you can do pretty much the same things
1188860	1195940	through other means. Now when the client retrieves the value of the modified GPLink attribute,
1195940	1202100	it will ask for a TGS, a Technical Grinding Service, to ldub slash test dot contoso dot com,
1202100	1206400	which will be encrypted with the hash of the password for the Atlantic computer we
1206400	1211840	provided earlier. Now when our fake domain controller receives the TGS through the port
1211840	1217100	forwarding, it will be able to decrypt it successfully since it will know the password.
1217880	1223680	And then it will allow the communication to move forward and for the client to request
1223680	1231980	the ldub attributes. So let's do a quick recap so far. First, we added the DNSA record for
1231980	1238440	test.contoso.com to point to the compromised host. Then we modified the GPLink attribute to
1238440	1246460	point to test.contoso.com. Then the GPO client will be forced to make an ldub connection to
1246940	1257080	the ROC-DC via port forwarding port 389 through our C2 channel on the compromised host.
1257860	1263020	The client will then request a number of GPO attributes, such as the gpc file syspath,
1263020	1269040	and the fake domain controller will provide whatever we configure it. And then the malicious
1269040	1277680	GPO in our fake test.contoso.com domain will contain the settings we want to post to the victim.
1279180	1286320	So the next step is that now that we've dealt with the gpc part of the GPO, so the ldub part
1286320	1293020	of the GPO, now we need to deal with the gpt part of the GPO, which is the actual settings.
1293160	1299760	The client will connect over SMB, as we said earlier, to wherever the gpc file syspath
1299760	1305760	attribute points at in order to retrieve the GPO settings. This is where our local admin rights on
1305760	1311740	workstation02 are useful on the compromised host. We can use these rights to create a new shared
1311740	1317600	folder called sysvol and allow members of the authenticated users group to read its contents.
1317600	1323380	Now on Windows, you need to be a local administrator to create a new file share,
1323840	1329940	a new shared folder. So this is where these rights are relevant. However, you can do the
1329940	1336860	same thing even if you are not local admin, although it will need a bit more effort.
1339100	1344860	The next thing is to copy the contents of the sysvol share from our fake domain controller
1344860	1352220	to the sysvol share of the workstation02. That way, we will transfer all the malicious
1352220	1358960	settings we want to push, and the GPO client will be able to retrieve them.
1359480	1365140	The next thing, the last thing we need to do actually, is that we need to modify the existing
1365140	1372560	value of the gpc file sysfile attribute of the malicious GPO within the fake test.contoso.com
1372560	1379880	domain to include the following. First of all, we need to change... so we need to point it essentially
1379880	1388440	to the sysvol share we created on workstation02. So we need to change the location to be
1388440	1394480	workstation02.contoso.com and then point it to the sysvol share and the folder we uploaded
1394480	1402380	with the malicious GPO settings. Now, when the client retrieves the gpc file syspath attribute
1402380	1407820	of the GPO, it will know that the GPO settings for the malicious GPO are located in the sysvol
1407820	1412780	share of workstation02. And upon the next GPO refresh cycle, the new registry key
1412780	1418620	is created for Alice Jones, who is a member of the finance OU, and our attack was successful.
1420100	1426900	So the most important thing to remember about this attack is that we used our rogue dc
1426900	1433540	to host the gpc part of the GPO, so the elda part of the GPO, and then we used the compromised
1433540	1439980	workstation on which we were local admins to create a new sysvol share and essentially host
1439980	1448180	the gpt part of the GPO. Now I will show you a demo of how this attack works and walk you
1448180	1458480	through each step. Here we are on the rogue domain controller, the name is Atlantic, and
1458480	1464860	for the test.contoso.com that we created in our attacking infrastructure, the first thing we do
1464860	1473220	is to create a new group policy object. We are naming it malicious GPO, and then we need to go
1473220	1479600	ahead and modify its settings. So as we said, we can do pretty much everything we want with GPOs.
1479600	1485940	We can assign user rights to a user, we can create immediate tasks, but for the purpose of this demo
1485940	1493900	I will just be creating a new test key and have a value of created by malicious GPO, and this
1493900	1502600	will be created on the victim. The next step is to go to the details of the malicious GPO
1502600	1508000	and as you can see there the GPO is creating the test.contoso.com, which is the fake domain we
1508000	1513700	created, and there you can see the unique ID of the GPO. So we need to take a note of that because
1513700	1521450	we are going to need it later. Next we go to the sysvol share of our fake domain controller,
1522100	1528100	and you can see there the gpt part of the GPO. So we need to copy the entire folder which contains
1528100	1534880	the settings of the GPO we just configured, and we just have to rename the folder to contoso.com,
1534880	1540880	and we need to save that folder because we are also going to need it later. The last step for
1540880	1546720	now on the Rogue DC is that we need to go ahead and run Mimikatz. Of course we can do that because
1546720	1554160	we are local administrators and we run logon passwords to get the long clear text machine
1554160	1560120	account password for Atlantic, and we also need to save that as well. So there are three things
1560120	1565820	here that we need to have. The unique ID of the GPO, the folder that contains the GPO settings,
1565820	1573020	so the gpt part of the GPO, and also the long machine account password in clear text. Here we
1573020	1578300	are on our attacking box and we have our Cobalt Strike instance running, and as you can see we
1578300	1586100	already have established a foothold on Bob Smith's workstation within the victim domain,
1586100	1592780	and the IP address is 10.1.1.22, and as you can also see Bob is a local administrator.
1593760	1601260	First of all we need to call invoke DNS update and we add a DNS A record
1601260	1612020	that points to 10.1.1.22 for the test.contoso.com domain. The next step is to use PowerView and get
1612020	1619100	domain object for the finance OU and then run set domain object to modify its gplink attribute.
1619780	1628100	As you can see we modify the LDAP path to point to the GPO that we just created, so we just have the
1628100	1633280	unique ID there, and then we point it to test.contoso.com as well, which is the
1633600	1642120	new DNS record that we added. Then we are using PowerMod again to add a new machine account
1642800	1650760	with the password we got earlier from Mimikatz, and then we name the computer object test,
1651220	1654080	which has the same password as the Atlantean computer.
1654080	1658520	The next step is to create a sysvol folder on Bob's workstation,
1659300	1666740	and we are using our local admin rights to share that folder and make it a share. The only thing
1666740	1671860	that we omit during this demo is that we need to upload the contents of the contoso.com folder we
1671860	1677660	got from our fake domain controller to the sysvol folder we just created on the workstation.
1677660	1686060	After you've done that, we just make the contents of this folder accessible for authenticated users,
1686340	1694920	and the last thing we need to do before our attack is to create a port forwarding
1694920	1702460	and forward port 389 of the victim computer to our rogue domain controller
1702460	1705840	for the LDAP communication to work fine.
1707240	1716080	Now, before launching our attack, the last step is to go to our rogue domain controller,
1716620	1724520	and we need to close what we did earlier, and we need to open ADAC, Active Directory Users and
1724520	1732400	Computers tool, and go to the policies. Find the policy that we just created, the malicious GPO,
1732460	1739540	using its unique ID, and we just need to modify one of its attributes, and specifically
1739540	1748100	the gpc file syspath attribute, so we can make it point to the sysvol share that we created
1748100	1754420	on the workstation we compromised. So we point it to wrk-stn02.contoso.com
1754420	1761920	slash sysvol slash contoso.com, since we renamed the folder, and we leave the rest as they are.
1763020	1770300	If we go ahead and close all the windows, we go to the workstation where the victim logs in,
1770300	1774500	Alice Jones, who is a member of the finance OU, and as you can see in the registrator,
1774500	1780220	there are no extra keys other than the default ones. Now, upon the next GPO refresh cycle,
1780220	1787840	or the next update, or in this case, we force the update, the GPO update to happen now,
1787840	1796620	when the GPO settings are applied, the malicious GPO settings, as you can see, have been applied,
1796620	1803840	and a new test key has been created with the value of create by malicious GPO,
1803840	1811520	and this means that our attack was successful. Thank you very much. Please contact me if you
1811520	1816000	have any questions. I will be available on the chat, and feel free to...