What is threat hunting?
Threat hunting is a proactive, human-led search for signs of an attacker who is already inside the environment and hasn't triggered any alert. Detection tools such as a SIEM, EDR or IDS are reactive: they fire when activity matches a rule or a model. Threat hunting starts from the opposite assumption, that something may have slipped past those tools, and goes looking for it. A hunter forms a hypothesis, searches the available telemetry to prove or disprove it, and records what was found.
How a threat hunt works
- Form a hypothesis. Base it on threat intelligence, a new advisory, a MITRE ATT&CK technique used by groups that target your industry, or something unusual an analyst noticed.
- Identify the data. Decide which logs and telemetry would show the behavior: EDR process events, authentication logs, DNS and proxy logs, NetFlow, cloud audit logs.
- Search and analyze. Query for the behavior, then investigate the hits to separate legitimate activity from malicious.
- Respond to findings. If the hunt finds an intruder, hand it to incident response.
- Improve detection. Turn what worked into a new detection rule, record any visibility gaps, and document the hunt, even when the result is "nothing found."
Hunts are often grouped as hypothesis-driven (based on attacker techniques), intelligence-driven (based on indicators of compromise from a feed or advisory) and analytics-driven (based on departures from a baseline).
Example: hunting for malicious PowerShell
Hypothesis: an attacker is running encoded PowerShell launched from Office documents, ATT&CK technique T1059.001. In an EDR platform that supports Kusto Query Language, the hunt might start like this:
DeviceProcessEvents | where Timestamp > ago(30d) | where FileName =~ "powershell.exe" and ProcessCommandLine contains "-enc" | where InitiatingProcessFileName in~ ("winword.exe", "excel.exe", "outlook.exe")
Word or Excel starting PowerShell with an encoded command is rare in legitimate use. Each hit gets examined: what the decoded command did, which user opened the document, and where the host connected afterward. If the pattern proves reliable, it becomes an automated detection, so the next occurrence raises an alert on its own.
Why threat hunting matters
Attackers who use valid accounts and built-in tools, an approach called living off the land, can stay inside a network for weeks without matching a signature. Hunting shortens that dwell time. It also tests the security program itself: a hunt that can't be completed because DNS logs were never collected exposes a visibility gap before an incident does. Mature teams hunt on a regular schedule and whenever a credible advisory describes techniques relevant to them.
Threat hunting vs. related activities
- Alert triage is reactive: an analyst reviews alerts the tools generated. Hunting looks for what produced no alert.
- Threat intelligence is information about adversaries and their methods. Hunting uses it as an input.
- Vulnerability scanning looks for weaknesses that could be exploited, not for attackers already present.
- Penetration testing is an authorized, simulated attack that looks for exploitable weaknesses. A hunt looks for a real attacker.
Threat hunting on the CompTIA Security+ exam
On SY0-801, threat hunting is part of objective 4.7, within the identification phase of incident response. Wording such as "proactively search," "assume a breach," "look for attackers that evaded existing controls" or "a new advisory describes techniques used against our industry" points to threat hunting. The tempting distractors are SIEM alerting and IDS signatures, which are automated and reactive, vulnerability scans, which look for flaws rather than intruders, and penetration tests, which simulate an attack. When a scenario says an advisory was received and asks for the best next step, hunting for the described techniques in your own logs is usually the answer.