cpassword Survives in SYSVOL Backups and VSS Shadows
Removing a Group Policy Preferences password field from the console only deletes the live XML file. DFSR staging folders, VSS shadow copies on domain controllers, and System State backups retain earlier versions of Groups.xml, Drives.xml, and ScheduledTasks.xml indefinitely, keeping a reversibly-encrypted credential recoverable long after the GPO looks clean.
At a glance
- Unsafe setting
- Legacy GPP cpassword values persist in VSS shadow copies, DFSR staging folders, and System State backups after removal from the live GPO.
- Failure trigger
- An attacker gains read access to a domain controller backup, VSS shadow copy, or replication staging area and extracts an old Groups.xml or ScheduledTasks.xml file.
- Blast radius
- A credential believed retired years earlier decrypts instantly with Microsoft's published AES key and grants standing domain or local admin access.
- Recommended control
- Scan every DC, shadow copy, and backup set for residual cpassword strings, rotate every affected account, and replace GPP-stored credentials with LAPS or gMSA.
Fix commands and configuration
Get-ChildItem \<dc>SYSVOL -Recurse -Include *.xml | Select-String cpasswordvssadmin list shadowsThe Trap
Group Policy Preferences cpassword fields (Groups.xml, Drives.xml, ScheduledTasks.xml, Services.xml, DataSources.xml) are encrypted with a single AES-256 key that Microsoft published publicly in the [MS-GPPREF] specification. MS14-025 stopped the GPMC console from writing new cpassword values, but it never scanned existing SYSVOL content, and it has no reach into anything outside the live policy store.
The Default State
Administrators who inherit an old domain assume that deleting the offending GPO setting and confirming the XML file is gone from \domainSYSVOLdomainPolicies{GUID} closes the exposure. Nobody checks the DFSR staging folder at C:WindowsSYSVOLdomainstaging areas, the VSS shadow copies sitting on every writable domain controller, or the last six months of System State backups sitting in the backup vendor’s repository. GPP cleanup scripts and even Microsoft’s own guidance stop at the live file.
The Blast Radius
An attacker who compromises a single domain controller, a backup server, or a tape/immutable-storage repository can mount a VSS shadow copy with vssadmin, restore an old System State backup, or read the DFSR staging journal, and pull a Groups.xml that was deleted from production years earlier. The cpassword blob decrypts in seconds with the published key, handing over a domain or local admin credential that was assumed retired. Because the live SYSVOL is clean, vulnerability scanners and GPO audits report zero findings while the credential remains valid in Active Directory, since nobody rotated the account after removing the policy setting rather than after the password was actually exposed.
The Lead Mechanic Fix
Treat every account that was ever set via GPP cpassword as permanently compromised, not just currently exposed. Run Get-ChildItem \<dc>SYSVOL -Recurse -Include *.xml | Select-String cpassword against every domain controller, every VSS shadow (vssadmin list shadows then mount and repeat the scan), and every restorable System State or wbadmin backup. Rotate any credential found, regardless of age. Disable the capability outright via Computer Configuration > Administrative Templates > enable “Configure security policy for Group Policy Preferences” restrictions, and purge or re-encrypt backup sets that predate remediation. Replace stored local admin and service credentials with LAPS or gMSA so no future policy artefact carries a decryptable secret in the first place.