Abusing Group Policy Preference files for password discovery

How attackers can exploit Group Policy Preferences file in order to discover passwords?
And how SysAdmins can mitigate this vulnerability?

During a penetration test or a security assessment, an important point must be the analysis of AD domain, especially the Group Policy Preference files.

Any group policy file that need to use a local or domain password (ie local admin password change, service creation, scheduled tasks creation) stores the password in the XML file, stored in the SYSVOL path (usually \\DOMAIN\SYSVOL).

The password is stored encrypted, with an AES256 algorithm, however Microsoft notify that this password is ‘discoverable’…why?

image

Because the encryption key is public and well documented on this MSDN page: https://msdn.microsoft.com/en-us/library/cc422924.aspx?f=255&MSPPError=-2147217396

So, an attacker that gains access to any client on the domain (with a valid domain user) may browse the sysvol in order to find preference files that may contains an encrypted password, using a simple DIR:

dir \\DOMAIN\sysvol\*.xml /a-d /s

Preference files that may contains a stored password are usually:

  • Groups.xml
  • Services.xml
  • Scheduledtasks.xml
  • DataSources.xml
  • Printers.xml
  • Drives.xml

Furthermore, well known tools like the Get-GPPPassword module of Powersploit framework allows an attacker to automate this enumeration process.

For example, this is a Group.xml file that set the local administrator password contains an encrypted password in the cpassword field:

<?xml version="1.0" encoding="utf-8"?>
<Groups clsid="{3125E937-EB16-4b4c-9934-544FC6D24D26}"><User clsid="{DF5F1855-51E5-4d24-8B1A-D9BDE98BA1D1}" name="Administrator (built-in)" image="2" changed="2017-10-10 11:23:48" uid="{355F2024-75C3-4EB4-9A16-BE114035625F}"><Properties action="U" newName="" fullName="" description="" cpassword="VPe/o9YRyz2cksnYRbNeQj35w9KxQ5ttbvtRaAVqxaE" changeLogon="0" noChange="1" neverExpires="1" acctDisabled="1" subAuthority="RID_ADMIN" userName="Administrator (built-in)"/></User>
</Groups>

The stored password is VPe/o9YRyz2cksnYRbNeQj35w9KxQ5ttbvtRaAVqxaE, and it can be decoded using a simple script that decrypt the AES256 using the key published on MSDN.

Below two simple implementation, in Powershell

https://gist.github.com/andreafortuna/6dc38f84f07fdadd1c90c41db7cd35e0
PowerShell version


and Python:

https://gist.github.com/andreafortuna/4d32100ae03abead52e8f3f61ab70385
Python version
andrea@Lucille:~/Projects$ ./GPPDecrypt.py VPe/o9YRyz2cksnYRbNeQj35w9KxQ5ttbvtRaAVqxaE
Password1
andrea@Lucille:~/Projects$

Obviously, in the Group.xml file the store password is “Password1” 🙂


How to prevent an attacker exploiting Group Policy preferences files?

In my opinion, the best way is NOT store passwords in policy files.

Also Microsoft has the same vision: in 2014 released an update for Group Policy Preferences (MS14-025) that removes the ability to create or modify any Group Policy which contains a Group Policy Preference that specifies account credentials.

In the update release:

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 and PowerSploit 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).

https://blogs.technet.microsoft.com/srd/2014/05/13/ms14-025-an-update-for-group-policy-preferences/

So Microsoft has removed this dangerous feature, but companies using GPP need to take action: now the only action that can be performed on such a Group Policy is “delete”, then companies need to implements alternative methods.

Luckily, Microsoft also provides, with this update, two useful PowerShell scripts:

Enum-SettingsWithCpassword.ps1: search existing GPO’s for use of the account password functionality, useful for an quick deletetion of all vulnerable files.

Invoke-PasswordRoll.ps1: 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.


References

Comments

This site uses Akismet to reduce spam. Learn how your comment data is processed.