Notifications
Clear all
Topic starter
19/08/2026 3:59 pm
TL;DR: Threat hunting at scale is less about tooling than about prioritisation, shared definitions, and understanding where attackers blend into normal administrator behaviour, according to Sprocket Security’s conversation with T. Rowe Price. The practical lesson is that hunters need context, graph-based reasoning, and a clear separation between hunting, incident response, and red teaming to reduce blind spots.
NHIMG editorial — based on content published by Sprocket Security: What effective threat hunting looks like inside large, complex environments
Questions worth separating out
Q: How should security teams structure threat hunting so it does not collapse into incident response?
A: Threat hunting should be a separate function with its own charter, data sources, and success metrics.
Q: Why do attackers who behave like administrators make threat hunting harder?
A: They make hunting harder because they exploit normal-looking access patterns, shared systems, and broad entitlements.
Q: How do graph-based methods improve threat hunting prioritisation?
A: Graph-based methods show which actions connect multiple stages of an attack and which ones are structurally important to the attacker’s path.
Practitioner guidance
- Define hunting as a separate operational function Write a formal charter that separates threat hunting from incident response, red teaming, and threat intelligence.
- Add identity context to hunt queries Join logs to user role, privilege scope, session type, and system ownership before you evaluate behaviour.
- Prioritise choke points in attacker paths Use graph analysis to find high-value transitions between stages of compromise, then focus hunting effort on the techniques that connect those stages.
What's in the full article
Sprocket Security's full conversation covers the operational detail this post intentionally leaves for the source:
- Practitioner commentary from Matthew Winters on how threat hunting works inside a large enterprise SOC.
- The reasoning behind prioritising execution-focused hunts over broad initial-access assumptions.
- The discussion of graph theory, betweenness centrality, and attacker-path disruption in real hunting workflows.
- The full episode context for teams that want the original practitioner perspective rather than the editorial analysis.
👉 Read Sprocket Security's conversation on threat hunting at scale and attacker prioritisation →
Threat hunting at scale: what should security teams prioritise first?
Explore further
19/08/2026 4:36 pm
Threat hunting fails when organisations treat it as a generic detection label rather than a disciplined search function. The article shows that teams often blur hunting with incident response, red teaming, and threat intelligence, which creates governance confusion before any analysis begins. That confusion is not just semantic. It affects resourcing, escalation, and the definition of success. The practical conclusion is that a hunting programme must have its own objectives, inputs, and outcomes.
A question worth separating out:
Q: What should organisations do when hunting at scale produces too much noise?
A: They should narrow the search space by separating automated activity from human behaviour, then compare the extremes, rare cases, and repeated patterns in each dataset. The goal is to reduce analysis paralysis before deeper investigation begins. Noise usually falls when teams improve data context rather than when they simply collect more of it.
👉 Read our full editorial: Threat hunting at scale depends on where defenders look first
