Threat Hunting: For what, when, and how? - SharITSec

img generated using openai’s dall-e-3 model

I recently wrote about what a good alert looks like. I breezed over the actual detection logic that outputs a good alert, instead focusing on the alert’s contents. To address the former, I first need to give an overview of what I find to be effective Threat Hunting, which I consider to be an integral first step of developing a detection.

To start, what is Threat Hunting? Many seem to agree that Threat Hunting is defined, in one flavor or another, as proactively detecting threats that evade existing security technologies. However, the manner in which threat hunting is performed seems to be less consistent. I don’t think it means one interpretation is right or wrong, but exemplifies the different variations of threat hunting that exist. This variance in implementation is usually due to the varying capabilities and maturity of a security operations program. In my opinion, a strong threat hunting capability implements the following types of hunts at their respective, appropriate cadences.

Intel Driven

Intelligence can come from various sources including open source reporting like blogs, private groups like ISACs, three-letter government agencies, and your own internal SOC. The intelligence may come in various forms, from finely edited threat reports, phone calls from an agency, or an incident report from your own organization. The amount of detail and relevancy to your organization will often vary.

Scenario

CISA releases an advisory warning of active exploitation of a vulnerable web server. The report includes details of attacker operated infrastructure and the URIs being requested to successfully compromise the server.

The Hunt

You search your environment to see if there is network traffic between any attacker operated IPs. You also search access logs to see if the URI has been requested from your public facing web server that would indicate attempted exploitation.

Hypothesis Driven

A hypothesis driven hunt is basically the application of the Scientific Method to threat hunting. You start with a question, conduct research, and hypothesize how an attack may be successful in your environment. This can be informed by threat modeling or knowledge of architecture and applications that may have greater risk for successful compromise. Your hypothesis has not yet been proven or reported as observed in the wild.

Scenario

Your company has an internal server that hosts sensitive documents. You perform a threat modeling exercise to determine the attack path an adversary would need to take to acquire the files. You hypothesize that an admin may inadvertently allow access to everyone including external users which would allow a download to originate from a user not associated with your company’s domain.

The Hunt

After researching the events that would be logged when sharing permissions for a file are changed and confirming you have those logs, you search for that configuration event occurring for the sensitive files or parent folders. Additionally, you identify download events in the audit logs and search for user emails with non-corporate domains.

Data Driven

You have large datasets which may contain anomalies indicative of suspicious activity. You don’t have a narrowly scoped hypothesis of the activity you’re looking for, but performing data analysis can identify the anomalies which may warrant deeper, manual review. This analysis will likely result in interesting findings but may not necessarily indicate malicious activity. The datasets rely on historical data to generate baselines to determine the anomalies.

Scenario

You recently enabled logging for a SaaS app which allows data exports. You don’t have a narrowly scoped hypothesis of the activity you’re looking for, but performing data analysis can identify anomalies which may warrant deeper, manual review. This analysis will likely result in interesting findings but may not necessarily indicate malicious activity.

The Hunt

You create a search that calculates the total bytes downloaded per day for each user. You reduce the result set by isolating user downloads exceeding two standard deviations which you’ve found to be an effective initial threshold. You find that, while the activity is anomalous according to the entire user base, it is so far always legitimate. You decide to keep tabs on this activity and deploy this search as a dashboard panel to be reviewed daily.

Cadence

The types of hunts outlined above usually occur at different cadences.

Ad-Hoc

Intel driven hunts are dependent on intel reports being published and reviewed. These hunts are not actually performed on a cadence, but instead on an unscheduled, ad-hoc basis according to the urgency and applicability of the threat to the environment. Ad-Hoc hunts are good candidates to track using a kanban board.

Planned

Hypothesis-driven hunts can be scheduled as there is typically no imminent threat they are addressing. These hunts require careful planning, usually involving a threat modeling exercise to identify the risk and attack surface that may be impacted. Hypothesis-driven hunts are good candidates to schedule in sprints using the scrum framework.

Scheduled Report

Data-driven hunts are most effective when scheduled on a recurring basis once they are refined to produce a high quality dataset as output. They may originate as a planned hunt, but can evolve into a scheduled “report”. Hypothesis-driven hunts can also be deployed as continuous scheduled reports if proper tuning has not yet been applied to enable conversion as a detection. These scheduled hunts should query contiguous timeframes of data, avoiding any gaps where the data isn’t being analyzed. Scheduled Reports are good candidates to be consumed daily using dashboards.

Overlap

The three types of hunts — Intel Driven, Hypothesis Driven, and Data Driven — are not always mutually exclusive. As an example, it would be a normal progression for a Data Driven hunt to inspire a more narrowly scoped Hypothesis which can be more specifically hunted.

Objective

The objective of the hunt, regardless of type, is fairly consistent:

• Identify suspicious activity that evaded existing security technologies
• Document and escalate hunt findings as appropriate to remediate accordingly
• Convert the hunt query into a detection to be deployed continuously

Findings

Most times, hunts will not have juicy findings like uncovering a nation state threat actor that has been dwelling in your environment undetected for months. But fortunately, that isn’t how the success of hunts should be measured. There are other findings that should be captured and reported appropriately, illuminating additional value hunts provide:

Security Posture Risk

• Example: server is allowing inbound traffic
• Example: service accounts are being used to logon interactively

Misconfigurations

• Example: logs are not properly parsed
• Example: log retention policy is set for 1 day

Policy Violations

• Example: user has an unapproved third party application running on startup to prevent their screen from locking
• Example: an administrator has GitHub tokens stored in cleartext in a shared google drive document

Hunt Query vs. Detection Query

You may have noticed I bolded one of the objectives above:

Convert the hunt query into a detection to be deployed continuously

In my opinion, this is one of the most important components of a hunt that sometimes gets neglected. Just because a hunt covering a specified period of time came up empty does not mean the activity will not occur tomorrow, falling outside the scope of your hunt. To prevent this evasion, you should strive to operationalize the hunt continuously in the form of a detection.

Let’s further clarify the difference between the two.

A hunt query is the result of an iterative process that begins with a wide scope and gradually narrows to return the interesting events. The process of this iterative query development is a story for another day, perhaps in the form of a future blog post .

A detection query is when a hunt query can be refined so narrowly that the results being returned are efficacious enough to warrant immediate investigation by an analyst.

This can more easily be distilled down to a difference in fidelity, usually implied by volume. A hunt query may return a stack of data that needs to be reviewed manually, line by line, while a detection query is automatically getting refined due to advanced, fine-tuned logic that excludes expected behavior and known false positives. This isn’t easy, as it requires careful analysis of the hunt results to identify these tuning opportunities. But, doing so can ensure the activity you hunted will be detected in the future if and when it does occur.

Key Takeaways

To wrap it all up, I’ve prepared a simple chart intended to answer the questions in the title: what, when, and how?

To elaborate a bit further:

Intel Driven

• What? TTPs and IOCs included in threat intelligence reports.
• When? As the reports are released.
• How? Using Kanban boards.

Hypothesis Driven

• What? Actions performed to achieve a specific objective you’ve defined in your hypothesis.
• When? During scheduled sprints.
• How? Using the scrum methodology.

Data Driven

• What? Anomalies found in large datasets.
• When? Following the initial hunt, review daily or perhaps weekly
• How? Dashboards or automated reports.

The question of “What?” could also be interpreted as the outcome of the hunt as opposed to the subject of the hunt. With this interpretation, there are a sequence of related answers which are essentially the hunt findings or deliverables:

• Suspicious activity that evaded existing security technologies and is escalated to the SOC for further investigation.
• Hunt queries that were able to get deployed as daily hunts or ideally new detections.
• Risky configurations requiring remediation to tighten your security posture and perhaps reduce your attack surface.

Note: I wrote this based on my experience as the technical team lead of a Threat Hunting and Detection Engineering team for a Fortune 500 company between 2018–2022. After I wrote this, I cautiously read the recently published PEAK threat hunting framework, curious of stark misalignment. I was pleased to find many similarities with my implementation. It makes sense, as the PEAK framework is seemingly inspired by David Bianco and other threat hunting frameworks, SQRRL and TaHiTI, which heavily influenced my implementation. I suggest anyone who finds the rendition I detailed above a logical, practical implementation of threat hunting to also review the PEAK threat hunting framework. It includes fantastic guidance for developing hypotheses, the hunt process, and producing measurable metrics. What you may not find, which I touched on, are expected cadences for performing the various types of hunts, as well as proposed project management methodologies that may help plan and track the hunts.

References

https://www.splunk.com/en_us/pdfs/gated/ebooks/splunk-peak-threat-hunting-framework.pdf

https://www.threathunting.net/files/framework-for-threat-hunting-whitepaper.pdf

https://www.betaalvereniging.nl/wp-content/uploads/TaHiTI-Threat-Hunting-Methodology-whitepaper.pdf

Threat Hunting: For what, when, and how? was originally published in Detect FYI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction to Malware Binary Triage (IMBT) Course

Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.

Enroll Now and Save 10%: Coupon Code MWNEWS10

Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.

Article Link: Threat Hunting: For what, when, and how? | by br4dy5 | Detect FYI

1 post - 1 participant

Read full topic

Malware Analysis, News and Indicators - Latest topics