GPO Backup Files Resurrect cpassword After Migration
An AD forest migration or Backup-GPO archive can carry an old Group Policy Preferences XML file straight into a clean domain, reintroducing a decryptable local admin credential that patching the GUI never removed and that DFSR will happily replicate to every domain controller within minutes.
At a glance
- Unsafe setting
- GPO backup and migration tooling exports the raw cpassword XML attribute without stripping or rotating it.
- Failure trigger
- A Backup-GPO archive or ADMT forest migration imports an old Preferences XML file into a new domain's SYSVOL.
- Blast radius
- DFSR replicates the decryptable local admin or service account credential to every domain controller in the target forest within minutes.
- Recommended control
- Scan all GPO backup archives for the cpassword attribute before any import and rotate any credential it ever contained.
Fix commands and configuration
Select-String -Path \fileservergpo-backups**.xml -Pattern 'cpassword'The Trap
Group Policy Preferences cpassword surviving inside Backup-GPO archives and cross-forest migration tooling, bypassing the fact that Microsoft removed the ability to create new cpassword entries years ago.
The Default State
KB2962486 and the MS14-025 update stopped the Group Policy Management Console from writing new cpassword values into groups.xml, drives.xml, scheduledtasks.xml, datasources.xml and printers.xml. It did nothing to the files that already existed. Engineers running Backup-GPO or exporting GPOs with GPMC’s backup wizard capture the full Preferences payload verbatim, cpassword field included, as an AES-256-encrypted string sitting in plain XML inside the backup folder. That backup gets checked into source control, copied to a migration share, or archived on a file server as part of an ADMT domain consolidation or forest-to-forest lift-and-shift.
The Blast Radius
The AES-256 key Microsoft used to encrypt cpassword is published openly in section 2.2.1.1.4 of the [MS-GPPREF] specification. It has never rotated. Anyone with the encrypted string decrypts the plaintext password with a handful of lines of PowerShell or the Metasploit gpp-decrypt module. When that stale backup is imported into a new forest using Import-GPO -CreateIfNeeded, or when a lift-and-shift migration links the old GPO to a new OU, the XML lands directly in the target domain’s SYSVOL and replicates via DFSR to every domain controller within the normal polling interval. Local administrator or service account credentials that were retired years earlier in the source domain are now live, domain-wide, and readable by any authenticated user who can browse \domainSYSVOLdomainPolicies. Because the GUI can no longer create cpassword, security teams assume the exposure class is closed and stop scanning backup archives for it.
The Lead Mechanic Fix
Before any GPO backup, export, or ADMT migration touches a target forest, grep every XML payload for the cpassword attribute: Select-String -Path \fileservergpo-backups**.xml -Pattern 'cpassword' across the entire backup store, not just the live SYSVOL. Strip or null the attribute in the source XML before packaging any backup, rotate every credential that attribute ever referenced, and treat GPO backup archives as tier-0 secrets material requiring the same access controls as a domain controller’s SYSVOL share. Add a pre-import Azure DevOps or Jenkins pipeline gate that fails the migration job outright if cpassword is present in any staged GPO backup.