Optimizing Threat Intel: Shifting Left on Detection to Minimize False Positives

TL;DR: Hunters has released new and advanced mechanism that automatically evaluates threat intel feeds and removes known benign IoCs before they ever create an alert, minimizing false positives from threat intel sources by around 98%.

Threat intel feeds are vital resources for security teams, but they change fast. They are notorious for creating mountains of noise for analysts to sift through, and sometimes within minutes, IoCs can be added or removed, leaving teams scrambling to keep up.

Imagine a world where you can aggregate your threat intelligence feeds, automate the traditional workflows you use for investigation and remove false positives from your team’s queue before they ever become alerts. Well, that world is here. 

Hunters has released a new and advanced mechanism that automatically evaluates threat intel feeds and removes known benign IoCs before they ever create an alert. This means that your analysts aren't spending time combing through troves of false positives or searching for context on benign IoCs, but instead focusing on the alerts that are most threatening to your environment.

Leveraging any threat intel source, whether it is a paid feed, open source or from an in-house team, Hunters applies its complex logic to reduce false positives by a whopping 98%. 

Real Hunters data showing a dramatic drop in leads created of around 98%

Threat intel sources are imperfect

There are many ways to detect threats, and one of the easiest ways to track obvious and known signals is by utilizing threat intelligence feeds. Although these feeds are necessary resources for security teams, they tend to present large amounts of false positives due to multiple imperfections in the TI feeds.

Threat intelligence feeds tend to suffer from noisy data, such as legitimate files signed by automation engines. Moreover, outdated data can linger within these feeds, causing false positives as historical information no longer aligns with current threat realities.

The lack of context in some IoC matches further compounds this problem, as it becomes challenging to differentiate between benign and malicious activities. 

With inefficiencies coming in from so many different angles, it is necessary to create a complex and layered approach to combat them.

Multi-layered and cross context logic

In order to eliminate such a large number of false positives, Hunters automates the MANY steps that are normally either done manually by analysts or built into a SOAR playbook. 

In order to accomplish this, different IoC types require different strategies, so let’s break down how hashes, IPs, domains and URLs are evaluated.

HASHES

The main goal is to identify and block hashes that are known to be benign. We utilized a set of criteria as the foundation to analyze hashes.

NSRL

The National Software Reference Library (NSRL) is a project managed by the National Institute of Standards and Technology (NIST) in the United States. It plays a crucial role in cybersecurity by providing a reference for "known good" software and files. 

NSRL can be useful for cross-referencing safe hashes against those in IoC feeds. For example, many IoCs are added automatically by engines scanning binaries. If they see a binary that was involved in the execution of an attack, the engine might include it in the IoC list derived from this attack even though the binary itself was not necessarily malicious. 

Hunters leverages NSRL to identify "known good" files, thus reducing flagging hashes that were known to be benign.

VirusTotal Enrichment

Combining logic created in-house by the Hunters Research team with data from VirusTotal, we employ a systematic verification process for each hash indicator within VirusTotal. If the data retrieved from VirusTotal proves to be trustworthy (valid, relevant, and reliable), Hunters will run it through an additional assessment process to enrich those IoCs. If it’s deemed untrustworthy, the data will not be used to label IoCs as either malicious or benign. Let’s quickly look at Hunters’ criteria for trustworthiness: 

• Validity:  We verify that the hash's associated data contains more than zero bytes, ensuring that it represents an actual file or binary.
• Relevancy: We look for the VirusTotal report about this hash to be applicable to the current time frame. For example, if the “last analysis time” is too old, then it’s possible the scoring  of VirusTotal is not up-to-date.
• Reliability: We evaluate if the report about this hash been consistent over time. For example, sometimes during a new attack campaign the binaries involved are still unknown, resulting in VirusTotal showing a low score. However, over time, the score might increase as the attack campaign is revealed and the VirusTotal engines are updated accordingly. Hence, if the “first submission time” is too close to the current time, we limit our confidence in the VirusTotal score, and avoid using it to determine whether a binary is suspicious or benign. 

If we find the data trustworthy, we activate our IoC assessment process. Within this process, we take into account four additional factors:

• Time difference between the first submission and last analysis of the hash on VirusTotal
• Risk-adjusted approach towards hashes with different VirusTotal scores
• Whether hashes were signed by Microsoft or tagged as Known-Distributer
• Strength of the engine reporting the hash (engines like Kaspersky, CrowdStrike Falcon, Microsoft, and Palo Alto are more trustworthy than ML-based, statistical, and generally less accurate engines)

If you are thinking this is a lot of steps, you’re right. But don’t worry, Hunters has built this into its platform so it is automatically performed on any threat intelligence source that is being used by our customers.

IPs, DOMAINS and URLs

Much like the policy for hashes, the policy for IPs, domains and URLs is a finely tuned combination of external data from reliable vendors used for enrichment, and Hunters’ research-based logic, used to weed out any irrelevant IoCs.

Cross referencing with third party services

For IPs and domains, Hunters incorporates data from multiple third party services. These services provide reputation scoring based on open-source feeds (OSINT) and user submissions. Many are known to provide high fidelity and actionable intelligence by aggregating dozens of feeds, active scans and passive scans. These allow Hunters to blocklist based on several factors, such as IP activity, direct-to-IP URLs, domain registration time, and more.

Cisco Umbrella (Umbrella 1M)

Hunters utilizes data from Cisco Umbrella, the popular resource that provides a list of most queried domains based on passive DNS usage across Cisco Umbrella global network. Domains found in the list are likely to be benign, and such are added to Hunters blocklist.

Time to Live

Threat intelligence feeds may include historical data that, while once valid, is no longer indicative of an active threat. By adjusting TTLs based on the nature of each IoC type, we can strike a balance between keeping historical data for contextual analysis and minimizing false positives caused by stale or irrelevant indicators.This means that if the last sample of the IoC is older than a designated timespan, Hunters will automatically refrain from generating leads. The timespan for the different IoC types is as follows:

• IPs - 30 days: IP addresses are often dynamic and can quickly change hands or purposes. A 30-day TTL is suitable as it allows for monitoring recent activity while reducing the risk of false positives from outdated IPs.
• Domains - 120 days: Domains tend to have a longer lifespan compared to IP addresses. A 120-day TTL allows for monitoring over a more extended period, which is useful for tracking persistent threats while still considering potential changes in ownership or use.
• URLs - 60 days: URLs’ relevance can change relatively quickly. A 60-day TTL strikes a balance between capturing recent activity and preventing false positives due to outdated URLs.

Benefits of Hunters’ approach

Implementing all of these criteria, has brought Hunters customers impressive benefits.

• Increased visibility into leads: leads that make it through this filtering process will include all of the details gathered from the listed criteria. This gives the analyst full access to the context of each IoC.
• Bring any threat intel feed: whether it is paid, open source, or even if you have an internal team that provides threat intel, it will be automatically run through our framework. This will prevent the vast majority of false positives from ever becoming a lead and clogging up your SOC Queue.
• Shift left what was previously being handled by your SOAR: With this framework being applied so early in the workflow, Hunters customers don’t need to spend time building SOAR playbooks to handle the overflow of alerts and false positives. Customers no longer have to wait for a lead to be created in order to deal with it.

Not only is this a massive upgrade for all of Hunters customers, but this is also a breath of fresh air for practitioners across the industry. The advanced logic that is continually developed by Hunters Research Team makes it even more efficient for security teams to tackle the leads that matter.

To learn more about Hunters' SOC Platform, set up a call with us here.