# 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:

```powershell
# 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:

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

{% embed url="<https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/gpupdate>" %}

### Exploitation example

Scenario adapted from TryHackMe Exploiting AD room:

{% embed url="<https://tryhackme.com/room/exploitingad>" %}

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*](https://bloodhound.specterops.io/resources/edges/gp-link) permission on the **MANAGEMENT SERVERS** OU which contains the **THMSERVER2** machine. We can observe the behavior from the following Bloodhound output:

<figure><img src="https://667177664-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMsAGomcNx5xaB1xFygc9%2Fuploads%2FkayEz2jtuu9U2xn9vSsW%2Fimage.png?alt=media&#x26;token=7563983a-d31e-458c-b397-5e9eb9c0ea80" alt=""><figcaption></figcaption></figure>

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*](https://bloodhound.specterops.io/resources/edges/gp-link) 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](https://jarrettgxz-sec.gitbook.io/penetration-testing-ethical-hacking-concepts/windows-active-directory/enumeration/runas.exe) command:

{% code overflow="wrap" %}

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

{% endcode %}

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:

```powershell
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:

{% code overflow="wrap" %}

```powershell
C:\> mmc
```

{% endcode %}