About detectors

Overview

Once all of the data is gathered in the data lake, Hunters will run its detectors on the data to detect anomalous events or behaviors. Hunters provides near-real-time detection of threat signals found in the raw data using a library of hundreds of detectors. Hunters comes with a continuously growing list of hundreds of detectors out-of-the-box, as well as the ability to create your own custom detectors.

▶️ Watch the video to dive deeper into Detection

As part of this phase, you will encounter the following terms:

Detector
A piece of logic, or rule, used to detect suspicious events in the collected data. When such a suspicious event is detected, a lead will be created. Detectors can have 3 sources: Hunters OOTB detectors created by the Hunters’ research team, 3rd party detectors brought over from the organization’s data sources (like other security vendors), and custom detectors you can build yourself on the platform. For example, the detector ‘Execution of Burp pen-testing suite’ will create a lead when it detects the execution of the Burp suite.

Lead
A lead is a detected signal of suspicious or malicious activity in your organization. Leads are generated as part of the detection phase and are later enriched with additional layers of information during the Auto-investigation phase. Each lead describes the suspicious event that happened, for instance: ‘The web pen-testing framework Burp Suite was executed’.

3rd party lead
A 3rd party lead is a lead detected by a 3rd party detector.

How does it work?

The Hunters Detection Engine is based on an advanced architecture, that allows:

A wide range of detection capabilities, from the simplest filter on a row-by-row basis, to complex aggregation, joining and learning capabilities
Detection-as-Code and CI/CD to seamlessly deliver new detections and improvements
Scaling detectors to run on terabytes of data in near-real-time

Types of Detectors

A detector is a piece of logic that aims to detect a specific type of suspicious activity in the data.

Some detectors are rule-based and detect TTPs in the raw security data, while other detectors leverage third-party alerts from EDR, IDS, Cloud Security products, and more. In addition, there are Machine Learning detectors that utilize UEBA and anomaly detection to find suspicious signals, and Threat Intelligence detectors that perform continuous IOC scanning over the raw security data.

Below you can find a more detailed explanation of each detector type in the Hunters platform.

‘Filter’ detectors

This is the simplest type of detector, which applies filters on each raw data event and generates leads for the events that answered the filter.
It is often used to detect specific event types of interest, specific binary names being executed with suspicious flags, etc.

The filter being used in the detector windows_event_user_added_to_admin_group:

‘Group By’ detectors

Deriving its name from the SQL “GROUP BY” function, these are detectors that trigger on a group of events in a certain time period, that passed a filter and a threshold.

Several time window functions can be used in this detector type - TUMBLE, HOP (also known as Sliding) and SESSION - based on the capabilities exposed by Apache Flink.

The detector cloudtrail_root_events, aggregating the activity of AWS root users to 4 hour chunks leads, to be investigated together:

'Change' (UEBA) detectors

The change detection template can monitor the set of values for given columns, and emit a lead on a configurable condition. Along with the change detection functionality, the template also features a learning period filter: a timeframe in which the baseline set of values is recorded and no leads will be generated.

The detector edr_macos_access_to_a_new_domain_using_curl learns the different domains accessed by MAC devices using the curl binary in the first 7 days it's running, and then emits a lead for every new domain being accessed after the learning period.

'Cross-Stream Sessions' detectors

The cross-stream sessions template attempts to find groups of events in one stream that are "missing" events from another stream. For example, a group of AWS CloudTrail events from a specific IP address, that didn’t match any CrowdStrike agent’s external IP address at the same time, hinting at AWS access being done from a computer with no CrowdStrike agent installed.

In the terminology of the template, the CloudTrail events are named the "target stream" (because we're looking for suspicious events in this stream), and the CrowdStrike events are named the "clearing streams" (because the events in this group are innocent). More than one clearing stream can be specified.

The template performs its logic by unifying the specified stream into one stream, applying Session Windows aggregation, and searching for windows that don't have any activity from the clearing streams.

The detector okta_logs_admin_access_from_computer_without_edr looks for access to the Okta admin app from an unmonitored device. It joins the admin activity with EDR heartbeats based on IP address (Okta’s `ip` with EDR's `aip`), and if we saw an entire session without any events from this IP in the EDR stream - a lead will be generated.

'Time-series' (UEBA) detectors

UEBA stands for User and Entity Behavior Analytics. It is a type of methodology used to detect anomalous behavior patterns in a network's users and entities.

The basic premise behind UEBA is that threats are often initiated by insiders who have legitimate access to the network. These threats can take many forms, such as stolen credentials, phishing attacks, or malicious insiders. By analyzing the behavior of users and entities on a network, UEBA can identify unusual or suspicious behavior patterns that may indicate a potential threat.

UEBA technology typically collects data from a variety of sources, including user activity logs, network traffic, and data access logs. This data is then analyzed to identify patterns and anomalies. Some common types of behavior that UEBA systems may look for include:

Multiple login attempts with different credentials
Accessing sensitive data outside of normal business hours
Unusual data transfer patterns
Changes to access permissions or other system configurations

By analyzing user and entity behavior patterns, UEBA can help organizations identify and respond to potential threats before they result in a data breach or other security incident.

More about Time-series detectors.

📘 Learn more

Learn more about working with detectors:

Machine Learning (UEBA) detectors

Our ML algorithm detectors utilize specific internally developed algorithms to identify suspicious behavior. Using ML methods, the detector refines its logic to improve its accuracy.

The Anomalous Login ML detector leverages specific attributes as input features:

IP address
Geo location: IP City; IP district; IP Country;
OS family
Browser family

The algorithm evaluates how uncertain or varied each attribute is in the training data and uses this information to assign weights to the attributes. These weights and the probabilities of specific attribute values are then used to compute the likelihood of a login event being anomalous. This approach allows the algorithm to adapt to different data distributions without relying on fixed baseline thresholds.