Threat Hunting: Looking Without an Alert

Assume something got through, then go find it.

January 6, 2026

Detection assumes you know what to look for. Threat hunting assumes you do not, and that something has already slipped past the things you do know about.

It is proactive, it is human led, and it is one of the more enjoyable parts of defensive work because you are asking your own questions rather than working a queue.

What Hunting Is and Is Not

Hunting is not staring at a dashboard waiting for red. It is not running a vulnerability scan. It is not the same as incident response, although a successful hunt turns into one.

A hunt starts with a hypothesis: if an attacker were doing X in our environment, we would see Y. Then you go look for Y, and either you find something, or you learn that your visibility for Y is worse than you thought.

Both outcomes are useful, and the second one is more common. Finding out that you cannot answer a question is itself a finding worth logging.

Where Hypotheses Come From

Threat intelligence, meaning a report describing what a particular group does, translated into what it would look like in your data.

MITRE ATT&CK, working through techniques relevant to your environment and asking whether you could see each one.

Your own environment knowledge, which is often the best source. If you know that one legacy application uses a shared service account with wide access, that is worth hunting around whether or not any intelligence report mentions it.

And recent incidents, yours or a peer's. What happened to somebody similar is a good hypothesis generator.

Flow diagram of hypothesis driven threat hunting from writing the hypothesis, through choosing the data and technique, to either a finding or a visibility gap, ending in a new detection.
A Hunt That Actually Finds Things

The Techniques That Do Most of the Work

Stack counting. Take a field across the whole environment, count occurrences, and look at the bottom of the list. Things that happen once are interesting. A parent and child process pair that appears on one machine out of four thousand is worth thirty seconds of attention.

Rarity and first seen analysis. When did this binary first appear anywhere. When did this account first authenticate to this system. New things are more interesting than common ones.

Grouping and outlier detection. Machines in the same role should look alike. The one domain controller that differs is a lead.

Time series and beaconing analysis. Automated command and control tends to produce regular intervals. Looking at the variance of connection timing per destination surfaces it even when the destination itself is unknown.

Volume analysis in the right direction. Large outbound transfers to somewhere new are worth a look, and this is one of the few places where a simple threshold works reasonably well.

The Data You Need

Process execution with command lines and parent and child relationships, which usually comes from EDR or from Sysmon.

DNS query logs, which are cheap and disproportionately valuable for finding command and control and exfiltration.

Authentication logs across the whole estate, including cloud and identity provider.

Network connection records and, ideally, some proxy or firewall detail.

And enough retention to look backwards. Ninety days is a reasonable minimum, and dwell time in real intrusions is frequently longer than that. All of this lands in the SIEM.

Running a Hunt Properly

Write the hypothesis down before you start. It stops the hunt drifting into aimless browsing, which is what most unsuccessful hunts turn into.

Timebox it. Two to four hours per hypothesis is normal. Hunting is open ended by nature and will consume unlimited time if allowed.

Record what you looked at, what you searched, and what you concluded, including negative results. A hunt log stops the team hunting the same thing every quarter and provides evidence to auditors that proactive work happens.

And close the loop. Anything you found by hand that could be found automatically should become a detection. A hunting program that never produces detections is repeating itself.

Maturity, Honestly Assessed

The commonly used maturity model runs from organizations with no hunting and minimal data collection, through those that follow published procedures, up to those creating their own procedures and finally automating the repeatable parts.

Most organizations are lower on that scale than they think, usually because the data collection is not there. Hunting is downstream of visibility, so if the honest answer is that you cannot see process execution across the estate, that is the first project rather than the hunt.

Learn This at HackRange

Week 9 of the mentorship is a hunt in everything but name. You get one thread and no alerts, and you have to decide where to look next.