I’ve finally moved up in the world and am pwning companies instead of n00bs, but all the workstations are locked down. What is this Group Policy thing? Why is it harshing my mellow?
So, you’ve finally moved up into the big leagues. You’re no longer wasting your time hacking your friends, parents, or that camping scrub from Fortnite. You’ve decided to take the skillz you learned (possibly from my previous post: Intro to Macros and VBA for Script Kiddies and go after corporate America. The pencil pushers in the cubicle farms may seem like easy targets, but they are protected by some serious red tape and the dreaded sysadmin. These sysadmins have a variety of tools in their arsenal and aren’t afraid to deploy them to protect their kingdom. One of the most widely used tools is Group Policy.
Group Policy is a feature built into the Windows operating system that allows an administrator to control the settings of the machine . While these Group Policies can be used on a standalone machine, they are most widely used and effective in administering machines and users on a domain using Active Directory. Group Policy provides an administrator with centralized management to implement security settings, enforce IT policies, deploy software, run scripts, and other tasks. Together, a set of configurations is called a Group Policy Object (GPO). Ultimately, these policies control what users can and cannot do on the system, which is why they are important.
Group Policies can be applied to specific computers, users, or organizational units. When a system or user logs in to the Active Directory, it processes the appropriate Group Policies based on membership within the domain, specific group, or organizational unit. The policies are pushed down via Active Directory, which is Microsoft’s directory service. Active Directory is used for domain management and provides its services using the Lightweight Directory Access Protocol (LDAP). The security policies for the domain are listed in the LDAP directory. In particular, they can be found on the domain-wide share, SYSVOL. All domain Group Policies are stored in \\<DOMAIN>\SYSVOL\<DOMAIN>\Policies\ and every authenticated user has read access to this location so the system can run these security policies every time the user logs on as well as randomly every 90 minutes.
Group Policy functionality is typically enhanced or extended through the use of Group Policy extensions. These extensions have server-side and client-side components. The administrator uses the server-side component and the Group Policy Editor (GPE) to configure the policy. The client-side extension applies the policy settings on the client.
Group Policy is complex and understanding all the relationships and settings is a whole sysadmin course in itself. The TL;DR is that Group Policy is used on domains to configure the settings of all the computers, and it provides a lot of functionality for sysadmins and a lot of headaches for hackers. So, you may want to throw in the towel and just go back to hacking that home user with the unpatched Windows Vista machine, but if you want to see what Group Policy can offer us Script Kiddies, keep reading.
Group Policies in Active Directory
Ok, ok, so Group Policy is a set of Commandments passed down from the sysadmin On High. It really seems unfair. Please tell me there is a way to nerf this superpower. I pwned a domain user, so can I use this access for fun and profit?
As we just learned, Group Policies are typically administered and distributed via Active Directory using LDAP. This means that most of the Group Policy information that we are interested in will be coming from the network. Additionally, if you are lucky enough to be an authenticated user by might or by right, then you have access to the LDAP share containing this valuable information. So what can you do given the right access to the network?
Group Policies store a lot of information that may be valuable to the average Script Kiddie. These settings can tell you a lot of information about the environment, security policies, services, etc. There are a variety of tools out there that will help you map and parse the Group Polices including PowerView and Bloodhound. You can determine which policies are applied to the local system or user or other systems in the network. These settings could help determine where to target, what to avoid, and possibly how to exploit other systems. In addition to the Group Policies themselves, you may be able to find some of the scripts that these GPOs run, which may include plaintext passwords, accounts, network shares, etc.
Abusing Group Policy
In addition to just gathering information, you may be able to take advantage of Group Policy to make your job easier. The most common hack is enumerating the Group Policies and finding some GPOs that you have permissions to edit. If you can edit a GPO, then you can do everything that a sysadmin can do (but better), including:
- Run scripts
- Install and execute a backdoor
- Change user passwords
- Create accounts
- Change permissions
Attacking Group Policy
We have gathered information and abused these Group Policies, but we can take it another step and actually attack some of the features of Group Polices. In addition to the passwords you can find in script, you may be able to recover passwords from Group Policy Preferences (GPPs). GPPs give sysadmins the ability to store and use credentials in several scenarios, including mapping drives, scheduling tasks, running services, and changing local Administrator passwords. That can help out the sysadmin, but it may also provide you with an avenue of attack. With access to these GPPs, attackers can use tools to decrypt these passwords. There are several tools available including modules built into Metasploit. Microsoft released a patch in 2014, but you can find some unpatched systems or old GPP files that are still vulnerable.
Local Group Policy Artifacts
So, you’re telling me there’s a chance? Still, it seems like most of the Active Directory Group Policy hax are patched. I’m pretty sure the network is locked down, and I really only have access to this nobody’s machine. What else can Group Policy do for me?
Most of the techniques described so far have been discussed widely on the forums. The GPP attacks have been built into standard tools, and Microsoft has patched the vulnerabilities. In addition, sysadmins are getting better and better at locking down the permissions with regards to GPOs. So, you may not be able to use and abuse GPOs like the good ol’ days, but you can still use Group Policy for situational awareness. When you land on a system, it is always best to get a little information about the environment, and there are some Group Policy artifacts that can help with that. Using the information available through local Group Policy artifacts maybe the easiest way to gather a better understanding of the system and network without triggering any reconnaissance red flags.
Group Policy History
Group Policies are pushed out from the domain controller through Active Directory service. As GPOs are applied when the computer starts or when a user logs on, the local system creates a history of these actions. This history is stored in the registry. The registry stores a history of every GPO applied to the system and each user who has logged on to the domain.
The Group Policy History subkey can provide some easy to access information about the environment. All users have access to the GPO history applied to their own account as well as the system, and administrators have access to the GPO history of every user who has logged into the system.
To inspect Group Policy Objects applied to the current user, browse to the registry key:
To inspect Group Policy Objects applied to the local system, browse to the registry key:
This History includes which Group Policy extensions were configured, the order the GPOs were applied, version data, and some of the options for each GPO.
As we see in Figure 1, information about each GPO is stored in the registry. This includes the DisplayName, Extensions, FileSysPath, and Link.
The history is broken down by Group Policy extension which is stored according to its GUID. Some of the common GUIDs are:
In Figure 1, we can see that the Administrative Template and Security client-side extensions were used to apply settings. We can also see a history of the different versions that were applied.
The History subkey contains some interesting information including the name of the domain controller and the domain to which the machine is joined.
Group Policy State
In addition to the History subkey, the Group Policy registry key also contains the State subkey. The State subkey has some more information for our situational awareness especially regarding the machine itself. This Machine subkey includes the Distinguished-Name in Active Directory and the Site-Name. You can use this information to start mapping out the design and layout of the network.
The State subkey also contains information about each user who has logged on interactively to the system. This includes their Distinguished-Name and the Site-Name that processed their logon. This information can be matched against the user’s SID.
Group Policy GroupMembership
The final Group Policy key we will look at is the GroupMembership subkey. The GroupMembership subkey contains group information for the user and the system. As the GPOs are processed, the registry stores a list for the SIDs of the corresponding groups.
In Figure 5, we can see all the groups that the current user is a member of. This could be useful for determining their access and permissions on the local machine and across the network.
In Figure 6, we see the group membership of the local machine, as well as every user that has logged on to that machine. Again, this may require more rights and permissions than you have, but it can give you a much better idea about who uses the machine and maybe what it is used for on the domain.
The group memberships use many well-known SIDs (https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/security-identifiers-in-windows). In addition to the regular security groups, there are some internal groups that may provide useful information such as:
- S-1-5-4 – Users that have logged on interactively.
- S-1-5-2 – Users that have logged on through a network connection.
- S-1-5-6 – All security principals that have logged on as a service.
- S-1-5-14 – Users who have logged on through a terminal services logon.
This additional information may give us an avenue of attack. If we see that a sysadmin logs into this machine via Remote Desktop Protocol (RDP), then we can force caching of plaintext credentials in LSASS for the next time they RDP into the box and—bam—creds for days.
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation /v AllowDefaultCredentials /t REG_DWORD /d 1
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation /v ConcatenateDefaults_AllowDefault /t REG_DWORD /d 1
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation\AllowDefaultCredentials /v 1 /t REG_SZ /d “TERMSRV/*”
So, Group Policy is for real. It helps protect all those pencil pushers who wouldn’t know a phish from an aquarium pet and who would rather just have “password” for their password. It is a source of frustration, but it can also be a source of information. Now I know where to look to gain some insider intel.
After this shallow dive into Group Policy, you should have a better understanding of what Group Policy is, how it makes a sysadmin’s job easier, and what information it can provide you as an attacker. Group Policy may be a powerful weapon in defending the castle that is the corporate domain, but it has been shown to have its vulnerabilities, and even if some of these vulnerabilities have been patched, it can still provide a wealth of situational awareness. It can give you information about the machine itself as well as the users that have logged into the system. In general, it can give you a better picture of the environment you have landed in and hopefully with great knowledge comes great power. So, try not to be too afraid of Group Policy, and always remember to checky your return values.