Threat Hunting: How to Find the Attacker Before the Alert Fires

A quiet SIEM feels like good news. No critical alerts, no open incidents, nothing on the dashboard. But "no alerts" only means that nothing matched the rules you already wrote. An attacker who uses valid credentials, built-in admin tools and slow, careful movement can sit inside that silence for days.

Threat hunting is the practice of going to look for that attacker on purpose, before an alert fires. This guide explains what hunting is (and what it is not), how to structure a hunt with a simple framework, which data you need, and how to turn each hunt into something that makes your SOC permanently better.

Why waiting for alerts is not enough

Mandiant's M-Trends 2026 report, based on its incident investigations during 2025, puts the global median dwell time (the time between the start of an intrusion and its detection) at 14 days, up from 11 days the year before. The same report shows how organizations found out:

• 52% of the time they detected the malicious activity internally.
• 34% of the time an external party told them.
• 14% of the time the attackers themselves announced it, usually with a ransom note.

Internal detection is improving, but almost half of the intrusions were still discovered by someone else. Every one of those cases had a window in which the evidence was already in the logs and nobody was looking for it. Hunting exists to shrink that window.

What threat hunting is, and what it is not

Threat hunting is a proactive, human-led search for malicious activity that your existing detections missed. It starts from a question, not from an alert.

It is not the same as:

• Alert triage. Triage reacts to what the tools flagged. Hunting looks for what they did not flag. Both matter; we covered triage in SOC alert fatigue and AI triage.
• Incident response. Response starts once you know something happened. A hunt can end in an incident, but it starts with uncertainty. Your incident response plan should say what happens when a hunt finds something real.
• Searching for IOCs. Sweeping logs for known bad IPs and hashes is useful hygiene, but attackers change those easily. David Bianco's "Pyramid of Pain" makes the point: hashes and IP addresses are trivial for an attacker to change, while their tactics, techniques and procedures (TTPs) are the hardest. Good hunts focus on behavior.

Three kinds of hunts

The PEAK framework (Prepare, Execute, and Act with Knowledge), published by Splunk in 2023, describes three types of hunts. They work well as a shared vocabulary.

Hypothesis-driven

You form a supposition about how an attacker might be operating in your environment, then use data to confirm or refute it. Example: "If someone stole a VPN credential, we would see successful logins for that account from a country where the employee has never worked, followed by access to file shares they do not normally use."

Baseline

You establish what "normal" looks like for a system, user group or data source, then look for deviations. Example: list every process that launches PowerShell on your servers over 30 days, and investigate the rare parents.

Model-assisted

You use machine learning models of known-good or known-malicious behavior and examine what matches or deviates. This needs more data and skill, so most teams start with the first two.

Where good hypotheses come from

A hypothesis should be specific, testable and tied to something that could really hurt you. Good sources:

• Threat intelligence about your sector or region. If a ransomware group is exploiting a VPN product you run, hunt for its known post-exploitation behavior on that VPN and on the hosts behind it. See how threat intelligence changes prioritization.
• MITRE ATT&CK. The ATT&CK Enterprise matrix organizes attacker behavior into tactics (the goal, such as credential access or lateral movement) and techniques (how it is done). Pick a technique relevant to your environment and ask: "If this happened here, what evidence would it leave, and do we collect it?"
• Your own vulnerabilities and exposures. A critical flaw that was exploitable on an internet-facing server for weeks before you patched it is a strong reason to hunt on that server. Patching closes the door; it does not tell you whether someone already walked through it.
• Recent incidents and near misses. If one host was compromised, hunt for the same behavior on its siblings.
• Gaps in detection coverage. Techniques for which you have no rule at all are natural hunting targets.

How to run a hunt in practice

The PEAK phases translate into a routine that a small team can sustain.

1. Prepare

Write the hypothesis in one or two sentences. Define the scope (which systems, which time window), the data sources you need and what result would confirm or refute it. Check that the data actually exists: many hunts end on day one because the logs were never collected or are only kept for a week.

2. Execute

Query the data, pivot on anything unusual and keep notes as you go. Most hunts do not find an attacker. That is normal. A hunt that finds nothing still tells you something: either the behavior is not there, or you cannot see it, and those two answers are very different.

3. Act

This is the phase that most teams skip. Document what you looked for, what you found and what data was missing. Then turn the result into something durable:

• A new detection rule if the behavior can be reliably detected automatically.
• A logging or retention change if you discovered a blind spot.
• An incident if you found real malicious activity.
• A remediation item if the hunt revealed a weakness, such as an over-privileged service account or an exposed management interface.

Every hunt should leave the SOC better than before, even when it finds nothing.

The data you need

You cannot hunt in data you do not have. A practical minimum:

• Endpoint telemetry with process creation and command lines (EDR or OS logging).
• Authentication logs from your identity provider, VPN and critical servers.
• Network metadata: DNS queries, proxy logs and firewall connections.
• Cloud audit logs for the accounts that matter.
• Enough retention to look back further than the median dwell time. If you keep seven days of logs, you cannot investigate a 14-day intrusion.

How to start with a small team

You do not need a dedicated hunting team to begin.

• Reserve a fixed slot, such as half a day every two weeks, and protect it from the alert queue.
• Start with one hypothesis per cycle, chosen from current threat intelligence or a recent vulnerability.
• Keep a simple hunt log: hypothesis, data used, outcome, follow-up actions.
• Measure what hunting produces, not how many hours it took: detections created, blind spots fixed, incidents found.
• Review the log every quarter to see which techniques you have covered and which remain untested.

Frequently asked questions

Is threat hunting only for large companies? No. Large companies hunt more often, but the method scales down. One focused hypothesis every two weeks is a meaningful start for a small SOC.

Can automation or AI replace hunters? Automation and AI can take over much of the repetitive triage work, which frees analysts' time for hunting. The hypothesis, the judgment about what is unusual in your business and the decision to escalate remain human tasks.

How is hunting different from a penetration test? A penetration test plays the attacker to find weaknesses. A hunt assumes an attacker may already be inside and looks for their traces.

How priorIQ.ai helps

SentinelIQ adds an AI triage layer on top of the SIEM or XDR you already run, such as Microsoft Sentinel, Splunk, Elastic, QRadar or Wazuh, so analysts spend less time discarding false positives and more time on proactive work. Its natural-language queries over alerts and its indexed, searchable incident history make it faster to test a hypothesis against what your SOC has already seen. OnGuardIQ tracks exploits and PoCs for the CVEs in your environment, a strong source of hunting hypotheses. And PriorIQ Core closes the loop: when a host is under attack, its vulnerabilities move up the remediation queue. Request a demo.