Threat Hunting: Proactive vs Reactive Security

The SolarWinds compromise lived in federal agency networks for over nine months — from March 2020 through December 2020 — while every automated detection system stayed silent. No SIEM rule fired. No EDR behavioral engine flagged the SUNBURST backdoor. It was discovered because FireEye's security team noticed an anomalous second device registered for MFA on an employee's account and pulled the thread manually. That single hypothesis — "why is this new device registered?" — unraveled one of the most sophisticated supply chain attacks in history. Automated detection failed. Proactive human analysis succeeded.

Why Now: CISA BOD 26-04 and the Hunting Mandate

CISA's Binding Operational Directive 26-04 takes a risk-based approach to federal cybersecurity that effectively mandates proactive hunting for high-value assets. The directive does not use the word "hunting" explicitly, but its requirements for validating detection coverage, identifying gaps in visibility, and proactively searching for adversary presence in HVA environments describe exactly what hunting programs do.

Beyond federal mandates, the dwell-time data tells the story: IBM's 2025 Cost of a Data Breach report shows mean dwell time for breaches discovered by internal teams (including hunters) at 197 days versus 277 days for breaches discovered via third-party notification. The Change Healthcare breach ($2.4B in costs) and the MOVEit campaign (CVE-2023-34362 exploited across 2,500+ organizations) both featured extended dwell times where proactive hunting could have shortened the blast radius. Every week of undetected presence compounds the cost.

What Threat Hunting Actually Is (And Is Not)

Threat hunting is the proactive, hypothesis-driven search for adversary activity in your environment that existing automated detections have not identified. The operative words:

Proactive — Hunting happens without an alert triggering it. The hunter initiates the search based on intelligence, hypothesis, or environmental change — not in response to a SIEM notification.

Hypothesis-driven — Every hunt starts with a testable theory about how an adversary might operate in your specific environment. "Let me look at DNS logs" is not a hunt. "I hypothesize that an adversary using DNS tunneling for exfiltration would generate queries with entropy above X to domains registered in the last 30 days" is a hunt.

Your environment — Generic ATT&CK technique descriptions are starting points, not hunt plans. Effective hunting requires deep knowledge of what normal looks like in YOUR network, YOUR endpoints, YOUR users. The hunter must distinguish between "unusual" and "malicious" — and that distinction is always environment-specific.

The Contrarian Truth

Threat hunting without a hypothesis is just browsing logs. If your "hunt" does not start with a testable theory about adversary behavior, you are doing ad-hoc incident response, not hunting. Many organizations claim to have hunting programs, but what they actually have is senior analysts periodically looking at dashboards without structure, without documentation, and without measurable outcomes.

A hunt that finds nothing is still a successful hunt — it tested and disproved a hypothesis, which is operationally valuable intelligence. A "hunt" that browses logs without a hypothesis cannot fail because it never defined what success or failure looks like. That is not hunting; it is scrolling.

Hunting Methodologies

Hypothesis-Driven Hunting

The foundational methodology. Start with a specific, testable theory:

Example hypothesis: "An adversary using scheduled tasks for persistence on our Windows domain controllers would create tasks with non-standard naming patterns and execution paths outside of C:\Windows\System32."

Hunt execution:

1. Query Windows Event ID 4698 (scheduled task created) across all domain controllers for the past 60 days
2. Baseline: identify all scheduled tasks created by known management tools (SCCM, monitoring agents, Windows Update)
3. Anomaly identification: flag any task creation where the executable path is not in the established baseline
4. Investigation: for each anomaly, examine the creating user, creation time, task schedule, and the executable itself
5. Conclusion: confirm or deny adversary persistence. If denied, document the hunt. If confirmed, escalate to incident response.

Where hypotheses come from:

• MITRE ATT&CK techniques relevant to your threat model
• Published threat intelligence about campaigns targeting your industry
• Red team findings from your last assessment
• Environmental changes (new cloud workloads, new SaaS tools, merger integrations) that create new attack surface
• Gaps in your detection rule coverage map

Intelligence-Driven Hunting

Start with specific threat intelligence about active campaigns:

Scenario: Intelligence reports indicate that a threat group is targeting defense contractors using spearphishing with ISO file attachments that bypass Mark-of-the-Web. The group establishes persistence via WMI event subscriptions and exfiltrates via DNS-over-HTTPS.

Hunt execution:

1. Review the group's full TTP chain from available reporting
2. Search email logs for ISO attachment delivery in the past 90 days
3. Query WMI event subscription creation events across the enterprise
4. Analyze DNS logs for anomalous HTTPS traffic to known DoH providers from endpoints that should be using internal DNS
5. Cross-correlate: any endpoint that received an ISO AND created a WMI subscription AND generated DoH traffic?

Intelligence-driven hunting is particularly effective after major vulnerability disclosures. When Citrix Bleed (CVE-2023-4966) was announced with evidence of pre-patch exploitation, organizations that hunted for post-exploitation indicators (session hijacking, lateral movement from Citrix infrastructure) found compromises that would not have triggered their existing detections.

Anomaly-Based Hunting

Search for statistical outliers without a specific threat theory:

• Users accessing 10x more files than their 90-day average
• Processes generating DNS queries at rates outside their established baseline
• Systems communicating with external domains that have zero historical prevalence in your environment
• Authentication events at times or from locations with no precedent for that user
• Data transfers at volumes inconsistent with the user's role and history

Anomaly-based hunting does not require specific intelligence but demands deep understanding of your environment's baselines. Without solid baselines, everything looks anomalous and nothing is actionable.

Prerequisites: What You Need Before You Can Hunt

Hunting against absent data is an exercise in frustration. Before launching a hunting program, verify these foundations:

Centralized, Searchable Data

You need a SIEM or data lake containing logs from across your environment — not just firewall logs and Windows Security events, but process telemetry, DNS queries, authentication events, cloud API calls, email metadata, and network flow data. The hunter must be able to query across these sources in near-real-time or at least within hours.

The SolarWinds hunt succeeded because FireEye had its authentication and MFA enrollment logs centralized and searchable. If those logs had been on a system that nobody queried, the compromise would have continued indefinitely.

Endpoint Telemetry

EDR provides process-level visibility that raw Windows Event Logs cannot match. Process trees, file modifications, registry changes, network connections per-process — this granularity is where hunts find their evidence. Without EDR, hunting for endpoint-based tradecraft (the majority of ATT&CK techniques) is severely constrained.

Skilled Hunters

Hunting requires a different skill set than alert triage. A hunter needs:

• Deep knowledge of operating system internals (how does Windows authentication actually work? What is a normal service creation chain?)
• Understanding of attacker tradecraft (not just ATT&CK technique names, but how techniques actually manifest in telemetry)
• Proficiency in your SIEM's query language (writing complex queries, not just running saved searches)
• Analytical discipline to test hypotheses rigorously rather than pattern-matching on intuition

Dedicated Time

Hunting cannot be a part-time activity squeezed between alert triage tasks. When a hunter is interrupted every 15 minutes to handle an escalation, the deep analytical state required for effective hunting never develops. Allocate dedicated hunting time — minimum one full day per week per hunter, or a rotation where one analyst is "off alerts" for hunting while others handle the queue.

Building a Hunt Cadence

Structure prevents hunting programs from dying of neglect. Establish a cadence:

Frequency	Hunt Type	Time Investment	Example
Weekly	Quick intelligence-driven	4-8 hours	"New CVE-2024-21762 FortiOS exploitation in the wild — hunt for post-exploitation indicators on our FortiGate fleet"
Bi-weekly	Hypothesis-driven (single technique)	8-16 hours	"Hunt for persistence via WMI event subscriptions across all Windows servers"
Monthly	Structured technique coverage	16-32 hours	"Cover the three highest-priority ATT&CK techniques without existing detection rules"
Quarterly	Deep environmental hunt	40+ hours	"Full review of authentication anomalies following Active Directory migration"

Documenting Hunts: The Output That Compounds

Every hunt — successful or not — should produce documentation:

1. Hypothesis — What adversary behavior were you testing for?
2. Data sources — Which logs and telemetry did you query?
3. Methodology — What queries did you run? What filters did you apply? What timeframe?
4. Findings — Positive (adversary activity found), negative (hypothesis disproved), or inconclusive (insufficient data)?
5. Detection gaps identified — Did the hunt reveal visibility gaps that need log source expansion?
6. New detection rules — If the hunt found a pattern worth monitoring continuously, write a SIGMA rule or vendor-native detection for it
7. Recommendations — Visibility improvements, configuration changes, or additional hunts triggered by this one

This documentation has three audiences: future hunters (who can learn from your methodology), detection engineers (who can automate your findings into rules), and auditors (who need evidence of proactive security activities for compliance frameworks).

Feeding Hunt Findings Back Into Detection

A hunt that finds something interesting but does not produce a detection rule has wasted half its value. The hunting-to-detection pipeline:

1. Hunt discovers a pattern — e.g., adversary persistence via scheduled tasks using non-standard paths
2. Analyst documents the indicators — specific event IDs, field values, and logic that distinguish malicious from legitimate
3. Detection engineer writes a rule — SIGMA format for portability, deployed to the SIEM
4. Rule enters production — with documented false-positive expectations and tuning guidance
5. Future hunts validate the rule — periodic checks that the automated detection still catches the behavior

This cycle — hunt, find, document, automate, validate — is how organizations systematically close detection gaps. Each hunt iteration makes the next hunt more productive because the automated layer covers more ground, freeing hunters to explore novel territory.

Measuring Hunting Effectiveness

Hunting programs need metrics to justify their resource allocation and demonstrate improvement:

Metric	What It Measures	Target
Hunts completed per quarter	Program throughput	12-24 (varies by team size)
True positives discovered	Effectiveness — threats found that automation missed	1-3 per quarter is good
Detection rules created from hunts	Value conversion — hunts that strengthen automated coverage	3-5 per quarter
Mean dwell time reduction	Impact — are breaches being found faster?	Trending downward year-over-year
ATT&CK techniques hunted	Coverage breadth — are you diversifying?	> 20 techniques per year
Data visibility gaps identified	Environmental improvement — are you finding blind spots?	Track and trend toward zero
Hunt-triggered incidents vs alert-triggered	Hunting's unique contribution	Higher ratio = higher program value

A hunting program that never finds anything is either hunting in the wrong places or your environment is genuinely clean (unlikely). A program that finds something every hunt may be setting the bar too low — easy finds suggest that detection engineering should have caught these first.

The Relationship Between Hunting and Detection Engineering

Hunting and detection engineering are complementary, not competing:

• Detection engineering builds the automated layer — rules that fire 24/7 without human intervention
• Threat hunting tests what the automated layer misses — probing for gaps, novel tradecraft, and environmental blind spots
• Detection engineering converts hunt findings into automated rules — closing the gaps that hunts reveal
• Threat hunting validates that detection rules actually work — confirming through hunting that deployed rules catch the behavior they target

Organizations that invest in hunting but not detection engineering rediscover the same threats repeatedly. Organizations that invest in detection engineering but not hunting accumulate coverage gaps until a sophisticated adversary exploits them. The SolarWinds compromise persisted because no detection rule covered the specific anomaly that gave it away — but a human pulling the thread found it.

Key Takeaways

• Threat hunting is proactive, hypothesis-driven searching for adversary activity that automated detections missed — not browsing logs without structure
• Every hunt starts with a testable theory; a hunt without a hypothesis is ad-hoc incident response with a better job title
• Prerequisites are non-negotiable: centralized searchable data, endpoint telemetry, skilled analysts, and dedicated (not spare) time
• Hunt findings must feed back into detection engineering — a discovery that does not produce an automated rule wastes half its value
• Documentation compounds: each hunt builds institutional knowledge for future hunters, detection engineers, and compliance evidence
• Anomaly-based hunting without solid behavioral baselines generates noise, not intelligence

Frequently Asked Questions

How many dedicated threat hunters does a mid-size organization need?

For an organization with 500-2,000 endpoints and a mature SIEM deployment: start with one dedicated hunter who spends 60-80% of their time on hunting (the remainder on detection engineering and mentoring). This supports a bi-weekly hunt cadence. Scale to 2-3 hunters when your program matures and hunt findings consistently produce detection rules that strengthen your automated layer. Below 500 endpoints, hunting is typically combined with senior SOC analyst responsibilities rather than a standalone role.

Can threat hunting be outsourced?

Partially. External hunting services bring fresh perspectives and specialized expertise (especially for advanced persistent threats), but they lack the deep environmental context that makes internal hunting effective. The most effective model is external hunters conducting quarterly deep hunts alongside internal analysts who hunt weekly with environmental knowledge. External hunters find novel tradecraft; internal hunters find the subtle anomalies that only make sense in context.

What tools does a threat hunter need beyond a SIEM?

At minimum: SIEM with ad-hoc query capability (not just saved searches), EDR console with raw telemetry access, threat intelligence platform for TTP research, a notebook for documenting hypotheses and findings (Jupyter, Obsidian, or similar), and ATT&CK Navigator for coverage mapping. Advanced teams add: network metadata (Zeek/Suricata), memory forensics tools (Volatility), and sandboxing capability for artifact analysis.

How do you distinguish a successful null hunt from a wasted effort?

A successful null hunt produces three artifacts: (1) documented hypothesis with rationale, (2) query methodology that future hunters can reuse, and (3) a confidence statement — "we can assert with high confidence that technique X was not present in our environment between dates Y and Z using data sources A, B, C." A wasted effort produces none of these. If you cannot explain what you searched for, where, and why you are confident in the negative finding, you browsed logs — you did not hunt.

Should threat hunting findings go into POA&Ms?

Detection gaps identified through hunting — "we discovered we have no visibility into technique X because log source Y is not collected" — absolutely belong in your POA&M as risk-accepted gaps with remediation timelines. Actual compromises discovered through hunting follow your incident response process, not your POA&M process. The line is clear: gaps in capability are POA&M items; active incidents are IR actions.

How Advisedly Helps

Advisedly provides the centralized data platform and ATT&CK coverage mapping that threat hunting requires — combining SIEM telemetry, vulnerability intelligence, and detection coverage analysis into a searchable environment where hunt findings feed directly into detection engineering and compliance evidence, closing the loop between proactive discovery and automated protection. Contact begin@advisedly.ai

<!-- LI hook: SolarWinds lived in networks 9 months. Every detection system missed it. A hunter found it. -->