Threat Hunting Is Not the Same Thing as Waiting for Alerts

The alert eventually fired. Ninety-three days after the initial compromise, a SIEM rule matched a pattern the threat actor had been using for two weeks, in a technique they had rotated to after their original tooling ran undetected for over two months. The IR team worked the incident, contained the attacker, and recovered. The post-incident timeline showed four separate indicators that would have surfaced the intrusion weeks earlier, if anyone had been looking for them rather than waiting to be told.

Monitoring catches what it was built to catch. Threat hunting looks for what monitoring was not built to look for. These are different activities, and conflating them is one of the quieter ways security programs underperform.

What Threat Hunting Actually Is

Threat hunting is an active, hypothesis-driven investigation into your environment, conducted on the assumption that a motivated attacker may already be present and operating below the detection threshold of your existing controls.

Note what is not in that sentence: "in response to an alert."

Alert-driven investigation is reactive. Something triggered. You go find out what. This is the work of security operations, and it is important and necessary. Threat hunting is different in premise. The hunter starts from a question ("If an adversary using technique X were operating in our environment, what evidence would that leave?") and goes looking for the answer, whether or not anything has triggered.

The distinction matters because detection coverage is never complete. Every SIEM rule was written after the technique was understood. Every behavioral model was trained on historical data. Every alert has a threshold below which it does not fire. Sophisticated attackers know this and operate in the gaps. Threat hunting is the practice of closing those gaps on purpose, rather than waiting for an incident to show you where they were.

Why Monitoring and Hunting Are Different Jobs

Security operations monitoring is built for volume and consistency. The job is to process a high number of alerts, correctly triage them, and escalate the real ones. The metrics are response times, false positive rates, and detection coverage.

Hunting has different success criteria and requires different skills. A hunter needs to understand adversary tradecraft at a level that lets them form realistic hypotheses about what an attacker in their specific environment would do. They need to be comfortable with ambiguous data, with spending two days following a thread that turns out to be nothing, and with forming and discarding theories quickly. They need access to raw data, not just alerts.

The organizations that run effective threat hunting programs have separated this work from the alert queue. Hunters who are also responsible for processing daily alerts never actually hunt, because the queue always wins. The work that produces alerts absorbs the work that supplements them.

Building a Hunting Hypothesis

The most common failure mode in fledgling hunting programs is the absence of a hypothesis. The analyst opens their data platform, looks around, and hopes something interesting reveals itself. This is not hunting. It is browsing.

A hunting hypothesis starts with threat intelligence. What adversary groups are targeting your sector this quarter? What techniques are they using? What did a recent major incident in your industry involve? MITRE ATT&CK provides a framework of documented adversary techniques that translates directly into hunting queries. Pick a technique relevant to your threat profile, form a specific hypothesis about how evidence of that technique would appear in your data, and go look.

A hypothesis that works: "An adversary using Kerberoasting would generate unusual service ticket requests from accounts with access to high-value SPNs. Specifically, I expect to see a spike in TGS-REQ events for service accounts with weak password policies, originating from workstations rather than service hosts."

A hypothesis that does not work: "Let me look at authentication logs and see if anything looks weird."

The first one tells you exactly what data to query, what baseline to compare against, and what a positive result looks like. The second one produces noise until the analyst gets tired and closes the ticket.

What Hunters Actually Look For

The techniques that tend to be most productive depend on the environment and the hypothesis, but a few categories surface valuable results with enough regularity to be worth understanding.

Living-off-the-land techniques are a consistent hunting target. When attackers avoid custom malware and use legitimate system tools instead (PowerShell, WMI, certutil, msiexec), they blend into normal administrative activity. But the specific combinations of parent process, command-line arguments, and network connections that legitimate administrators actually produce are narrower than they appear. PowerShell spawned from an Office document has a very small population of legitimate explanations.

Unusual parent-child process relationships are a related signal. cmd.exe spawned by Word is not normal operation. mshta.exe making an outbound connection is not normal operation. These do not always produce alerts because the individual events look unremarkable in isolation. As a relationship, they narrow the population of benign explanations considerably.

Beaconing patterns in network traffic are harder to detect with alert rules but tractable with statistical analysis. An endpoint that makes a connection to an external host at regular intervals, even at intervals designed to look human-like, has a statistical signature that is distinguishable from irregular human browsing at scale.

Credential access activity is a third category worth hunting regularly. Kerberoasting, AS-REP Roasting, and NTLM relay attacks all leave traces in authentication logs that fall below alert thresholds in many environments. Looking at the baseline of TGS requests or NTLM authentications and identifying deviations from that baseline is more reliable than waiting for a rule to fire.

Why Hunting Programs Fail

The structural failure is treating threat hunting as an event rather than a program. Organizations run a hunt during a slow week after a tabletop exercise identified it as a gap, produce some results, write it up, and return to the normal alert queue. The dwell time that gets detected is the dwell time from the two-week window the hunt happened to cover. The ninety-day intrusion that preceded and followed that window remains invisible.

Effective hunting runs on a cadence. Not quarterly. Monthly at minimum for the highest-priority hypotheses, with the cadence adjusted based on your threat profile and what recent intelligence suggests is active. The adversary operating in your environment does not take breaks because your hunting program is between cycles.

The other failure is not following through. A hunter who identifies something interesting and escalates it into an informal note that no one acts on has not reduced risk. The bridge between a hunting finding and a remediated risk requires the same ownership and tracking structure as any other security finding. Without it, hunting produces interesting data and no outcomes.

The Value of Finding Nothing

A hunt that returns negative results is not wasted time. A well-formed hypothesis that finds no evidence of a specific technique in your environment gives you something: bounded confidence that the technique is either not present or not leaving the expected traces, which is itself information about your detection coverage.

The hunt that finds something you would otherwise have missed for another two months is the reason the work exists. Ninety-three days of dwell time is the version of that story where nobody was hunting. Build the program that finds it earlier. The alert queue will tell you what your detections caught. Hunting tells you what they did not.