Attack path hunting
Attack path hunting is a form of threat hunting in which the hunt returns the reconstructed sequence of what an attacker did across hosts, accounts, tools and regions, rather than a list of events that matched a query. Each hunt ends in one of two recorded outcomes: a path, or a clean result.
Why paths and not matches
Most threat hunting, manual or AI-assisted, is query-shaped. A hypothesis becomes a search; the search returns rows; an analyst decides whether the rows are connected and how far the activity went. That last step is the hunt, and it is the step most tools leave to people. Attack path hunting moves it into the tool: every match is investigated, every finding is pivoted on, and what comes back is the connected story or a statement that nothing connected.
What a hunt should hand back
- The path: the ordered sequence of hosts, accounts, processes and connections the activity touched, and where it ended
- The evidence for each step, with the source it came from
- What was already known: alerts that fired, incidents that were opened or closed along the path
- The clean result, recorded, when nothing connected: technique, sources checked, time window, verdict
How it differs from threat hunting in a SIEM
SIEM hunting is the search step. It is fast at answering “is this indicator here?” and slow at answering “how far did it get?”, because the second question needs pivots across sources the query did not cover. Attack path hunting starts where the query stops.
How it differs from attack path management
Attack path management (also attack path analysis, exposure management) maps the paths an attacker could take through your misconfigurations, identities and vulnerabilities. It is a posture discipline and works from configuration. Attack path hunting reconstructs the path an attacker did take, and works from telemetry: endpoint, identity, network, cloud and SaaS logs. The two are complementary and are usually run by different teams.
How it differs from query-based AI hunting
Several agentic SOC platforms now accept a hunt in plain language and run it across connected tools. Most describe the result as findings or matches. The test that separates them is what happens after the first match: whether the tool keeps investigating until the trail ends, and whether it records what it checked when the trail does not exist.
The record of clean results
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. An attack path hunting program keeps that record, so the question “show me every technique you hunted last quarter, against which sources, and what came back clean” has an answer.
Testing a rule before it goes live
Hunts produce new detection rules. Before a rule is enabled, it should be run against recent history to see what it would have done: fired twice, or four hundred times; caught the thing that was missed, or buried the team. Prophet Security’s AI Detection Engineer backtests proposed detections this way, and it is the right bar for any hunting tool that also writes rules.
Four questions to ask any AI threat hunting tool
- 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?
Glossary
Morpheus Threat Hunting is a planned Morpheus AI module, targeted for the end of November 2026.