Threat Hunting Methodology: A Practical Framework for Any Team Size

What Is Threat Hunting — and What It Isn't

Threat hunting is the practice of proactively searching through your environment's data to identify indicators of compromise, attacker behavior, or suspicious patterns that existing detection rules have not surfaced. It is analyst-driven, hypothesis-led, and structured around specific questions about attacker behavior in your environment.

What threat hunting is not:

• Not alert response: If you're working a ticket queue, you're doing alert response, not threat hunting. Hunting is discretionary, proactive time spent outside the alert queue.
• Not penetration testing: Pen testing probes your defenses from the outside. Threat hunting searches your own telemetry for evidence of attacker activity that's already occurring or has already occurred.
• Not threat intelligence consumption: Reading threat reports is research. Threat hunting is applying that research to your own environment's data.
• Not automated detection: Detection rules run continuously and generate alerts. Threat hunting is manual, query-driven investigation that finds things detection rules don't catch.

The Reactive vs Proactive Security Gap

The median attacker dwell time — the period between initial compromise and detection — has remained stubbornly high despite years of detection technology investment. The reason is structural: detection rules are written for known attacker behaviors. When an adversary uses a technique for which no rule exists, they can operate in the environment indefinitely without generating an alert.

This is not a hypothetical problem. Initial access brokers routinely sell access to corporate environments where they've been resident for weeks or months with no detection. Advanced persistent threat actors in critical infrastructure and financial services environments measure dwell time in months, not days. A purely reactive security program cannot catch these actors because they're specifically designed to avoid triggering the thresholds that reactive programs depend on.

Threat hunting closes this gap by operating outside the alert threshold model entirely. A hunter looking for lateral movement doesn't wait for a lateral movement alert — they search the raw authentication and SMB logs directly, looking for patterns consistent with lateral movement that didn't trigger a rule.

Hunting Approach 1: Hypothesis-Driven Hunting

Hypothesis-driven hunting starts with a question: "If technique X were occurring in my environment, what evidence would it leave, and where?" The hunter formulates a specific, testable hypothesis about attacker behavior and then queries the data to confirm or refute it.

A well-formed hunting hypothesis has four components:

• Attacker goal: What is the adversary trying to accomplish? (e.g., gain persistence, move laterally, exfiltrate data)
• Technique: How would they accomplish it? Referenced to MITRE ATT&CK when possible (e.g., T1053.005 — Scheduled Task/Job: Scheduled Task)
• Evidence prediction: What specific log data would this technique generate? (e.g., Event ID 4698 — A scheduled task was created, followed by unusual process execution from the task)
• Data source: Where does this evidence live? (e.g., Windows Security Event Log, Sysmon, EDR telemetry)

Hunting Approach 2: IOC-Based Hunting

IOC-based hunting uses threat intelligence — known malicious indicators from external sources — to search for evidence that those specific indicators have appeared in your environment. When a threat report publishes infrastructure used by a specific threat actor, IOC hunting takes those indicators and runs them against historical log data.

IOC-based hunting is reactive to threat intelligence but proactive relative to your detection rules. A new IOC report might publish infrastructure that has been active for months — your historical logs might contain evidence of that infrastructure even though no alert fired at the time.

The key limitation of IOC hunting is that it only finds what you're looking for. Threat actors who use unique infrastructure per operation (which sophisticated actors consistently do) won't be caught by IOC hunting because their indicators haven't been published yet.

Hunting Approach 3: Anomaly-Based Hunting

Anomaly-based hunting searches for statistical outliers in behavioral data — patterns that deviate from established baselines without necessarily matching known malicious indicators. This approach is particularly effective for detecting insider threats and novel attack techniques.

Examples of anomaly-based hunts:

• Users who accessed significantly more systems than their 30-day baseline during a specific time window
• Service accounts that authenticated to systems they have no record of accessing before
• Network connections from endpoints to destinations in geographic regions those endpoints have no history with
• Processes that made DNS requests to domains with unusually high entropy names (consistent with DGA malware)
• Authentication events succeeding for accounts that have been dormant for 90+ days

Building a Hunting Hypothesis: The MITRE ATT&CK Framework

MITRE ATT&CK structures adversary behavior into tactics (high-level goals like Initial Access, Persistence, Lateral Movement) and techniques (specific methods to accomplish those goals). For threat hunting, ATT&CK provides:

• A structured vocabulary for describing hunting hypotheses
• Data source requirements for each technique — what logs you need to detect it
• Procedure examples showing how specific threat actors have implemented the technique in real attacks
• Detection opportunities — behavioral patterns that distinguish technique use from legitimate activity

The Data Requirements for Effective Threat Hunting

Threat hunting is only as good as the data available to hunt in. Before you can run hunts, you need:

• Process execution logging: Windows Event ID 4688 (process creation) with command line logging enabled, or Sysmon Event ID 1. Without process execution data, you cannot hunt for most execution and persistence techniques.
• Network connection data: Firewall and proxy logs showing source/destination IP, port, protocol, bytes transferred, and DNS resolution data. Zeek/Bro logs from network sensors provide richer metadata.
• Authentication logs: Windows Security Event IDs 4624, 4625, 4648, 4672, 4768, 4769, 4776 covering all login types — local, network, remote, kerberos, NTLM.
• File system events: Process creation of unusual executables, modifications to sensitive directories, creation of new scheduled tasks or services.
• PowerShell logging: Script block logging (Event ID 4104) is essential for hunting PowerShell-based attacks. Module logging and transcription add additional depth.
• Behavioral baselines: Historical context showing what "normal" looks like for each user and system, so anomalies can be identified relative to that baseline rather than in absolute terms.

A Sample Hunt: Detecting Lateral Movement via SMB

Walking through an actual hunting example makes the methodology concrete. Hypothesis: "An attacker with access to one system is moving laterally using pass-the-hash or pass-the-ticket, connecting to other systems via SMB using stolen credentials."

Evidence Prediction

Lateral movement via SMB credential reuse leaves these evidence patterns in Windows Security Event logs:

• Event ID 4624 (Successful Logon) with Logon Type 3 (Network) — many network logons from a single source host to multiple destinations
• Event ID 4624 with Authentication Package = NTLM in an environment that has been migrated to Kerberos (unexpected NTLM use)
• Short session durations — attacker connects, executes commands, disconnects quickly across many targets
• Logons occurring outside the authenticated user's normal working hours
• The source account has no history of accessing the destination systems

Query Logic

The hunt query in pseudo-SQL logic:

Results showing an account making NTLM network logons to 15+ destinations over a 4-hour window warrant immediate investigation. Results showing 2–3 destinations over 8 hours require correlation with user context — is this a sysadmin account doing legitimate maintenance, or an analyst's account being used by an attacker?

Running Threat Hunts with a Small Team

Most threat hunting content assumes a dedicated team with unlimited time. The reality for most organizations is different: 2–3 analysts who need to fit hunting into an existing alert-response workload. Practical adaptations:

• Time-box hunts strictly: Allocate 2–4 hours per hunt. A hunt that runs longer than planned is a hunt that cuts into alert response time. Design hunts to produce initial results within the time box, with a documented continuation plan if the results warrant follow-up.
• Prioritize by threat actor relevance: Use ATT&CK Navigator to identify the 5–10 techniques most relevant to your industry's threat actors. Hunt those first. Don't try to cover the entire ATT&CK matrix — focus coverage where adversary activity is most likely.
• Establish a weekly cadence: Even a 2-hour hunt per week is 100+ hours per year of proactive detection. Schedule it as a fixed calendar commitment with an assigned analyst, not as aspirational "when we have time" activity.
• Reuse queries: The second time you run a hunt for a technique, you're running a query you already wrote. Build a hunt library of tested queries so each new hunt cycle takes less setup time.
• Use AI-assisted hunting: Platforms like ZonForge Sentinel can generate initial hunt queries from natural language descriptions of hunting hypotheses, dramatically reducing the query-writing overhead.

Documenting Hunt Results and Converting Findings into Detection Rules

A hunt that finds nothing is still valuable if it's documented. Documentation should capture: the hypothesis tested, the data sources queried, the query logic used, the time period covered, the findings (including negative findings), and the analyst's assessment of whether the technique was present or absent in the environment.

When a hunt does find evidence of a technique, the outcome should be:

1. Escalate the specific finding as a potential incident for investigation
2. Convert the successful hunt query into a detection rule so future occurrences alert automatically
3. Document the gap that the hunt exposed — what was missing from your detection coverage that allowed this technique to go undetected
4. Update the threat model to reflect the confirmed presence of activity consistent with this technique

This is the mechanism by which threat hunting improves your detection program over time. Every successful hunt closes a coverage gap. The hunt library becomes a detection rule library. Over 12–18 months, a team that hunts regularly ends up with materially better detection coverage than a team that only responds to alerts.

How ZonForge Sentinel Supports Threat Hunting Workflows

ZonForge Sentinel is designed to lower the barrier to threat hunting for teams that don't have a dedicated hunting function:

Conclusion: Threat Hunting Is a Practice, Not a Product

Threat hunting methodology is not something you buy — it's a practice you build. The data infrastructure, the query skills, the hypothesis generation discipline, and the hunt-to-detection feedback loop take time to develop. But teams that invest in it systematically find real threats that their alert-driven programs consistently miss.

Start small and consistent. A weekly 2-hour hunt with a documented hypothesis, tested query, and recorded findings is worth more than an occasional weekend marathon hunt with no process around it. Build the habit first, then optimize the technique.

ZonForge Sentinel provides the data foundation — the normalized event history, behavioral baselines, and query infrastructure — that makes consistent threat hunting practical for teams of any size. The methodology is yours to bring; the data and infrastructure are already there.