Risky Events from Privileged Users

Description

When something generally risky occurs to your most privileged users, you likely should respond more quickly. Fortunately, this is easy to do.


Use Case

Insider Threat, Security Monitoring

Category

Insider Threat, IAM Analytics

Security Impact

There are many searches that you would not normally want to analyze... except when they occur to your most privileged users. A high entropy process starting in a weird location is probably software installation that only really matters when combined with other events, but it's best to double check when it's occurring on the laptop belonging to the CEO's Executive Assistant. By combining a list of risky events (generated through the Enterprise Security risk framework, or your own version thereof) with a list of privileged users, you can easily prioritize those events.

Alert Volume

Low (?)

SPL Difficulty

Basic

Journey

Stage 4

MITRE ATT&CK Tactics

Persistence
Privilege Escalation

MITRE ATT&CK Techniques

Valid Accounts

MITRE Threat Groups

APT18
APT28
APT3
APT32
APT33
APT39
APT41
Carbanak
Dragonfly 2.0
FIN10
FIN4
FIN5
FIN6
FIN8
Leviathan
Night Dragon
OilRig
PittyTiger
Soft Cell
Stolen Pencil
Suckfly
TEMP.Veles
Threat Group-1314
Threat Group-3390
menuPass

Data Sources

Ticket Management

   How to Implement

Implementation of this search depends on two key components -- a list of risky events, and a list of privileged users.

You can use almost anything to generate a list of risky events -- in fact that's the desired intent for most medium-or-higher alert volume searches in Splunk Security Essentials! Most customers who go down this path will use the Enterprise Security Risk Framework to aggregate these events, though you can also 'roll your own' risk framework with Summary Indexing.

Generating a list of risky users is complicated -- that's why one of the most detailed examples in Splunk Security Essentials takes this on! Check it out! (link).

Once you have these components, implementation of this detection is straightforward.

   Known False Positives

This search can inherently generate false positives because it opens the door to alerting users to low confidence events that occur to privileged users. You will need to tune the underlying search, or potentially filter for a certain risk score to manage these false positives.

   How To Respond

See the response guidance for the underlying searches that generate the original events.

   Help

Risky Events from Privileged Users Help

This example leverages the Simple Search search assistant. Our example dataset is a collection of events from the risk index of a demo environment for Splunk Enterprise Security. The risk index provides a way to track "risky" events that aren't necessarily significant enough to send to a SOC analyst (along with aggregating the overall volume of events for a given user). Our live search looks for the same behavior using the standard sourcetypes. See How to Implement if you do not use Enterprise Security.

SPL for Risky Events from Privileged Users

Demo Data

First we bring in our basic demo dataset. In this case, a list of events from the risk index of a demo Splunk Enterprise Security environment. We're using a macro called Load_Sample_Log_Data to wrap around | inputlookup, just so it is cleaner for the demo data.
Next we use a lookup with the risk scores of user accounts.
Finally we can filter for just the events occurring to privileged employees.

Live Data

First we bring in our dataset of events from the risk index of Splunk Enterprise Security.
Next we use a lookup with the risk scores of user accounts.
Finally we can filter for just the events occurring to privileged employees.

Screenshot of Demo Data