A buyer’s guide · Operating since 2002
Threat hunting starts from an uncomfortable premise: that prevention has already failed somewhere in your estate and nobody has noticed. It is the deliberate search for an intruder who triggered no rule — because if a rule existed, the operations centre would already have the ticket.
That premise is what makes it useful and also what makes it awkward to sell. Most hunts find nothing. This page explains what they produce anyway, why that is the point, and how to tell a real hunting practice from alert triage with a better name.
The comparison
Hunting vs detection vs intelligence vs red teaming
These six get used interchangeably in sales conversations and are genuinely different activities, with different people, different inputs and different failure modes.
Scroll the table sideways →
| Activity | What it is | What starts it | The honest limitation |
|---|---|---|---|
| Threat huntingthis page | A human assumes a compromise has already happened and goes looking for it. | A hypothesis about attacker behaviour. | Finds what no rule was written for. Slow, skilled, and unpredictable in yield. |
| Detection engineering | Building and tuning the rules that fire automatically. | Known behaviour worth alerting on. | Only ever as good as the behaviour someone thought to encode. It cannot surprise you. |
| Alert triagethe SOC queue | Investigating what the tooling already flagged. | An alert. | Entirely reactive by design. If nothing fired, nothing is examined. |
| Threat intelligence | Knowledge about attackers, their tooling and their infrastructure. | External reporting and telemetry. | Tells you what to look for, not whether it is in your estate. Intelligence without hunting is reading. |
| Threat modelling | Reasoning about what could go wrong in a system, usually before it is built. | A design or an architecture. | Concerns hypothetical future weakness, not present compromise. Different question entirely. |
| Red teaming / pen testing | Authorised attackers testing whether they can get in. | A scope and a set of objectives. | Tests defences against a known friendly. A hunt looks for an unknown hostile who may already be inside. |
The row that matters most is detection engineering. Automated rules only ever encode behaviour somebody already thought of, which is precisely the boundary hunting exists to cross — and precisely why a successful hunt should end by becoming a rule.
Method
How a hunt actually runs
Four steps and three possible outcomes. Two of the three happen when nothing is found, and those two are where most of the cumulative value comes from.
A provider who reports a nil result with nothing attached to it has not done the work. Every hunt should leave behind either an incident, a new detection, or a documented reason you could not have seen the thing you went looking for.
Where hunts come from
Four ways to choose the question
A hunt is only as good as its hypothesis. These are the four starting points that reliably produce useful ones, each with its own failure mode.
Ask any provider which of these four they would use on your estate, and why that one. A provider without a preference has not thought about your environment.
Intelligence-led
A report describes a group targeting your sector and the techniques they favour. The hunt asks whether those techniques have already been used here.
Strongest when the intelligence is specific about behaviour rather than about indicators, because infrastructure changes weekly and behaviour changes slowly.
TTP-led
Start from a technique catalogue rather than a specific actor: how would credential dumping, or lateral movement over WMI, or persistence via scheduled task actually appear in our telemetry?
The most systematic approach, because coverage can be tracked and gaps are visible rather than assumed.
Anomaly-led
Begin from something odd in the data: a service account authenticating at an unusual hour, an endpoint talking to a destination nothing else talks to.
Productive but easy to rabbit-hole. Needs a time limit agreed before starting, or curiosity consumes the week.
Crown-jewel-led
Start from what matters most — the finance system, the source repository, the customer database — and work outwards asking who has touched it and whether that was legitimate.
The approach that most often produces findings a board understands, because the subject is already something they care about.
Straight answers
What buyers get wrong about threat hunting
Most hunts find nothing, and that is the expected result
A practice measured on intrusions discovered will either get lucky occasionally or start counting ordinary alerts as hunt findings. The value is cumulative: each hunt either finds something, leaves behind a detection rule that fires automatically forever afterwards, or proves you cannot see a technique at all. All three outcomes improve the estate. Only one of them makes a good story.
Hunting starts where your alerts stop
If a rule already exists for a behaviour, the SOC will catch it and no hunt is required. Hunting is therefore, by definition, the search for what nobody wrote a rule for — which is why it cannot be automated without becoming detection engineering, and why it needs people senior enough to know what normal looks like.
“We hunt continuously”
Ask what that means in hours and in hypotheses. Continuous hunting usually describes a tool running saved queries on a schedule, which is a useful thing but is automated detection under another name. Real hunting is discrete, bounded and led by a question.
A hunt is bounded by what you collect
You cannot hunt for lateral movement over a protocol you do not log, or for credential access on endpoints with no process telemetry. This is why visibility gaps are a legitimate and valuable hunt output — frequently more valuable than a finding, because a gap explains why previous hunts and previous alerts saw nothing.
“Is the hunter the same person as the tier-one analyst?”
Not necessarily a problem, but it changes what you are buying. Triage rewards speed and consistency; hunting rewards patience and lateral thinking. Providers who staff both from the same pool are usually optimising for the first, because the queue is what has an SLA attached.
Assumed breach is the starting position
Hunting begins from the premise that prevention has already failed somewhere and nobody has noticed. That assumption is what makes it productive — and it is also why an organisation that finds the premise offensive tends not to get value from the exercise.
Before you sign
Ten questions for any threat hunting provider
Use these on us and on everyone else. Question three is the one that separates a practice from a performance.
Is this hunting, or is it alert triage with a better name?
Ask for the hypothesis behind the last three hunts. If the answer describes responding to alerts, it is triage. Both are valuable; only one is what you are being quoted for.
What data do you need, and what happens when we do not have it?
Hunting is bounded by telemetry. A provider who never reports visibility gaps is either not looking hard or not telling you.
What do we receive when a hunt finds nothing?
This is the question that separates a real practice from theatre. The correct answer involves new detection content and a documented visibility gap, not a one-line email saying all clear.
How do you track which techniques have been hunted and which have not?
Ask to see the coverage map. Without one, hunts repeat the comfortable questions and never reach the awkward ones.
Who actually performs the hunt, and what is their background?
Hunting is a senior activity. Ask whether the people doing it are the same tier that handles your alert queue, and expect an honest answer either way.
How often, for how long, and who decides the subject?
A hunt with no time limit becomes an open-ended research project. A hunt with no say from you looks at what suits the provider.
What happens the moment something is found?
The escalation path from hunt to incident response should be written down before the first hunt, not improvised during the one that matters.
Which findings become permanent detections, and who maintains them?
A hunt that does not leave detection content behind has to be repeated forever. Ask who owns the rule afterwards and who tunes it.
Do you hunt in tooling we own, or only in yours?
This determines what happens to your capability when the contract ends. Content built in a platform you license is content you keep.
Can we see a redacted hunt report?
Ask before signing. A genuine one shows the hypothesis, the data queried, what was ruled out and what changed as a result — including the hunts that found nothing.
Working with us
How we run this
We have run security operations since 2002. Hunting sits alongside that floor rather than replacing it, which matters: a hunt that finds something needs somewhere to hand it, immediately.
Senior analysts
Hunting is done by people who know what normal looks like, not by the tier that works the alert queue. Ask us who would be assigned and we will name them.
Tracked coverage
Hunts run against a technique catalogue with a coverage map, so what has not been hunted is visible rather than assumed. You see the gaps as well as the results.
Every hunt leaves something
An incident, a permanent detection rule, or a documented visibility gap. Nil results arrive with the reason attached.
Built in your platform
Where you own the SIEM or EDR, detection content is built there so it stays yours when the engagement ends.
Straight into response
The path from hunt to incident response is written down before the first hunt, not improvised during the one that matters.
US presence
P J Networks LLC is our US entity, based in Dallas, Texas — the company a US client contracts with. It is a subsidiary of P J Networks Pvt Ltd, which holds the ISO/IEC 27001:2022 certification referenced on this page.
Questions we get asked
Threat hunting, answered
What is threat hunting?
Threat hunting is the proactive search for attackers already inside an environment who have not triggered any alert. It starts from the assumption that prevention and detection have failed somewhere, forms a specific hypothesis about how an attacker would behave, and interrogates telemetry to prove or disprove it. It is deliberately not alert-driven — if a rule already fires for the behaviour, hunting it is unnecessary.
What is the difference between threat hunting and threat detection?
Detection is automated and reactive: rules encode known-bad behaviour and fire when they match. Hunting is manual and proactive: a person asks a question nobody has written a rule for. The relationship is a cycle rather than a competition — a successful hunt should end by becoming a detection rule, so the same question never needs asking by hand again. An organisation doing only detection is limited to what someone previously thought to encode.
What is the difference between threat hunting and detection engineering?
Detection engineering builds and maintains the rules; hunting explores the space those rules do not cover. They feed each other directly: hunting finds behaviour worth alerting on, and engineering makes it permanent. Teams that separate the two entirely tend to produce hunts whose findings evaporate, and rule sets that only ever grow from vendor content.
How is threat hunting different from threat intelligence?
Intelligence is knowledge about attackers — who they are, what they use, how they operate. Hunting is the act of checking whether that behaviour is present in your estate. Intelligence tells you what to look for; without hunting, it is reading. Hunting without intelligence still works, but it starts from technique catalogues or your own anomalies rather than from what is currently being used against your sector.
How is threat hunting different from red teaming or penetration testing?
A red team is a friendly attacker testing whether your defences can be beaten, on a known scope and timeline. A hunt looks for an unknown hostile who may already be present, with no scope and no timeline supplied by the adversary. They pair well — a red team exercise creates real activity for hunters to try to find, which tests detection and hunting simultaneously.
What does a hunt actually involve?
A hypothesis stated precisely enough to be wrong. A decision about which data would prove or disprove it. Queries and analysis across that data, usually iterating as the picture develops. Then one of three outcomes: something was found and becomes an incident; nothing was found but the query becomes a permanent detection; or the data needed did not exist, and a visibility gap is logged.
What happens if a hunt finds nothing?
That is the usual outcome and it is still productive. The hunt either leaves behind a detection rule that will fire automatically from then on, or it establishes that you cannot currently see a class of behaviour at all — which explains why neither hunts nor alerts have surfaced it. Both permanently improve the estate. A provider who reports a nil result with nothing attached has not done the work.
How often should hunting happen?
Regular and bounded beats occasional and open-ended. A defined hunt on a defined hypothesis with a time limit, repeated on a cadence, produces measurable coverage growth. Continuous unstructured hunting tends to revisit comfortable questions. What matters more than frequency is whether coverage against a technique catalogue is being tracked, so gaps are visible instead of assumed.
Do we need a SOC before we can hunt?
You need telemetry, retention and someone to hand findings to — which in practice usually means a SOC, ours or your own. Hunting without an incident response path produces discoveries nobody acts on. Hunting without log retention produces questions that cannot be answered. Those two prerequisites matter far more than the label on the team.
What data do you need?
Endpoint process telemetry, authentication and directory logs, network flow or DNS, and cloud and identity provider audit trails cover most hypotheses. Not all of it is needed at once — the hypothesis determines the data. Where something required is missing we say so and log it as a visibility gap rather than quietly hunting only what happens to be available.
Can you hunt in our existing tooling?
Yes. We work in customer-owned SIEM and EDR platforms regularly, and where hunts produce detection content we build it in the platform you license so it remains yours if the engagement ends. Content that only exists in a provider’s platform is content you lose at renewal.
Who performs the hunt?
Senior analysts rather than the tier-one queue. Triage rewards speed and consistency; hunting rewards patience and knowing what normal looks like on your specific estate. It is a fair question to ask any provider, and worth asking about the people who will actually be assigned rather than about the team in general.
What is in a hunt report?
The hypothesis, why it was chosen, the data queried, what was ruled out, anything found, and what changed as a result — new detections written, visibility gaps identified, coverage added. Including for the hunts that found nothing, since those are the majority and their output is the point. Redacted samples are available before you commit.
How is this priced?
By hunt cadence and scope rather than by device or user count, because the work is analyst time rather than telemetry volume. What drives it is how often, across how much of the estate, against how broad a technique catalogue, and whether we are working in your platform or ours.
Next step
Start with one hunt, not a programme
Tell us what you collect and what you would least like to find. We will propose a hypothesis, tell you honestly whether your telemetry can answer it, and run it as a bounded exercise. If the answer is that you cannot see the thing you are worried about, that is the finding — and it is worth more than a clean report.