SYSVOL's Broad Read Access Exposes Legacy GPP Passwords

Symptom

Any authenticated domain user, with no elevated rights, can retrieve a plaintext-equivalent password from Active Directory even though the SYSVOL share appears correctly scoped and no anonymous or Everyone access is granted. A routine security review of a domain controller’s SYSVOL replica finds one or more Group Policy Preferences (GPP) XML files — typically Groups.xml, Services.xml, ScheduledTasks.xml or DataSources.xml — each containing a cpassword attribute inside a GPO folder that every domain-joined workstation can already read.

False Assumption

The team assumes that because SYSVOL is restricted to Domain Users/Authenticated Users rather than Everyone, access is already least-privilege and therefore safe. They further assume that any password stored inside a Group Policy object must be encrypted in a way that makes it operationally inaccessible to ordinary users, since the GPMC console never displays the value in cleartext.

Root Cause

SYSVOL must be readable by every domain-joined computer account and, by extension, by every authenticated user session on those computers, because Group Policy client-side extensions read GPO templates directly from SYSVOL during logon and background refresh. This broad-read requirement is an unavoidable platform default, not a misconfiguration in isolation.

The trap appears where that unavoidable default combines with a second, older mechanism: legacy Group Policy Preferences items stored a local account, scheduled task or mapped-drive password inside the GPO’s XML as a cpassword attribute, encrypted with a single, fixed AES-256 key. Microsoft publishes that key in its [MS-GPPREF] protocol documentation, and security bulletin MS14-025 (CVE-2014-1812) removed the password fields from these items without deleting existing cpassword values from SYSVOL. Because the decryption key is public and the ciphertext sits inside a file every domain user can already read, recovering the plaintext requires no more than basic scripting skill, not a privilege escalation.

Impact

Any legacy GPP item containing a cpassword attribute converts a routine, necessary SYSVOL read permission into domain-wide credential disclosure. Observed consequences include recovery of local administrator passwords that are frequently reused across many machines, recovery of service or scheduled-task account credentials, and a direct path to lateral movement once one workstation is compromised. Because the exposure rides on a legitimate access control rather than a broken one, it is routinely missed by permission-focused audits that only check who can read SYSVOL, not what is stored inside it.

Diagnosis

Treat this as a read-only investigation until the scope of affected GPOs and accounts is fully understood.

• Enumerate every GPO for Group Policy Preferences extensions that historically supported cpassword (Groups, Services, Scheduled Tasks, Data Sources, Drive Maps).
• Search the live SYSVOL tree, not just GPMC, because stale or orphaned XML files can persist after a GPO is edited in the console.
• Record the affected GPO names, the account names referenced, and which computers the GPO is linked to, before making any change.

A read-only sweep of every domain controller’s SYSVOL replica for non-empty cpassword values:

Get-ADDomainController -Filter * | ForEach-Object {
    Get-ChildItem "\\$($_.HostName)\SYSVOL\<domain-fqdn>\Policies" -Recurse -Include Groups.xml, Services.xml, ScheduledTasks.xml, DataSources.xml, Drives.xml |
        Select-String -Pattern 'cpassword="[^"]+'
}

Correction

Correction requires removing the credential from Group Policy Preferences entirely and treating the exposed password as permanently compromised, not merely hidden. Take a GPO backup first, then remove the affected preference item through GPMC (not by editing the SYSVOL file directly, which bypasses GPO versioning and replication integrity), and finally rotate every account referenced by the removed preference.

1. Back up the affected GPO(s) so the pre-change state is recoverable.
2. Remove the specific Group Policy Preferences item (the Groups/Services/ScheduledTasks/DataSources entry) through the GPMC console under an authorised change record, rather than by deleting SYSVOL files by hand.
3. Rotate every local account, service account or scheduled-task credential that the removed preference referenced, using a mechanism that does not repeat the same weakness — for example LAPS for local administrator accounts or a managed service account for service credentials.
4. Do not reuse the previously exposed password anywhere, including on a delayed or gradual rollout, because it must be treated as public.

Validation

Validation confirms both that the credential exposure is closed and that nothing downstream broke as a result of the change.

• Re-run the SYSVOL cpassword search across every domain controller’s replica, not just the one where the change was made, and confirm zero matches remain.
• Confirm SYSVOL replication has converged domain-wide before declaring the remediation complete.
• In an isolated test, confirm the rotated account authenticates only with its new credential and that the old, exposed password is rejected.
• Confirm every service, scheduled task or drive mapping that depended on the rotated account still starts and authenticates correctly.

Rollback

Rollback restores the pre-change GPO configuration if the removal breaks a dependent service, while never reinstating the exposed password as a live credential.

• If a dependent service fails after the Group Policy Preferences item is removed, do not restore the backed-up preference item as it stands, because it would push the exposed password back out; restore only non-credential settings from the backup, then investigate the dependency before attempting removal again.
• If a dependent service fails specifically because of the credential rotation, use the organisation’s documented break-glass or vaulted-credential procedure to restore access with a newly issued secret — never by reusing the exposed legacy password.
• Stop condition: halt rotation immediately and escalate to the account owner if a referenced account has no documented owner or no vaulted rotation path, since proceeding without one risks an unrecoverable outage.

Prevention

Prevent recurrence by removing the underlying mechanism rather than only the discovered instances.

• Install the MS14-025 update (KB2962486) or later on every machine used to edit Group Policy, which removes the password fields from these preference items, so the pattern cannot be recreated from a patched console.
• Replace local administrator password management with LAPS (or an equivalent rotated-secret mechanism) and replace static service-account passwords with group-managed service accounts where supported.
• Add a recurring, read-only SYSVOL scan for the cpassword string to change-detection or security baseline tooling, so any reintroduction — including through a restored backup GPO — is caught automatically.
• Document this trap in onboarding material for anyone with GPO edit rights, since the underlying SYSVOL read permission will always look correctly scoped on its own.

Related reading

• Legacy AXFR Flags Survive Windows DNS Upgrades
• SYSVOL Scripts Expose Embedded Credentials to All Domain Users
• SYSVOL Scripts Folder: Authenticated Users Write Trap
• The Legacy Auth Exclusion Group Nobody Prunes