Group Policy Preferences password present in SYSVOL
A Group Policy Preferences file in SYSVOL still holds a password that any domain user can decrypt.
- Category
- Hygiene
- Severity
- Critical.
- Typical owner
- AD / identity team, with the owner of the account
- Data needed
- Pathwarden's built-in collector* only: it reads the Preferences files in SYSVOL (as the current Windows user on Windows, or with
--user). SharpHound doesn't collect them.
On this page
In plain language
Years ago, Group Policy Preferences let administrators set passwords (for local admin accounts, services, scheduled tasks) through Group Policy. The passwords were stored, encrypted, in files on the SYSVOL share that every domain user can read, and Microsoft published the decryption key in its documentation.
Microsoft removed the feature in 2014 (MS14-025), but the update doesn't delete passwords that were already there. Any found today is readable by everyone. Pathwarden records where it is and for which account; it never decrypts or stores the password.
What Pathwarden flags
A Group Policy Preferences (GPP) file in SYSVOL has a cpassword attribute: a
password that a GPO sets for a local account, a service, a scheduled task, a
mapped drive, a data source or a printer. GPP files live under
\\<domain>\SYSVOL\<domain>\Policies\{GUID}\Machine\Preferences and
...\User\Preferences, in Groups.xml, Services.xml,
ScheduledTasks.xml, DataSources.xml, Drives.xml or Printers.xml.
The password is encrypted with AES, but Microsoft published the key in its protocol documentation in 2012. Every authenticated user can read SYSVOL, so anyone in the domain can decrypt it in seconds. Microsoft removed the ability to create these passwords in 2014 (MS14-025, KB2962486), but the update does not delete the ones that already exist.
Pathwarden records that a password exists, in which GPO and file, and for which account. It never decrypts it and never stores the value.
How attackers use it
It is one of the first things any attacker or penetration tester checks (Unsecured Credentials: Group Policy Preferences, T1552.006). One read of SYSVOL gives a working password, often for a local administrator account that is the same on every computer the GPO applies to, or for a service account with broad rights.
Find it with Pathwarden
Data needed: Pathwarden's built-in collector* only: it reads the Preferences files in SYSVOL (as the current Windows user on Windows, or with --user). SharpHound doesn't collect them.
In the web UI or the HTML report, open the Findings tab and expand PW-026: each finding shows who can use it (its exposure), the attack path drawn out, the affected objects, and the fix. The remediation path tells you whether a single plan step closes it. On the command line:
# every finding of this rule, with its path and fix
pathwarden findings -i .\collect --rule PW-026
# the step-by-step guide on this page, offline
pathwarden guide PW-026
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-026Exit codes make retest easy to script: 0 Fixed, 1 Still open, 3 Can't tell. See findings lifecycle and retest.
Before you change anything
- Assume the password is known. Removing the file does not undo that: the password must also be changed.
- Find out what still depends on the preference item: which computers get the local account, which service or task runs with it.
- For local administrator passwords, plan the replacement first: Windows LAPS gives every computer its own password.
How to fix it
- Change the password of the account the finding names, everywhere it is used. For a local account set by the GPO, every computer the GPO applied to has that password: rotate it there too (LAPS does this for you).
- In Group Policy Management, edit the GPO named in the finding. Under Computer Configuration or User Configuration > Preferences, open the extension that matches the file (Local Users and Groups, Services, Scheduled Tasks, Data Sources, Drive Maps, Printers) and delete the item that sets the password. If the GPO holds nothing else, unlink and delete the GPO.
- Install MS14-025 (KB2962486) on every computer that runs Group Policy Management, so that no one can create new GPP passwords.
- Replace the use case: Windows LAPS for local administrator passwords, group Managed Service Accounts for services and scheduled tasks.
Audit SYSVOL for every remaining GPP password
Run as any domain user. It lists files and lines, not the passwords:
$domain = $env:USERDNSDOMAIN
Get-ChildItem -Path "\\$domain\SYSVOL\$domain\Policies" -Recurse -Include *.xml -ErrorAction SilentlyContinue |
Select-String -Pattern 'cpassword="[^"]+"' |
Select-Object Path, LineNumberMicrosoft's KB2962486 also has a script (Get-SettingsWithCPassword.ps1) that
reports the GPO name and the preference for each.
Verify the fix
The audit command above returns nothing for the GPO in the finding. Collect again with the built-in collector and confirm the finding ID is gone. Try the old password for the account: it must no longer work.
Roll back
Removing a preference item stops the GPO from setting that password on the
next refresh; computers keep whatever they already have. To restore it, back
the GPO up first (Backup-GPO -Name '<GPO>' -Path C:\GPOBackup) and restore it
with Restore-GPO. Do not put the password back: use LAPS or a gMSA instead.
References
- Microsoft Security Bulletin MS14-025learn.microsoft.com
- MITRE ATT&CK T1552.006: Unsecured Credentials: Group Policy Preferencesattack.mitre.org
Very new and undergoing testing. These features haven't received a lot of testing yet. Try them out and let us know what's working.