Security Operations · Topic 7 of 10
Threat Hunting Methods
Threat hunting for CySA+: hypothesis driven searches, triggers, data sources, methods such as IOC sweeps and baselining, and how hunts improve detection.
- 4 min
- Hunting is proactive and starts from a hypothesis, while alert handling is reactive.
- Common triggers are new intelligence, anomalies, detection gaps and past incidents.
- A good hypothesis is specific, testable and tied to available data.
What it is
Threat hunting is a proactive search for attackers that have evaded existing alerts. Instead of waiting for a tool to fire, the hunter assumes that a breach may already exist and goes looking for evidence.
A hunt starts from a question, not from an alert. The outcome is either a finding to investigate, or proof that a particular behaviour is not present, and both improve security.
How it works
Hunting versus alert handling
| Aspect | Alert triage | Threat hunting |
|---|---|---|
| Starting point | A tool raised an alert | A hypothesis or question |
| Mode | Reactive | Proactive |
| Assumption | Something specific may be wrong | Something may be missed |
| Result | Close, escalate or contain | New findings, detections or confirmed absence |
Triggers
Hunts usually begin from one of these.
- Threat intelligence: a new report about an attack group or campaign that targets your sector.
- Anomalies: an odd pattern in baseline data, such as a rare process, an unusual login hour or a new outbound destination.
- Detection gaps: a technique the current rules do not cover.
- Incident lessons: an earlier incident suggests the same method may exist elsewhere.
- A new vulnerability under active exploitation.
Hypothesis driven hunting
A good hypothesis is specific and testable. For example: "An attacker who has valid credentials may be creating scheduled tasks on servers to stay in place, so look for tasks created outside change windows."
The hunter then decides which data would show it, runs the searches, reviews results and records what was found. If the idea is false, the hunt still shows that the behaviour is absent and which data was missing.
Data sources
- Endpoint telemetry from EDR (Endpoint Detection and Response) tools, including process, file and registry activity.
- Security Information and Event Management (SIEM) logs from authentication, firewalls and proxies.
- Network data: Domain Name System (DNS) logs, flow records and packet captures.
- Cloud audit logs and identity provider logs.
- Threat intelligence and vulnerability data.
Hunting is only as good as the data. If process creation is not logged, a hunt for suspicious processes cannot succeed, which is a finding in itself.
Methods
| Method | Idea |
|---|---|
| Indicator of compromise (IOC) sweep | Search the history for indicators from new intelligence |
| Tactics, techniques and procedures (TTP) based hunt | Look for attacker behaviours, often organised with MITRE ATT&CK techniques |
| Baselining and anomaly search | Compare activity to normal and examine outliers |
| Frequency analysis (stacking) | Count how often values occur and review the rarest, since malware is often uncommon |
| Pivoting | Take one finding and follow its links to related hosts, accounts and files |
MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a catalogue of attacker behaviours that gives hunters a shared vocabulary and a way to measure which techniques are covered.
Question: which hosts ran a script interpreter that was started by an office program?
Data: EDR process creation events, last 30 days
Review: rare parent and child pairs, then check the user, time and command line
Outcomes
A hunt should end with something concrete.
- Confirmed compromise: open an incident and hand over to the response process.
- New detection rule: turn a successful search into an automatic alert.
- Visibility fix: enable missing logging or deploy an agent.
- Hardening: close a weakness that the hunt revealed.
- Documentation: record hypothesis, data, method and result so the hunt can be repeated.
What to remember for the exam
- Hunting is proactive and starts from a hypothesis, while alert handling is reactive.
- Common triggers are new intelligence, anomalies, detection gaps and past incidents.
- A good hypothesis is specific, testable and tied to available data.
- Hunters rely on endpoint, network, identity and cloud data, and missing data limits the hunt.
- IOC sweeps look for known artefacts, and TTP hunts look for behaviours.
- Stacking looks at the least common values because attackers are often rare in the data.
- Successful hunts become new detection rules.
- A hunt that finds nothing is still useful if it is documented.
- A confirmed hunt finding is handed to incident response.
If a question asks which activity proactively looks for undetected threats, choose threat hunting, not vulnerability scanning or alert triage.
Common mistakes
Calling any alert review a hunt. A hunt begins without an alert and tests an idea.
Hunting without data. Without the right logs, a hunt produces false confidence that nothing is there.
Searching only for known indicators. Sweeps find what is already known, while behaviour based hunting can find new activity.
Not recording the work. An undocumented hunt cannot be repeated, measured or turned into a rule.
Treating a negative result as failure. Showing that a behaviour is absent, and that data exists to prove it, has value.
Check yourself
What starts a threat hunt?
A hypothesis or question, often prompted by intelligence, an anomaly or a gap in detection, rather than by an alert.
Why is stacking useful in hunting?
Counting values and reviewing the rarest ones helps find uncommon behaviour that malware often produces.
What should happen after a hunt finds a repeatable malicious pattern?
It should become an automated detection rule, and any real compromise should be passed to incident response.
Topic 7 of 10 in Security Operations
Test yourself on Security Operations
The full CompTIA CySA+ CS0-004 question bank has 654 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by CompTIA. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.