One policy to rule them all

Windows group policies are a powerful management tool that allows administrators to define and control user and computer settings within a domain environment in a centralized manner. While group policies offer functionality and utility, they are unfortunately a prime target for attackers. In particular, attackers are increasingly using group policies to distribute malware, execute hidden scripts and deploy ransomware.

These attacks can range from simple configuration changes that could result in data breaches to more complex scenarios where attackers gain complete control over the corporate network. To ensure the security of your IT infrastructure, it is crucial to understand the vulnerabilities in group policies and the tactics used by attackers. This story examines how cybercriminals exploit group policies as an attack vector, what risks attacks like these pose, and what measures can be taken to protect against potential threats.

Group Policy Object

A Group Policy Object (GPO) includes two key components: a Group Policy Container (GPC) and a Group Policy Template (GPT). A GPC is an Active Directory container that holds information about the GPO version, its status and so on.

Example of Group Policy Container contents

A GPT is a collection of files and folders kept on the SYSVOL system volume of every domain controller within a domain. These files hold a variety of settings, scripts and presets for users and workstations.

Group Policy Templates on SYSVOL

The path to each template is specified in the attribute of the group policy container named gPCFileSysPath.

Contents of the gPCFileSysPath attribute

Next, gPCMachineExtensionNames and gPCUserExtensionNames are important attributes in each policy. Each of these attributes contains a GUID for Client Side Extensions (CSE) that will be distributed to user and/or computer settings. Extensions themselves are most often implemented using libraries that contain a set of functions necessary for applying extension settings to users or computers. So, the GUID provides information about which exact library needs to be loaded. A list of all CSE GUIDs can be found in the following registry key:

Contents of one of the GUIDs in GPExtensions

To determine which policies a client will apply, it makes an LDAP query to the domain controller, which returns a set of policies for a specific user and/or computer. This set is called SOM (Scope of Management). A key attribute of a SOM is gpLink, which connects organizational units (OUs) to the GPOs that apply to them.

Policy application process

How attackers exploit group policies

In this story, we will not delve into the specifics of how attackers gain access to Group Policies. We will only note that to modify policies, attackers need only have WriteProperty permissions on the gPCFileSysPath attribute within the GPO. This has been described in more detail in SpecterOps’ study, An ACE Up The Sleeve: Designing Active Directory DACL Backdoors. Let’s focus on examples of how attackers specifically use these very policies for their own purposes.

The most common policy abuse tactic used by malicious actors is to deploy ransomware across multiple hosts. Our Global Emergency Response Team (GERT) regularly encounters its consequences in their work. However, group policies can also be used to covertly gain a foothold in a domain, where attackers can do virtually anything they want:

• Create new local users/administrators;
• Create malicious scheduler tasks;
• Create various services;
• Run tasks on behalf of the system and/or user;
• Change the registry configuration and much more.

Modifying the gPCMachineExtensionNames and gPCUserExtensionNames attributes

There are several tools designed to compromise GPOs. While they are all functionally similar, we will focus on the most popular one (after the built-in Windows MMC tool) SharpGPOAbuse. This utility provides a step-by-step guide to modifying Group Policy Objects (GPOs), making it convenient for analyzing the specific changes involved. As an example, let’s create a user-defined scheduler task that will run under the account labdomain.local\admin.

Adding a scheduled task to launch cmd.exe on behalf of a specific user

As seen in the screenshot above, during GPO modification, a new task is first added to the GPT on SYSVOL as an XML file. After that, the versionNumber attribute is changed, and the version number in the GPT.ini file is increased. This is necessary so that when checking for GPO updates, the client can detect that there is a newer version than the one in the cache and download the modified policy. Such changes can be tracked using event 5136, which is generated whenever an AD object is modified.

Event 5136, which reflects a change in GPO attributes

As we were creating a custom policy, we modified the gPCUserExtensionNames attribute, which now includes the following CSE GUID values:

• {00000000-0000-0000-0000-000000000000} — Core GPO Engine;
• {CAB54552-DEEA-4691-817E-ED4A4D1AFC72} — Preference Tool CSE GUID Scheduled Tasks;
• {AADCED64-746C-4633-A97C-D61349046527} — Preference CSE GUID Scheduled Tasks.

After the policy is applied, a scheduled task will start:

Scheduled task start events

Each function within the SharpGPOAbuse tool (such as creating scheduled tasks, adding users, granting privileges and so on) has a unique set of CSEs that will be recorded in the user or computer attributes.

CSE toolkit for adding a local administrator, new privileges and an autostart script in the SharpGPOAbuse code

These CSEs can serve as the basis for developing rules for detecting similar policies:

Detecting the addition of new privileges through GPOs

Detecting the addition of new autorun scripts through GPOs

Detecting the addition of a new scheduler task using GPOs

Modifying the gPCFileSysPath attribute

In some scenarios, the adversary can modify the GPC but cannot access the directory where the GPTs are located. This is because different methods are used to manage different GPO entities: A GPC is stored in the LDAP directories of Active Directory, while a GPT is stored in a system folder on the domain controller: SYSVOL. Consequently, a user may have permissions to modify the GPC LDAP container, but not have permissions to modify or add files in SYSVOL. In this case, when attempting to modify the policy, the user will see the following error:

Permissions mismatch between LDAP and SMB

An attacker without SYSVOL access can modify the GPC attribute gPCFileSysPath, specifying a path to a network resource they control. As a result, all clients subject to the policy will retrieve templates from this resource. Let’s consider this scenario using the example of a GPOddity attack. The tool spins up its own SMB server, where it creates malicious policies, then changes the path to the GPT, and after applying the modified policies, restores them to their original state from its backup.

Example of using GPOddity

The technique of modifying the gPCFileSysPath attribute was highlighted back in 2020 in a blog post by researcher Mark Gamache, who was working at Microsoft at the time. However, the company believes that the ability to store GPTs outside of the SYSVOL system folder is a feature rather than a bug. At the same time, Microsoft does not recommend storing GPTs on third-party resources, as this can break certain Windows mechanisms.

The possibility of storing policy data on third-party resources as mentioned in Microsoft documentation

To detect this technique, we can once again utilize event 5136, where we will monitor the modification of the attribute we are interested in.

Example of changing the gPCFileSysPath attribute in the Windows event log

It’s possible to automatically detect an event 5136, related to changes in gPCFileSysPath, in logs by using the following rule:

To eliminate the risk of false positives, we added to exceptions events that are generated when creating a new GPO where the attribute specifies the normal path to the GPT:

Changing the gPCFileSysPath attribute when creating a new GPO

How we search for “bad” policies in Compromise Assessment projects

One of the items on the checklist for each of our Compromise Assessment projects is searching for compromise via group policies, as attackers often rely on this method both to distribute malicious software, scripts, vulnerable settings and so on, and to secretly gain a foothold in the domain. We use the Group3r tool to analyze a large volume of policies. It helps us quickly find all policies and run them through our detection rules to identify suspicious ones, as well as find various vulnerabilities that an attacker could exploit.

Example of a suspicious policy

Example of a vulnerable policy

Since Group3r only searches for policies located on the SYSVOL domain volume, it is important to determine which of them have the gPCFileSysPath attribute changed. To do this, you can use the following script:

Example of the script’s operation

In addition to Group3r, SharpHound is an excellent tool for finding various GPO configuration errors. It allows you to find potential GPO attack vectors.

An example of a misconfiguration that grants write permissions for policies to users who do not need them

How we monitor group policies in MDR

Organizations often fail to log many events on hosts. To ensure security and proactive monitoring of group policies in our MDR service, we have developed several improvements to our telemetry. Firstly, since Windows advanced auditing is disabled on some hosts, we try to use ETW providers (Event Tracing for Windows) wherever possible to replace the events needed to understand what happened in the system. Where ETW alone is not enough, we improve our technology and expand telemetry coverage. For instance, to detach from event 5136, monitoring of which requires configuring Directory Service Changes audit, our SOC R&D team developed the GCNet tool based on Microsoft’s PoC for monitoring directory service changes. The tool connects to the LDAP database where we specify a search for a particular distinguishedName attribute value (in our case, CN=Policies) and subscribe to any changes to it. If we receive a notification about a policy change, we request detailed information about the corresponding GPO, including GPC and GPT data.

Example of an event with GPO output

Detected events are run through our detection rules, allowing us to identify various malicious policies. One of the important attributes of a policy is GPLink options and policy flags. Policies flagged as Enforced take precedence over other policies and will be applied before them, and they cannot be overwritten by another policy. Additionally, GPOs have several flags that, when known, can help us determine whether a policy is enabled or not. The combination of all attributes provides us with additional information about how much time we have to respond to an incident before the next group policy is applied, and where and how it is applied, significantly broadening the investigation scope. By default, policies are updated every 90 minutes +/– 30 minutes on client machines and every 5 minutes on the domain controller.

Conclusion

Group policies (GPOs) are a versatile tool that, in the hands of malicious actors, can pose a serious threat to a corporate network. Their compromise allows attackers to perform covert actions, modify configurations and spread malware to multiple hosts simultaneously. For this reason, group policies must be closely monitored and constantly secured. Tracking changes in group policies and responding to detected threats is part of our Managed Detection and Response (MDR) service.