Hosts Sending To More Destinations Than Normal

Description

This will typically detect scanning activity, along with lateral movement activity.


Use Case

Advanced Threat Detection, Security Monitoring

Category

Scanning, Endpoint Compromise

Security Impact

The first phase of the Lockheed Martin Kill Chain is reconnaissance, which can include initial scanning of a target network to map out assets, as well as vulnerabilities for potential entry points using known exploits. It is important to note that this type of activity can happen both on the perimeter as well as inside of a network once an initial foothold has been made. Monitoring for this type of activity can help identify precursors to an attack as well as be an indicator that assets within an organization, or credentials have been compromised.

Alert Volume

Low (?)

SPL Difficulty

Basic

Journey

Stage 1

MITRE ATT&CK Tactics

Discovery

MITRE ATT&CK Techniques

Remote System Discovery
Network Service Scanning

MITRE Threat Groups

APT3
APT32
APT39
APT41
BRONZE BUTLER
Cobalt Group
Deep Panda
Dragonfly 2.0
FIN5
FIN6
FIN8
Ke3chang
Leafminer
OilRig
Soft Cell
Suckfly
Threat Group-3390
Tropic Trooper
Turla
menuPass

Kill Chain Phases

Reconnaissance

Data Sources

Network Communication

   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 identify the other systems that the alerting system is communicating with. Capture the time, applications, destination systems, ports, byte count and other pertinent information. Contact the system owner and user if the logs have the appropriate fidelity of this action. If systems being communicated to are internal, contact the owner(s) of those systems as well. If it is authorized, 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 to determine why additional systems are being communicated with.

   Help

Hosts Sending To More Destinations Than Normal Help

This example leverages the Detect Spikes (standard deviation) search assistant. Our demo dataset is an anonymized set of firewall logs. For this analysis, we are tracking the total number of unique destinations the source IP has reached out to per day 'dc(dest) by src _time'. 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. Note that this use case is only reliable for servers -- users will move around too much due to DHCP and it won't be reliable. Look to a more advanced product, such as Splunk UBA.

SPL for Hosts Sending To More Destinations Than Normal

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. In this case, we're using eval instead due to some odd performance seen with | bucket following | inputlookup on a 7.2.0 instance.
Finally, we can count and aggregate per src_ip, 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 Firewall dataset (we should specify a single index and sourcetype in production environments).
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 src_ip, per day.
calculate the mean, standard deviation and most recent value
calculate the bounds as a multiple of the standard deviation

Accelerated Data

Here, tstats is pulling in one command a super-fast count per src_ip, per day.
calculate the mean, standard deviation and most recent value
calculate the bounds as a multiple of the standard deviation