Threat hunting: looking without an alert

Why this matters

Everything so far has been reactive: something fired, you triaged it. Hunting is the opposite posture — you go looking on the assumption that something is already present and has not alerted.

That assumption is reasonable. Every detection you have was written for a behaviour someone anticipated; an intrusion that avoids all of them produces silence, and silence is indistinguishable from safety. Hunting is the activity that distinguishes them, which makes it the practical answer to the theme this course has returned to in every lesson.

CS0-004 tests whether you can structure a hunt rather than browse logs hopefully.

The lesson

Hypothesis-driven hunting

A hunt without a hypothesis is scrolling. The hypothesis is what makes it finishable, because it tells you what would count as an answer.

A good hypothesis is specific, falsifiable and scoped to available data:

Weak: "Look for anything suspicious in the proxy logs." Better: "If an attacker were using DNS tunnelling for command and control, I would see hosts making a high volume of queries with long, high-entropy subdomains to a small number of parent domains. Do any internal hosts show that pattern in the last 30 days?"

Where hypotheses come from:

• Threat intelligence — an actor's described behaviour, per the previous lesson.
• Coverage gaps — techniques you know you cannot detect. These are the most valuable hunts, because nothing else is looking.
• Crown jewels — start from what matters and ask how it would be reached.
• Recent incidents, yours or a peer's.
• Anomalies noticed in passing that nobody had time to chase.

Every hunt then ends in one of three honest outcomes: found something (it becomes an incident), found nothing and the data was adequate (a real negative result, worth recording), or could not tell because the data was missing (a coverage finding, often more valuable than either).

That third outcome is the one teams routinely fail to record, and it is exactly the "not measured is a third result" distinction that runs through this whole course. A hunt that could not see is not a hunt that found nothing.

Baselining: knowing normal well enough to see abnormal

Hunting is anomaly detection performed by a human, and anomaly requires a baseline. This is why lesson 2 insisted on generating benign traffic before anything else.

Baselines worth having, and worth building before you need them:

• Per host: which processes normally run, which destinations it contacts, when it is active.
• Per user: working hours, applications, typical data volumes, usual locations.
• Per service account: the narrowest and most useful baseline of all, because service accounts should be boringly consistent.
• Per network segment: which protocols are normal, which pairs normally talk.
• Estate-wide: how many hosts run this binary, how common is this parent- child pair.

Two cautions. First, a baseline built from a compromised environment normalises the compromise — if the attacker was present when you measured, their beacon is now part of "normal". Second, baselines drift with deployments and reorganisations, so they need refreshing or they generate increasing noise.

Stack counting, frequency analysis and outliers

The workhorse techniques, and they are simpler than they sound.

Stack counting — also called long-tail analysis — means aggregating a field across the estate and sorting by frequency. Malicious things are usually rare; legitimate things are usually common. So you look at the bottom of the list.

Worked examples:

• Count every parent-child process pair. The bottom of that list contains Office spawning interpreters and web servers spawning shells.
• Count binary names by how many hosts run them. A binary present on one host out of 8,000 is worth a look.
• Count scheduled task names across the estate; unique ones stand out.
• Count user agents by frequency; the rare ones are automation.
• Count destination domains by number of distinct internal clients. One host talking somewhere nobody else goes is the shape from lesson 6.

Frequency analysis looks at regularity over time, which is beacon hunting: group by source and destination, compute interval variance, and inspect the tightest clusters.

Outlier analysis looks for the statistically unusual — a host uploading far more than its peers, a user authenticating far more often than their team.

Two practical rules. Compare like with like: a domain controller is not an outlier for behaving like a domain controller, so segment by role before you rank. And remember that rare is not the same as bad — rarity tells you where to look, not what you found.

Documenting a hunt so it can be repeated

A hunt nobody wrote down is a hunt that gets redone from scratch in six months by someone who does not know it was already done.

What a record needs:

• The hypothesis, stated as it was before you started.
• Data sources and the exact time range searched.
• The queries, verbatim and runnable.
• What you found, including the benign explanations for things that looked interesting. These are the most reusable part — next time the same pattern appears, somebody already knows it is the backup agent.
• The outcome, as one of the three honest results above.
• Gaps discovered, which usually become their own work.
• Time spent, so the programme can be evaluated honestly.

The negative results matter as much as the positives. "We hunted for DNS tunnelling across 90 days with adequate telemetry and found none" is a genuine statement about your risk position, and it is the kind of statement an executive report can actually use — a point developed in the reporting lessons.

Turning a successful hunt into a permanent detection

The productive end state of hunting is that you hunt for something once and never have to again, because it now alerts automatically.

The conversion:

1. Can this be expressed as a rule? Some hunts depend on human judgement and cannot be, which is a legitimate answer.
2. Measure the false-positive rate first, using the historical data you just searched. You already know how often it would have fired over 90 days — that is the best possible estimate of its future noise, and it is free.
3. Raise specificity until the volume is tolerable: add the parent process, the user context, the time-of-day condition.
4. Write the response. What should the analyst do when it fires? Per lesson 10, a rule with no answer should not ship.
5. Test it in the lab with the technique that motivated it.
6. Deploy, then review after a few weeks against what actually fired.

And where conversion is not possible, the remaining option is a scheduled hunt — the same query run monthly by a human, on a calendar, with its results recorded.

That is the honest end of this objective. Some things cannot be automated, and the mature position is to schedule them rather than to pretend the automation covers it. An organisation that knows which of its risks are covered by detections, which by scheduled hunts, and which by nothing at all has something most do not: an accurate picture of its own blind spots.

Topics this lesson owns

• [x] Hypothesis-driven hunting
• [x] Baselining: knowing normal well enough to see abnormal
• [x] Stack counting, frequency analysis and outliers
• [x] Documenting a hunt so it can be repeated
• [x] Turning a successful hunt into a permanent detection