Significant Increase in Interactively Logged On Users

Description

Most systems will have a relatively predictable number of interactively logged on users. This search will look for systems that have dramatically more than they typically do, with a per-user baseline.


Use Case

Advanced Threat Detection

Category

Endpoint Compromise

Security Impact

By monitoring the number of interactively logged in users to assets, security teams can identify anomalies that may indicate the compromise of an asset or credentials. A spike in users on a particular asset could be an indicate that the asset was compromised and additional system level user accounts are being created for malicious purposes, or if they are valid credentials in AD that accounts have been compromised and the adversary is testing the accounts against a particular asset or groups of assets to test and or escalate privileges to gain deeper access to critical assets and infrastructure.

Alert Volume

Medium (?)

SPL Difficulty

Medium

Journey

Stage 1

MITRE ATT&CK Tactics

Privilege Escalation
Persistence

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

Kill Chain Phases

Command and Control
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.

This detection is relatively unique amongst the behavioral searches in that there can be special tuning required for it. Generally, you can choose a high standard deviation if you do not want to receive much noise, but for this particular search we will see many systems where 99% of days there is only one user logged on. For this reason, you will likely be alerting effectively on when any other user logs onto the system. It might be prudent to exclude help desk staff from the search, or filter specifically for where 3 or more users log on if you're receiving too much noise. In any event, this is generally most useful as a contextual search technique.

   How To Respond

When this search returns values, initiate your incident response process and capture the time of events created, as well as the user accounts logged into the system, processes executed and other pertinent information. Contact the users and 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

Significant Increase in Interactively Logged On Users Help

This example leverages the Detect Spikes (standard deviation) search assistant. Our dataset is an anonymized collection of Windows Logon events, filtered to interactive logon types (Local: 2, RemoteInteractive: 10, Cached Local: 11). For this analysis, we are tracking the number of unique users log into each system per day 'dc(user) by host _time'. Then we calculate the average, standard deviation, and the most recent value, and filter out any systems where the most recent is within the configurable number of standard deviations from average.

SPL for Significant Increase in Interactively Logged On Users

Demo Data

First we pull in our demo dataset.
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 of Windows Authentication events specifying interactive logon types.
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 system, per day.
calculate the mean, standard deviation and most recent value
calculate the bounds as a multiple of the standard deviation