During a workstation assessment in the beginning of 2021, we identified a trivial privilege escalation vulnerability occurring during Group Policy Updates. The vulnerability itself was not exploitable by default but relied on a misconfiguration. However, this kind of misconfiguration seemed likely to occur in other environments too, so we informed Microsoft about the issue. They did not consider it security relevant. [出自:jiwo.org]

From this point on, the first thing we did when getting access to an Active Directory in an assessment was checking for this kind of misconfiguration. It was as expected: We identified similar issues in 90% of the analyzed environments, although not all of them led to privilege escalation.

With this blog post, we want to increase awareness for this issue and hopefully help other security analysts and system administrators to identify and fix it.

Performing File Operations via Group Policy Updates

Windows Group Policies are used to control and define the working environment of users and computers within Active Directory. They provide a great amount of control and allow to centrally manage Windows settings across an organization. From an offensive perspective, Group Policies have been mostly discussed in the context of access permissions (as for example in this excellent article by Andy Robbins) or when extracting credentials out of Group Policy Preference files (as outlined in this blog post by Bill Harshbarger). However, Group Policies can contain many other interesting configuration settings and perform operations that are interesting from an offensive perspective. Among these are file operations.

Group Policies can be used to deploy files, folders and access permissions across domain joined computers. This may sound uncommon, but from our experience it is used by many organizations to deploy globally used scripts and templates, to create folders that require a specific set of permissions or to remove legacy components that may still be available on some workstations. File system operations can be configured using the Group Policy Management Editor:

Example for a file operation deployed via group policy

The example above demonstrates how a template file can be deployed to all computers within a domain, but why is this dangerous? Well, there are several examples available where file system operations during Group Policy Updates have been abused for privilege escalation (e.g. this one from CyberArk or this one from Andrea Pierini). The underlying principle of these attacks is basically the same: A file system symbolic link is used to redirect file operations from the high privileged GPSVC service to different locations within the file system.

General attack pattern

How difficult it is to identify this kind of vulnerabilities depends on your goal. When you are only interested in exploitation opportunities from your current user account, creating a HTML report using gpresult /R report.html is usually sufficient. A configuration like the one demonstrated above can be found in Settings -> Preferences -> Windows Settings -> Files within this report:

I. Group Policy data generated by gpresult

If your intent is to find this kind of vulnerabilities globally within a domain, your best chance is probably to use a sufficiently high privileged user and to use Group Policy Management Editor to inspect all file and folder-based GPOs manually. If you only have a low privileged user available, you can attempt to find vulnerable policies manually by inspecting the SYSVOL share of the domain controller. Enrollment policies for files and folders are usually stored in XML files named Files.xml and Folders.xml:

Another nice trick to identify potentially vulnerable files and folders is looking for unexpected file ownership. Files within your %AppData% folder owned by Administrators or NT Authority\SYSTEM were obviously created with high privileges. Tools like PowerEnum can be used to quickly identify such files:

Attack Vectors

Depending on the type of file operation that is performed, different attacks are possible. For this blog post, we have summarized the three most common vulnerability types we have encountered.

Overwriting Arbitrary Files

The ability to overwrite arbitrary files on a workstation is by far the most common vulnerability we identified. Group Policies that deploy files to user writable locations in C:\ProgramData or %AppData% are often used by organizations and redirecting these file operations to different locations is usually possible. As an example, assume we found the following Group Policy definition within an HTML report created with gpresult:

I. Vulnerable policy definition

This GPO is dangerous, as the target can be written to by the user:

We can now use SharpLink to create a symbolic link at the targeted file location and redirect the operation to a different location:

Obviously, since the written content is not user controlled, such a vulnerability can usually only be used for denial-of-service attacks. However, as outlined in this blog post by Andrea Pierini, the source location of file operations is sometimes writable. This allows turning an uncontrolled file write into a fully controlled file write, resulting in a reliable privilege escalation.

Deleting Arbitrary Files

Being able to delete arbitrary files is almost as common as the overwriting scenario described above. Consider an organization realizes that a certain resource is no longer required but was already deployed to all workstations. Group Policies can be used to easily clean this up. We have encountered rules like the one in the following example during many engagements:

II. Group Policy data generated by gpresult

Exploitation in this case is even easier than for the file overwrite. Instead of working with symbolic links, we can just create a Junction using the builtin mklink utility. Wiping data from a protected folder? No problem!

While file deletion vulnerabilities can obviously be used for denial-of-service attacks, in many cases they can also be exploited for privilege escalation. One example can be found in this article by Jonas L, but on typical workstations with many third-party software components, the whole C:\ProgramData folder is an interesting target in general. Several products run high privileged processes or services that rely on files within C:\ProgramData. Many of them do not change the inherited directory permissions and only configure restrictive permissions for files contained in those directories. This allows low privileged users write access to those directories. Being able to delete files and to replace them with other content often results in privilege escalation.

Permission Modification on Arbitrary Files

Permission modifications have usually been the most dangerous Group Policy configurations. Luckily, we have not encountered them often. Configuring them needs to be done in the Computer Configuration section of the Group Policy Management Editor:

II. Vulnerable policy definition

One example for this situation was an organization, that used central Log folder C:\Internal\Logs for storing all log output generated by internally used tools. Since this log folder was also supposed to work for shared workspaces, modify permissions were assigned via Group Policies and the corresponding rule looked roughly like this:

III. Group Policy data generated by gpresult

Unfortunately, the folder C:\Internal was under the control of low privileged user accounts. Therefore, by removing the C:\Internal\Logs folder and replacing it with Junction or symbolic link, the permission assignment could be redirected to arbitrary resources:

Turning this vulnerability in a privilege escalation can be done in several ways, e.g. by overwriting service binaries or DLL hijacking.

Identifying a misconfiguration as the one described above can be tricky. If you have a sufficiently high privileged user account, the computer policies are usually displayed within a report when running gpresult (you can also use the /SCOPE:Computer option to request them explicitly). When using a low privileged user, you may not be allowed to view computer policies using gpresult. However, you can still find corresponding policies within the SYSVOL share of the domain controller:

Conclusion and Recommendation

Performing file operations via Group Policies is a powerful mechanism for deploying and managing files and resources required by multiple computers across the domain. But with power comes responsibility. When using such policies, administrators should be aware that file operations targeting user-controlled parts of the file system can be redirected to different locations. Therefore, it is recommended to avoid such policies and only to use them when the targeted location is known to be secure. Organizations should check their existing Group Policy configuration for possible misconfigurations.

• All policies that deploy, modify or remove files, folders or permissions should be reviewed.
• It should be checked whether the source or destination of the operation is located in a user controlled part of the file system.
• Vulnerable policy definitions should be replaced by a secure alternative.

Additionally, if vulnerable policy definitions were identified in your organisation, indicators for already occurred attacks should be searched for.

September Update

As outlined by Andrea Pierini, with the 2022 September update, Microsoft configured Redirection Trust for the Group Policy Client service, which is responsible for applying Group Policies to domain joined systems. Redirection Trust is a relatively new feature which is described in more detail within this great blog post by Gal De Leon. It basically blocks high privileged service accounts from accessing File System Junctions that were created by low privileged user accounts. This feature is a great security improvement and could block attacks as described above. That being said, James Forshaw already outlined that the solution may not be bullet proof at this point.