Threat HUNTing Platform
Credential Risk Assessment and Remediation
ORKOS: Preventing the 9 steps to domain collapse
R9B understands the cognitive aspects of cyber operations. Our curriculum provides the hands-on technical skills students require to attain a variety of advanced cybersecurity qualifications. We instill the knowledge, skills, and abilities necessary for our students to defeat the adversary. Below are our available courses. Please check back often as our course offerings are updated regularly. Government organizations, please contact R9B directly via training@root9B.com for pricing and purchasing information.
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:
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.
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.
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 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.
BACK TO NEWSROOM