Navigation :

Pull List of Privileged Users

Description

To focus detection or response on privileged users, you must first build a list of accounts that have elevated rights or access to privileged information.

Use Case

Insider Threat

Security Impact

Every organization should seek to inform their detections with the relative risk of the users and systems involved. If two users send out a large volume of data but one of those users is a database administrator, you should probably respond to that alert first. Security organizations serious about insider threat should be able to look at different dimensions of privilege and then inform both their detection methods and their response prioritization accordingly. The two easiest of those dimensions are "users with elevated rights on systems" (e.g., sysadmins, database admins, etc.) and "employees who have access to privileged information" (e.g., executives, employees involved in mergers and acquisitions, etc.). It's entirely possible that you will build out a series of different lists for different scenarios (for example, a list of users read in on a particularly acquisition project, etc.) but it's easiest to start with just accounts that have elevated rights and those that have privileged information.

Alert Volume

Very Low (?)

SPL Difficulty

Hard

Journey

Stage 4

Kill Chain Phases

Actions on Objectives

Data Sources

Windows Security

How to Implement
There are multiple approaches for pulling lists of Privileged Users, and multiple definitions of what privileged really means for a given scenario. Pulling Users. In this example we show three different methods for pulling lists of users: querying LDAP, querying a database, or looking for users who take the actions that a privileged user would take. Let's walk through these examples. Pulling from LDAP - there are three different approaches for pulling from LDAP. We generally recommend that most users start by using the Supporting Add-on for Active Directory (aka SA-ldapsearch) which provides the ldapsearch command. This command is native in Splunk, and works great for on premises installations in organizations with fewer than 50,000 users (app link, docs link). You can also pull data using AD Monitor, which is the Splunk Universal Forwarder's ability to monitor Active Directory for changes -- recommended for large organizations, and for Cloud environments (doc link). Finally, it is sometimes simpler to use Powershell for this effort (link). Organizations with formal systems for managing privileged users that don't sync to Active Directory will most frequently need to pull a list of users by querying a database (though sometimes an API is available). This frequently occurs when you have an on-prem software application backed by a database that stores a list of privileged users. The process you will walk through to pull that data into Splunk is to first discover the username and password to log into the database along with the query that will return your desired set of users, and then configure Splunk DB Connect (link, doc link) to pull that data. Learning the credentials and the required query is sometimes very easy, and sometimes very difficult, but often you will be able to find help from Splunk Professional Services or on Splunk Answers. Finally, we can always infer a list of privileged users by finding users who take privileged actions. There are many ways to approach this process, but the simplest is by searching for the use of tag=privileged on authentication events, as defined by the Splunk Common Information Model. Now we've discussed how to ingest the data in the first place -- but we haven't discussed what data we actually should be ingesting. There are two primary categories of privileged users that we might want to monitor: those who have administrative rights, and those that are privileged. Those who have administrative rights is a very simple question to answer in a smaller organization, but exponentially more difficult with the complexity of the environment. It's best to start with standard privileged AD groups, such as Domain Admins, and then expand into environment-specific groups, such as the custom help desk admin group that had local admin rights on all workstations (every company has at least one of these). It's often easiest to find these types of groups by hunting through LDAP for key terms such as "admin" or "operator" etc. Finally, wrap up by searching for users with specific admin rights, such as privileged service accounts and see what groups (if any) they belong to. It's generally advisable to look for known administrative users across the organization (either specific names, or by naming scheme such as jsmith-a) and seeing which groups these users belong to. Generally speaking, understanding VIP users in an organization can be dramatically easier than finding all admin accounts. Title will frequently get you all you need, though you may also find that tracking the # of steps away from the CEO based on reporting structure can be very effective. It's important to not forget employees that are associated with highly visible people but aren't themselves as visible, particularly the executive assistants for all your important users. They generally have full access to an exec's calendar, mailboxes, and more often than we would like they will also have a text file somewhere on their computer with the executive's password (or similar).

How to Implement

There are multiple approaches for pulling lists of Privileged Users, and multiple definitions of what privileged really means for a given scenario.

Pulling Users. In this example we show three different methods for pulling lists of users: querying LDAP, querying a database, or looking for users who take the actions that a privileged user would take. Let's walk through these examples.

Pulling from LDAP - there are three different approaches for pulling from LDAP. We generally recommend that most users start by using the Supporting Add-on for Active Directory (aka SA-ldapsearch) which provides the ldapsearch command. This command is native in Splunk, and works great for on premises installations in organizations with fewer than 50,000 users (app link, docs link). You can also pull data using AD Monitor, which is the Splunk Universal Forwarder's ability to monitor Active Directory for changes -- recommended for large organizations, and for Cloud environments (doc link). Finally, it is sometimes simpler to use Powershell for this effort (link).
Organizations with formal systems for managing privileged users that don't sync to Active Directory will most frequently need to pull a list of users by querying a database (though sometimes an API is available). This frequently occurs when you have an on-prem software application backed by a database that stores a list of privileged users. The process you will walk through to pull that data into Splunk is to first discover the username and password to log into the database along with the query that will return your desired set of users, and then configure Splunk DB Connect (link, doc link) to pull that data. Learning the credentials and the required query is sometimes very easy, and sometimes very difficult, but often you will be able to find help from Splunk Professional Services or on Splunk Answers.
Finally, we can always infer a list of privileged users by finding users who take privileged actions. There are many ways to approach this process, but the simplest is by searching for the use of tag=privileged on authentication events, as defined by the Splunk Common Information Model.

Now we've discussed how to ingest the data in the first place -- but we haven't discussed what data we actually should be ingesting. There are two primary categories of privileged users that we might want to monitor: those who have administrative rights, and those that are privileged.

Those who have administrative rights is a very simple question to answer in a smaller organization, but exponentially more difficult with the complexity of the environment. It's best to start with standard privileged AD groups, such as Domain Admins, and then expand into environment-specific groups, such as the custom help desk admin group that had local admin rights on all workstations (every company has at least one of these). It's often easiest to find these types of groups by hunting through LDAP for key terms such as "*admin*" or "*operator*" etc. Finally, wrap up by searching for users with specific admin rights, such as privileged service accounts and see what groups (if any) they belong to. It's generally advisable to look for known administrative users across the organization (either specific names, or by naming scheme such as jsmith-a) and seeing which groups these users belong to.
Generally speaking, understanding VIP users in an organization can be dramatically easier than finding all admin accounts. Title will frequently get you all you need, though you may also find that tracking the # of steps away from the CEO based on reporting structure can be very effective. It's important to not forget employees that are associated with highly visible people but aren't themselves as visible, particularly the executive assistants for all your important users. They generally have full access to an exec's calendar, mailboxes, and more often than we would like they will also have a text file somewhere on their computer with the executive's password (or similar).

Known False Positives
The concept of a false positive versus false negative is slightly different for this example as ultimately we are working to build out a list of users, but both are extremely common. Mapping the organizational structure (and permissions structures) of an organization is inherently very complicated, and will require lots of testing and tuning to get a meaningful list. The benefit though is that since this search does not directly create alarms, some amount of inaccuracy is acceptable.

Known False Positives

The concept of a false positive versus false negative is slightly different for this example as ultimately we are working to build out a list of users, but both are extremely common. Mapping the organizational structure (and permissions structures) of an organization is inherently very complicated, and will require lots of testing and tuning to get a meaningful list. The benefit though is that since this search does not directly create alarms, some amount of inaccuracy is acceptable.

How To Respond
This search does not directly create alarms, but is only used to generate lists of users for use in other searches. See Related Content.

Help
Pull List of Privileged Users Help This example leverages the Simple Search Assistant. There are several ways to pull this data from live environments -- see the different options for more information.

Help