Group Policy Objects (GPOs)

A Group Policy Object (GPO) is a virtual collection of policy settings, represented by a unique name called a GUID. The GPOs of an AD network is usually stored in the SYSVOL directory: \\domain\SYSVOL, and can be viewed with:

# From a domain-joined machine
C:\> dir \\domain\SYSVOL

Group Policy Management

A mechanism to deploy a configuration from a central location, by defining policies directly on the AD structure for AD objects such as specific OU or group. Domain-joined computers would then be able to pull all policies from SYSVOL periodically and apply relevant ones.

By default, policies are replicated every 15 minutes through the gpupdate application. However, we can manually trigger this application from the command prompt to apply policies instantly:

C:\> gpupdate
C:\> gpupate /force

gpupdateMicrosoftLearn

Exploitation example

Scenario adapted from TryHackMe Exploiting AD room:

TryHackMe | Cyber Security TrainingTryHackMe

Suppose we have stolen credentials for a certain user named SVCSERVMAN that can be used on THMSERVER1. We have found that this user has GenericWrite permissions on the MANAGEMENT SERVER PUSHES GPO, which has a GpLink permission on the MANAGEMENT SERVERS OU which contains the THMSERVER2 machine. We can observe the behavior from the following Bloodhound output:

This provides us the following exploitation opportunity:

a. Add a user account we control to the local Administrators and local Remote Desktop Users group on the MANAGEMENT SERVER PUSHES GPO

• This exploits the GenericWrite permissions

• This will allow us to gain a remote desktop session as an administrator

b. Since the MANAGEMENT SERVER PUSHES GPO has a GpLink permission on the MANAGEMENT SERVERS OU, this means that any changes we make to the GPO will apply to the OU (and any other users or computers contained within that OU)

c. After we add our user account to the relevant groups (part #a), we will have the relevant permissions on the THMSERVER2.ZA.TRYHACKME.LOC machine

Steps

To perform the steps outlined above, we first have to start a Microsoft Management Console instance as the privileged user. We can achieve with 2 methods:

1. Directly RDP into THMSERVER1 (where our compromised account: SVCSERVMAN has privileges in) machine. However, this is not recommended, as it may kick that user out of their active session (terrible OPSEC)

2. RDP into a jump machine (eg. THMWRK1, in the TryHackMe lab) as any user, and inject SVCSERVMAN's user credentials into memory using the runas command:

C:\> runas.exe /netonly /user:za.tryhackme.loc\SVCSERVMAN cmd.exe

We will be prompted for a password associated with the account. To verify that we provided the correct credentials, we can run the following command:

C:\> dir \\za.tryhackme.loc\sysvol

We can confirm that the credentials are valid, and we are domain-joined with the SVCSERVMAN user if we are able to view the SYSVOL directory.

Next, we simply run the mmc command to start the Microsoft Management Console:

C:\> mmc