Group Policy Preferences (GPP) is a powerful Windows group policy extension that makes setting and management of the park of computers easier and is a sort of substitution to different scripts in GPO. One of the GPP opportunities is to manage passwords of local and service accounts widely used by many administrators, who even have no idea of this technology being insecure. In this article we will explain why you shouldn’t use the password management features of Group Policy Preferences.
There are 5 different policies that allow to set a user/administrator password in Group Policy Preferences.
- Local users and groups – with GPP, an administrator can create/change a local account and set its password (this policy is quite often used to change the password of the local administrator on all corporate PCs)
- Drive Maps – GPP allow the user to connect a drive map with the definite user name and password
- Data sources – when creating a data source, you can set a user name and a password for the account to connect from.
- Windows Scheduled Tasks – scheduled tasks can be run from a certain user account
- Services – GPP allow to specify an account and its password from which a certain service is run (instead of Local System account).
After the administrator saves the password in any of the GPPs listed above, it is stored in a special XML file in the corresponding GPO directory and later — in the domain controllers in the SYSVOL folder. The password is stored encrypted in the XML file, but to cipher/decipher the password, a very unstable symmetric algorithm AES 32 is used (it is recognized by Microsoft itself).
Suppose, the administrator has set the policy that changes the local administrator password on all PCs using the GPP. Then the system saves the encrypted password in the file groups.xml in the GPO directory. Let’s see what this file contains (in our example this file is stored in the \\woshub.com\SYSVOL\woshub.com\Policies\{POLICY_ID}\Machine\Preferences\Groups directory).
The encrypted password is the value of the CPASSWORD field. The most interesting is that Microsoft has published a 32-bit AES key used to encrypt the password in MSDN (http://msdn.microsoft.com/en-us/library/2c15cbf0-f086-4c74-8b70-1f2fa45dd4be.aspx#endNote2)
So, anyone can write a script that allows to decrypt the password that is stored in the XML file (the AES algorithm is symmetric and the encryption key makes it possible to get a source text easily).
Note. You can download a script to decipher a password stored in the GPP here: Get-GPPPassword. Obviously, we upload this file for reference only and it must not be used for lucrative purposes.
Microsoft developers have added the warning of the insecurity of this way to store passwords in Windows Server 2012 / Windows Server 2012 R2. When trying to specify the password with the GPP, the following warning appears:
This password is stored as part of the GPO in SYSOL and is discoverable, although obscured.
It is also important to note that the MetaSploit module of obtaining and decrypting passwords stored in the GPP exists since 2012. It means that hackers can implement this attack vector almost automatically.
So, will you go on using Group Policy Preferences to manage passwords?