May 15

Group Policy Preferences Password Vulnerability Now Patched

Looks like Microsoft finally removed the ability to set admin account passwords through GPP due to the Group Policy Preferences password  exposure vulnerability.

More information on how Group Policy Preferences are attacked is in the post “Finding Passwords in SYSVOL & Exploiting Group Policy Preferences“.

Because of the security concerns with storing passwords in Group Policy Preferences, Microsoft just released a security patch, MS14-025: Vulnerability in Group Policy Preferences could allow elevation of privilege, that removes this functionality. Any passwords that were in Group Policy Preference xml files stored in SYSVOL before the patch are still in SYSVOL after MS14-025.

Note that this doesn’t remove the ability for Windows to perform this functionality, it only removes the ability to configure passwords in Group Policy Preferences through the GUI. In other words, the patch is for the RSAT – Server Admin Tools. This is impressive since it actually removes functionality which is something Microsoft is traditionally not fond of doing.

In July 2013,  I wrote about the vulnerability of managing passwords with Group Policy Preferences. Here’s the information:

Using Group Policy Preferences for Password Management = Bad Idea OR “How to Get Your Network Owned in Several Simple Steps”

One of my customers recently needed to change the local administrator password on several hundred Windows 7 workstations and was trying to determine the best method: PowerShell script or Group Policy Preferences.

The easy answer is to use Group Policy Preferences since it has a built-in mechanism for changing/managing local computer passwords. The problem is that while the password in Group Policy Preferences is encrypted using AES 256, the private key for the encryption is posted on MSDN.

Since the private key for this data is well known, using Group Policy Preferences to manage local computer passwords means these passwords are vulnerable to discovery. Since the Group Policy Preference data is stored in an XML file in SYSVOL (such as drives.xml, groups.xml, printers.xml, etc), all authenticated users in the domain has read access (they have to in order to apply Group Policy). This means that any authenticated user can open the Group Policy Preference XML file with the encrypted password and decrypt it using the AES key posted on MSDN. This AES key is part of every Windows computer that is Group Policy Preferences capable (native support in Windows 7 and newer; Windows Vista with an install; and Windows XP SP 2 & Windows 2003 SP1 with a patch, KB943729) in order for the computers to decrypt the password and use it. If the Group Policy Preference requires a password to be entered, it is stored in an XML file in SYSVOL. Despite the fact that the password is AES 256-bit encrypted (and base 64 encoded with padding if necessary), it is not secure. Microsoft does not recommend storing passwords in Group Policy Preferences (blog post linked below) and Windows Server 2012 displays a message with a similar warning.

Windows Server 2012 Group Policy Preference password Warning:







Here’s a sample groups.xml file from SYSVOL representing a Group Policy using Group Policy Preferences to add a new user to computers in the linked OU.

<?xml version=”1.0″ encoding=”utf-8″?>
<Groups clsid=”{3125E937-EB16-4b4c-9934-544FC6D24D26}”>
<User clsid=”{DF5F1855-51E5-4d24-8B1A-D9BDE98BA1D1}” name=”LocalTestUser” image=”0″ changed=”2013-07-04 00:07:13″ uid=”{47F24835-4B58-4C48-A749-5747EAC84669}”>
<Properties action=”C” fullName=”” description=”” cpassword=”sFWOJZOU7bJICaqvmd+KAEN0o4RcpxxMLWnK7s7zgNR+JiJwoSa+DLU3kAIdXc1WW5NKrIjIe9MIdBuJHvqFgbcNS873bDK2nbQBqpydkjbsPXV0HRPpQ96phie6N9tn4NF3KYyswokkDnj8gvuyZBXqoG94ML8M1Iq7/jhe37eHJiZGyi5IBoPuCfKpurj2″ changeLogon=”0″ noChange=”0″ neverExpires=”0″ acctDisabled=”0″ userName=”LocalTestUser”/>

cpassword above represents the encrypted password and I was able to browse to and save this file from SYSVOL with a regular domain user account. All that is left to do is to perform a Base64 unencode, then decrypt using the MSDN AES key.

Here’s the 32-byte AES key used to encrypt ALL Group Policy Preferences passwords in any domain:

4e 99 06 e8  fc b6 6c c9  fa f4 93 10  62 0f fe e8
f4 96 e8 06  cc 05 79 90  20 9b 09 a4  33 b6 6c 1b

The problem is that since the AES encryption (and decryption) key is known (and posted publicly on MSDN and here), Group Policy Preferences can’t be considered a secure method for changing passwords.

The Microsoft Group Policy Blog posted about the potential issues in 2009:

Are passwords in preference items secure?
A password in a preference item is stored in SYSVOL in the GPO containing that preference item. To obscure the password from casual users, it is not stored as clear text in the XML source code of the preference item. However, the password is not secured. Because the password is stored in SYSVOL, all authenticated users have read access to it. Additionally, it can be read by the client in transit if the user has the necessary permissions.

Because passwords in preference items are not secured, we recommend that you carefully consider the security ramifications when deciding whether to store passwords in preference items. If you choose to use this feature, we recommend that you consider creating dedicated accounts for use with it and that you do not store administrative passwords in preference items.

Where can you use passwords?
You can use passwords in the following types of preference items:

  • Local User preference items: When you create or modify a local user account, you can specify both a user name and a password for the account.
  • Data Source preference items: If a user name and password are required to access the data source, you can provide them in the preference item. If you do so, end users to whom the preference item applies can access the data source regardless of their own permissions, but only if the specified account has the necessary permissions.
  • Mapped Drive preference items: You can specify the user name and password to be used to connect to a mapped drive. If you do so, end users to whom the preference item applies can access the mapped drive regardless of their own permissions, but only if the specified account has the necessary permissions.
  • Scheduled Task or Immediate Task preference items: You can configure a scheduled task to run under the security context of a specified user (allowing the task to run regardless of whether that user is logged on), by selecting the “Run as” check box and providing a user name and password.
  • Service preference items: You can modify which account the service runs under by selecting “Local System account” or by selecting “This account” and specifying a user name and password.

If this HAS to be done and you accept the risk, you can set the group policy for a few days and then delete it. However, there is a chance that someone already copied the XML file containing the password and already knows it. Using SCCM or a scripted solution may be the best answer for now, unless you want to pay for a product from CyberArk or Quest (note that these products are mentioned for informational purposes only).

Here’s a PowerShell script I wrote that reports on what credentials are stored in Group Policies. PowerShell Script: Discover Group Policy Passwords. Updated 10/2014 – Requires the Active Directory PowerShell module.

Attack Vectors:

There is code on MSDN for managing local admin passwords for computers by storing the password in a confidential Active Directory attribute on each computer object. Note that this solution is not supported by Microsoft.


This sample is a fully working solution that implements automatic management of password of builtin Administrator account on computers joined to domain.

Solution currently available out of box on the platform (Group Policy Preferences) does not fulfill usual security requirements. Main problems with GPO Preferences are:

  • Password is the same on many workstations
  • Password stored in GPO and transported over network is not encrypted, but obfuscated (and obfuscation algorithm is published on MSDN), so it is not secure solution

Solution implemented by this sample does not have such weak points.


Due to the issues involved with publishing easily accessed password data, the question is, how can this be mitigated?
One way to mitigate the risk of managing local computer administrator passwords is to remove Authenticated Users (and Domain Users) from having Read rights to the Group Policy XML file and add Domain Computers (or a subset) to have Read (& apply) rights. Make sure you  test this scenario in a production lab environment if you decide this is the method you want to use.
My previous post on this issue includes other possible password management methods.

I wrote a quick PowerShell script that will scan SYSVOL for XML files, identify the userid & encrypted password for each GPO, and write a CSV report with this data. For those that have some PowerShell knowledge, the script will also decrypt the cPassword value ($Decrypt switch) using the function Get-DecryptedCpassword.

The PowerShell script included here is for educational purposes only and should not to be used in a production environment.

Here’s the PowerShell script code (Find-GPOPasswords) that will discover Group Policy Preference XML file data in SYSVOL and provide a CSV report:


(Visited 5,244 times, 14 visits today)