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.
Last time, I talked about the importance and effects that Restricted Group settings can have on your network. Another powerful group policy setting that system administrators can employ is User Rights Assignments. What are User Rights Assignments? These settings define who can log on to a system and what method they can use to log on. Most users think that when logging on to a system, you generally are sitting at a keyboard, typing in your username and password. However, there are many other ways that domain logons can occur.
One example is an administrator using a command line terminal to connect to a remote machine. This logon is governed by the “Access to this computer from the network” User Right Assignment. Another way an account can log on to the domain is through system services like Microsoft Exchange, or it can be granted the ability to use Remote Desktop Protocol (RDP). Along with these types of logons, User Rights Assignments can grant powers to accounts when they log on. Some of these powers include the privilege to shut down a machine, change system time, or, more dangerously, debug programs or “Act as part of the operating system”.
As always, Microsoft’s Technet has a wonderful article on each of the User Rights Assignments.1 In this post, I want to cover a handful of User Rights Assignments settings that can help mitigate possible avenues of lateral movement. I encourage you to read through every setting, although this can be done in multiple sittings. To start off, let’s go over “Sam’s General Rules for User Rights Assignments”:
Now that we have covered some general guidelines, I want to talk specifically about three configurations that should be set up on every system throughout your domain.
These two settings define who can physically sit at a keyboard and log on to a machine. For the most part on workstations, you will not need to touch the “allow” settings. By default, everyone should have logon rights to all workstations; there is no need to waste resources adjusting this configuration. However, you may want to fine tune it for your servers. I personally would configure the “allow” setting only for the groups that have a need to log on to the server.
Furthermore, I would configure the “deny” setting for all your sensitive groups that don’t belong on workstations. For example, is there any reason for a Domain Admin to log on to a workstation? In my book, no. Domain Admins should only log on to the domain controllers and authorized systems used to help administer the domain (Privileged Access Workstations or Jump Servers). Specifically denying this logon will ensure that a domain administrator doesn’t accidentally start scattering their credentials all over the network. Also, this can help prevent users that hold privileges at different administrative levels from accidentally logging on to a system that they shouldn’t be accessing. Let’s say that a user is a member of “Domain Administrators” and “Print Server Administrators”, and you have your User Rights Assignment perfectly configured (domain admins can only log on to domain administrating systems). The Print Servers will still deny any logon attempt, thus preventing a potential adversary from stealing domain administrator credentials that could be used to compromise another system. This can help enforce the tier styled delegation model I mentioned in my previous article.2
Allow/Deny log on through Remote Desktop Services
Just like the local logon, this User Rights Assignment governs who can connect a system through RDP. The strategy here follows the same method as before. Only grant this privilege to those that need it, and specifically deny access to your sensitive groups.
Once again, the strategy doesn’t change here. (I think there is a pattern to these User Rights Assignments.) Allow only those who need remote network access to a system, and explicitly deny those groups that are of high value to the network. These settings govern who can interact with a system remotely.
There are a number of ways that I can affect a system without logging on to the machine locally or through a remote desktop. If I don’t have this right granted to me or if I am specifically denied, then I cannot affect another system unless I have some highly-advanced exploits at my disposal. But like my example from before, blindly configuring this can cut off your machines from the network and the legit administrators that need to fix them.
I hope I provided you with enough information to start adding another layer to your credential defenses. Again, I see the value of User Rights Assignments as a means to have systems defend themselves from infected machines.
In my next post, I will be discussing the benefits of Microsoft LAPS (or local password rotation capabilities).
Until next time.
BACK TO NEWSROOM