This is the first part of a threat hunting blog series I want to start. I plan to share some insights on several related ideas such as risk hunting, incident-based hunting, and leveraging a system similar to requests for intelligence (RFIs) in cyber threat intelligence (CTI) but for threat hunting.

These ideas and concepts came to me from creating and running a professional threat hunting program over the course of more than two years, from early 2022 to mid 2024. In this blog are many of the lessons I have learned in my time venturing on this journey. If you are just looking for some threat hunting resources in general, please find this collection on my GitHub I’ve compiled and were helpful to me during my journey.

Introduction

If you are like myself and have been generating and disseminating cyber threat intelligence (CTI) for many years, it may be an obvious choice to transition into a role whereby you consume and leverage it. Threat Hunting is an activity that experienced CTI analysts are likely to be particularly good at due to acquiring deep knowledge of adversary tactics, techniques, and procedures (TTPs), as well as their motivations and the decisions they make during their intrusions.

Put simply, the goal of threat hunting is to look for evidence of bad guys in an organisation’s environment. However, during this process of looking for evidence of bad guy activities, you will inevitably come across risky behaviour instead of actual signs of an advanced persistent threat (APT) actor or one of the stealthier ransomware gangs.

Scoping Out Threat Hunting

From my discussions with the Curated Intel community, the widely accepted description of a Threat Hunter in an Information Security Team is that they proactively seek out and investigate potential threats within an organisation. They can use a combination of manual and automated techniques to look for adversaries that have managed to evade security tooling. The main purpose of a Threat Hunter or Threat Hunting Team is to prevent security incidents before it causes damage, reputational harm, or disruption to the organisation they are responsible for.

Beginning Your First Threat Hunt

The first thing to take note of is that threat hunts can begin in a number of ways. The main two triggers for starting a proactive threat hunt involve intelligence-based threat hunting and hypothesis-based threat hunting. These two triggers are widely accepted and talked about in various articles, academic and commercial. In-house infosec teams, however, are often asked to perform a type of reactive threat hunt related to an incident at their organisation.

Intelligence-based Threat Hunting: The Hunter receives intelligence about the latest threat actor activities targeting the same industry their organisations is from or a certain information technology product their organisation uses. They then decide to see if that activity has taken place in their environment.

Hypothesis-based Threat Hunting: The Hunter hypothesizes that a certain type of activity that may be more likely to take place in their organisation’s environment based their knowledge of what systems or products it has. They then decide to look for signs of activities they anticipate based on their experience or research.

Incident-based Threat Hunting: The Hunter is requested to participate in an incident response situation, such as a malware being detected on an endpoint or accounts created on an internet-facing networking device by an adversary at their organisation. They then decide to look for additional signs of related activity based on what was observed during the incident.

Threat Hunting Outputs

To be able to prove you accomplished something following a threat hunt, it is important to consider what outputs you are striving for. This includes any noteworthy discoveries or potential incidents you uncovered. Plus, any future hunt ideas you came up with while hunting, any risky behaviours you observed, any times you leveraged CTI during your hunt, or gaps in your protection coverage. It is important to capture these in your reporting methodology.

During your threat hunts, such as leveraging behavioural detection rules against various log sources, you may not often actually find any signs of malicious activity. This is okay. It is not a failed hunt because you found nothing. As a hunter, you have validated that your protections are in place for that specific threat. This enables limited resources to be allocated elsewhere and will ultimately lead to improving the overall security posture of the organisation.

Request For Hunt (RFH)

If you work in CTI, you will be very familiar with the term request for intelligence (RFI), especially if you work on the vendor side. The same concept also still applies generally for in-house CTI teams at large companies with a global presence. Generally, in an RFI you will provide a product, which can range from a detailed report to simply an email or message response.

At an in-house CTI team, instead of receiving RFIs from various clients at different companies like if you work for a vendor, you will receive RFIs from various individuals across different teams, such as the executive leadership team (ELT) or the security operations center (SOC), as well as non-Infosec focused teams in departments like a physical security team.

However, another thing to consider with RFIs received by in-house CTI team is that it will likely include a question of “Are we impacted by this?” This is a reasonable question to ask by any member of an infosec team when they come across recent news that they think could affect the company they are responsible for keeping secure.

This is where the new concept of a request for hunt (RFH) can be introduced. The thing to remember about threat hunting is that delegating the entire responsibility of deciding what to hunt for to the threat hunting team alone is likely going to lead to skewed results. One way to mitigate the threat hunting team’s biases and preferences (i.e. they hunt for the things they like to hunt for) can be RFHs from stakeholders.

Other internal infosec teams (the stakeholders), such as a red team or physical security team may have their own ideas of what types of threats should be hunted for based on their observations of the architecture, nature and day-to-day running of the business.

Just as prehistoric hunters out in the wild benefitted from others that specialise in different habitats, from jungles to mountains to savannahs. Differing perspectives are going to augment your understanding of anything and make you more effective at it.

Please click here for part two.