Strengthening Threat Hunting Programs - Part 1: Requests for Threat Hunts
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.
