GPP cpassword (MS14-025)

Group Policy Preferences (GPP) was a Group Policy extension that allowed, among other things, creating local users or changing passwords centrally from the domain. Those settings are stored in XML files inside SYSVOL (Groups.xml, Services.xml, ScheduledTasks.xml, DataSources.xml...), and SYSVOL replicates to every domain controller and can be read by any domain member.

The flaw. When a policy sets a password, it's stored in the cpassword attribute, encrypted with AES-256. The problem isn't the algorithm: it's that Microsoft published the AES key in its developer documentation (MSDN). A public encryption key turns encryption into encoding. Anyone who reads Groups.xml can decrypt the cpassword to cleartext:

<Groups ...>
  <User name="active.htb\SVC_TGS" ...>
    <Properties cpassword="edBSHOwhZLTjt/QS9FeIcJ83mjWA98gw9guKOhJOdcqh+ZGMeXOsQbCpZ3xUjTLfCuNH8pG5aSVYdYw/NglVmQ" .../>
  </User>
</Groups>

gpp-decrypt '<cpassword>'          # applies the published AES key and returns the cleartext

gpp-decrypt (or the equivalent impacket/metasploit module) applies that known key and returns the password. There's no brute force: it's direct decryption.

Why it matters. It's a classic Active Directory vector because it chains two oversights: a readable SYSVOL (by design) and a password the algorithm no longer protects. It usually yields a domain service-account credential, the first authenticated foothold from which to pivot to Kerberoasting or other attacks.

How to detect it. The decryption is offline (impossible to see), so detection lives in the file access: reading Groups.xml or other GPP *.xml under \\<dc>\SYSVOL\...\Policies\... leaves an Event ID 4663 (an attempt was made to access an object) on the DC if object-access auditing with a SACL is set on those SYSVOL paths, and a 5145 (a network share object was checked for access) for the SMB access. Since the legitimate file is barely read after deployment, any bulk SYSVOL sweep looking for cpassword (netexec --gpp-password, Get-GPPPassword) stands out. Proactively, a periodic sweep of SYSVOL itself for residual cpassword is both detection and remediation.

Defence. Microsoft retired GPP as a password-setting mechanism and shipped patch MS14-025, which prevents creating new preferences with cpassword. But the patch doesn't remove existing XML files: you must manually find and delete any inherited cpassword in SYSVOL. The underlying rule: don't distribute passwords via Group Policy. Related to the credential-less SMB enumeration that usually exposes the share.