Pick a threat-informed hypothesis
Do not start from "let us look for weird stuff." Start from a concrete statement that you can prove or disprove with data you already have. Good examples:
- "An adversary with initial access is using WMI for lateral movement in our environment."
- "An attacker abused our SSO identity provider to provision a rogue application."
- "Credential dumping via LSASS read is happening on any server in the last 30 days."
Each of these maps cleanly to specific MITRE ATT&CK techniques. Each is testable with your existing telemetry. Each produces a written result — yes, no, or "needs more data" — that you can file, review, and re-run next quarter.
Write the detection logic on paper first
Before touching your SIEM, draft the query in plain language:
- Data source: process creation events from EDR
- Filter: look for processes that requested
PROCESS_VM_READaccess againstlsass.exe - Noise filter: exclude legitimate security software already on your allowlist
- Target: any remaining unknown process
Only then translate to your SIEM's query language. Writing the logic on paper first forces you to think about data completeness before you get lost in syntax.
Run it. Count the results. Expect too many.
The first run of any hunt query returns more hits than you can triage. That is not failure, that is signal. It tells you where the noise lives. For each noise source, decide: is it legitimate traffic I should exclude, or is it interesting enough to investigate once?
If the first run returns zero hits, your query is probably wrong. Revisit the filters; they are almost always too tight.
Tune, but do not tune away the hunt
The art of hunting is knowing the difference between "this query returns too many benign processes, let me exclude them by path" and "this query returns too many hits, let me lower the scope so it runs faster." The first is good tuning. The second is giving up.
A well-tuned hunt query is narrow enough to return a reviewable result set and broad enough to still catch the adversary. If you find yourself adding exclusions for entire subnets to make the query run, you have lost the thread.
Capture what you found, even if it was nothing
Most hunts end with "no evidence of compromise." That is a finding. Write it up:
- Hypothesis being tested
- Query executed (verbatim)
- Time range and data sources covered
- Result — even if null
- Confidence level in the null result
- Next hunt to run based on what you learned
A null result is valuable because it narrows the threat landscape and shows that the SOC is systematically sweeping for adversaries. It is also the evidence your CISO will want when the board asks "how do we know we are not compromised right now?"
Turn successful hunts into detections
Any hunt query that catches a real finding should become a scheduled detection. This is how your SOC's detection coverage grows organically — informed by actual adversary behavior instead of vendor-supplied rules.
The hand-off from hunt to detection is where a lot of programs fail. They find something interesting, celebrate, and then forget to convert it. Build the conversion into your workflow: every closed hunt ticket should link to either a new detection rule or a documented decision to not productize.
The habit that matters most
Run one hunt a week. Not ten, not two — one. Make it part of the analyst rotation. Over a year that is 52 hypotheses tested, 52 writeups, and 10 to 15 new detections.
That is how SOC maturity actually improves. Not by buying another tool, not by hiring another analyst — by running one good hunt a week, every week, forever.
Written by Sari Taher. Based on real threat hunting programs I have helped build.