Module 14 · Group Policy Object (GPO) Abuse

Last updated: April 29, 2026

Why this module exists. Group Policy was designed in 2000 to centralise Windows administration. It’s still the primary configuration mechanism for AD-joined hosts in 2026. Attackers learned its weaknesses long ago; defenders mostly still don’t audit GPO ACLs. Three flavours of GPO abuse pay off in nearly every internal pentest.

The GPP cpassword bug — still relevant in 2026

Group Policy Preferences (introduced 2008) let admins push settings like “create a local admin account with this password.” The password was stored in the GPO XML, encrypted with AES-256 — using a published key. Microsoft shipped the key in MSDN documentation.

The result: any domain user could read the GPO XML and decrypt the password. Microsoft patched in MS14-025 (2014) — but only stopped creating new GPP password entries. Existing entries were left untouched. To this day, in roughly 30% of large enterprise pentests, you find legacy GPP cpasswords.

# Find GPP cpasswords from any domain user
Get-DomainGPPPassword

# Or with PowerView
Find-DomainShare -CheckShareAccess
# SYSVOL share readable by all domain users
# Walk SYSVOL for *.xml, grep cpassword

# Decrypt
gpp-decrypt 'cpassword_value'

The decrypted password is often a domain admin or a service account. Game over.

GPO hijacking via misconfigured ACLs

Each GPO is an AD object with an ACL. Default: only Domain Admins / Group Policy Creator Owners can edit. Reality: many environments have delegated GPO edit rights — to help-desk groups, server admins, individual users — and forgotten about it.

If an attacker compromises a user with edit rights to a GPO that’s linked to high-value OUs (especially “Domain Controllers” OU or workstation OUs), they can:

• Add a logon script that executes on every host the GPO applies to
• Add a scheduled task
• Add a Restricted Group entry that puts attacker into Administrators
• Add a software installation

Within hours (or instantly with gpupdate /force), the GPO change executes on hundreds of endpoints with SYSTEM privilege.

# Find GPOs editable by your current user
Get-DomainGPO | Get-DomainObjectAcl -ResolveGUIDs | ?{
  $_.SecurityIdentifier -match "S-1-5-21-DOMAIN-USER" -and
  $_.ActiveDirectoryRights -match "WriteProperty"
}

# BloodHound query
MATCH p=(u {name:'[email protected]'})-[:GenericAll|WriteDacl|WriteOwner]->(g:GPO) RETURN p

# Push payload via SharpGPOAbuse
SharpGPOAbuse.exe --AddComputerScript --ScriptName malicious.ps1 
  --ScriptContents "" --GPOName "Workstations Policy"

Logon script abuse — the persistent backdoor

GPOs that deploy logon scripts run with the user’s privileges every time the user logs on. If an attacker can write to the script’s network location (which is often a regular SMB share with permissions creep), they can replace the script with malicious code.

Defender’s blind spot: logon scripts are rarely reviewed. They were configured in 2017, “work fine”, nobody looks at them.

The “what GPOs apply to this OU” question

# What GPOs target the Domain Controllers OU? (most sensitive)
Get-GPInheritance -Target "OU=Domain Controllers,DC=corp,DC=local"

# What GPOs target workstations?
Get-GPInheritance -Target "OU=Workstations,DC=corp,DC=local"

# Visualise the full GPO graph in BloodHound
# (BloodHound has GPO and OU edges since v4)

Answer the question for every sensitive OU. The scope of a compromised GPO is the count of objects in OUs it links to — often thousands.

Real-world cases

• Numerous internal-pentest reports document GPP cpassword findings in 2024-25.
• Conti / LockBit operations regularly use GPO modification for ransomware deployment — push the encryptor as a logon script, every host runs it on next reboot.
• SolarWinds 2020 — among the techniques was GPO modification for persistence.

Defender’s checklist

• Audit SYSVOL for any remaining GPP cpassword entries: findstr /S /I cpassword \corp.localsysvolcorp.localpolicies*. Remove every match. Reset any passwords found.
• Audit GPO ACLs quarterly. List every principal with WriteProperty or WriteDACL on every GPO. Investigate non-Domain-Admin entries.
• Restrict GPO creation/edit to Tier-0 administrators. Use a delegation model that uses dedicated admin OUs and delegate per-OU rather than per-GPO.
• Detection: Event ID 5136 (directory service object modified) on GPO containers. SYSVOL file modifications outside change-control windows.
• Logon script audit: review every logon script in SYSVOL. Each one is a backdoor opportunity.
• Sign GPO scripts where possible. PowerShell execution policy AllSigned on workstations forces tampering to break execution.