Group Policy is how an administrator imposes configuration on thousands of machines and users at once — password rules, drive mappings, software installs, security settings, scheduled tasks. That reach is the point, and it is also the danger: if you can modify a Group Policy Object that applies to many machines, you can run code on all of them. GPO abuse is mass compromise from a single write.
How Group Policy is structured
| Term | Meaning |
|---|---|
| GPO (Group Policy Object) | A named bundle of settings. It has two parts: settings in AD (the container) and files in SYSVOL (the template) |
| GPC (Group Policy Container) | The AD object for the GPO, holding metadata and version info |
| GPT (Group Policy Template) | The files in the SYSVOL share (\\domain\SYSVOL\...\Policies\) that actually define the settings |
| Link | The attachment of a GPO to a site, domain, or OU — this determines who it applies to |
| Scope | Everything under the linked container, unless filtered by security groups or WMI |
Machines refresh Group Policy roughly every 90 minutes (plus at boot/logon), reading the GPOs linked to their location and applying the settings. This automatic, scheduled pull is what makes a malicious GPO edit propagate on its own.
Why write access to a GPO is so dangerous
A GPO can configure things that amount to code execution: an immediate scheduled task, a startup/logon script, a software installation, or a change to local group membership. If you can edit a GPO, you can add one of these, and every machine in the GPO's scope will execute it at the next refresh.
The blast radius is the scope of the GPO. A GPO linked at the domain root, or to an OU containing all workstations, turns one write into code execution across the entire fleet. A GPO linked to an OU that contains a domain controller is a direct path to DA.
How you get write access
It comes down to ACLs again. The GPO object
in AD has a DACL, and if your principal has GenericWrite,
WriteDACL, WriteOwner, or full control over it, you can
modify the policy. BloodHound flags these as GPOAbuse edges and can show
you exactly which computers a writable GPO affects.
| Step | Action |
|---|---|
| 1. Find a writable GPO | BloodHound: "GPOs writable by owned principals", and which objects each affects |
| 2. Confirm the scope | Check what the GPO is linked to — the wider and more privileged, the better the payoff |
| 3. Inject a payload | Add an immediate scheduled task, startup script, or a local-admin group addition |
| 4. Wait for refresh (or force it) | Targets apply the change on their next Group Policy cycle |
# SharpGPOAbuse-style payload (from a Windows foothold)
SharpGPOAbuse.exe --AddComputerTask \
--TaskName "Update" --Author CORP\admin \
--Command "cmd.exe" --Arguments "/c net localgroup administrators corp\jdoe /add" \
--GPOName "Vulnerable GPO"
# pyGPOAbuse from Linux
pygpoabuse.py corp.local/jdoe:pass -gpo-id "<GPO-GUID>" \
-command "net localgroup administrators corp\jdoe /add"Group Policy Preferences — the classic credential leak
A separate, historical GPO issue worth knowing because it still turns up.
Group Policy Preferences (GPP) could set local account passwords, and
those passwords were stored in SYSVOL — encrypted with a key that Microsoft
published. Because SYSVOL is readable by every authenticated user, anyone
could read the Groups.xml file and decrypt the password.
# find and decrypt GPP passwords (any domain user can read SYSVOL)
netexec smb dc01 -u jdoe -p pass -M gpp_password
# or Get-GPPPassword / gpp-decrypt on the cpassword value
Microsoft patched the feature so new GPP passwords cannot be set this way, but old
cpassword values left in SYSVOL from before the patch are still there
and still decryptable. It is a reliable Snaffler/NetExec find.
Detection and defence
| Control | Effect |
|---|---|
| Audit GPO permissions | Only Domain/Enterprise Admins should have write on GPOs; BloodHound reveals the exceptions |
| Limit GPO scope | Avoid broad domain-root links; a tighter scope means a smaller blast radius if a GPO is abused |
| Monitor GPO changes | Version-number bumps and SYSVOL file changes (events 5136/5137) on sensitive GPOs are high-signal |
| Remove legacy GPP passwords | Search SYSVOL for cpassword and purge it |
| Restrict who can link GPOs | The link controls scope; linking rights are as sensitive as edit rights |
The takeaway
Group Policy is a legitimate mass-configuration system, and mass configuration is mass code execution to anyone who can write the policy. Whether you can is decided by the GPO's ACL, and the payoff is decided by the GPO's scope — a broadly linked, writable GPO is one of the fastest ways to go from a single ACL win to the whole fleet, or to a domain controller. Alongside that, legacy GPP passwords in SYSVOL remain an easy credential source. BloodHound finds the writable GPOs and their targets; the abuse tools are in theToolkit Vulns & Misconfigs. The rights that grant write access are explained on the ACLs & DACLs page.