Threat hunting

35 minIntermediate

Threat hunting

Your detections and your alert queue only catch what someone already wrote a rule for. Threat hunting is the proactive search for the attacker who slipped past all of them. This lesson shows you how to start from a hypothesis instead of an alert, baseline what normal looks like so you can spot the outliers, and turn every successful hunt into a new detection so you never have to hunt the same thing twice.

By the end you can

Explain why a SOC hunts even when no alert has fired, in terms of dwell time and coverage gaps
Write a specific, testable hunting hypothesis from ATT&CK, threat intel, crown-jewel analysis or an anomaly
Run the hunt loop and feed a confirmed finding back into a detection and a documented, repeatable hunt
Baseline normal activity and find outliers with stack counting, rare parent-child processes and beaconing
Measure a hunt program by hypotheses tested, detections created and gaps found, not by incident count

The everyday picture

A supermarket has alarms on the doors and cameras over the tills. Those catch the obvious theft: a tag crosses the sensor, a drawer opens when it should not. But a good store also has a floor walker who strolls the aisles when no alarm has gone off. They are not waiting for a signal. They carry a quiet question in their head: "if someone were stealing from us in a way the alarms miss, what would it look like?" Then they go and look. Someone lingering by the same shelf every day at closing, a trolley that keeps leaving half full, a staff locker that opens too often.

The floor walker works because they know what a normal evening looks like, so the odd thing stands out. And when they find a new trick, the store does not just stop that one person. It adds a camera, a checklist, a new rule, so the trick is caught automatically next time. Threat hunting is that floor walker for your network. The alarms are your detections (Writing detections) and the camera feed is your alert queue (Triage and investigation). Hunting is the deliberate walk through the data, led by a question, looking for the attacker no rule caught, and ending with a new rule so the next one is caught.

Why hunt when nothing has fired

Detections are rules someone wrote ahead of time. They are powerful, but they share one blind spot: they can only match behaviour you already thought of. A patient attacker using stolen but valid staff credentials, living off tools already on the machine, and moving slowly, can stay inside a network for a long time without tripping a single rule. The time between the first compromise and the moment someone notices is the dwell time, and across the industry it is often measured in weeks, not minutes.

Hunting attacks dwell time directly. Instead of waiting for a signal, you assume the attacker may already be inside and go looking. That mindset has a name, assume breach, and it is the opposite of hoping the perimeter held. There are three good reasons to start a hunt:

Dwell time. Even a well-run SOC misses things. A regular hunt is a second pass that shortens how long a quiet intruder goes unnoticed.
Coverage gaps. Every detection set has holes. Hunting in an area with no rules tells you where you are blind, and each hunt can close a hole by producing a new detection.
New intelligence. A report lands describing how a group breaks in, say a malware family that calls home on a fixed timer. You do not have a rule yet, so you hunt for its fingerprints in your own logs today.

Hunting does not replace detections or triage. It complements them. A finding from triage can seed a hunt ("this one alert was odd, is it happening elsewhere and quieter?"), and a hunt almost always ends by writing the detection that triage will use tomorrow.

Quick check

Mangrove's SOC has a tuned alert queue and few false positives, and the manager asks why the team should spend a day a week hunting. What is the strongest reason?