October 19, 2026
GPP Password Attack in AD: Exploitation, Detection and Prevention
Active Directory environments often contain legacy configurations that can introduce unexpected security risks. One such issue is Group…
By Enes Cayvarli
4 min read
Active Directory environments often contain legacy configurations that can introduce unexpected security risks. One such issue is Group Policy Preferences (GPP) password exposure, a vulnerability that allows attackers to recover credentials stored in SYSVOL.
Although Microsoft addressed this issue in 2014, previously stored credentials may still be present in some environments, making it a relevant security concern today.
In this article, we'll explore how GPP password exposure works, demonstrate its exploitation in a lab environment and discuss practical detection and prevention techniques from a Blue Team perspective.
Understanding Group Policy Preferences (GPP) and cpassword
Group Policy Preferences (GPP) was introduced with Windows Server 2008 to simplify the management of settings across Active Directory environments. One of its features allowed administrators to configure credentials for local users, scheduled tasks and services through Group Policy.
These configurations are stored as XML files within the SYSVOL shared directory, which contains Group Policy data, logon scripts and other domain-wide resources. The default location for Group Policy files is:
\\<DOMAIN>\SYSVOL\<DOMAIN>\Policies\\\<DOMAIN>\SYSVOL\<DOMAIN>\Policies\The security issue arises from the way GPP historically handled passwords. Instead of storing them in plaintext, GPP encrypted passwords using AES-256 and saved the encrypted values in an XML attribute called cpassword.
However, Microsoft publicly documented the AES key used for this encryption and the same key was used across Active Directory environments. As a result, anyone who obtains a GPP XML file containing a cpassword value can decrypt the stored password.
Furthermore, SYSVOL is readable by authenticated domain users, making these files accessible even to accounts with limited privileges. An attacker with domain access could therefore discover an XML file containing cpassword and recover the associated credentials.
The following example illustrates a GPP XML configuration containing an encrypted password associated with the svc-iis account.
Exploiting GPP: From SYSVOL to Plaintext Credentials
An attacker who gains access to an Active Directory environment with a valid domain account can search SYSVOL for Group Policy Preferences files containing encrypted credentials.
Instead of manually inspecting XML files and decrypting cpassword values, this process can be automated using Get-GPPPassword, a PowerSploit function that identifies vulnerable GPP configurations and extracts their stored credentials.
In the lab environment, we first configured PowerShell to allow the script to run within the current session:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy BypassSet-ExecutionPolicy -Scope Process -ExecutionPolicy BypassThis command changes the execution policy only for the current PowerShell process, without modifying the system-wide configuration.
Next, we imported the Get-GPPPassword script and executed the function:
https://github.com/PowerShellMafia/PowerSploit/blob/master/Exfiltration/Get-GPPPassword.ps1
Import-Module .\Get-GPPPassword.ps1
Get-GPPPasswordImport-Module .\Get-GPPPassword.ps1
Get-GPPPasswordThe function searches accessible Group Policy Preferences XML files in SYSVOL, identifies cpassword attributes and decrypts the associated passwords using the publicly documented AES key.
As shown in the output, the tool successfully recovered the plaintext password abcd@123 for the svc-iis account from a Groups.xml file located in the domain's SYSVOL share.
This demonstrates how an authenticated domain user could retrieve exposed credentials without needing administrative privileges to read the affected policy file. Depending on the compromised account's permissions, the recovered credentials could potentially be used for privilege escalation or lateral movement within the Active Directory environment.
Detecting GPP Credential Access with Windows Event Logs
One approach to detecting potential GPP credential theft is monitoring access to XML files containing the cpassword attribute within the SYSVOL directory.
Windows provides file access auditing through System Access Control Lists (SACLs), allowing administrators to track attempts to read sensitive files. By configuring an auditing entry for the affected XML file and enabling the Audit File System policy, we can generate security events when the file is accessed.
After enabling auditing, we used Windows Event Viewer to examine the Security log and filtered for Event ID 4663 (An attempt was made to access an object).
The generated event revealed several important details:
These fields help identify which account accessed the monitored file and which type of access was recorded.
However, Event ID 4663 alone does not confirm credential theft. The 0x80 access mask shown in our example indicates that file attributes were read, rather than proving that the file contents were extracted.
For more reliable detection, security teams should correlate file access events with suspicious PowerShell activity, unusual SYSVOL enumeration and access to multiple GPP XML files within a short period.
Preventing GPP Credential Exposure
In 2014, Microsoft released security update MS14-025 (KB2962486) to address the insecure storage of passwords in Group Policy Preferences. This update prevents administrators from configuring new passwords through the affected GPP settings.
However, the update does not automatically remove credentials stored in existing XML files. Therefore, legacy configurations may still expose sensitive information even in patched Active Directory environments.
To minimize this risk, organizations should regularly audit SYSVOL for XML files containing the cpassword attribute, remove exposed credentials and reset any affected account passwords. Administrators should also avoid storing credentials in Group Policy Preferences and use secure alternatives such as Group Managed Service Accounts (gMSAs) where applicable.
Regular security assessments and continuous monitoring are essential to ensure that outdated GPP configurations do not become an entry point for attackers.
https://learn.microsoft.com/en-us/security-updates/securitybulletins/2014/ms14-025
Conclusion
Group Policy Preferences (GPP) password exposure demonstrates how outdated configurations can introduce serious security risks into Active Directory environments.
As demonstrated in this article, credentials stored in SYSVOL can be recovered using publicly available tools, potentially allowing attackers to escalate privileges or move laterally across the network.
Although Microsoft addressed this vulnerability in 2014, legacy configurations may still expose sensitive credentials. Therefore, regular SYSVOL audits, proper monitoring and credential management remain essential for maintaining a secure Active Directory environment.