One of the bigger headaches I think we can all agree on in the Cyber Security business is the overuse of buzzwords, and the overlapping mutations of what they mean, depending on who’s saying them. Threat Hunting has certainly become one of those phrases. So what is threat hunting, really? Well, depending on who you ask… (i.e., an Enterprise, a Vendor, or perhaps both), that answer can certainly vary. And the interesting thing is none of them may actually be wrong, despite having somewhat different answers to the same question. There is certainly a wide collection of different tools, skill sets, approaches, and processes to help identify things currently happening or that could happen within the network. What is an effective hunting process for one organization may be a waste of time for another, depending on each company’s understanding of what threats they might face. Man-hours spent hunting are typically most beneficial for large organizations, that may be targeted by the cybercriminal community on a regular basis, but that’s not to say that regular hunts for small/medium-sized enterprises can’t benefit from and identify threats by doing the same.
So let’s start with what is (at least somewhat of) a traditional definition of threat hunting. Threat Hunting can be defined as a focused and intensive human/machine-assisted process aimed to identify the possibility of something malicious happening within the network or likely about to happen; this is based on abnormal network behavior, artifacts, or identification via active threat research. A good example of this would be:
But that’s just one basic example. The “possibly malicious” aspect mentioned above can come from a variety of hunting methods, which again can all be “correct” in their own right, depending on the threats, skills, and tools specific to an enterprise. These methods can be driven by the following:
One thing that is interesting about this topic is that when discussing it, you may hear something along the lines of “Threat hunting is not detection/remediation, and detection/remediation is not threat hunting.” This is 100% accurate, but the two processes certainly rub shoulders and compliment each other to a certain degree. An example of this could be a high-priority detection from a known critical asset to a known APT IP (which could be provided by a third party, open-source, etc.). Now, of course, this a detection and not part of a Threat Hunt, but if that one asset is communicating to that IP, what else might that APT have been up to? This is where a Hunter could pivot into an Actor profile, and gather/extract all additional information about their behaviors and additional infrastructure, such as TTP’s, IOC’s, etc., to execute a retrospective search within their SIEM/Endpoint tools to identify: a) what other machines might have been mapping to these behaviors; b) what other machines may have direct identification (associated IOC’s); c) what known critical assets were involved; and d) how long this activity has been occurring in the network.
The unfortunate thing about threat intelligence is that it is massive; in order to realistically operationalize it within the network, we have to make sacrifices based on contextual information, like how recent it is, the perceived severity by vendor A vs. vendor B, its associations, et cetera, et cetera. While we all want finished intel to seamlessly flow through our network, this is rarely the case. While you may see a piece of this APT activity that launches your investigation from that initial IP connection, chances are you don’t have all of the associated information for that APT being actively correlated. After your proactive hunting/gathering of “new” associated information to that APT, this can then be actively leveraged to find new threats or defend proactively against what would be the next phase of an APT’s attempts to maintain persistence. Unlike a lot of other tools/processes that tout automation as a central selling point to its usefulness, Threat Hunting is a different approach that requires manual effort to find the things that traditional tools are missing, and that’s something that we just have to live with (for now). As with any successful hunt, this, of course, will be dependent on the Threat Hunter’s skills and access to the right tools.
The above use case is one of the reasons Anomali developed “Anomali Enterprise,” a dedicated appliance that is built to take a massive threat intelligence dataset (including threat reports, TTPs, and actor information) and correlate this against a compressed set of network activity to provide both retrospective search capability and lower-level intelligence correlation that may not be relevant until scenarios like the above arise.
Regardless of my definition of threat hunting, what do I need to be effective?
A lot of folks have a lot of opinions on this subject, but regardless of what your definition of threat hunting is, an enterprise needs to have the right components in place for it to be a possibility.
In conclusion, our security tools are never going to alert you 100% of the issues lurking in the network, which is why the term Threat Hunting exists in the first place. Attackers depend on you to rely on your signature-based detection, so every organization needs to dedicate skills, tools, and time to the hunting process to be a truly end-to-end security organization. Each organization’s process may be slightly (or widely) different from another, and that doesn’t mean it’s “wrong,” so long as that process is laser-focused on hunting for threats that were otherwise not seen or known about by traditional tools.
Daniel Katz is a Sr Solutions Engineer at Anomali with experience across the cyber security technology stack. Prior to his current expertise with Threat Intelligence Platforms, Daniel worked at HPE focusing on IDS/IPS and Application Security.