Active Directory Privilege Segmentation

This post tries to summarize the key steps to take for an effective Privilege Access Management program. Segmenting Privileges in an Active Directory based IT infrastructure is a key defense strategy against automated as well as human operated Ransomware attacks.

Key Challenges:

  1. Domain Admin group members have global privileges
  2. IT staff has local Admin privileges on all workstations
  3. The local Administrator account has the same password on many/all systems
  4. Passwords of highly privileged accounts aren't rotated frequently
  5. IT staff's normal user accounts have high privileges

The problem with the above is not that IT staff will misuse these privileges – The problem is rather that if one of the IT staffs' privileged accounts is compromised, adversary can laterally move very easily and quickly create a lot of damage (like encrypting all the systems they get access to).

Let's look into mitigating strategies for the above 5 Challenges!

Domain Admin group members have global privileges

There is a reason why the Domain Admins group is automatically being added to the local Administrators group on every system that is being joined to an Active Directory Domain: Control of the system and Ease of administration. Although you can technically remove the Domain Admins group from the local Administrators group, the following steps result in an environment that is still easy to manage:

  1. Minimize the day2day use of Domain Admin accounts – Most administrative tasks don't really need Domain Admin privileges. In fact, you should only use Domain Admin privileges when you promote/demote domain controllers or make substantial changes to the configuration of the AD architecture. Administration of groups and users can be done with lesser privileges and should be.
  2. Minimize the number of Domain Admin Accounts – After you have minimized the day2day use of DA accounts, you will quickly realize that there are only a few IT staff members, who actually have the knowledge and experience to make changes that require DA privileges. Everyone else should be removed from the Domain Admins group.
  3. Rotate the passwords of Domain Admin accounts often – What does often mean? The best case is to rotate the password right after use because it invalidates any memory cached credentials and Kerberos tickets that were left behind. To accomplish that you need a PAM tool like CyberArk or Thycotic Secret Server.
  4. Make sure that there are absolutely no Service Accounts that have DA privileges! Service Accounts can be relatively easily be compromised when adversary gains local admin privileges on the system where the service runs.

IT staff has local Admin privileges on all workstations

Most IT departments try to minimize time needed to help their users in remote support sessions. And having local Admin privileges on all workstations helps with that a lot. However, there are other ways to provide local Admin privileges to helpdesk personal than putting them all into the local Admin group:

  1. Use a remote management tool that comes with an agent that runs as the System user on the workstation.
  2. Use a tool that rotates the password of the local Administrator (.\Administrator) on all workstations frequently and allows the IT staff to look up the current password for each workstation, so they can use the .\Administrator account instead. Examples for such a tool would be Microsoft LAPS and Thycotic Privilege Manager.

The local Administrator account has the same password on many/all systems

Why is that a problem? Answer: If one of the local Administrator accounts gets compromised on one system, the same credentials can be used on all other systems, which allows adversary to easily move laterally and create a lot of damage quickly.

The solution to this problem is #2 from the previous section.

Passwords of highly privileged accounts aren't rotated frequently

Even after you do all the steps in the previous sections you will still have a good amount of highly privileged accounts in your environment.

So why would you want to rotate the passwords of these accounts frequently? Well, as your admins move from one system to the next they leave behind disconnected RDP sessions, cached credentials in browsers and other apps, and Kerberos tickets that can be discovered and stolen by any medium skilled adversary.

OK, how frequent is frequently? The most frequent would be after each use. Other options are Daily, Weekly, Monthly. It makes sense to decide the frequency based on the scope of privileges – DA accounts should be rotated right away after use. Other accounts with a more limited scope of privileges can be rotated at a lesser interval.

As soon as you start rotating these passwords frequently you will ask yourself whether that can be automated. The answer is YES and there are PAM tools that can do that for you and that can even take care of dependencies in case you want to automatically rotate passwords of highly privileged service accounts. Examples of such products are CyberArk and Thycotic Secret Server.

IT staff's normal user accounts have high privileges

So what is the problem with IT staff attaching administrative privileges to their normal user accounts? The answer is that normal user accounts are used to process potentially malicious content (email and web surfing) every day. So they are constantly at risk of getting compromised.

Therefore, normal user accounts should never have administrative privileges – That is why we don't give local Admin privileges to normal employees.

The solution is to give the IT staff a second account for administrative use cases that does not have an email mailbox and is still MFA protected. Many organizations use the naming schema a_firstname.lastname but you can obviously use any other naming schema. A naming schema should be used though to make it easier for your Security Operations Center to differentiate between privileged and normal user accounts.

#infosec