Jump to content
Nytro

GPO Abuse and You

Recommended Posts

GPO Abuse and You

I recently took the Red Team Tactics course through SpecterOps (which is a great course and I highly recommend everyone take it if given the opportunity) and one of the topics that the instructors touched on briefly was abusing Group Policy Objects (GPOs) to exploit a domain. While I had known about Group Policy (and even used it for network reconnaissance while on target) I had never thought about using them as a lateral movement technique. So I started digging.

Talking to fellow Red Teamers made me realize that use of GPOs to laterally pivot through networks isn’t anything new, but I was somewhat disheartened by how others used this technique. From the small (very small, admittedly) sample of people I discussed this with, it appears the common technique is to RDP onto a domain controller or use the Group Policy plugin for Microsoft Management Console (MMC) in order to manipulate GPOs. The problem with these techniques is they either require domain admin credentials (in the case of RDP) or a proxy connection into the network (in the case of utilizing MMC). If you already have clear-text domain admin credentials, then utilizing GPOs for lateral movement is a moot point. Just get the hashes you need through DCSync and laterally move to your target through other means. On a different note, utilizing a proxy connection into the network to use MMC can result in more network traffic that can get you caught by defenders.

Which leads me to the question I wanted to answer. Is it possible to manipulate GPOs via command-line (without RDP or MMC)? So I started doing research. In the post below, I will discuss what I discovered about using GPOs for exploitation purposes. Additionally, I figured I would talk a little bit about what GPOs actually do and what they look like (for those who, like me, might not know). A lot of this information is pulled from Andy Robbin’s (wald0) GPO post and Will Schroeder’s (harmj0y) similar GPO post. If you already know this, I would recommend just skipping on down to the fun part about abusing these policies!


An Introduction to GPOs

GPOs are one of the mechanisms used to manage large Windows enterprise networks. They allow admins to push out system changes to groups of devices on a network. Admins will decide exactly what changes they want to make to a group of devices, create the GPO, and then apply the GPO to an organization unit, or OU. This is typically all done either on the actual domain controller for a network (through the Group Policy Management Console) or from another system on the network through the use of Microsoft Management Console (with the Group Policy Management plug-in).

image

So what exactly can you do with GPOs? The proverbial sky seems to be the limit. Do you want to add local users to a group of computers? There’s a GPO for that. Do you want to change power settings for all laptops connected to your domain? There’s a GPO for that. Do you want to add a startup or shutdown script to certain computers? There is a GPO for that. Do you want to add or remove specific registry keys or values? Well, there’s a GPO for that too.

So what do GPOs actually look like? As mentioned above, they can be created through the Group Policy Management Console on domain controllers or with the plug-in for Microsoft Management Console. Once they are created, they are viewable in Active Directory under the grouppolicycontainer objectclass. This can be done using either a tool like PowerView/SharpView or using the Windows tool DSQuery.

image

Each GPO in a domain will have three distinguishing attributes: a display name, a name, and an objectguid. The display name, assigned at creation, is a human-readable name for the GPO, a name is the actual “name” of the GPO (yeah, confusing), and the objectguid is a globally unique parameter for identifying the GPO in the domain. Additionally, each GPO has a few other attributes which help us to understand more about what they do (since display names can often be unclear). The attributes I want to focus on are gpcFilePath, gpcMachineExtensionNames, gpcUserExtensionNames, and versionnumber. The gpcFilePath attributepoints to where the GPO files exist on disk. This location is in the SYSVOL directory/share. The gpcMachineExtensionNames and gpcUserExtensionNames are GUID-esque extensions which appear when GPOs are configured to do certain things, such as scheduled tasks (a handy list of these GUIDs can be found here). The versionnumber attribute is an integer which increments every time that there is a change in the GPO. This attribute is critical for computers knowing when there are changes in a GPO.

Another important attribute to mention when talking about GPOs is the gplink field. This isn’t a field you’ll find when looking at a GPO in Active Directory, but instead when you look at OUs in the network. The gplink will tell you what GPOs are applied to an OU. Since multiple GPOs can be applied to the same OU, you will find all GPOs listed in one field. The order they are in appears to be, in my experience, based on the order that they are applied to the OU (based on priority) when a system reaches out for policy updates.

image

As mentioned above with the gpcFilePath, each GPO also has a presence on the file system of the domain controller. In the SYSVOL share there is a policies folder which contains a folder for each GPO, sorted by GUIDs. You can find these policy folders remotely at \<domain>\sysvol\<domain>\policies or locally on the domain controller at C:\Windows\SYSVOL\SYSVOL\<domain>\Policies. Within these folders are any files necessary for the configuration changes which the GPO is set to apply. If there are necessary scripts for the GPO, those are in here. If there is a registry change to apply through the GPO, there will be a registry.pol file located in these folders.

image

Abusing GPOs for Fun and Profit

So what is the “so-what” factor of GPOs? Why should we as Red Teamers care about using them? Well, like everything else in a Windows network, GPOs can be misconfigured and that misconfiguration opens up a whole range of possibilities for us. And this is the part that got me excited to write this and where I did a ton of research into how GPOs are applied in a network. What if we as Red Teamers could target GPOs as a means of expanding our access or gaining SYSTEM-access on targets we didn’t previously have SYSTEM-access on? All before domain compromise!? One of the cool things about enumerating GPOs is stumbling upon a GPO that can be edited by users other than domain admins. Windows allows admins to assign permissions to GPOs in a similar fashion to files and directories.

image

In the above picture we have what looks like fairly hardened delegation of GPO editing privileges. Your typical domain admins and enterprise admins can make changes, but no one else. On the other hand, below you’ll see that a random user has privileges with another GPO…

image

As seen above, other user accounts and service accounts could be granted the permission to edit a specific GPO. There are two easy ways to enumerate these permissions. The first, and simplest, is using the windows executable icacls.exe. You can point icacls.exe at the folder in SYSVOL related to the GPO in question and see the permissions assigned to that GPO. Below is the icacls.exe result for a GPO in my home test network (which conveniently has this normaluser guy added in!).

image

The other easy way of enumerating GPO permissions is en masse using BloodHound. One of the cool things which BloodHound spits out after running is GPO information and what users have permissions to edit those GPOs. This is a great way of figuring out the road from a user account that you have credentials for all the way to domain compromise. Just be careful, it can generate a LOT of network traffic. I won’t be going into detail about how to use BloodHound here, but be sure to check out the BloodHound wiki if you have any questions about it  (located here).

With this information, how exactly can we manipulate GPOs for expanding our access (and is it possible to do this via the command-line)? The answer I came up with took the form of a tool written in C# which allows a user to query for necessary information on a GPO and then use that information to set certain attributes in Active Directory, allowing a user to abuse the GPO. Since this is the first tool I have written, I wanted to give it a fun name: METRONOME (get it? C#? Music? Metronomes?). I decided to focus my efforts for the time being on two techniques for expansion of access using GPOs and this tool: adding scheduled tasks to a computer and adding users to a local administrator group.

Leveraging Scheduled Tasks for GPOs   

Scheduled tasks exist as a configuration change in GPOs under both Computer and User configuration changes under Preferences and Control Panel Settings. When added as a configuration change, three things are added to the GPO. First, a unique extension name ([{AADCED64-746C-4633-A97C-D61349046527}{CAB54552-DEEA-4691-817E-ED4A4D1AFC72}]) is added to the gpcMachineExtensionNames field (or gpcUserExtensionNames field) in Active Directory and the versionnumber field is incremented to show a change. In the file system for the GPO, the XML for the scheduled task will also appear in the <policy>\Machine\Preferences\Scheduled Task folder as the file ScheduledTask.xml. Multiple tasks can be added per GPO, but only one XML file will be present (with the multiple scheduled tasks being wrapped in this file).

If you are targeting a GPO which does not apply any scheduled tasks, there are a few things that need to be done. First, the gpcMachineExtensionNames field in Active Directory needs to be updated with the unique extension name above and the versionnumber field needs to be incremented so machines know there is a change in the GPO. Both of these changes can be done with METRONOME. First, you use the tool to query the existing attributes and then use these existing attributes to add the unique extension name and increment the version number.

image

Once the Active Directory attributes are changed, the scheduled task XML needs to be added to the scheduled task folder on the SYSVOL share. This is where the GPO will look for any scheduled task XML when updating configurations applied. These XMLs can either be setting tasks on a schedule or they can be used to apply an immediate task to the host. Additionally, these tasks can be targeted via hostname (DNS or NetBIOS) or IP address. This is useful if you are trying to laterally pivot to a specific host or if you simply want to limit the effect your task might have on a network (i.e. if the GPO is applied to an OU that contains thousands of hosts).

image

With these pieces in place, the only thing left to do is wait. Unless changed (via GPO) workstations and servers on a network will check for updates to GPOs every 90 to 120 minutes (domain controllers update every 5 minutes). If you are feeling impatient and are trying to affect change on the computer you are currently on, you can also run GPUPDATE /FORCE. This can be run as a normal user and will force the host to check for GPO updates and apply any changes.

When you are finished with the scheduled task, clean up is straight forward. METRONOMEl can be used to set the Active Directory attributes back to their original state and then you simply need to remove the task XML which you added to the policy folder. Keep in mind though that you will also have to remove the task from every computer to which the GPO was applied. This is why using targeted tasks is useful. If you are concerned with clean up it can be difficult to clean up all hosts that the GPO applies to (especially if that OU the GPO applies to is large or stretches across multiple OUs).

image

If the GPO you are targeting already applies a task, then all you need to do is slip your task into the task XML file which already exists in the policy folders. Since the GPO is already configured to push out a scheduled task, there is no need to update the gpcMachineExtensionsName field, only the versionnumber field (which METRONOME can do). Once you update that you just wait for the GPO to update on its own or run the GPUPDATE executable to force an update. Once you are finished, all you need to do is delete the task out of the task XML file. Below is a great example simply slipping in your task. You’ll see that the third task in this XML is my “malicious” task (so creative) running as SYSTEM on all hosts in an OU (since I don’t target any specific hosts).

image

I wanted to try this with an actual backdoor instead of just using the task to kick off calc.exe or notepad.exe, so I booted up a Kali VM and dusted off my Empire listeners. The task embedded in the policy handles both the arguments flag as well as a blob of Powershell encoded characters, resulting in a SYSTEM-level callback from a user-level callback within my test network!

First all I had to do was add in the PowerShell blob into the task like so…

image

…and then wait for it to update. After the computer reached out for updates, it looks like it was applied!…

image

…And now we just need to wait for the task to kick off and….

imageimage

…VOILA! Look at that lovely SYSTEM callback!

Adding Users to a Local Administrators Group

Adding users to a local admin group appeared to be pretty simple. Once again, the option to add users to local groups exists under both User and Computer preferences in the Control Panel options. I figured initially that it would be a simple matter of adding an extension name to the proper Active Directory field and incrementing the versionnumber after adding the proper XML file. It turns out that if a GPO is already doing this, there will be a policy collision and the policies will be applied by priority. Since only domain admins can modify this priority, the GPOs which I edited always lost this conflict in my research. So what do we do? Thankfully, it is actually simpler than I initially thought.

There exists ANOTHER way to add users to a local administrators group through GPOs. It is a configuration option in the Administration preferences. Instead of adding a user to the local administrators group, you reset the local administrators group and add all new users to it through this interface. In order to do this without the GUI, you simply drop a file titled GptTmpl.inf into the <policy>\Machine\Microsoft\Windows NT\SecEdit folder in the SYSVOL directory. This file follows a pretty simple format. Simply add the objectsids for all users/groups that you want added to the local administrators group. With the help of tools like PowerView/SharpView/DSQuery, it is easy to find the objectsids for not only account you need added to the group, but also the objectsids for all the other groups currently being applied through any other GPOs.

imageimage

With this information, simply plug in these objectsids, set the file in the folder mentioned above with the same name, and use METRONOME to update the version number of the GPO you are targeting. As with the scheduled tasks, either wait and be patient or force the system to update its policies. Clean up is easy. Just delete the file and reset the version number. A word of caution though, there is no way to target this policy within the OU (similar to tasks). Whatever user you apply to the local administrators group will be added on all systems within the OU that the GPO applies to.

imageimage

Now that certain users are in the local administrators group, I think we can figure out what to do next…

Parting Thoughts

As mentioned above, the culmination of this research is the GPOEdit tool which I wrote in C#. If you wish to use this tool, feel free to download the .cs file from my github located here. The code can be compiled with csc.exe, no need for Visual Studio. Included in this repository are two task template XML files (one for filtering by hostname and the other for filtering by IP address) and then also the GptTmpl.inf file necessary for manipulating local administrator groups. Again, feel free to use them. Just make sure to put in the right IP addresses and hostnames!

As a side note, while I was putting this post together (it took me way too long to type this out), Petros Koutroumpis over at MWR Labs put out an incredibly verbose tool, SharpGPOAbuse, which also abuses misconfigured GPOs. The tool can be found on their github with more information on its use on their website. It looks like it is still an ongoing project, which is awesome!

GPOs have turned out to be a potentially valuable means of moving through a domain. With my research I only looked into using them to push out scheduled tasks and local administrator changes, but judging from the list of configuration options in the GPMC, this is only scratching the surface. There will be more research on my end on how these can be leveraged for nefarious purposes and I will be sure to post them here!. Those firewall changes look particularly interesting….

 

Sursa: http://nightwatchman.me/post/184884366363/gpo-abuse-and-you

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...