Lesson 80 — Turn the Successful Hunt into Team Capability
The hunt worked.
A behavioural hypothesis led to a query.
The query found activity the alert queue had not surfaced.
The analyst investigated the matches.
Two devices required escalation.
Excellent result.
Then Agent Foskett asked another question:
“Could the analyst on the night shift run this hunt tomorrow?”
Silence.
The query was sitting in someone's browser tab.
The reasoning was in their head.
The exclusions were undocumented.
Nobody had recorded what a meaningful match looked like.
Agent Foskett smiled.
“Then we haven't built a capability yet. We've built a good afternoon.”
A hunt should outlive the analyst who wrote it.
Capture the hypothesis, required telemetry, query logic, expected results, limitations, tuning and escalation criteria so the team can use it again.
Case briefing
Investigation objective
Turn a useful one-off threat hunt into a repeatable SOC asset by documenting its purpose, evidence requirements, query logic, interpretation, tuning, limitations and escalation path.
Investigator's rule
If the hunt only works when its author is sitting beside you, it is not operational yet.
Stage 1 — capture why the hunt exists
| Field | What to record |
|---|---|
| Hunt name | A concise description of the behaviour being tested. |
| Hypothesis | The suspicious behaviour or attacker activity the team believes may exist. |
| Origin | Incident, intelligence, anomaly, analyst observation or previous hunt. |
| Required telemetry | The tables, products and coverage needed to run the hunt. |
| Time window | The normal period to search and why. |
| Expected output | What a candidate result looks like. |
| Limitations | What the hunt cannot establish. |
Start with the hypothesis
The team needs to understand what the query is testing. A block of KQL without investigative intent is difficult to interpret, tune or safely modify.
Record where the idea came from
If the hunt originated from an incident, document the behaviour that made it reusable. If it came from intelligence, record the technique or observation that motivated it.
Stage 2 — preserve the working query
DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName in~ (
"msedge.exe", "chrome.exe", "firefox.exe"
)
| project Timestamp, DeviceId, DeviceName,
AccountName, FileName,
ProcessCommandLine,
InitiatingProcessFileName
| order by Timestamp ascStore the query with context
The useful asset is not just the KQL. Record why each important condition exists, what data source it expects and what the analyst should investigate after a match.
A saved query is only the beginning
A technically valid query can still be operationally useless if nobody knows how to interpret its output.
Stage 3 — document what a result means
Define candidate versus finding
A hunting query usually produces activity worth reviewing. Documentation should explain what additional evidence turns a candidate into a stronger lead.
Give the analyst a pivot path
List the next useful pivots: process timeline, network events, file activity, identity evidence, messaging evidence or cloud activity as appropriate.
Stage 4 — capture known benign patterns
| Observed pattern | Analyst action |
|---|---|
| Approved automation launches PowerShell through a known workflow | Validate owner, command and expected schedule before treating as benign. |
| Administrative tooling produces a similar parent-child chain | Confirm authorised tool, operator and change context. |
| Rare but legitimate support activity | Document the business context rather than blindly excluding the device. |
| New command or changed execution pattern | Re-investigate even if the broader workflow was previously known. |
Do not create permanent blind spots
Exclusions should be narrow, justified and reviewable. “Exclude the IT subnet” may make the query quieter while hiding exactly the activity the team needs to see.
Document why an exclusion exists
Future analysts need to know whether an exclusion represents validated normal behaviour or merely an old attempt to reduce noise.
Stage 5 — make the hunt measurable
Track useful outcomes
Candidate volume, confirmed findings, common benign explanations and recurring data gaps can all help determine whether the hunt remains useful.
Do not worship the numbers
A hunt that finds nothing may still constrain uncertainty. A hunt with many matches may still be valuable if the matches can be efficiently triaged. Metrics support judgement; they do not replace it.
Stage 6 — test whether another analyst can run it
Repeatability is a quality test
Another analyst should be able to reproduce the hunt without reconstructing the original author's thought process from scratch.
Peer review improves the hunt
A second analyst may identify assumptions, weak filters, missing telemetry or confusing documentation that the original author no longer notices.
Stage 7 — define escalation criteria
| Result | Suggested disposition |
|---|---|
| Known approved behaviour with matching context | Document and close the candidate. |
| Unusual behaviour with insufficient context | Continue investigation or seek additional evidence. |
| Behaviour plus suspicious network/file activity | Escalate according to SOC process. |
| Multiple affected entities or active malicious activity | Consider incident response and containment workflow. |
| Required telemetry unavailable | Document visibility limitation and involve the appropriate owner. |
The hunt should lead somewhere
Analysts need to know what action follows a meaningful result. Otherwise the team can repeatedly discover the same suspicious activity without consistently responding to it.
Keep judgement in the workflow
Escalation guidance should support analysts, not pretend every investigation can be reduced to a rigid score or single query result.
Stage 8 — decide whether the hunt should become a detection
Hunting and detection are related
A successful hunt can reveal behaviour worth monitoring continuously. If the signal is reliable and actionable, the team can consider engineering a detection around it.
Do not automate uncertainty blindly
If the hunt requires substantial human context to distinguish benign from suspicious activity, converting every match into an alert may simply create noise.
Stage 9 — version the capability
| Version | Change | Reason |
|---|---|---|
| 1.0 | Initial browser → PowerShell hypothesis | Derived from confirmed incident behaviour |
| 1.1 | Added command context guidance | Reduced ambiguous candidates |
| 1.2 | Added network pivot procedure | Improved investigation consistency |
| 1.3 | Updated known benign workflow notes | Environment changed |
Hunts are living assets
Attackers change, environments change and telemetry changes. Record meaningful revisions so analysts understand why the hunt looks different from the version they used last month.
Retire hunts deliberately
If a hunt is obsolete, replaced by a detection, no longer supported by telemetry or no longer relevant, record that decision instead of leaving stale queries scattered around the SOC.
Stage 10 — package the hunt
Now it belongs to the team
The hunt has moved from one analyst's successful investigation to a documented process that the SOC can repeat, review and improve.
That is how capability compounds
One investigation teaches one analyst. A documented hunt teaches the team. A refined detection or playbook can eventually protect the environment continuously.
Lesson 80 key takeaways
- A successful one-off hunt is not automatically team capability.
- Document the hypothesis before the query.
- Record required telemetry, time window and limitations.
- Explain how analysts should interpret candidate results.
- Provide clear investigation pivots after a match.
- Document benign patterns and exclusions with reasons.
- Keep exclusions narrow and reviewable.
- Track hunt outcomes to identify drift and tuning opportunities.
- Peer-test the hunt with another analyst.
- Define defensible escalation criteria.
- Consider whether repeatable, actionable behaviour should become a detection.
- Not every useful hunt should become an alert.
- Version, review and deliberately retire hunting content.
- A hunt becomes capability when the team can repeat and improve it.
Module 8 complete — Threat Hunting: Looking Beyond the Alerts
You started this module by forming a behavioural hypothesis instead of waiting for an IOC. You scoped techniques across devices, hunted beyond quiet alert queues, built baselines, recognised baseline drift, combined weak signals, interpreted negative findings, survived changing IOCs, crossed telemetry boundaries and finally turned a successful hunt into repeatable team capability.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 8: Threat Hunting: Looking Beyond the Alerts
How do you turn a successful threat hunt into SOC capability?
Lesson 80 of the Agent Foskett SOC Analyst Academy teaches analysts how to package a threat hunt with its hypothesis, telemetry requirements, KQL, interpretation guidance, limitations, tuning, escalation criteria and review process so another analyst can repeat it.
Operationalising threat hunting in a SOC
Learn how repeatable hunting content can support team knowledge, peer review, continuous improvement and, where appropriate, future detection engineering without automatically turning every hunting query into an alert.
