GPO SYSVOL cPassword Secrets Active Directory: Why a 2014 Patch Didn't Fix It

GPO SYSVOL cPassword Secrets Active Directory: What They Are

GPO SYSVOL cPassword secrets active directory misconfigurations are some of the oldest that refuse to die — and one of the most common Active Directory misconfigurations still found in production audits today. They come from Group Policy Preferences (GPP), a feature Microsoft added in Windows Server 2008 that let administrators push local user accounts, mapped drives, scheduled tasks, services, and data sources through Group Policy — including, for several of these preference types, a username and password to apply on the target machines.

Those credentials were stored in the cpassword attribute of the preference's XML file (Groups.xml, Services.xml, ScheduledTasks.xml, Printers.xml, Drives.xml, DataSources.xml), AES-256 encrypted, and written to the domain's SYSVOL share — the same share every domain controller replicates and every authenticated user (and, by default, users from any trusted domain) can read so client machines can pull their Group Policy Objects (GPOs).

The problem: Microsoft published the private AES key used to encrypt every cpassword value in its own protocol documentation, because GPP needed a way to decrypt the value client-side during policy processing. Any authenticated domain user who can read SYSVOL — which is all of them, by design — can find the encrypted string and decrypt it in seconds with publicly available tooling. The exposure was first documented publicly in 2012 by security researcher Chris Campbell (obscuresec), who released a PowerShell proof-of-concept to locate and decrypt these values well before Microsoft shipped a fix.

Why This Keeps Reappearing a Decade Later

If MS14-025 shipped in 2014, why do audits still find live cpassword entries today? A few recurring patterns explain it:

• Domain migrations and acquisitions. GPOs are frequently migrated wholesale from a legacy domain, complete with any preferences configured before the acquired environment was ever patched or reviewed.
• Restored GPO backups. GPO backups taken pre-2014 and restored years later reintroduce the exact XML the patch was meant to prevent going forward — the patch protects the editor, not a restore operation.
• MSP and vendor-managed environments. Managed service providers reusing a standard GPO template across multiple clients can propagate the same exposed local admin credential to every environment that template touches.
• No periodic SYSVOL review. Unlike a live service, SYSVOL content does not expire or get flagged by routine patching — nothing forces a re-scan unless someone runs one deliberately.

None of these paths require a misconfigured system to have skipped the 2014 patch. They only require that a cpassword value existed in SYSVOL at some point in the domain's history and was never actively hunted down and removed — which is exactly why proactive scanning, not patch compliance, is the control that actually closes this gap.

How It Works

Microsoft addressed part of this with MS14-025 (CVE-2014-1812), published May 13, 2014, and shipped as update KB2962486. The patch removed the "Password" fields from the Group Policy Preferences editor in the Group Policy Management Console (GPMC) and Remote Server Administration Tools (RSAT), so administrators can no longer create new GPP entries containing a password (Microsoft Support: MS14-025).

What KB2962486 does not do is retroactively strip cpassword values that were already written to SYSVOL before the patch was installed, and it does not stop an attacker from decrypting whatever is still sitting there. ANSSI's guide on secure AD administration flags this specific gap: the patch changes what the editor lets an administrator type in going forward, but historical GPP objects created before the patch was installed must be located and cleaned up manually (ANSSI-PA-099).

The AES key itself is not a secret an attacker has to steal — it is the same static 32-byte key for every Active Directory domain on earth, documented by Microsoft and mirrored across security research going back to that original 2012 disclosure, and later baked directly into offensive tooling like PowerSploit and CrackMapExec (adsecurity.org: Finding Passwords in SYSVOL & Exploiting Group Policy Preferences).

The Attack Chain

Exploiting a leftover cpassword requires no elevated access and no exploit — it is a post-authentication technique available to any domain user, and often to any user in a trusted forest as well.

Step 1 — Enumerate SYSVOL for cpassword

An attacker with any valid domain credential (or a low-privilege foothold) searches the SYSVOL share for XML files containing the cpassword attribute:

# Linux, with valid domain creds
crackmapexec smb <dc-ip> -u 'user' -p 'password' -M gpp_password

# Windows, PowerSploit
Import-Module .\Get-GPPPassword.ps1
Get-GPPPassword -Verbose

Step 2 — Decrypt with the published AES key

Get-GPPPassword and equivalent tools (Get-DecryptedCpassword, gpp-decrypt) apply the publicly known AES key to the Base64-decoded cpassword value and return the plaintext instantly — there is no brute force or cracking step, just a fixed decryption routine.

Step 3 — Reuse the credential

Because GPP was frequently used to standardize a local administrator account across many machines, or to run a scheduled task or service under a domain service account, the recovered password is often directly reusable for lateral movement or privilege escalation, with no additional technique required. A single Groups.xml entry that set a common local admin password domain-wide is enough to compromise every workstation that GPO touches.

Detection

To confirm exposure directly rather than waiting on log signals, ANSSI's guide on secure AD administration (ANSSI-PA-099) gives a one-line proactive check auditors can run from a domain-joined system:

:: Replace <FQDN> with the AD domain's fully qualified name.
findstr /S /I cpassword \\<FQDN>\sysvol\<FQDN>\policies\*.xml

Any hit means a cpassword value — patched tooling or not — is still sitting in SYSVOL today (ANSSI-PA-099, Recommendation R31, Listing 3). Because this check reads static file content rather than live telemetry, it is the fastest way for an auditor to get a definitive answer without waiting on log retention. The same principle applies to other stale credential leaks worth checking during the same pass, such as passwords left in AD description fields. For a broader walkthrough of what to prioritize during a full review, see our guide on how to audit Active Directory security.

Remediation

1. Confirm KB2962486 is deployed on every system still used to edit Group Policy through the native GPMC/MMC console (pre–Windows Server 2016) or through older RSAT tooling (pre–Windows 10). This stops new passwords from being entered into GPP going forward.
2. Run the SYSVOL scan (findstr command above, or an equivalent recursive search) and enumerate every Groups.xml, Services.xml, ScheduledTasks.xml, Printers.xml, Drives.xml, and DataSources.xml file across every GPO for a cpassword attribute — including disabled and unlinked GPOs, which are frequently skipped during manual reviews.
3. Rotate every credential found, immediately. Deleting the XML entry does not invalidate a password that was already decryptable; assume it has been read and act accordingly.
4. Remove the GPP setting rather than leaving an empty password field — per ANSSI recommendation R32, no password should ever be recorded in a Group Policy Preference again (ANSSI-PA-099, Recommendation R32, p.49). Our practical guide to ANSSI's AD recommendations covers how to turn recommendations like this one into a rollout plan.
5. Replace GPP-managed local admin accounts with Windows LAPS, which rotates a unique, randomized password per machine and stores it as a protected AD attribute instead of a static XML file.
6. Extend the same scrutiny to logon/logoff scripts stored on SYSVOL or NETLOGON — ANSSI recommendation R31 applies the same reusable-secret principle to any script readable by lower-privileged accounts, not just GPP XML. A script that maps a drive with an embedded service account password is exactly as exposed as a cpassword field.
7. Harden read access where feasible. SYSVOL and NETLOGON need to remain readable for policy processing, but review for SYSVOL/NETLOGON permission drift beyond the default, and enable UNC hardening for these shares so clients validate integrity and mutual authentication when reading them.
8. Re-run the scan after every GPO backup restore or domain migration, not just once. Since these are the two most common ways old cpassword entries resurface, treat SYSVOL re-scanning as a standing step in any migration runbook rather than a one-time cleanup, and assign it an owner so it does not depend on someone remembering.

How EtcSec Detects This

EtcSec's Active Directory audit flags this exposure as GPO_PASSWORD_IN_SYSVOL, a critical-severity check that scans every GPO's preference XML for a populated cpassword attribute — including GPOs that are disabled or unlinked, which manual reviews often miss. It is paired with SYSVOL_NETLOGON_PERMISSIONS, which reviews read/write access on the SYSVOL and NETLOGON shares for drift beyond the expected baseline. Together, the two checks cover both the historical GPP exposure and the ongoing permission hygiene needed to keep SYSVOL from becoming a dumping ground for reusable secrets again.