Blog: How-Tos
Abusing Group Policy Preferences to Elevate Privileges
As a standard domain user, you don’t have many rights on your workstation (or at least you shouldn’t), however time and time again we see ways that a normal user can elevate their privileges to a local administrator or in some cases even domain administrator.
This is a serious issue as if a rogue employee decided to hack your network, this would be the first thing they would need to do in order to then attack the rest of the network.
One interesting way we have achieved this over the last 12 months is through Group Policy Preferences (GPP).
A common scenario we’ve seen is companies setting local administrator passwords on hosts via GPP. When this is configured, an XML file is created on the domain controller that contains the information required to configure the account when the policy is applied to the workstation or laptop connected to the domain.
This file contains the password for the administrative account and is generally readable by any domain user. Microsoft has encrypted the value using AES to increase security, but have also published the key used to encrypt and decrypt the value which renders the encryption pointless.
A user could exploit this to gain local administrative access to their workstation by taking the following steps:
First the domain controller can be found by issuing the following command:
LOCALAPPDATA=C:\Users\Joe\AppData\Local
LOGONSERVER=\\TestDC1
This shows that the domain controller is called TestDC1
We can then connect to the default SYSVOL share of the domain controller and search it for instances of groups.xml. If these files exist they will be in a folder with a format similar to this:
As an example, a groups.xml files may look similar to this:
<Groups clsid=”{E9373125-16FB-4F3a-335D-63DCAB124D26}”> <User clsid=”{FD5F8155-ABE3-4d24-8B1A-A9CDE43BA121}” name=”Administrator (built-in)” image=”2″ changed=”2013-12-12 14:37:47″ uid=”{8F9E43E1-8FDA-42EB-9649-4CC444B09FAE}” userContext=”0″ removePolicy=”0″> <Properties action=”U” newName=”ladm” fullName=”” description=”” cpassword=” dGhpcyBpc250IGFjdHVhbGx5IGFlcyBlbmNyeXB0ZWQh ” changeLogon=”0″ noChange=”0″ neverExpires=”0″ acctDisabled=”0″ subAuthority=”RID_ADMIN” userName=”Administrator (built-in)”/ > </User>
</Groups>
As stated, the password would be AES encrypted, however Microsoft publish the encryption key at the following URL:
http://msdn.microsoft.com/en-us/library/2c15cbf0-f086-4c74-8b70-1f2fa45dd4be.aspx#endNote2
The key turns out to be:
Using this, we can decrypt the local administrator password:
UserName NewName Password
——– ——- ——–
Administrator (built-in) ladm h4ppyxm455!!
From this point, it’s as easy as spawning an instance of the command prompt or PowerShell as the local administrator using the runas command:
Enter the password for ladm:
Attempting to start cmd.exe as user “topsecretmachine\ladm” …Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.C:\Windows\system32> whoami
topsecretmachine\ladm
And there we have it! We are in to the local system as the administrator account.
An attacker could then use a multitude of techniques to then further attack the network and try to get domain administrative access (which is a whole different blog post).
This is the expected behaviour of a Windows 2008 domain and is therefore not an insecurity caused by a misconfiguration but rather just a flaw in the design that could be detrimental to your network’s security.
You could try changing permissions of the groups.xml files to prevent standard users from reading the file, or investigate other means of performing tasks such as setting local passwords.
My advice would be to have a different password for every local administrator account and to not have passwords defined in group policy.
