General

A GPO is a virtual collection of policy settings. Each GPO has a unique name, called a GUID. That's why if you try to read the contents of the SYSVOL directory, it won't make a lot of sense with all the random names.

===The SYSVOL directory is where AD GPOs are stored to be replicated to domain-joined machines.===

Each Windows computer has a Local Policy Configuration. This contains several notable configurations such as:

• Application configuration for services such as the Firewall, Anti-Virus, and Applocker.

• Local Group membership such as the Administrator or Remote Desktop Users groups.

• Startup configuration such as scripts that should be executed.

• Security and protocol settings such as SMBv1 support.

These are just a few examples. There are a significant amount of configuration options that can be set.

Group Policy Management

If you only have one Windows computer, it is easy to change the local policy configuration directly on the host. However, you need a mechanism to deploy a configuration from a central location in large organisations. This is where Group Policy Management (GPM) comes into play. Instead of defining policies locally on each machine, GPM allows us to define policies directly on the AD structure. Essentially, we can define GPOs for AD objects, such as a specific OU or group.

Domain-joined computers would then pull all policies from SYSVOL periodically and apply the relevant ones. By default, policies are replicated every 15 minutes through the gpupdate application. We can, however, also manually execute this application from Command Prompt to apply policies instantly.

Commands

Although there are several ways in which GPOs can be exploited, we will stick with the simple solution of adding an AD account we control to both the local Administrators and local Remote Desktop Users groups (This will give us Administator priv on the server).

In order to modify the GPO, we need to access Group Policy Management as the AD user that has the relevant permissions. We could RDP into THMSERVER1 as the user, but that may kick the user out of their active session, raising suspicion. Instead, we will RDP into THMWRK1 with either our normal or our Tier 2 Admin account, inject the AD user's credentials into memory using the runas command, and open MMC to modify the GPO

CMD (Runas command --> Normal Station (Where we have RDP access))

C:\>runas /netonly /user:za.tryhackme.loc\<AD Username> cmd.exe

Once prompted, provide the password associated with the account.

Start Microsoft Management Console in the new prompt window

C:\>mmc

We now want to add the Group Policy Management snap-in:

1. Click File -> Add/Remove Snap-in
2. Select the Group Policy Management snap-in and click Add
3. Click Ok

You should now be able to see GPOs for the za.tryhackme.com domain:

We can now navigate to the GPO that our user has permission to modify (Servers > Management Servers> Management Server Pushes).

We can right-click on the GPO and select Edit. This will open the new Group Policy Management Editor window.

In order to add our account to the local groups, we need to perform the following steps:

1. Expand Computer Configuration

2. Expand Policies

3. Expand Windows Settings

4. Expand Security Settings

5. Right Click on Restricted Groups and select Add Group (If the IT Support group already exists, it means someone has already performed the exploit. You can either delete it to create it yourself, or just inspect it to see what was configured.)

6. Click Browse, enter IT Support and  click Check Names

7. Click Okay twice

The first filter is not used. For the second filter, we want to add both the Administrators and Remote Desktop Users groups. In the end, it should look something like this:

Once the configuration has been made, we can click Apply and OK. Now, all we need to do is wait for a maximum of 15 minutes for the GPO to be applied.