Today, we released an update to address a vulnerability in Group Policy Preferences (MS14-025). Group Policy Preferences was an addition made to Group Policy to extend its capabilities. Among other things, Group Policy Preferences allows an administrator to configure:
- Local administrator accounts (name of the account, account password, etc)
- Configure a service or scheduled task (allowed to specify alternate credentials to run as)
- Mount network drives when a user logs in (allowed to specify alternate credentials to connect with)
Group Policy Preferences are distributed just like normal group policy: An XML file containing the settings is written to the SYSVOL share of the domain controllers, and computers periodically query the SYSVOL share (authenticating to it using their computer account) for updates to the group policy.
Several of the Group Policy Preferences allow credentials to be specified. When this option is used, the password is symmetrically encrypted using a static key and written to the XML file along with the rest of the settings. What is this key you ask? It turns out, we document it on MSDN: http://msdn.microsoft.com/en-us/library/cc422924.aspx.
If an attacker is able to get access to the SYSVOL share (which is open to all authenticated users, so a malicious or spear phished employee will have access to it) and obtain the AES encryption key used to encrypt/decrypt passwords set with GPP (which we document on MSDN), the attacker will be able to obtain the credentials set with GPP.
Microsoft has observed that Group Policy Preferences abuse is one of the most common tactics used by attackers to elevate permissions in a domain. Multiple toolkits used by attackers such as Metasploit (http://www.rapid7.com/db/modules/post/windows/gather/credentials/gpp) and PowerSploit (https://github.com/mattifestation/PowerSploit/blob/master/Exfiltration/Get-GPPPassword.ps1) provide easy to use methods for retrieving and decrypting GPP passwords. In the worst case scenario, companies use Domain Administrator credentials in their Group Policy Preference accounts, resulting in a full domain compromise as soon as the attacker is able to access with SYSVOL share (and decrypt the passwords using the documented key).
Microsoft has released an update to change the behavior for this issue, but companies using GPP need to take action. Microsoft has removed the ability to create or modify any Group Policy which contains a Group Policy Preference that specifies account credentials. The only action that can be performed on such a Group Policy is “delete”. Note that Microsoft is not automatically disabling these Group Policies because we do not want to disrupt existing environments which rely on this feature. You can see in the picture below that when attempting to create a local account the “username” and “password” fields are disabled. If you attempt to create a user, an error dialog will be displayed.
](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/47/gpp.png)
In addition to the change in behavior, Microsoft is providing customers with two PowerShell scripts. The first script, Enum-SettingsWithCpassword, will search existing GPO’s for use of the account password functionality. We urge companies to immediately run this script and delete vulnerable GPO’s detected.
The second script, Invoke-PasswordRoll, can be used to set local administrator passwords on remote systems (something that Group Policy Preferences is commonly used for). The script takes a list of usernames and computers, and uses PowerShell remoting to connect to each computer and change each specified usernames password to a randomized password. The username/password combinations will be written recorded in a file on disk (which is encrypted, but optionally can be stored in clear-text). Note that the script enforces randomized passwords to ensure the local accounts cannot be used in pass-the-hash attacks.
You can find both scripts at http://support.microsoft.com/kb/2962486.
- Joe Bialek, MSRC engineering team