FortiGuard Labs Threat Analysis Report
This is the 4th installment of the “Offense and Defense – A Tale of Two Sides blog series, where we focus on different tactics and techniques malicious actors use to complete their cyber missions—and how organizations can detect and ultimately prevent them. If you happened to miss the first three blogs of the series you can check them out at Offense and Defense – A Tale of Two Sides: PowerShell, Offense and Defense – A Tale of Two Sides: Bypass UAC and Offense and Defense – A Tale of Two Sides: OS Credential Dumping.
In this blog, we will look at Group Policy Objects (GPO) in Windows operating systems. Specifically, how they can be used to deploy and execute malicious payloads on target machines within an Active Directory environment. We will also look at ways to reduce the risk of an attacker using this technique. The technique is called Group Policy Modification in the MITRE ATT&CK knowledgebase, and it is being actively used these days in targeted ransomware attacks.
Group Policies 101
Simply put, GPOs are built-in configuration management technology found in Windows and Active Directory. They can be used by administrators to perform a variety of admin tasks, such as:
- General lockdown of systems
- Security Hardening
- Configuration of Internet Explorer
- Logon and logoff script changes
- Drive and printer mappings
- Setting local administrators – Local group membership
GPOs are stored in two locations:
- Group Policy Containers (GPC)
- GPCs are stored in each domain controller in an Active Directory environment. They contain property information, such as status and versioning information, references to client-side extensions (CSEs), paths to Group policy templates (GPT) and software installation packages and others. It’s important to note that GPCs are referenced by a GPO GUID (Globally Unique Identifier).
2. Group Policy Templates (GPT)
- The GPT is stored as a file system folder located on the system volume folder (SysVol) in the domain policies subfolder. It contains information about the specific setting you define in the policy itself. This could be security settings, script files, etc.
GPOs can be applied per user or computer, and are updated in the background every 90 minutes with a random offset of 0 to 30 minutes. Domain controllers, however, are updated a much more frequently, about every 5 minutes. It’s worth noting that a GPO will only update if a change has been made.
Once you create a group policy you need to link or apply it to something. You can link to a site, domain or an organizational unit. There is also a local GPO on all windows devices but if a GPC or GPT have a GPO linked to them, that GPO will supersede any configuration on the local GPO. That’s because, while a computer and user can have multiple GPOs, if there are any conflicts the last GPO applied takes priority unless you have the “Block Inheritance” setting enabled. Below is the order of application.
- Local GPO
- Site GPO
- Domain GPO
- Organizational Unit GPO
You can also apply more granular filtering for how GPOs are applied using security groups, Windows Management Instrumentation (WMI) filtering – that can apply decisions based on the OS, make and model of device, time zones, etc, and Item-level targeting, where you can set filters based on a per-setting basis. Figure 2 provides an example of these types of settings.
There is one more feature that needs to be discussed, and that’s GPO enforcement. As you can see from the information above, there are numerous GPOs and linkage opportunities. And as I mentioned, if there are any conflicts, the priority linking order will take care of that. That concept seems pretty straightforward, but when you have multiple GPOs, GPO links, blocked inheritance, and the ability to enforce a GPO it can all get a bit confusing to understand which GPOs apply and which ones do not.
Enforcing a GPO is one way to help with this management issue. Enforcing an GPO means that its setting cannot be blocked or overwritten by a parent container that has a linked GPO. Instead, the enforced GPO will be applied throughout. Below is a good visual example of how enforced GPOs will always win regardless of inheritance or blocked Inheritance.
Abusing Group Policy Objects
As you can see from above section, there is a lot of flexibility – or should I say complexity – in managing GPOs. And as a result, an important security maxim applies here: with complexity there are usually opportunities for an attacker to take advantage of misconfigurations. Let’s take a look at ways an attacker can abuse GPOs.
First of all, that there is a lot of very valuable information in the GPOs, which is why they are useful to use for an attacker when doing reconnaissance once in an Active Directory (AD) environment. In addition, by default, any authenticated user in an AD has the ability to query for information in GPOs and get a valid response back (i.e. see who has access to what). There is no need to escalate privilege for this task.
Over the years, a few open source tools were created to help automate the reconnaissance activities needed to map out the GPO environment. Below are a few of them that used in attacks today.
- This is a PowerShell tool that is part of PowerSploit. It is used to gain situational awareness in Active Directory environments. The tool provides useful information on users, group, privileges and more.
- This tool finds relationships within Active Directory that can then be exploited as attack paths. It also uses graph theory to identify vulnerabilities that could let an attacker move laterally across the network as well as elevate privileges.
- This one assists in finding security-related misconfigurations in Active Directory Group Policies.
The most obvious abuse of GPOs (at least to me it was) would be to change the settings to deliver and execute malicious payloads on the devices the GPO applies to. It’s not uncommon for an attacker in a targeted attack to gain the right access to the environment, modify group policy settings, and then deploy a destructive payload like ransomware. These attackers could do this by modifying or creating a windows preference, like Schedule Task or a logon/logoff script.
Some of these settings can also reference external paths that may not have the same secure access as your GPO. That way, if they can’t modify the GPO, but have access to the referenced path, they can replace the legitimate file with a malicious one. Below, in Figure 3, is an example of how to manually create an immediately scheduled task.
Once an attacker has the ability to change the GPO settings, there are so many other thing they can do, such as change security settings to allow for other malicious actions, provide admin access to a machine by adding a new local admin account, or creating ways to get a malicious file to run, such as creating and running a new service.
Since GPOs are applied based on inheritance from above, linking an attacker with the right access can link and unlink GPOs. This enables them to accomplish tasks such as elevating access by modifying domain group memberships, or changing security policies on Windows devices, which could increase the attack surface for an attacker.
There are many other potential GPO abuses we can discuss, but I will stop here for now. If you do want to dig into more attacks on GPOs, check out GPT redirection, admin template abuse, and attacks around starter GPOs messing with the registry.pol file.
There are a variety of things you can do to protect against GPO attacks, but first and foremost, don’t let the attackers gain admin access. There are far too many tools that can help with this to cover here, but they range from password protection to blocking privilege escalation attacks to anomaly detection. Suffice it to say that these attacks require the right access to execute, and although an attacker may still be able to complete a technique without admin access, it will require a bit more time and far more steps to do so., which gives you more opportunity to identify something suspicious occurring in the environment.
Speaking of access, one tip is to remove the default setting of providing authenticated users with read access to the security filtering of the GPOs. Think of modifying it to domain computers. This will make it more difficult for an attack to map out your security posture. A lot of the reconnaissance tools I mentioned above (PowerView, BloodHound and Grouper2) need read access to GPOs for them to provide all the information the hacker needs. They may still provide some helpful information, but not all. You can make it much more difficult for the attacker by limiting their visibility.
Those same reconnaissance tools can also be used by the defender, by the way, to understand your overall GPO and AD security posture. For example, if you run the Grouper2 tool in your AD environment you can quickly understand all GPO misconfigurations that could possibly lead to exploitation from an attacker. A good example is found in the Grouper2 results shown in figure 5, below.
You can see that I configured an MSI package of 7zip to install. And while the file does not exist anymore, it still has access to write to the directory it’s pointing to. This means it possible for an attacker to change their malicious payload name to the 7z1900-x64.msi and copy it to that specific path. This would result in the attacker getting their malicious payload loaded and executed on every machine this policy applies to.
Another of the reconnaissance tools that can be useful for defense is BloodHound. In video 1, below, I discuss some of the information you can glean with the tool and how it not only helps attackers on the offensive side, but administrators on the defensive side as well.
The last defensive measure I want to mention is implementing an AD Administrative Tier Model. The AD tiering model concept is very similar to network segmentation. You basically set up zones in AD to control privilege access. Implementing a tiering model will make it a bit more difficult for the attacker to go from tier to tier, even when they have some type of administrative privileges. The model is comprised of 3 levels for administrative accounts, which are outlined below.
- Tier 0
- This is the highest-level tier and is comprised of all AD objects that are responsible for administrative control of active directory, including the forest, domains, domain controllers, etc. Only the admin users responsible for maintaining the AD itself would have access to this tier.
- Tier 1
- This tier is compromised of the enterprise servers and applications, including cloud services that a typical server administrator would have access to.
- Tier 2
- This lowest tier contains the user workstations and devices. You would typically see helpdesk and other support folks have access to resources in this tier.
By using this tier model, if an attacker managed to escalate themselves to an admin at Tier 2, they would still need to figure out access to Tiers 1 and 0. Again, while this is not a full protection solution, it does require more steps for the attacker to go through in order to gain access at the various tiers. And if proper security controls are in place across the network, the more steps an attacker needs to take the more chances there are that their activity will be detected.
Chinks in your AD amour can lead to GPOs delivering and executing malicious payloads, such as ransomware and unraveling hardening configurations, thereby increasing your attack surface and making your systems more vulnerable. In this blog we focused on the basics of GPOs, the various tools and ways that attackers gather information about your AD network, including GPOs, and how that information is exploited to advance their cyber mission.
It’s important to see your environment through the eyes of an attacker. Using the tools mentioned in this blog can not only help you better understand your potential security gaps, and the possible attack paths an attacker might take, but to also take a fresh look at your environment from the perspective of someone looking to exploit your network. It’s always good to play both sides. (Offense and Defense)
When it comes to protecting against Group Policy Modification, I don’t think there is a one-to-one relationship here. Modifying a policy by itself is not necessary a malicious activity. You need to look at the possible techniques an adversary might execute that are chained before and after any Group Policy Modification technique.
A good example we see quite often with our Managed Detection and Response and IR customers is that an attacker will first gain the right access to modify a GPO by using an OS Credential Dumping technique, then modify the GPO to download and execute a malware such as ransomware to all the windows systems. In this scenario, both the pre and post actions can be addressed with an EDR solution such as FortiEDR because it can identify and prevent malicious activities from executing.