First Time Access to Jump Server for Peer Group

Description

Detect a user who is logging into a jump server that neither they nor any of their peers have accessed before.


Use Case

Insider Threat, Advanced Threat Detection

Category

Lateral Movement, Insider Threat

Security Impact

By monitoring and alerting on first time log ins to a jump server, you are able to detect if/when an adversary is able to escalate permissions or add new accounts to AD, or to endpoints directly. This should be a priority particularly for critical infrastructure, high-value and mission critical assets or those systems containing sensitive data. In addition to external adversary, this type of behavior can also be indicative of a potential insider threat issue, where an employee is probing their access, or potentially testing new accounts they may have created for malicious purposes.

Alert Volume

High (?)

SPL Difficulty

Medium

Journey

Stage 4

MITRE ATT&CK Tactics

Lateral Movement
Initial Access

MITRE ATT&CK Techniques

Valid Accounts
Remote Desktop Protocol

MITRE Threat Groups

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

Kill Chain Phases

Installation
Actions on Objectives

Data Sources

Windows Security
Authentication

   How to Implement

Implementation of this example (or any of the First Time Seen examples) is generally very simple.

  • Validate that you have the right data onboarded, and that the fields you want to monitor are properly extracted.
  • Save the search.

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 leveraging a lookup cache. For more on this, see the lookup cache dropdown below and select the sample item. A window will pop up telling you more about this feature.

For the specific scenario of jump server detection, you will need a way to prioritize jump servers in your environment. For customers that have a standard naming scheme for jump servers, that is easy to implement. If instead you have a list of random hostnames that can be jump servers, it's generally easiest to put them into a lookup and then use a subsearch to bring them in (e.g., | tstats ... where [| inputlookup jumpservers | table Authentication.dest | format] ).

The final piece of implementing this is to build out a departmental peer group. Follow here for an example: (DVREMINDER -- ADD THIS IN).

   Known False Positives

This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately reflect the first occurrence in the time period you're searching over (or for the lookup cache feature, the first occurrence over whatever time period you built the lookup). But while there are really no "false positives" in a traditional sense, there is definitely lots of noise.

You should not review these alerts directly (except for access to extremely sensitive system), but instead use them for context, or to aggregate risk (as mentioned under How To Respond).

   How To Respond

When this search returns values, initiate your incident response process and validate the user account accessing the specific system. Determine who the system owner is and contact them. If it is authorized, document it as such and by whom. If not, the user credentials may have been used by another party and additional investigation is warranted as a first time logon to a server that was never logged into before could suggest compromised credentials gaining access to other systems.

   Help

First Time Access to Jump Server for Peer Group Help

This example leverages the Detect New Values search assistant. Our dataset is an anonymized collection of Windows Logon events. For this analysis, we are effectively grouping by username and system name, which will give us a row for each username+systemname combination. We check if the first time that has occurred was in the last day, and if the hostname matches our designation for jump servers.

SPL for First Time Access to Jump Server for Peer Group

Demo Data (No Peer Group)

First we pull in our demo dataset.
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 (No Peer Group)

Here we start with our basic dataset of WinSecurity authentication logs. Notably, this technique of doing the value and then the field=value can bypass some quirks around field extractions, and make searches faster for very large datasets (though that's an area of active work, and it's less true every year).
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 (No Peer Group)

Here, tstats is pulling in one command a super-fast count per user, per system, per day of authentications.
It is usually easiest to work with data model acceleration after we've renamed the fields to something a little friendlier.
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.

Demo Data (With Peer Group)

First we pull in our demo dataset.
Find where the most recent value is less than -1d@d from either now() or the value showing your most recent data point (depending on your particular search desires)
Enrich primary with peer group
Here we are comparing the # of 'Secondary Field's viewed today and historically by the 'Primary Field'. multireport is a search operator that allows you to leverage the power of stats, but multiple times.
Now we join the two | stats output together into one, so that we can analyze them together
Filtering out null earliest will handle corner cases to make a clean report.

Live Data (With Peer Group)

Here we start with our basic dataset of WinSecurity authentication logs. Notably, this technique of doing the value and then the field=value can bypass some quirks around field extractions, and make searches faster for very large datasets (though that's an area of active work, and it's less true every year).
Find where the most recent value is less than -1d@d from either now() or the value showing your most recent data point (depending on your particular search desires)
Enrich primary with peer group
Here we are comparing the # of 'Secondary Field's viewed today and historically by the 'Primary Field'. multireport is a search operator that allows you to leverage the power of stats, but multiple times.
Now we join the two | stats output together into one, so that we can analyze them together

Accelerated Data (With Peer Group)

Here, tstats is pulling in one command a super-fast count per user, per system, per day of authentications.
It is usually easiest to work with data model acceleration after we've renamed the fields to something a little friendlier.
Find where the most recent value is less than -1d@d from either now() or the value showing your most recent data point (depending on your particular search desires)
Enrich primary with peer group
Here we are comparing the # of 'Secondary Field's viewed today and historically by the 'Primary Field'. multireport is a search operator that allows you to leverage the power of stats, but multiple times.
Now we join the two | stats output together into one, so that we can analyze them together

Screenshot of Demo Data