SYSVOL permissions differ from the GPO's AD permissions

Someone can write a Group Policy Object's files in SYSVOL without being allowed to edit the GPO itself.

Category: Hygiene
Severity: High or Medium.
Typical owner: AD / identity team
Data needed: Pathwarden's built-in collector^* run as the current Windows user on Windows, which reads the SYSVOL folder permissions. Password-based and SharpHound collections can't see them.

Most useful toDefensive engineers Identity and access engineers Auditors

On this page

In plain language

A Group Policy Object has two halves: an object in Active Directory, and a folder in SYSVOL that holds its settings and scripts. The Group Policy console keeps their permissions in step, but changes made directly on the folder drift apart, and the console's Delegation tab doesn't show them.

Whoever can write the folder decides what the policy does: a startup script, a scheduled task, a new local administrator. Every computer the GPO applies to runs it at the next refresh.

What Pathwarden flags

A Group Policy Object has two halves: the object in Active Directory (CN={GUID},CN=Policies,CN=System,...) and a folder in SYSVOL (\\<domain>\SYSVOL\<domain>\Policies\{GUID}) that holds its settings, scripts and preference files. Group Policy Management keeps the folder's permissions in step with the object's when you delegate through it.

Here the folder (or its Machine, User or Scripts subfolder) lets an account or group write files although it has no right to edit the GPO in AD. Default writers are not reported: SYSTEM, CREATOR OWNER, BUILTIN Administrators, Enterprise Domain Controllers, Domain Admins, Enterprise Admins and Group Policy Creator Owners.

Pathwarden also draws this as a WriteGPOFiles relationship from the account or group to the GPO. When the GPO applies to Tier Zero (or to a Privilege Zone), that relationship is an attack path and PW-003 (or PW-022) reports it as well.

How attackers use it

Whoever writes the folder decides what the GPO does: a startup script in Machine\Scripts, a scheduled task in Preferences\ScheduledTasks, a new local administrator in Groups.xml, a user right in GptTmpl.inf (Domain or Tenant Policy Modification: Group Policy Modification, T1484.001). Every computer and user the GPO is linked to runs it at the next refresh. The Delegation tab in Group Policy Management doesn't show folder permissions, so this access is easy to miss.

Find it with Pathwarden

Data needed: Pathwarden's built-in collector^* run as the current Windows user on Windows, which reads the SYSVOL folder permissions. Password-based and SharpHound collections can't see them.

In the web UI or the HTML report, open the Findings tab and expand PW-027: each finding shows who can use it (its exposure), the attack path drawn out, the affected objects, and the fix. The remediation path tells you whether a single plan step closes it. On the command line:

Shell

# every finding of this rule, with its path and fix
pathwarden findings -i .\collect --rule PW-027
# the step-by-step guide on this page, offline
pathwarden guide PW-027
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-027

Exit codes make retest easy to script: 0 Fixed, 1 Still open, 3 Can't tell. See findings lifecycle and retest.

Before you change anything

Find out why the permission is there: a deployment tool, an old migration (SYSVOL copied by hand, FRS to DFSR), a script that sets ACLs, or a helpdesk shortcut.
If the account or group really needs to edit the GPO, delegate it properly in Group Policy Management (Delegation tab, Edit settings), which sets both halves.
Save the folder's current permissions so you can roll back: icacls "\\<domain>\SYSVOL\<domain>\Policies\{GUID}" /save gpo-acl.txt /t

How to fix it

Option A: Let Group Policy Management make them consistent (recommended)

Open Group Policy Management as a Domain Admin and select the GPO.
When the folder's permissions differ from the object's, it warns that the SYSVOL permissions are inconsistent and offers to make them match. Click OK. This rewrites the SYSVOL folder permissions from the GPO's Group Policy security permissions, so Authenticated Users keeps its read access if the GPO grants it.
Check the Delegation tab: only the accounts and groups that should edit the GPO are listed.

Option B: Remove the permission with icacls

The finding's fix lists each folder and the command, for example:

PowerShell

icacls "\\scale.local\SYSVOL\scale.local\Policies\{GUID}" /remove:g *S-1-5-21-...-1105

/remove:g removes every allow entry of the account or group on that folder, read access included. For Authenticated Users, Domain Computers or another broad group, give Read & Execute back straight after, or the GPO can stop applying (Group Policy reads the folder to apply it):

PowerShell

icacls "<folder>" /remove:g *S-1-5-11
icacls "<folder>" /grant *S-1-5-11:(OI)(CI)RX

An entry marked (I) in icacls output is inherited: remove it on the parent folder instead. For a folder the account or group owns, set the owner back: icacls "<folder>" /setowner *S-1-5-32-544.

If nobody uses the GPO any more, unlink and delete it instead.

Also look at the files inside for anything the account or group may have planted (scripts, ScheduledTasks.xml, Groups.xml, GptTmpl.inf), and compare the GPO's settings report with what you expect.

Verify the fix

icacls "<folder>" no longer lists the account or group. Collect again with the built-in collector (on Windows, as a domain user) and confirm the finding ID is gone.

Roll back

icacls "\\<domain>\SYSVOL\<domain>\Policies" /restore gpo-acl.txt puts back the permissions saved before the change (run it on the parent folder of the one you saved).

References

Microsoft: icaclslearn.microsoft.com
SpecterOps BloodHound docs: GPLinkbloodhound.specterops.io
MITRE ATT&CK T1484.001: Domain or Tenant Policy Modification: Group Policy Modificationattack.mitre.org

Very new and undergoing testing. These features haven't received a lot of testing yet. Try them out and let us know what's working.