Building a Hunt Team the SOC Can Rely On

In-house hunt teams need data they can actually hunt in. Getting hunters involved early in defining collection leads to better hunts, new detections and a more efficient SOC.

Organizations are bringing threat hunting back in-house. In the 2026 SANS Threat Hunting Survey, outsourced hunting fell to 18%, from 30% in 2025 and 37% in 2024. In-house hunting has held at 58% for two years, up from 45% in 2024. SANS argues the shift makes sense because “no third party will ever know an organization’s environment, its soft spots, or the creative corners a threat actor might exploit better than the people who work in it every day.”

Hunting is now its own discipline, with more than 80% of 2026 SANS respondents having hunted for at least two years. But the function still inherits much of its data from a pipeline built mainly for SOC detection and compliance. Most hunts still run across SIEM and EDR platforms, and SOC queue coordination is one of the most common ways teams prioritize which hunt runs next. Hunting has grown up, but with a large dependency on data and tooling from the SOC.

Yet those teams are also drowning in data they struggle to hunt in, because normalization and standards haven’t kept pace with collection across cloud, identity and other sources. For the first time in the survey’s history, data quality or quantity (50%) has overtaken skilled staff (45%) as the top barrier to successful hunting.

What’s the solution? Data normalization and dedicated hunt teams should be a priority, as the authors of the recently released TaHiTI 2.0 intelligence-driven hunt methodology suggest. That means getting hunters involved early to define data requirements, rather than relying on the SOC or incident response teams to meet a hunt team’s different needs.

In our first post on the survey, we looked at why adversaries are prizing stealth over speed, and in the second, at methodology and measurement. In this final post, we look at the relationship between hunters, the SOC and the data they share, and how in-house hunting teams can drive SOC efficiencies.

Hunting is still tethered to the SOC

It’s not surprising that some hunt teams depend on data requirements set for the SOC’s detection needs. Not long ago, many hunting programs followed a traditional SOC monitoring model, with hunts triggered by alerts rather than intelligence. In the 2017 SANS Threat Hunting Survey, 45% of organizations hunted ad hoc and only 31% had a dedicated hunting team.

Rob Lee, then SANS’ digital forensics and incident response curriculum lead, wrote in 2017 that many teams were doing intrusion detection rather than hunting. He also observed that after a breach, teams often discovered their sensors had recorded the adversary, but were too occupied by alerts to notice — another problem with alert-driven hunting.

As Richard Bejtlich, who helped popularize the term threat hunting, described in 2011, hunters test new ways of identifying adversary techniques, and the ones that work become repeatable detections for SOC analysts. The same basic handoff remains today, yet many hunt programs still struggle to follow a structured, documented and repeatable approach that optimizes their output for this critical handoff. In the 2026 survey, formally defined methodologies fell to 37% from 46% in 2025, and 38% of respondents said available headcount drives their choice of methodology. Skilled staff is still the second-biggest barrier to hunting at 45%. While more internal investigative staff is the top planned improvement at 44%, hunting responsibilities are often spread across security functions, with 23% saying their CISOs both contribute to and perform hunts.

As TaHiTI’s authors acknowledge, hunting often sits low on the priority list, so hunts get delayed or cut back in scope. Their answer is a dedicated team or, failing that, time reserved specifically for hunting. When hunting is treated as a nice-to-have, bolted on to red teams, CTI or the SOC, it can fall into a loop of failure. When little hunting time yields no findings, the program becomes hard to justify and it never matures.

Why data is now the top barrier

Data quality or quantity has climbed steadily as a barrier: 34% in 2023, 44% in 2024, 41% in 2025 and 50% this year. Lack of data standards (39%) and tool limitations (37%) sit close behind, according to SANS’ 2026 survey.

The data that matters has also changed in the past decade. In 2017, 77% of respondents said endpoint data was critical for hunting and 73% said the same of access and authentication logs, yet endpoint visibility, including user activity, was a major gap. EDR and XDR have since helped narrow that gap. The blind spots have moved to cloud and identity: teams with workable hunting playbooks told SANS their ceiling is now a data problem, with gaps in cloud logging and identity telemetry cited most often. Those logs typically sit with identity, cloud and SaaS owners outside the security team, and each platform records the same activity differently.

Scott Poley, Senior Threat Hunt Manager at Intel 471, explained the problem on the SANS panel. Most organizations aren’t short on security tools, he said, but different products describe the same activity with different fields, data types and levels of context. Differences in how each source formats time, or which field holds the source versus destination IP address, add caveats to every hunt across those sources.

The sheer volume of data also makes it hard to see gaps. “If you look at your data ingest and see a billion logs coming in, how are you going to know you’re missing the few thousand you really need from specific sources?” Poley asked. SOC analysts battle alert fatigue. Nothing tells a hunter what’s missing.

Shaping the data pipeline for proactive hunts

The SOC’s data pipeline is built for detection, which is its job. But hunting asks different questions of that data, so hunters need a say in what gets collected. TaHiTI 2.0 recommends the hunt team be involved in defining data requirements from the outset, covering which data is needed, where it’s stored and how long it’s kept. As Poley explained, an actual data strategy upfront would help resolve the data quality and normalization issues many teams face today.

TaHiTI builds these checks into every hunt. Before a hunt runs, the team confirms that it has access to each data source, that the data is usable in its current format and that it holds enough detail to test the hypothesis. The methodology also defines a “log specialist” role in the team, focused on data sources, log quality, normalization and data gaps — a role that arguably matters more today, since more data now sits outside the security team with identity, cloud and SaaS owners. Hunting findings should feed discussions with security architecture about missing log sources and incorrect log flows.

In practice, developing a hunt is often how teams find those gaps. Poley describes threat hunting as “doing the incident without the incident.” In an incident, a blind spot is discovered during response. In a hunt, a misconfigured single sign-on proxy that logs its own identity rather than the user’s can be found before the incident.

Close the loop back into the SOC

In our view, hunting works best as a function integrated with CTI but separate to the SOC, which is one of its key stakeholders. The SOC runs detection at scale; hunters look for adversary activity that hasn’t triggered an alert. The result of more proven hunts are handed back to the SOC as detections it can run every day.

In the 2026 survey, turning confirmed findings into detections is the most common way respondents close out a hunt. TaHiTI builds that handoff into its process. Detection teams turn successful hunt queries into new or improved detection rules, and the final step hands new use cases to the security monitoring team.

At maturity, the loop compounds. Poley told the SANS panel that 80% to 90% of the behaviors his team sees in new threat reporting are already generically covered by hunts they’ve built.

This is where in-house hunting makes the biggest difference. Turning that finding into a detection that runs in your SIEM, against your fields and log sources, takes knowledge of your environment and a working relationship with the SOC that inherits it. It also depends on normalization: a hunt query only becomes a reusable detection if the data underneath it is consistent.

How Intel 471 helps in-house hunt teams

Your hunt team needs to learn your environment. You own your handoff to the SOC. But the right hunt content can make logging requirements explicit and gaps visible, giving lean teams a repeatable path from hunt to detection.

Know what data a hunt needs before you run it. Hunt Mode on Verity471 provides more than 800 MITRE-mapped, analyst-validated behavioral hunt packages covering more than 220 adversaries. Every package lists the log source categories it depends on, such as EDR, Windows event logs and Sysmon. That gives hunters a concrete set of data requirements to take to SOC and platform teams, before a gap surfaces halfway through a hunt.

Tell a true negative from a blind spot. When a hunt finds nothing, Emulation and Validation packages let teams confirm whether the behavior would have been seen. The Hunt Management Module then turns empty results that expose visibility gaps into evidence-backed logging recommendations, and captures coverage metrics automatically.

Expertise built into every hunt. All HUNTER packages carry the hypothesis and CTI context, runbook, analyst notes, deployment steps and mitigation recommendations. Less experienced hunters can run validated hunts consistently while learning the behavior behind them, and senior hunters are freed for the environment-specific work only they can do.

A cleaner handoff. The Hunt Management Module captures evidence and reporting so findings are easier to hand to the SOC, incident response and platform owners. The organization still defines where those outputs go and who acts on them.

Intelligence the SOC uses every day. The SOC is a key stakeholder in any hunt program, and Verity471 serves it directly in the SIEM, SOAR and threat intelligence platforms it already runs. Indicators carry a confidence score, an expiry date and a revocation flag, so SOC tools can enrich and triage alerts automatically and retire stale indicators without an analyst. Detection engineers get YARA rule text and malware configuration extracted from live operations, the raw material for behavioral detections that survive infrastructure changes. Exposure findings for external-facing assets, brand and key third parties come backed by underground evidence. As Rob Lee noted in 2017, the right intelligence can reveal that a seemingly benign alert is a major event.

AI around the hunt, not instead of the hunter. Agent471, our native AI analyst on Verity471, helps analysts pivot from new intelligence to the right hunt package faster. MCP471 brings Verity471 intelligence into the AI tools teams already use. Every hunt package is still written and validated by an Intel 471 analyst.

In 2017, hunting lived inside the SOC. In 2026, it’s a discipline of its own, but it still relies on data built for the SOC’s needs. The organizations that get the most from bringing hunting home will run it as its own function, with the SOC as a key partner: hunters help define the data that goes in, and hand back detections the SOC can run every day.

Start behavioral threat hunting today with HUNTER Community

Sign up for HUNTER Community. Building or growing an in-house hunt team? HUNTER Community gives you a 30-day, no-fee trial with access to dozens of hunt packages built by Intel 471’s threat hunters, complete with emulation and validation, so you can see what your own telemetry can and can’t show you.