Under the Hood Series: Hunters' Open XDR Approach to Automatic Threat Investigation & Scoring


There are different approaches to Extended Detection and Response (XDR). These approaches define the way that data is being collected, analyzed and projected to the user.

Firstly, there is the single-vendor XDR approach that allows to collect and correlate data only from the specific vendor products. This approach may be problematic for users who have a variety of vendors in their security stack (which is the case in most organizations).

On the other side of the spectrum, there is the “open XDR” approach. Open XDRs use native, API-based integrations to collect and analyze threat signals and telemetry from best-of-breed providers of: endpoint, network, cloud, email, identity, and other security tools.

Hunters’ open XDR is based on a product pipeline that has unique capabilities: Flexible Ingestion, Detection Engine, Automatic Investigation, Scoring and Prioritization, and Cross-Surface Correlation.

This blog post will cover the Automatic Investigation and the Scoring and Prioritization parts of the pipeline. Hunters' unique approach to these enables outperforming in the handling of security alerts, as it amplifies true positive threat signals while reducing false positive ones. These capabilities, too, provide unique visibility into security data, as well as clear explainability throughout the detection pipeline to fully act as a decision support system for the analyst at the top of the funnel


Automatic Investigation 

First, let’s talk about the Auto-Investigation mechanism, which enhances the analyst’s ability to triage, investigate and understand the impact of the attack that is presented in the Hunters’ portal, with an emphasis on explainability.

Investigations focus on the key entities involved in an alert or threat signal and all of its relevant associated attributes, and providing more context to enable a thorough understanding and effective triage.

Once an alert or threat signal is presented, there are multiple continuous questions that enrich it with additional supporting data. This algorithm correlates information with other data points such as EDR, proxy, firewall and also retrieves data from external sources such as VirusTotal, Geolocation and more. 

Let’s see an example.

When analysts deal with a list of alerts to further look into, the biggest problem are false-positives, so let's take a look at one of the very noisy alerts out there, which is the “login without an EDR agent” one.

In the image below you can see an “AWS login without an EDR agent” alert. The related enrichments extract all relevant data of the alert and further enrich it, providing important information to decide on the maliciousness level. 

For this example, you can see the location of the IP address, how many logins were made by this IP, what users were seen from the IP, and several other questions.


"AWS login without an EDR" alert enrichments

Behind the enrichment function there is a complex engine that classifies the different associated attributes (i.g. Source IP address) into a series of entities.

Entities ultimately are groups of attributes that make sense together. For instance, one of the most used entities is the “Employee” one. This entity contains different kinds of attributes that help to define an “Employee” internally: attributes like “full name”, “username”, “email”, “department”, “job_title” and more.

Often information like “job_title” is not given as part of the alert data, so there are enrichments that run and bring the required data from different sources (for instance the identity-related data from the existing IAM tool of the organization).

Every enrichment has a list of alerts or threat signal IDs it runs on, and what additional attributes to extract, in order to have enough information to create an entity. After creating an entity, there are more enrichments that run for the sake of enriching the data to prepare for the scoring engine to run and be effective. Later on, the scoring engine picks it up and gives a scoring based on the alert or threat signal and enrichments data. 


An example of an Auto-Investigation for an “AWS Console Login from Host without an EDR Agent” alert

Scoring and Prioritization

One of the challenges in the security space is how to empower a SOC analyst to be more effective. Hunters’ Scoring and Prioritization enables SOC analysts to focus on the true positives, while deprioritizing most false positives.

After performing Automatic Investigations on threat signals and alerts, and once there is enough context around them, Hunters XDR leverages ML models to score them from 0 to 100, allowing for an effective prioritization and quick triage.

There is an initial scoring mechanism that looks at all the elements of the associated with an alert or threat signals, an it immediately decides on an initial scoring to prioritize threat signals for the user. It asks a number of questions based on the specific alert or threat signal that the scoring module runs on. 

To decide the main score given to a specific alert or threat signal, enrichments must run first to enrich the data and to have more telemetry to execute the algorithm of the relevant scoring module.

After the enrichments run, the main scoring module decides on the score and presents it to the user. For example, a detection that looks for PE files written to a user’s subfolder with an unusual file extension, receives a high score because there was a use of a ".txt". 


The scoring of an unusual extension of a PE file threat signal

After every threat signal is scored, the next thing to do is to prioritize them based on the scoring. Analysts receive a list of threat signals from the highest score to the lowest, allowing them to decide smartly on what to work on next. 

There is also the “confidence” mechanism that provides the analyst with the ability to see how confident the scoring module is regarding the maliciousness of the threat signal.


Next is forming stories, which are a combination of several related by entity threat signals. Stories are mainly based on the Graph (while we won’t dive into it, you are more than welcome to watch the webinar about it) and their goal is to create a way for the analyst to understand the whole picture of an attack scenario and not only single non-related threat signals from different tools.

Forming an Attack Story is a key feature that emphasizes the importance of explainability. The user is able to see and understand the entire situation by visualizing the entire story and timeline, which will help the analyst to decide on what to act on first. 

An example of an Attack Story that we saw earlier this year:


An example of an Attack Story

In the story we see that a “Windows Situational Awareness Process Execution” event has taken place. With the help of an enrichment, an agent_id was extracted and other threat signals that were related to the specific agent_id were connected.

Combining the three different threat signals that are presented above, there is the summarized scoring of the story, making it the first on the list for the analyst, with the explanation of why it received the specific score.


Scoring Breakdown of the Attack Story

As you can see above, because there were 3 different Detections the score was raised, and for each Detection, the score became higher. 


Hunters XDR is all about empowering the SOC by giving them the means to detect and see threats and attacks as they take place, and minimize the time to understand in order to take action with confidence.

Stay tuned for the next blog post of the Open XDR - Under the Hood Series, which will focus on data ingestion methods.