Increase in Windows Privilege Escalations

Description

Privilege escalation (either via RunAs or Scheduled Tasks) create Windows Security EventID 4648 events. This search will baseline per (original, unprivileged) user and then track deviations.


Use Case

Security Monitoring

Category

Account Compromise

Security Impact

Building upon the simpler example of reporting against 4648 events, this example tracks the privileged executions on a per-credential basis. It may be perfectly normal for a certain amount of privileged executions to happen from a given account, but when these spike against a certain account, this may be an indicator of account compromise.

Alert Volume

Low (?)

SPL Difficulty

Medium

Journey

Stage 1

MITRE ATT&CK Tactics

Privilege Escalation

MITRE ATT&CK Techniques

Scheduled Task
Access Token Manipulation

MITRE Threat Groups

APT18
APT28
APT29
APT3
APT32
APT33
APT39
APT41
BRONZE BUTLER
Cobalt Group
Dragonfly 2.0
FIN10
FIN6
FIN7
FIN8
Lazarus Group
Machete
OilRig
Patchwork
Rancor
Silence
Soft Cell
Stealth Falcon
TEMP.Veles
Threat Group-3390
Turla
menuPass

Kill Chain Phases

Installation

Data Sources

Windows Security

   How to Implement

Implementation of this example (or any of the Time Series Spike / Standard Deviation examples) is generally pretty simple.

  • Validate that you have the right data onboarded, and that the fields you want to monitor are properly extracted. If the base search you see in the box below returns results.
  • Save the search to run over a long period of time (recommended: at least 30 days).

For most environments, these searches can be run once a day, often overnight, without worrying too much about a slow search. If you wish to run this search more frequently, or if this search is too slow for your environment, we recommend using a summary index that first aggregates the data. We will have documentation for this process shortly, but for now you can look at Summary Indexing descriptions such as here and here.

   Known False Positives

This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately a spike in the number we're monitoring... it's nearly impossible for the math to lie. But while there are really no "false positives" in a traditional sense, there is definitely lots of noise.

How you handle these alerts depends on where you set the standard deviation. If you set a low standard deviation (2 or 3), you are likely to get a lot of events that are useful only for contextual information. If you set a high standard deviation (6 or 10), the amount of noise can be reduced enough to send an alert directly to analysts.

   How To Respond

When this search returns values, initiate your incident response process and capture the time of the creation, as well as the user account and system, credentials that were used, process executed and other pertinent information. Contact the owner of the system. If it is authorized behavior, document that this is authorized and by whom. If not, the user credentials may have been used by another party and additional investigation is warranted.

   Help

Increase in Windows Privilege Escalations Help

This example leverages the Detect Spikes (standard deviation) search assistant. Our dataset is an anonymized collection of Windows logon with explicit credentials events (Event ID 4648, as you would see with RunAs). For this analysis, we are tracking the number of times the originating (unprivileged) user initiates an authentication with explicit credentials. Then we calculate the average, standard deviation, and the most recent value, and filter out any users where the most recent is within the configurable number of standard deviations from average. Notably, it might be more useful here to track the privileged account, for different use cases -- that's easy to do, just switch the dropdown from Unprivileged to Privileged. If you have a strong background and opinion on which is relevant in what scenarios, let us know so that we can improve this content for everyone.

SPL for Increase in Windows Privilege Escalations

Demo Data

First we pull in our demo dataset.
This line won't exist outside of demo data.
Bucket (aliased to bin) allows us to group events based on _time, effectively flattening the actual _time value to the same day.
Finally, we can count and aggregate per user, per day.
calculate the mean, standard deviation and most recent value
calculate the bounds as a multiple of the standard deviation

Live Data

First we pull in our dataset, consisting of Windows Security logs with Event ID 4648, showing "Run As" events.
Next we filter out the Windows System usernames, where this can occur frequently
Windows Security logs often include two usernames -- the acting username, and the target username. We want the latter (note that this hasn't been proven to work uniformly across all log sources, but it seems to work well for this scenario).
Bucket (aliased to bin) allows us to group events based on _time, effectively flattening the actual _time value to the same day.
Finally, we can count and aggregate per user, per day.
calculate the mean, standard deviation and most recent value
calculate the bounds as a multiple of the standard deviation