Threat Hunting for Beginners: Finding What Alerts Miss

TL;DR

Threat hunting is the proactive practice of searching through networks and datasets to find adversaries that automated detection tools miss. Research from the SANS Institute shows that organizations with dedicated threat hunting programs detect breaches 2.5 times faster than those relying solely on alerts. This guide covers hypothesis-driven methodology, the MITRE ATT&CK framework as a hunting map, essential data sources like EDR telemetry and DNS logs, and practical tools including Elastic, Splunk, and Velociraptor.

The SIEM dashboard showed green across every panel. No critical alerts. No high severity events. Nothing that demanded attention. Inside that same network, an advanced persistent threat group had maintained access for six months. They had compromised a domain controller, exfiltrated 14 gigabytes of intellectual property, and established three separate persistence mechanisms on endpoints across two continents. Every action they took fell below the detection thresholds the security team had configured. Every tool worked exactly as designed. And every tool missed them completely.

It was a threat hunter who found them. Not through an alert. Not through a signature match. Through a hypothesis: "If an adversary had compromised our environment, where would they establish persistence, and what would that look like in our telemetry?" That single question, asked by an analyst who refused to trust silence as evidence of safety, unraveled six months of undetected espionage.

This is the core promise of threat hunting. You stop waiting for tools to tell you something is wrong. You go looking.

Reactive vs. Proactive: Why Alerts Are Not Enough

Traditional security operations centers run on a reactive model. Detection tools fire alerts. Analysts triage them. The cycle repeats. This model works for known threats, the attacks that match existing signatures and rules. It fails against adversaries who study your detection capabilities and deliberately operate beneath them.

According to CrowdStrike's 2025 Global Threat Report, 75% of intrusions involved hands on keyboard activity that generated minimal automated alerts. Attackers used legitimate credentials, native operating system tools, and trusted administrative utilities. No malware to trigger antivirus. No exploit to match a signature. Just a human sitting at a keyboard, using the same tools your administrators use every day.

Proactive threat hunting inverts the model. Instead of waiting for the machine to say "something is wrong," a human analyst says "let me verify that nothing is wrong." The distinction sounds subtle. In practice, it is the difference between discovering a breach in 8 days versus 21. Mandiant's M-Trends 2025 report documented this exact gap: organizations with structured hunting programs cut median dwell time from 21 days to 8.

The reactive model answers the question: "What did our tools detect?" The proactive model answers: "What might our tools have missed?" Both questions matter. Only one of them catches the adversary who read your detection documentation before launching their campaign.

Hypothesis-Driven Hunting: Starting With a Question

Every effective threat hunt begins with a hypothesis. Not a vague suspicion, but a specific, testable statement about adversary behavior. A hypothesis gives the hunt direction, defines what data to examine, and establishes clear criteria for success or failure.

A weak hypothesis: "Something might be wrong with our network."

A strong hypothesis: "An adversary may be using scheduled tasks on Windows endpoints to maintain persistence, creating tasks that execute encoded PowerShell commands during off hours."

The difference is testability. The strong hypothesis tells you exactly what data source to query (Windows Task Scheduler logs, event ID 4698), what pattern to search for (Base64 encoded commands in task actions), and when to look (execution times between 11 PM and 5 AM). You can prove or disprove it within a defined investigation window.

The Sqrrl framework (now archived, its methodology remains foundational) identifies three sources for hypothesis generation:

Intelligence-driven hypotheses come from threat intelligence reports. When a new APT campaign is documented, you ask: "Could this group have targeted us using these techniques?" You then hunt for the specific indicators and behaviors described in the report.

Situational hypotheses come from your own environment. A new cloud migration, a recent acquisition, or an unusual spike in outbound DNS traffic can all generate hunting questions. These hunts are unique to your organization and cannot be outsourced to generic detection rules.

Analytics-driven hypotheses come from statistical anomalies in your data. An endpoint that suddenly starts making DNS queries to domains with high entropy names. A service account that authenticated from a workstation for the first time in six months. A process that reads files from 400 directories in under a minute. These anomalies do not trigger alerts, but they warrant investigation.

MITRE ATT&CK as Your Hunting Framework

The MITRE ATT&CK framework is the most widely adopted structure for organizing threat hunting activities. It catalogs over 200 adversary techniques across 14 tactics, from initial access through exfiltration. For threat hunters, ATT&CK serves as both a map and a checklist.

Each ATT&CK technique describes how adversaries accomplish a specific objective. Technique T1053 (Scheduled Task/Job) describes how attackers use operating system task schedulers to execute malicious code at predetermined times. Technique T1071 (Application Layer Protocol) describes how attackers tunnel command and control traffic through HTTP, HTTPS, or DNS to blend with normal network activity. Each entry includes real world examples, detection guidance, and references to specific threat groups that have used the technique.

Here is how ATT&CK translates into a structured hunting workflow:

1. Select a tactic. Start with one of the 14 ATT&CK tactics. Persistence and defense evasion are strong starting points because attackers must use them in nearly every intrusion.

2. Choose specific techniques. Under the Persistence tactic, ATT&CK lists techniques like Boot or Logon Autostart Execution, Create or Modify System Process, and Scheduled Task/Job. Select one based on your intelligence-driven or situational hypothesis.

3. Map to data sources. ATT&CK tells you exactly which data sources reveal each technique. For Scheduled Task/Job, you need Windows Event Log (Event IDs 4698, 4702), process creation logs (Sysmon Event ID 1), and file creation events in task directories.

4. Write detection queries. Translate the technique description into specific queries against your log data. Search for scheduled tasks created by non-standard user accounts, tasks with encoded command arguments, or tasks pointing to executables in temporary directories.

5. Investigate anomalies. Any result that does not match known administrative patterns becomes a lead. Follow each lead by examining surrounding events: what happened on that endpoint before and after the suspicious task was created?

The SANS 2025 Threat Hunting Survey found that 68% of organizations with active hunting programs discovered threats that existing detection tools failed to identify. ATT&CK is the framework that makes this kind of structured discovery repeatable.

Data Sources: Where Adversaries Leave Traces

A threat hunt is only as good as the data available. Without visibility, even the best hypothesis goes untested. Five data sources form the foundation of effective hunting.

EDR Telemetry is the single most valuable source. Endpoint Detection and Response platforms like CrowdStrike Falcon, Microsoft Defender for Endpoint, and SentinelOne record process creation trees, file modifications, registry changes, network connections, and DLL loads at the host level. When an adversary runs cmd.exe to launch powershell.exe to execute an encoded command, EDR captures the entire parent/child relationship chain. This visibility makes it possible to distinguish legitimate administrative activity from adversary tool execution.

DNS Query Logs reveal communication with command and control infrastructure. Attackers frequently use domain generation algorithms (DGAs) to create domains that resolve for only hours before rotating. These domains have high character entropy, unusual TLD patterns, and no historical reputation. Passive DNS logging captures every query from every endpoint, creating a searchable record that outlives the ephemeral domains themselves.

Proxy and Web Gateway Logs capture outbound HTTP/HTTPS traffic metadata. Even when traffic is encrypted, you can analyze destination domains, User-Agent strings, request timing patterns, and data transfer volumes. A workstation that sends exactly 4,096 bytes of data to the same external IP every 60 seconds is exhibiting beaconing behavior consistent with malware command and control.

Authentication Logs from Active Directory and identity providers expose lateral movement. An adversary who compromises one endpoint typically needs to move across the network to reach high value targets like database servers and domain controllers. Each hop requires authentication. Unusual patterns include a single account authenticating to 30 systems within an hour, service accounts logging in interactively, or administrative accounts authenticating from workstations in geographic locations where no administrators are based.

Network Flow Data (NetFlow, sFlow) provides a record of every network conversation: source, destination, ports, protocols, byte counts, and duration. While it lacks payload content, flow data excels at identifying long duration connections, unusual port usage, and large data transfers that signal exfiltration.

The Hunting Workflow: From Hypothesis to Finding

A structured threat hunt follows a repeatable cycle. While individual hunts vary in scope and technique, the workflow remains consistent.

Step 1: Formulate the hypothesis. Define what you are looking for, where you expect to find evidence, and what "normal" looks like in that context. Write it down. A hypothesis you cannot articulate is a hypothesis you cannot test.

Step 2: Identify required data. Map the hypothesis to specific data sources and log types. Verify that the data exists, covers the relevant time period, and is queryable. Discovering a data gap before you start hunting is better than discovering it midway through.

Step 3: Build and run queries. Translate the hypothesis into search queries against your SIEM, EDR platform, or data lake. Start broad to understand the baseline, then progressively narrow to isolate anomalies. For example, begin by counting all scheduled task creation events, then filter for tasks created by non-standard accounts, then examine those with encoded arguments.

Step 4: Analyze results. Evaluate each anomaly against your knowledge of the environment. Not every outlier is malicious. A server that makes 10,000 DNS queries per hour might be a busy web application, not a compromised host. Context transforms data points into intelligence.

Step 5: Document and escalate. Record your findings whether you found a threat or confirmed the environment is clean for the scope you examined. If you discover confirmed malicious activity, escalate to your incident response process. If you discover detection gaps, create new alerts or rules to prevent the same blind spot from persisting.

Step 6: Refine and repeat. Every hunt generates new questions. The scheduled task you investigated was legitimate, but you noticed three service accounts with administrative privileges that nobody on the team recognizes. That becomes the next hypothesis.

Tools of the Trade

You do not need a dedicated threat hunting platform to start. The tools most organizations already deploy for security monitoring double as hunting instruments when used with intention.

Elastic Security (ELK Stack)

The Elastic Stack (Elasticsearch, Logstash, Kibana) is widely deployed for log aggregation and search. For threat hunting, its strengths are flexible querying with KQL (Kibana Query Language), fast full text search across billions of events, and visualization dashboards that reveal patterns.

A sample KQL query hunting for suspicious PowerShell execution:

process.name: "powershell.exe" AND process.args: ("-enc" OR "-encodedcommand" OR "FromBase64String") AND NOT user.name: ("SYSTEM" OR "svc-deploy")

This query finds PowerShell processes launched with encoded commands, excluding known service accounts. Any results warrant immediate investigation because legitimate administrators rarely need to encode their commands.

Splunk

Splunk's Search Processing Language (SPL) is purpose-built for security investigation. Its statistical commands allow hunters to identify outliers across massive datasets.

A sample SPL query hunting for DNS beaconing behavior:

index=dns sourcetype=stream:dns
| stats count dc(query) as unique_queries avg(bytes_out) as avg_bytes by src_ip dest_ip
| where count > 500 AND unique_queries < 10 AND avg_bytes < 512
| sort - count

This query identifies endpoints making many DNS requests to few unique domains with small, consistent payload sizes. Those three characteristics together indicate automated beaconing rather than human browsing behavior.

Velociraptor

Velociraptor is an open source endpoint visibility and forensics tool designed specifically for threat hunting and incident response. Unlike SIEM-based hunting, Velociraptor queries endpoints directly and in real time using VQL (Velociraptor Query Language).

Velociraptor excels at hunts that require endpoint state information: currently loaded DLLs, running processes, open network connections, scheduled tasks, and registry entries. You write a VQL artifact that describes what you are looking for, deploy it to thousands of endpoints simultaneously, and collect results within minutes.

For teams without a commercial EDR platform, Velociraptor provides enterprise scale endpoint hunting at zero licensing cost. It is particularly powerful for hunting persistence mechanisms because it can query the actual state of endpoints rather than relying on historical log events.

Threat Hunting vs. Incident Response: Complementary Disciplines

A common point of confusion is the boundary between threat hunting and incident response. They share tools, techniques, and often the same analysts. The distinction lies in what triggers the activity.

Incident response begins when something triggers: an alert fires, a user reports suspicious activity, or an external party notifies you of a compromise. You know something happened. The work is containment, investigation, and remediation.

Threat hunting begins when nothing has triggered. No alert, no report, no notification. You operate under the assumption that an adversary might be present despite the silence. The work is discovery. You are searching for evidence that a breach has occurred, is occurring, or is being prepared.

The two disciplines feed each other. Hunts that discover threats transition into incident response workflows. Incident response investigations that reveal gaps in detection coverage generate hypotheses for future hunts. The SOC analyst who investigated a phishing incident last month and discovered the organization had no visibility into OAuth token abuse now has a hunting hypothesis for next quarter.

Organizations with mature security programs run both activities continuously. The reactive capability handles the known. The proactive capability searches for the unknown. Neither alone is sufficient.

Building Your First Hunting Program

Starting a threat hunting practice does not require a dedicated team or specialized tools. It requires a deliberate decision to allocate time for proactive investigation.

Begin by dedicating four hours per week to structured hunting. Choose one ATT&CK technique per session. Write the hypothesis. Run the queries. Document the results. Four hours per week across 52 weeks produces 52 documented hunts, a body of evidence that demonstrates both security posture awareness and continuous improvement to auditors, executives, and regulators.

Build a hypothesis backlog. Every threat intelligence report you read, every incident you respond to, every anomaly you notice during routine monitoring can generate a hunting hypothesis. Maintain a prioritized list so you always know what to hunt next.

Measure your program's impact. Track the number of hunts completed, unique ATT&CK techniques covered, confirmed findings, new detection rules created from hunt results, and detection gaps identified. These metrics justify the time investment and guide resource allocation as the program matures.

The SANS Institute's threat hunting maturity model describes five levels from HMM0 (initial, primarily reactive) to HMM4 (leading, with automated hunt workflows integrated into SOC operations). Most organizations start at HMM1. The goal is not to reach HMM4 immediately but to progress steadily by making hunting a consistent, documented practice rather than an occasional exercise.

From Passive Monitoring to Active Discovery

The security industry spent two decades building faster, smarter, more expensive alert machines. They work. They catch most threats. But "most" is not "all," and the threats they miss tend to be the ones that cause catastrophic damage.

Threat hunting closes that gap. It acknowledges a fundamental truth that no detection system is complete and channels that acknowledgment into productive action. The analyst who found the six month APT did not use a tool the rest of the team lacked. She used the same SIEM, the same EDR, the same data everyone else had access to. The difference was a question: "What if something is here that we have not seen?"

That question, asked consistently and investigated methodically, is the entire discipline. Start with one hypothesis. Run one hunt. Document what you find. Then do it again next week. The adversaries are not waiting for your tools to catch up. Neither should you.