Threat Hunting: What Should You Hunt For?

What threat hunting is, and what it is not

Threat hunting is a human-led, hypothesis-based search for adversary activity that automated detection has not flagged. It rests on one assumption: detections can fail, so some activity will get through unseen. The hunter’s job is to test that assumption in a specific place, with specific data.

It is often confused with neighboring work. The distinctions matter because each has a different input and a different output.

Three ways to hunt

The PEAK framework, published by David Bianco with Ryan Fetterman as part of SURGe by Splunk, describes three hunt types. They are a useful way to see that “hunting” is not one activity.

PEAK also gives a simple cycle: Prepare, Execute, Act. Prepare covers choosing the topic, researching it and planning the hunt. Execute is the analysis. Act is where findings are documented, turned into automation where possible, and communicated. Without Act, a hunt leaves nothing behind.

Where hypotheses come from

Six sources produce most useful hypotheses:

• Threat intelligence about actors and techniques relevant to your sector and technology stack. Intelligence tells you what to consider, not what is present.

• ATT&CK coverage review. MITRE ATT&CK is a public knowledge base of adversary tactics and techniques based on real-world observation. Map your detections to it, then look for techniques that matter to you and have weak or untested coverage.

• Past incidents and near misses, yours and public ones. Ask what the attacker did before the alert, and whether you would see it again.

• Red team and purple team results. Techniques that succeeded without detection are ready-made hypotheses.

• Changes in your environment. A new identity provider, a cloud migration, a new remote access method or an acquisition each create activity that existing detections were not written for.

• Critical assets. Start from what an attacker would want and work backward to the paths and privileges that reach it.

Choose with four filters

Hunting capacity is small. Choose hunts by asking four questions, in this order.

1. Relevance. Is this behavior credible against your environment and your likely adversaries?

2. Impact. If it were happening, what would the attacker gain? Prefer behavior that leads to privilege, persistence or access to critical data.

3. Visibility. Do you collect the data that would show it, for a long enough period? If not, the hunt cannot succeed. Fix the logging first and record that as the finding.

4. Detectability. Would an existing detection catch it today? Prefer areas where the answer is no, or where you do not know.

The best candidates are relevant, high in impact, visible in your data, and weakly covered by detection. A topic that scores high on everything except visibility belongs on the logging backlog, not in this week’s hunt.

Examples

These are illustrative hypotheses, not findings from any organization. Technique references are to MITRE ATT&CK. Each needs adjusting to your own data sources and normal behavior.

The last column carries weight. A hunt that cannot say what normal looks like will produce a list of oddities rather than findings.

Running a hunt

Write the plan down before you query. A short record keeps hunts repeatable and reviewable:

• The hypothesis, and where it came from.

• The data sources, the time window, and any known gaps in that data.

• The method: the logic or queries, and what counts as suspicious.

• The stopping rule: how long the hunt runs, and what ends it early.

• The result, with each notable item given a disposition.

• The outputs and who owns them.

Set a time limit. An open-ended hunt tends to turn into data browsing. If a hunt finds activity that looks malicious, hand it to incident response with the evidence and stop treating it as a hunt.

What a finished hunt leaves behind

A hunt that ends with a chat message has not finished. Each hunt should produce at least one of these:

A negative result has value, and it has limits. It says that within this data and this period, you did not find this behavior. It does not say the behavior is absent. Write the limits down, so that no one later reads “we hunted for it” as “we are clear.”

Common mistakes

• Calling indicator sweeps “hunting.” Indicators are useful, and they belong in detection.

• Hunting without the data. Check retention and field quality before the hunt, not during it.

• Choosing topics because a tool makes them easy.

• Skipping the handoff to detection engineering, so the same hunt must be run by hand again.

• Treating every deviation as a finding. Baselines produce noise, and the hunter’s job is to sort it.

• Never refreshing the backlog. Revisit hunt priorities when threat reporting, your environment or your detections change.

What to do next

Pick one technique that matters to your business and has weak detection coverage. Check whether you have the data to hunt it. If you do, write the hypothesis, the stopping rule and the expected benign activity, then run it. If you do not, you have your first improvement. If you want help building a hunting practice around your own threat picture and data, Cybrilliant can work with your team on it.

Sources

• MITRE ATT&CK. MITRE. https://attack.mitre.org/

• PEAK Threat Hunting Framework. David Bianco, with Ryan Fetterman, SURGe by Splunk. https://www.splunk.com/en_us/blog/security/peak-threat-hunting-framework.html

• ATT&CK technique T1550.004, Web Session Cookie. MITRE ATT&CK. https://attack.mitre.org/techniques/T1550/004/

• ATT&CK technique T1078, Valid Accounts. MITRE ATT&CK. https://attack.mitre.org/techniques/T1078/

• ATT&CK technique T1098, Account Manipulation. MITRE ATT&CK. https://attack.mitre.org/techniques/T1098/

• ATT&CK technique T1219, Remote Access Tools. MITRE ATT&CK. https://attack.mitre.org/techniques/T1219/

• ATT&CK technique T1562, Impair Defenses. MITRE ATT&CK. https://attack.mitre.org/techniques/T1562/