Secrets in SYSVOL: cpassword, scripts and clear-text passwords readable by everyone
The SYSVOL share is replicated to every domain controller and readable by every authenticated user. That is its purpose: devices must be able to read Group Policy and logon scripts from it. Any secret stored there is therefore, by design, within reach of any account in the domain.
The Group Policy Preferences legacy
Group Policy Preferences (GPP), introduced with Windows Server 2008, made it possible to create local accounts, set passwords for services or scheduled tasks and map drives with credentials. The password entered was stored in an XML file in the GPO, in an attribute named cpassword, encrypted with AES.
The problem: the encryption key was the same for every environment, and Microsoft published it in its documentation. Any domain user could therefore read the file and decrypt the password. Bulletin MS14-025, released in May 2014, removed the ability to enter new passwords in these preferences, but did not delete existing files. GPOs created before then, including disabled or unlinked ones, can still contain these values.
Where to look
The relevant files sit in the GPO tree under SYSVOL, in the Machine and User subfolders. The most common are:
Groups.xml: local users and groups, often the local administrator password;Services.xml: service logon accounts;ScheduledTasks.xml: scheduled tasks;DataSources.xml: ODBC data sources;Drives.xmlandPrinters.xml: drives and printers mapped with credentials.
A simple search for the string cpassword in SYSVOL XML files is enough to find them. At the time, Microsoft released a detection script alongside the bulletin. An empty cpassword value is harmless; a populated value must be considered compromised.
Other secrets in SYSVOL and NETLOGON
GPP is only the best-known part of the problem. Our audits regularly find:
- logon scripts (batch, PowerShell, VBScript) containing an account and password to map a drive or run an installation;
- unattended installation answer files left in a deployment folder;
- application configuration files, exports or backups copied "temporarily" into NETLOGON;
- local administrator passwords encoded in Base64 or lightly obfuscated, which is no protection at all.
Search for keywords such as password, pwd, net use, runas, ConvertTo-SecureString or credential, then review the results manually: false positives are common, but true positives are critical.
Deleting is not enough. A password exposed in SYSVOL may have been read by any account for years. It must be changed everywhere it is used, not just removed from the file.
Clean up and replace
- Inventory each file containing a secret, the originating GPO or script and the systems involved.
- Change exposed passwords immediately, starting with privileged accounts and local administrators.
- Remove the relevant preferences in the Group Policy Management Console rather than deleting files by hand, to avoid inconsistencies.
- Replace the use cases: Windows LAPS for local administrators, Group Managed Service Accounts for services and scheduled tasks, share permissions based on the user's identity for drive mappings.
- Remove orphaned GPOs and policy folders with no matching object in the directory.
Also think about GPO backups and SYSVOL copies kept on file servers: they contain the same secrets.
What an audit checks
- populated
cpasswordvalues in SYSVOL; - scripts and files in SYSVOL and NETLOGON containing credentials;
- orphaned, disabled or unlinked GPOs still present;
- write permissions on SYSVOL and NETLOGON, which would allow tampering with a script everyone runs;
- effective rotation of previously exposed passwords.