If you’re in infosec and you blinked, you’ll notice today that “threat hunting” is a thing. It’s more than a thing, it’s quite the movement (though probably ranking below blockchain, machine learning, and AI as far as infosec marketing buzzwords). Wikipedia’s page on the subject was created mid-2016. I spent about an hour doing Google searches trying to find earlier mentions of the term/process, but really found nothing. I think Sqrrl/David Bianco [pdf] was one of the earlier describers of threat hunting.

So, where did threat hunting come from?

First, threat hunting is about looking for threats already in your environment. Underlying this process is the assumption that attackers can and have gotten in, and that your current protections are not enough (with an optionally-implied “advanced threat” assumed). This process identifies weaknesses, compromises, and informs defenses. This stands in contrast to reactive technologies like IPS and SIEM alerts, or preventative processes like Antimalware defenses. Threat hunting by skilled analysts has them creatively hypothesizing about attackers, examining evidence and logs for confirmation of a weakness or presence of an attacker, and then informing defenses to protect against them.

Threat intelligence is often pulled into this mix, which is just a fancy way to saying, “increasingly detailed, technical information about attackers and the things they do when attacking.” If you have a mature threat hunting process, you’re helping create that internal intelligence, rather than just consuming outside sources.

Cool, but where did this come from? Why weren’t we doing this 10 years ago?

Ten years ago, we had blue teams (defenders) against red teams, pen testers, and real attackers. The blue team would wield various security tools and try to prevent, detect, and mitigate against those attackers with somewhat standard playbooks and relatively rigid signatures and alerts.

We’ve had various enlightened members on both sides who have contributed to threat intelligence over the years, and plenty of blue team members who have tried (probably largey in vain) to squeeze more out of their tools and high level access in their environments to sleep better at night. So, many of the tasks that a threat hunter may go through are known, but certainly had never before been truly organized, planned, or laid down in writing; they’re tasks many of us have tried to go through when work is light (hah!). One difference today is the ability to gather and parse massive amounts of data collected in an environment.

It has been long found that environments are becoming more complex (i.e. the attack surface keeps increasing, networks are becoming less efficient to defend, and no external consulting source can quickly given guidance beyond broad strokes and “well, it depends…” conversations) and relatively static signature-based tools don’t find even mediocre incidents. Blue teams have traditionally been poor about internalizing red team findings and creating effective mitigations. And red teams, particularly vulnerability assessment and pen testing teams have become a crowded market with several of their tasks somewhat commoditized through automation and point-in-time limitations.

Threat hunting teams can shore up plenty of these weaknesses. Rather than a point-in-time external pen test, threat hunting teams can act as internal, always-on pen testers; they think like attackers, study attacker methods, determine IOC, and inform and test defenses.

Threat hunting helps turn an infosec team from believing they are not compromised, to at least knowing they are not compromised via X, Y, or Z. And in today’s landscape, the X, Y, and Z incidents hitting the news are what board members ask about.

Threat hunting also acts as an outlet to some otherwise mundane tasks in infosec: analyzing logs and alerts and directing the rollout of a new patch every week. A way to exercise some creativity, learn more about attacker methods and tools (poppin’ root shells, my dudes!), and actually test internal controls and visibility.

They also fill a small gap in between security tools, blue teams, and red teams. Sure, red teams can detect weaknesses and security tools can act as a locked door or tripwire, but what about things the red team misses, or what about attackers who have already leveraged those weaknesses to get into an organization and evade security tools?

Ten years ago, threat hunting probably only went as far as a blue team admin finding something “weird” happening on a server or workstation, and investigating it to find an existing compromise. They fix the compromise, wonder how someone/something got in, wonder if it impacted anything else, and then likely moved on when those answers were not going to be efficiently forthcoming.

Sounds like a no-brainer to start doing this, yeah? Well, not so fast.

To my mind, the main challenge with threat hunting is being able to log, capture, and know everything (or enough) in an environment such that testing a hypothesis is efficient. An organization that is poorly logging things, has poor standards, and struggles to control the environment, will have a very uphill battle to do any real threat hunting. At that point, you’re walking into a forest inferno and looking for dumpsters that are on fire.