Queries Return Rows. Hunts Should Return Paths.

• A query answers “Is it here?” A hunt has to answer “How far did it get?” Only the second answer tells a SOC what to do next.
• A hunt should end in one of two recorded outcomes: a path, or a clean result. A list of matches is an intermediate step.
• A clean result is evidence. Recorded with the technique, the sources checked and the time window, it shows that someone looked. A coverage dashboard shows which rules are switched on. It cannot show that anybody looked.
• When a hunt finds something an alert should have caught, there are three possible reasons, and each needs a different fix: nothing was watching, a tool went quiet, or triage closed the alert.
• Every rule a hunt proposes should be run against the last three months of data before it is enabled. Approving a rule without that answer is a guess.
• A hunt can propose changes. It should not make them. Nothing should change until a person approves it.

Threat hunting starts with a hypothesis. An attacker is using a stolen service account. A technique from last week’s advisory is already in the environment. In most tools, manual or AI-assisted, the hypothesis becomes a search. The search runs against one or more sources and returns the events that matched.

That output answers one question well: is this indicator or behavior here? It does not answer the question the hunt was started for. Fourteen hosts matched. Are any of them connected? Did the activity move from one host to the next? Which accounts did it use? Where did it stop?

Working that out is the hunt. It means pivoting from each match into sources the original query did not cover: identity logs, cloud audit trails, network flows, the alert history for the same hosts. In most tools that step is left to an analyst.

1. Hypothesiswhat to look for
2. Querysearch the sources
3. Rowsevents that matched
4. Analystpivots, by hand

Why does AI-assisted hunting still return rows?

Several agentic SOC platforms now accept a hunt in plain language and run it across connected tools. That removes the query language. It does not always remove the analysis step. Most describe what comes back as findings or matches. The test is what happens after the first match: does the tool keep investigating until the trail ends, or does it hand the matches back?

Does returning paths need a new hunting engine?

No. Morpheus AI pointed its existing investigation engine at hunting, as every agentic SOC vendor did. What matters is what that engine was built to do. An engine built to check one alert, pointed at a hypothesis, returns matches. An engine built to reconstruct an attack, pointed at the same hypothesis, returns the path.

A hunt that returns a path has already done the pivoting. It investigates every match, follows what it finds into the next source, and hands back the connected sequence. If nothing connects, it says so, and it records that it looked. This method is called attack path hunting.

Run the same hypothesis both ways. The first output is a work queue. The second tells the SOC what happened.

What should a hunt hand back?

• The path. The ordered sequence of hosts, accounts, processes and connections the activity touched, and where it ended.
• The evidence. The evidence for each step, with the source it came from.
• What was already known. Alerts that fired, and incidents that were opened or closed along the path.
• The clean result. When nothing connected: the technique, the sources checked, the time window and the verdict.

Why does this investigation belong in hunting and not in triage?

Triage is time-bound. An analyst answers the alert in front of them and moves on: a suspicious binary on one host, a verdict, the next alert. Hunting has nobody waiting. The investigation can keep going as long as the trail does: the same binary on three hosts, the same address, an account reused, a second region. An alert shows one step. An attack is a sequence. The deepest investigation a SOC can run belongs where there is time to finish it.

Most hunts find nothing. That is the normal outcome, and it is useful. A hunt that came back clean confirms that a technique was checked against a set of sources over a period of time. The problem is that the result is rarely kept in a form anyone can query later.

Ask a SOC this question: “Show me every technique you hunted last quarter, against which sources, and what came back clean.” How long would that take your team to assemble?

A coverage dashboard does not answer it either. A coverage dashboard tells you which detection rules are switched on. It does not tell you whether anybody looked for a technique, against which sources, or what they found.

What should a clean result record?

• The technique or hypothesis that was hunted.
• The sources the hunt ran against.
• The time window it covered.
• When it ran, and whether it ran on demand, on a schedule or from threat intelligence.
• The verdict: path found, or came back clean.

Who asks for this record?

CISOs reporting to a board ask for it. So do auditors and cyber-insurance questionnaires that want evidence that hunting happened. Service providers need it for every client: the same record, kept per tenant, is proof of work a client can audit. That is the basis of threat hunting as a service for MSSPs.

Sometimes a hunt finds an intruder that an alert should have caught. The finding matters, and so does the next question: why did nobody catch it? There are three possible answers, and each one needs a different fix.

The third case matters most to any SOC that uses AI triage. A platform that runs both hunting and triage can check its own triage, say plainly that it closed the alert, and propose the correction.

In all three cases the right output is a proposal: the evidence, the reason and the fix. None of them should take effect until a person approves it.

A hunt can propose a new continuous hunt, a coverage fix, a corrected verdict or a new rule. It should not enact any of them. Each proposal should show its evidence, its expected effect and, for rules, what it would have done on past data. Approval stays with the SOC.

1. Hunt findingpath or miss
2. Proposalevidence, effect, test
3. Person approvesor declines
4. Changeonly then

Hunts produce detection rules. A hunt that found something once can usually describe how to find it again, and the next step is to switch that rule on. Before it is enabled, it should be run against the last three months of data to see what it would have done.

Approving a rule without that answer is a guess. Testing on past data is the right bar for any hunting tool that also writes rules. Which vendors publish rule testing today is set out in our comparison of AI threat hunting tools.

• After the first match, does the hunt keep investigating until the trail ends, or does it return the matches?
• Can it show me every technique it hunted last quarter, against which sources, and what came back clean?
• When a hunt finds something an alert should have caught, does it say why, and does it check its own triage?
• Before a new rule is enabled, can it show what the rule would have done on my last three months of data?

Morpheus Threat Hunting is built on the outcomes in this paper.

• Paths. A hunt in Morpheus AI investigates every match, pivots on what it finds, and hands back the connected sequence or a recorded clean result.
• The record. Morpheus Threat Hunting keeps a record of what it hunted, when, against which sources, and what came back clean, and can report it.
• Triage self-check. When a hunt finds something an alert should have caught, Morpheus AI identifies which of the three reasons applies, including its own triage, and proposes the matching fix.
• Rule testing. Morpheus AI can run a proposed rule against the last three months of data before it is switched on.
• Three ways to start a hunt. Hunts run from plain language, from threat intelligence and on a schedule.
• Views. Views of hunting data are built from a sentence, from live data, then shared, scheduled and versioned. Each view states what data it relies on.
• Approval. Nothing changes until a person approves it.