Threat hunting is a cool term. It’s so cool that so many people, managers, and marketers have latched onto it and used it to describe almost anything you can think of from pen testing to SOC operations to red teaming to incident response. It’s become a pet peeve of mine how badly “threat hunting” is mis-used and mis-understood.

And I’m still convinced that threat hunting started for two main reasons. First, to slip in between the major efforts already in play between detection engineering (the blue team SOC), incident response which tackles found things, and handling threat intelligence, which usually ends up being an automated feed and corrrelation mechanism within a SIEM. Another way to put it: the human in between the matured automated technical activities.

And second, something for bored internal red teamers, IR folks, and senior detection engineers to do in between the main projects. (I’m joking, but I’m not….but I am…)

I just skimmed through a free PDF that caused me to make this post to keep this link around and share it: Threat Hunting Essentials, Part 1: Threat Hunting Defined, by Fidelis Cybersecurity.

In this, they not only talk about a good definition of Threat Hunting, but also examples of what it is not. This is super important, because I’ve talked to way too many people from keyboard warriors in the trenches up to management and executive levels who have the wrong idea of what Threat Hunting is. And having it wrong almost certainly means the chances of a successful threat hunting team are limited, and they probably won’t be happy hunters if everyone is operating under slightly different missions. That is bad friction.

Fidelis gives this definition:

“Threat hunting is the proactive hypothesis driven discovery of artifacts, activity, or detection methods not accounted for in passive monitoring capabilities.”

And see, even trying to isolate a good definition like this will still be open to interpretation. It is best to read the entire paper, as they do an amazing job of framing the problem, tackling the problem with easily understood examples and language, and allowing it all to funnel down into something that I consider easy to handle. There’s lots of good examples and discussions over recent years, but it’s been hard to find one so clear and yet (mostly) concise enough to present to others.

And yes, it can still be done by bored internal red teamers, senior detection engineers who need a break, or incident responders that don’t have any incidents being currently worked. But the inputs, outputs, methods, results, and expectations need to get aligned in order for the mission to add value and be successful.

And I’ll also just add that Threat Hunting is an advanced activity. It should only be a thing with maturing security operations and engineers teams, and only for those with senior skills in understanding offensive tactics, forensics artifacts left behind, and where the gaps in blue team visibility occur.