New User Taking Privileged Actions

Description

Record when a user who hasn't taken privileged actions before suddenly starts.


Use Case

Compliance, Insider Threat

Category

Insider Threat, Privilege Escalation

Security Impact

Most larger organizations have strict controls to look for users enacting privileged actions. While most (maybe all!) users who suddenly start taking privileged actions will be legitimate, there is always a certain degree of risk associated with a user who suddenly begins exercising privileged rights they've long had, or uses new rights. Combine these events with other risky behavior to detect users who should be analyzed by your Insider or SOC team.

Alert Volume

High (?)

SPL Difficulty

Basic

Journey

Stage 2

MITRE ATT&CK Tactics

Privilege Escalation
Persistence

MITRE ATT&CK Techniques

Valid Accounts
Create Account

MITRE Threat Groups

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

Kill Chain Phases

Actions on Objectives

Data Sources

Windows Security
Authentication

   How to Implement

Implementation of this search depends on one key component -- privileged events. Generating the privileged events is relatively straightforward to get started with as many TAs will define privileged actions by default. You can start by searching out this information with just tag=privileged. Once you have defined privileged events, the First Time Search Assistant makes the rest of the detection very easy to implement.

   Known False Positives

The #1 scenario when this alerts falsely is when the events themselves are incorrectly marked with tag=privileged. The Windows TA defines what eventtypes (basically, micro-searches that we evaluate every time you click the search button) is privileged in a file called tags.conf. You can always tune this set of tags, though it's probably easier to just add NOT EventCode=XXXX to block out the event IDs that you don't find valuable.

   How To Respond

When this alert fires, you should first analyze whether this particular event is one that you would not expect the user to be able to do with their existing permissions. If that's the case, analyze the groups that the user is a member of, or see if there's a local account with the same username that might be the source of these rights. Evaluate whether this is allowable or not.

   Help

New User Taking Privileged Actions Help

This example leverages the Simple Search Assistant. Our demo dataset is a list of anonymized Windows events with the EventCode and the tags (which come from the technology add-ons).

SPL for New User Taking Privileged Actions

Demo Data

First we bring in our basic demo dataset. In this case, a list of anonymized Windows events with the EventCode and the tags (which come from the technology add-ons). We're using a macro called Load_Sample_Log_Data to wrap around | inputlookup, just so it is cleaner for the demo data.
This line is only needed for demo data, to convert a semi-colon separated list into a multi-value field. In the live search, it's already multi-value.
Then we filter for just events where the "privileged" tag is assigned.
Here we use the stats command to calculate what the earliest and the latest time is that we have seen this combination of fields.
Next we calculate the most recent value in our demo dataset
We end by seeing if the earliest time we've seen this value is within the last day of the end of our demo dataset.

Live Data

This search is simple -- we are looking for any actions tagged as privileged across the entire environment.
Here we use the stats command to calculate what the earliest and the latest time is that we have seen this combination of fields.
We end by seeing if the earliest time we've seen this value is within the last day.

Accelerated Data

First we bring in our privileged authentication data from the accelerated data model. (If you're wondering, yes this will limit us just to the authentication data model -- it's prudent to run similar searches for the other data models as well.)
Next we rename Authentication.user to just user because shorter is better than longer.
Here we use the stats command to calculate what the earliest and the latest time is that we have seen this combination of fields.
We end by seeing if the earliest time we've seen this value is within the last day.

Screenshot of Demo Data