In a previous post, we discussed about Active Directory ACL/ACE and how to abuse them. Now we will see how to abuse Active Directory’s GPOs
What is Group Policy Objects (GPO)
Active Directory Group Policy Objects (GPOs) are a feature of Microsoft’s Active Directory that allows administrators to easily manage and configure settings for users, computers, and other Active Directory objects.
GPOs, in general, allow us to define and enforce policies across a network, such as security settings, software installations, and user preferences. This is super useful for keeping everything running smoothly!
GPOs are rules and preferences assigned to objects in the Active Directory and stored in the Active Directory database.
To apply a GPO to an object, we can use the Group Policy Management Console (GPMC) or other management tools.
Settings we can configure using GPO include, but not limited to:
- Security settings: Configuring password policies, account lockout policies, and other security settings.
- Software deployment: Deploying software applications and updates to computers and users.
- User settings: Configuring desktop settings in general.
- Network settings: Configuring network settings, such as IP addresses, DNS settings, and proxy settings.
- Group Policy Preferences: Defining custom preferences and settings for specific applications or system components.
Every OU with a GPO can be discovered via the gpLink attribute.
GpLink is an attribute of the AD Object to which the group policy is linked.
The Group Policy Objects are located in the Policies container.
Creating a new GPO in the Group Policy Management Console will place the object in the CN=Policies.
Abusing Group Policy Objects
Again, we can use PowerView to start enumerating the permissions for all GPOs in the current domain.
Get-NetGPO | %{Get-ObjectAcl -ResolveGUIDs -Name $_.Name}We find that the User ‘GPOWRITE.USER’ can modify the ‘Default Domain Controllers Policy’ GPO linked to the ‘Domain Controllers’ OU, which contains the ‘FIRST-DC’ computer object
In Bloodhound, this looks like this:
Now, to abuse this, we can use SharpGPOAbuse
The command was successful, and the GPO is now updated.
The updated file is visible on the First-DC, and the Group Policy Management console shows the precise settings.
The GPO is refreshed by default about every 90 minutes. We can afterward verify our results on the target system.
Looking at the Task Scheduler, we can see that Taks1 has been created.
When executed, we receive our callback.
And we got our shell.
Things to consider from a pentesting perspective:
- The impact could be significant, so verify how this affects your position. I.e., how many machines will this concern, what sort of machines, what infrastructure criticality, etc.
An alternative route to reach your goal may have less of an impact. - An alternative approach to highlighting this risk to a client might be demonstrating through RSAT by creating a blank GPO and linking it to the OU without creating the task or any actions.
- To the best of my knowledge, I couldn’t see a ‘remove’ or ‘reverse’ action within SharpGPO Abuse to revert back/clean up our modifications.
You should be mindful of this as a Pentester/Red Team member. - This is not OPSEC safe. Admins may see the changes in the GPO console.
- Always remember to clear up after yourself.