The Big Lie in Threat Hunting

Gaurav Banga
October 21, 2020 | 8 min read | Security Posture, Vulnerability Management

Wikipedia defines cyber threat hunting as “the process of proactively and iteratively searching through networks to detect and isolate advanced threats that evade existing security solutions.” In practice, this is a very manual process where trained “hunters” combine expertise in attacker behavior and techniques combined with a deep knowledge of the networks and assets that they are protecting to iteratively search for and uncover threats that have slipped past deployed protective security tools such as firewalls and EDR.

Depending on who you ask, threat hunting has been around for upwards of 20 years, with the job title, “threat hunter,” originating in the last 6-7 years. Today, there are nearly 1500 profiles on LinkedIn with this title (up 50% just over last year), reflecting perhaps the explosion of popularity of threat hunting in the enterprise and the “cool factor” of the name.

The big lie in threat hunting is that this practice (as usually implemented) is really not proactive, with the major focus being on trailing indicators vs leading indicators.

To understand this better, let’s take a closer look at the “threat indicators” typically used.

Trailing Indicators of Compromise vs. Leading Indicators of Risk

What is an Indicator of Compromise?

At its simplest, an IOC is evidence that a cyber attack of some sort has occurred. Examples of IOCs include malware infection, unexpected traffic from or to a specific device, large outbound data transfers, etc. To identify and triage IOCs, security teams set up a SIEM that ingests and analyzes events from the important pieces of software in the enterprise.

The focus on IOC identification is to shrink the 170 day average dwell time before a company detects a threat. The problem with the IOC approach is that it’s completely reactive – the damage has already been done.

Indicators of Compromise (IOC) Detection Timeline
Indicators of Compromise (IOC) Detection Timeline

Indicators of Attack (IOA)

This shortcomings of IOC hunting (“too late, damage already done”) has led infosec teams to make their detection capabilities more proactive, focusing not on “What has happened,” but instead on “What is happening.” IOA hunting is also implemented using SIEM rules and programs.

The search for Indicators of Attack (IOAs) focuses more on the activities and behaviors that adversaries undertake leading up to an attack, often corresponding to the reconnaissance step of the Cyber Kill Chain. This is like having a camera at your front door facing the street trying to catch potential burglars as they stake out your house before their robbery event. While IOA detection helps to identify threats sooner in the process, its Achilles’ Heel is that practically detection is still only possible after an initial infiltration attempt has occurred. Dialing up aggressiveness to try to be more proactive with IOAs leads to an explosion of false positives.

Indicators of Attack (IOA) Detection Timeline
Indicators of Attack (IOA) Detection Timeline

IOR Detection

In light of these challenges, threat hunting teams are increasingly turning their attention to indicators that are observable long before the adversary has infiltrated the organization – Indicators of Risk (IORs). Unlike the IOC and IOA approaches, the proactive threat hunter starts with hypotheses on how attacks might be conducted, and iterates through testing for the presence of relevant vulnerabilities across 100s of attack vectors. The primary advantage of  IORs vs. IOCs/IOAs is that defenders can mitigate risk before any attack begins.

Indicators of Risk (IOR) Detection Timeline
Indicators of Risk (IOR) Detection Timeline

IORs tell the threat hunter whether the organization is vulnerable to a particular type of attack, not whether or not an attack of this type is happening right then. Let’s look at how this works in practice.

Suppose your organization hosts several of its most mission critical applications on Linux servers running SMB/CIFS. You might hypothesize that attackers would go after these assets, potentially exploiting the SambaCry vulnerability. With an IOA/IOC approach, you need to wait for this vulnerability to be exploited, and then catch the adversary red handed. Using the IOR approach, however, you can check proactively with a simple query – no need to search through old vulnerability scan reports or manually check hundreds of software versions.

Here’s an example using Balbix. With a single query using the built-in natural language search capability, you can see that there are 105 Linux servers still vulnerable, across a range of different corporate locations.

Exposure to Sambacry
Exposure to Sambacry

Consider a more general example, where you simply want to look for critical assets that are unpatched and subject to a broad range of exploits. Another simple search shows 157 critical assets, including Exchange Servers and Domain Controllers that have not been properly patched.

Unpatched Critical Servers
Unpatched Critical Servers Dashboard

One final example illustrates the human vulnerabilities that are indicators of risk. Suppose you suspect that web browsing activities of individuals in one of your offices exposes them to risk of being phished. Here we see 59 individuals with iPhones in the Bangalore office with elevated risk of being phished, perhaps an indication that additional security training is in order.

Tracking iPhone Phishing By Location
Tracking iPhone Phishing By Location

Want proactive threat hunting: focus on the IORs

Reacting to threats after they’ve happened, or even as they happen, will always be a losing proposition. As the enterprise attack surface continues to grow, proactive cybersecurity posture transformation is the only viable path forward. Balbix can help – take a look.