How to PWN Systems Through Group Policy Preferences

Thursday, September 20, 2012

Jeff McCutchan


SecureState’s Profiling Team loves breaking into systems.  Sometimes we use advanced tactics, and sometimes we only need to use simple attacks. 

No matter how we do it we are always excited to learn and try new techniques.  Typically on a penetration test, a user account is compromised and the consultant now has access to the network as that user. 

One of the first things we try to do is leverage the account to obtain administrative access to as many systems as possible. There are multiple techniques for doing this; this article will discuss one that was disclosed earlier this year but not widely adopted until recently.  The technique works by exploiting a “feature” of Windows Server 2008 group policy preferences (GPP) and it has the potential to lead to complete domain wide compromise.

How it works:

Actions such as adding a local user or configuring mapped drives or printers, when performed on a domain controller may require a password to be specified.  If these preferences are then applied to the other systems in the domain, that password also has to be pushed down to those systems as well.  Windows accomplishes this by transmitting an XML configuration file with all of the parameters inside. 

In order to prevent cleartext passwords from being transmitted over the network, the password is encrypted with AES 256 encryption and then Base64-encoded before it is stored in the XML file.  The configuration file which contains the encrypted password is located on the domain controller in a subfolder of the “SYSVOL” directory.  The name of the file depends on the action being applied through group policy. Some of the more common files are groups.xml, printers.xml, and drives.xml.

Figure 1: Groups.xml and encrypted password

In order for the preference to be applied to the servers and workstations in the domain, those systems must be able to decrypt the password when the policy is updated.  For that to be possible, the decryption key must be stored on the local machine.  It is, but that doesn’t really matter.  As it turns out Microsoft knowingly released the decryption key in an MSDN article. 

By using this key, one can easily decrypt the password recovered from the configuration file.  Additionally, there are scripts and even a Meterpreter post module freely available that automate the entire process (Figures 2 and 3).  Microsoft is aware of the risks presented by this and warns users not to store passwords in GPPs, especially those of administrative users.  Windows Server 2012 will even warn the user of this security risk in the form of a dialogue box.


Figure 2: Using a script to decrypt the password

Figure 3: Automating the process with Meterpreter

Why you should care:

The thing to remember here is that any domain user can perform this attack because all users have read access to the SYSVOL share of the domain controller.  Forget about password cracking or passing the hash, you just get the cleartext password.  A simple search for “*.xml” in the SYSVOL share on the domain controller will show if your organization is vulnerable.  If any files are found, search through them for “cpassword=”. 

Obviously, the risk varies according to the account that is compromised.  Often times it is the local administrator account.  Couple this with the fact that many organizations use the same administrator password throughout the entire domain, and this is a deadly combination. Worse yet, there is no patch or update to fix this, it’s just the way GPPs work.  The only way to protect your organization is through prevention.

Cross-posted from SecureState

Possibly Related Articles:
Network->General Operating Systems
Passwords Methodologies Hacking Vulnerabilities Penetration Testing Attacks Meterpreter Group Policy Preferences
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.