Insider Threats in Active Directory: How to Safeguard Privileged and Non-Privileged User Accounts

In this post, we define privileges related to Active Directory and highlight the key security risks of internal privileged and non-privileged user groups.

What do we mean by “privileges”?

For the purpose of this blog, I am defining privileges that are related to Active Directory and the objects stored within the database. Examples of privileged users include those with membership to the Domain Admins, Enterprise Admins, Group Policy Creator Owners, Account Operators and similar groups. They also include users that have delegated permissions over Active Directory, such as the ability to reset passwords and modify group membership.

I don’t want to negate the other privileges within a Microsoft Windows environment, such as user rights, Group Policy Object (GPO) delegations and service permissions. But those aren’t the focus here.

What can an internal non-privileged user do?

An internal non-privileged user is typically an end-user. This individual will not have any capabilities to modify Active Directory. We could dive into the concept of whether or not the user has administrative privileges over their desktop, but for the purpose of this blog, let’s assume the user is a local administrator.

In this scenario, the user has quite a bit of power to install and run applications from their computer. Not all Active Directory interrogation tools require a local administrator, but in many cases they do. This user has the ability to conduct reconnaissance on the entire Active Directory domain, and beyond. Since the user has an Active Directory user account, the user has read access to the entire Active Directory database. Of course, the user can’t dump out all of the passwords for domain users. (That is not the level of read access provided.) However, they can obtain user, group, computer, GPO and trust details. Here are a few examples of what a user can see:

• All members of the Domain Admins group
• The last time a user changed their password
• Settings in a GPO

If tools like BloodHound are utilized, not only can this user see the objects within the database, but they can get a full mapping of the attack paths for each user to obtain privileges to Active Directory.

What can an internal privileged user do?

Of course, an internal privileged user can do all that a non-privileged user can—and more. It can be a bit confusing why an internal privileged user is a concern. I mean, isn’t this just an Active Directory admin? Not at all.

The issue with an internal privileged user is that they can do anything they want… which includes creating backdoors, changing settings without being tracked, obtaining security information without generating an event log, and more. Also, the internal privileged user might not be an employee of the company; this could be a service account or an outside attacker that has compromised an internal account.

The entire game changes when we start introducing attacks like DCSync and DCShadow (available in Mimikatz), both of which bypass many of the auditing, tracking and event logging solutions on which IT and security teams rely. Organizations require a much deeper solution to “see” that these attacks are happening.

How you can take action

As we can’t go deep into the attacks that both non-privileged and privileged users can perform, I want to leave you with an action you can take to help secure both of these internal user groups. 

For non-privileged users, make sure you remove their local administrative privileges on their computer. For privileged users, make sure that all privileged groups (e.g., built-in, service, application and custom) have the correct members; this includes any nested groups, too. It is also important to ensure that all Active Directory delegations are correct. Again, this includes not only the direct access control list (ACL), but any nested groups within groups listed on the ACL (referred to as EFFECTIVE permissions).

For more information on this topic and strategies for strengthening your Active Directory security, visit our Tenable.ad product page.

This blog post originally appeared on the Alsid website on August 5, 2020.