3 Things to Do Today to Help Combat the Gender Gap in Cybersecurity
In my last blog, I wrote about the purpose of formalizing a delegation model for your domain. Now, it is time to talk about how to enforce that model through technical configurations. Thankfully, it is not as complicated as you might think. In this post, I will outline one of two specific group policy object (GPO) settings that will make this process as painless as possible: Restricted Groups.
“Restricted Groups” GPO settings are used to enforce group memberships either in the domain or on a local system.1 This is not to be confused with the Group Policy Preferences configurations which affect group membership. Restricted Groups allow an administrator to define who is a member of a given group, and the machine will enforce that policy. For example, let’s say I create a GPO for a handful of workstations that defines “test.lab\Workstation Admins”, “test.lab\Tier 2 Helpdesk Admins”, and the built-in administrators (on the workstations, not the domains) as members of the built-in administrators group. The designated workstations then will ensure that those three members are the only members in the “administrators” group.
But, what happens if a workstation is compromised? Good question. Unless an adversary can compromise the workstation to the point of disabling Group Policy Processing, any adversary persistence will be cleaned out every time the machine applies its group policy. Even if the adversary tries to add “Domain Admins” to the built-in administrators, group policy will override these modifications, forcing the adversary to start again from the beginning.
That said, here are a few things to know about Restricted Groups:
- Restricted Groups settings have two modes: “Members” and “MemberOf”. “Members” acts as the “end all, be all” of Restricted Groups settings. If you are not listed on the Members setting in the GPO, your user account or group is deleted from the membership. “MemberOf” settings only add the group or user to the existing group membership. Here are some specific pointers on these two configurations:
- Apply a “Members” GPO as high in the organizational unit (OU) structure as possible for specific types of assets (servers, domain controllers, or workstations). With workstations, create a GPO that defines groups and users that will be universal for every workstation, such as your Tier 2 helpdesk and the local administrator account.
- As you work your way down the OU structure, create “MemberOf” GPOs for the more-specific administrative groups. For example, let’s say my organization has offices in Chicago and New York City with helpdesk teams at each of these locations. The New York City administrators will be added as administrators to the New York City workstations and the Chicago helpdesk as administrators to the workstations in that city.
The graphic below illustrates how this concept of restricted groups works. I have a Restricted Groups GPO applied with the restrictive settings (Members) under the Systems OU and another one in the additive mode under the “subOU” Organizational Unit (MembersOf). As you can see, the Windows 7 machine located in the “subOU” Organizational Unit has both groups as part of the built-in administrators.
- Use Restricted Groups on domain controllers. Since Active Directory is technically the local users and groups for the domain controllers, you can define the members of groups like “Domain Admins”, “Enterprise Admins”, and others. This means if Jimmy the Janitor somehow gets added to the domain admins, the domain controller will delete him the next time it applies its group policies.
- True Story: Restricted Groups can be quite frustrating for an adversary. I once participated in a cyber war games for the U.S. military involving multiple nations and branches of the U.S. military. My job was to manage the domain controllers for the U.S. Air Force team, and part of my management was creating restricted groups for my domain admins. The red team had “compromised” a domain admin and tried to leave some persistence by adding their own account into domain admins. However, every 15 minutes the domain controller kept kicking their persistence account out of domain admins, and the red team couldn’t figure out why. When they figured out what was happening, they deleted all of my GPOs out of frustration, hoping to fix the problem. Of course, this move was quite obvious, and most adversaries won’t try something so bold.
- When establishing a baseline for workstations, servers, and domain controllers, I recommend targeting the following objects with Restricted Groups:
- Workstations: Administrators, Remote Desktop Users and Remote Management Users.
- Servers: Administrators, Remote Desktop Users and Remote Management Users, and any special groups based on server role (E.G. SQL, IIS, or DHCP groups).
- Domain Controllers: Account Operators, Administrators, Backup Operators, Cert Publishers, DNSAdmins, Domain Admins, Enterprise Admins, Group Policy Creators Owners, Hyper-V Administrators, Incoming Forest Trust Builders, Print Operators, Remote Desktop Users, Remote Management Users, Schema Admins, Server Operators, Users, WinRMRemoteWMIUsers, and any highly-sensitive administrative security group.
- For the domain controllers, these listed groups potentially have some level of remote access to the domain controller. I am a firm believer that security of the domain controller is the highest priority. This list of security groups may cross the border into the realm of micromanagement, but I feel it is better to be uncomfortably safe than comfortably compromised. When it comes to extra administrative accounts from your delegation model, not every group needs to be defined. You may have high turnover at your Tier 1 helpdesk which would quickly become a nightmare to maintain. It is up to you to find that balance. You can still protect less-privileged groups with active directory Access Control Lists (ACLs) and security permissions.
- For more detailed information, I have provided a link below of all built-in accounts in terms of the domain. It is a great reference guide.2
Hopefully, this provides you with a solid foundation for deploying Restricted Groups in your domain. As always, test everything before committing new policies to an entire domain.
Next time, I will cover another fantastic group-policy configuration to help defend your network: User Rights Assignments.
SOAPBOX: Group Policy Preferences
First off, I am not a fan of Group Policy Preferences (GPP) as GPPs tend to tattoo the registry. I don’t like anything that hardcodes itself into systems. Second, the only benefit that GPP provides over Restricted Groups is the ability to create dynamic groups when determining which groups are members of the group you are configuring. The idea is to have the GPP create a “ghost” security group that is dynamic and unique to each machine. Such a setup would look something like this: test.lab\Comp1 Admins would be created for a workstation named Comp1, test.lab\Comp2 Admins for a system called Comp2, and so forth. Then, in Active Directory, you can create a security group called Comp1 Admins or Comp2 Admins and add a specific user to those groups.
Bottom-line, end users should not have have administrator rights. Helpdesk, IT support staff, system admins are the ones who manage each individual machine. If you grant a end user administrative permissions to their machine, an attacker can skip right to administrative privileges during a phishing campaign. People make mistakes and click the wrong thing from time to time, so don’t configure your machines to let those mistakes give your enemies an extra advantage in their campaign. The only time a normal user should have administrative rights to a workstation is if the person that signs your paycheck says to allow it. Even in those situations, technologies exist today where you don’t need a “dynamic solution” for your exemptions. At the very least, you can provide the password to the local admin account in a secure method and then have the password changed when the need no longer exits. (Each workstation’s local admin password should be unique anyway, so supplying the password shouldn’t present a high risk.)
With the dynamic solution, you also must determine how to manage the tracking of those “dynamic groups”. Since they are active directory groups, you need to formalize requests, track them, and identify configurations outside of the approved process. On the other hand, it is more than likely that all GPO changes have some sort of process in place for modifications through your change management. It would be easy to track and validate these requests through existing processes.
Many leaders don’t understand that convenience (not availability) usually is what gives your adversaries the foothold they need to breach your network. If you must have a dynamic method in place, I have a resource to guide you in successfully setting up such a enviroment.3 Again, I personally don’t recommend it, yet I also know that sometimes we blue teamers must do things that we don’t like.
Until next time.
Sources
1https://technet.microsoft.com/en-us/library/cc957640.aspx
2https://technet.microsoft.com/en-us/library/dn579255(v=ws.11).aspx