CVE-2014-1812

What Is Group Policy Preferences?

Group Policy Preferences (GPP) is a feature in Windows Active Directory that allows domain administrators to configure settings on domain-joined computers via Group Policy — including mapping drives, configuring scheduled tasks, and managing local user accounts and their passwords. GPP configuration files are stored as XML in the SYSVOL share on domain controllers, which is readable by all domain-authenticated users by design (SYSVOL distributes policy to all domain members).

This is precisely the source of the vulnerability: SYSVOL is world-readable, and GPP stored passwords with encryption — but used a fixed AES-256 key that Microsoft published in its own documentation.

Overview

CVE-2014-1812 describes a fundamental design flaw in Windows Active Directory's Group Policy Preferences: when administrators deployed local account passwords via GPP, those passwords were AES-256 encrypted and stored in XML files in SYSVOL. However, Microsoft published the encryption key in its own MSDN documentation (to allow application compatibility). Because all authenticated domain users can read SYSVOL, any domain user can read the GPP XML files and use the published key to decrypt administrator passwords. This is not a software bug in the traditional sense — it is a security architecture failure: encryption with a publicly documented key provides no confidentiality.

This was one of the most exploited techniques in penetration testing from 2012 through the mid-2020s, standardized in tools like PowerSploit and Metasploit.

Affected Versions

The vulnerability exists anywhere GPP passwords were configured before or after MS14-025. The patch removes the ability to set new GPP passwords but does not remove existing ones from SYSVOL — existing cpassword entries must be found and deleted manually.

Technical Details

The Published AES Key

Microsoft's MSDN documentation for the Group Policy Preferences SDK published the AES-256 key used to encrypt the cpassword attribute:

4e 99 06 e8  fc b6 6c c9  fa f4 93 10  62 0f fe e8
f4 96 e8 06  cc 05 79 90  20 9b 09 a4  33 b4 54 54

This key is the same across all Windows deployments worldwide. Publishing a symmetric encryption key in documentation eliminates any security benefit the encryption provides.

Where the Credentials Are Stored

GPP passwords appear in XML files within SYSVOL:

• Local Users and Groups: \\<domain>\SYSVOL\<domain>\Policies\{GUID}\Machine\Preferences\Groups\Groups.xml
• Scheduled Tasks: ...\ScheduledTasks\ScheduledTasks.xml
• Services: ...\Services\Services.xml
• Data Sources: ...\DataSources\DataSources.xml
• Drives: ...\Drives\Drives.xml

The cpassword attribute in these files contains the AES-encrypted password. Any authenticated domain user can read these files and any user with the published key can decrypt them.

Attack Steps

1. Authenticate to the domain as any low-privileged domain user
2. Search SYSVOL for cpassword entries: findstr /S /I cpassword \\<domain>\sysvol\<domain>\policies\*.xml
3. Decrypt the value using the published AES key (automated by tools)
4. Use the recovered credentials (typically local administrator passwords) for lateral movement across all machines where that GPP password was deployed

Impact Scale

A single GPP password policy applied to 1,000 workstations means all 1,000 workstations share the same local administrator password — and that password is readable by all ~10,000 domain users. One low-privileged account → domain-wide lateral movement.

Tool Automation

Discovery

The vulnerability class was documented by security researcher Chris Campbell in 2012 and quickly became a standard penetration testing technique. The pentesting community had been using this technique for years before Microsoft formally addressed it with MS14-025 in May 2014. The Get-GPPPassword PowerShell function (part of PowerSploit) became a standard post-compromise enumeration tool.

Exploitation Context

• Massively used in penetration testing: From 2012 onward, GPP password hunting was a standard step in any Active Directory penetration test; automated tools made it a one-command operation
• Ransomware operators: Ransomware groups use GPP password extraction as part of their Active Directory reconnaissance and lateral movement playbooks — confirmed use by multiple ransomware families (ransomwareUse: true)
• APT campaigns: Nation-state actors conducting long-term intrusions routinely harvest GPP credentials as part of domain enumeration
• Long exploitation window: Microsoft was aware of the issue for years before patching, citing it as "by design"; external pressure (including security community publication) ultimately drove MS14-025
• CISA KEV: Added November 2021, confirming active exploitation continues — many organizations still have un-deleted cpassword entries in SYSVOL even after patching

Remediation

1. Apply MS14-025 — removes the ability to set new passwords via GPP. This prevents the problem from recurring but does not remove existing cpassword entries.

2. Audit and remove existing cpassword entries from SYSVOL:

   # Find all GPP files with cpassword in SYSVOL
   findstr /S /I /M "cpassword" "\\<domain>\SYSVOL\<domain>\Policies\*.xml"
   

   Delete the cpassword attribute from all identified files. The GPP objects themselves can remain (with the password field empty).

3. Rotate all passwords that were deployed via GPP. These passwords must be treated as permanently compromised — assume any attacker with domain user access has already retrieved them.

4. Deploy Microsoft LAPS (Local Administrator Password Solution) as the replacement for managing local administrator passwords. LAPS stores unique per-computer passwords in Active Directory (encrypted, with access controls) rather than in SYSVOL.

5. Verify with a post-remediation scan: Use Get-GPPPassword (PowerSploit) or equivalent tooling after cleanup to confirm no cpassword entries remain.

6. Monitor for SYSVOL access patterns that suggest enumeration: bulk reads of policy XML files from non-administrative endpoints.