Threat Hunting Fundamentals: Finding What Alerts Miss

Alerts only catch what you already know how to catch

Alert-driven response is reactive by design. A rule fires, an analyst triages, a ticket closes. That loop is essential, but it only surfaces what someone already wrote a detection for. Everything novel — the technique your tooling has never been tuned to see, the intruder who deliberately blends into normal admin activity — slides past in silence. That silence is the whole problem. Industry breach research consistently puts the mean time to identify an intrusion in the hundreds of days, and attackers dwell that long precisely because nothing alerted.

Threat hunting inverts the loop. Instead of waiting for a signature to fire, a hunter starts from a hypothesis about how an adversary might be operating in the environment right now, then digs through raw telemetry to prove or disprove it. It is proactive, human-led, and it assumes compromise rather than waiting to be told about one. The two disciplines are complementary: hunting finds what alerting missed, and every good hunt should end by making the alerting better.

Framing hunts with MITRE ATT&CK

A hunt without a hypothesis is just staring at logs. MITRE ATT&CK gives you the vocabulary to write good ones. ATT&CK catalogs the tactics an attacker pursues (the goal — persistence, credential access, lateral movement) and the techniques they use to get there (the specific how, such as T1003 OS Credential Dumping), all observed in real intrusions. Framing a hunt against a named technique makes it testable and repeatable instead of open-ended.

A workable hypothesis names three things: the technique, the data that would reveal it, and what "normal" looks like so you can spot the deviation. For example: an adversary is dumping credentials from LSASS memory (T1003.001), so process-access events in EDR should show a non-standard process opening a handle to lsass.exe. That is something you can actually query.

Prioritize by relevance, not by the sheer size of the ATT&CK matrix. Map your recent alert history, the adversaries known to target your industry (the Verizon DBIR is useful here), and your crown-jewel systems, then hunt the techniques most likely to touch them first.

Figure: a hunt is a funnel — a scoped hypothesis turns an unmanageable event volume into the handful of things a human should actually review.

The data you need before you hunt

You cannot hunt telemetry you do not collect. Four sources carry most of the value:

• Endpoint (EDR). Process creation with full command lines, parent-child lineage, module loads, file writes, and per-process network connections. This is the richest source and the one most hunts depend on.
• DNS. Query logs expose command-and-control that hides in plain sight — beaconing domains, algorithmically generated names, and data smuggled out through DNS tunneling. DNS is cheap to collect and disproportionately valuable.
• Authentication. Domain controller and Kerberos logs plus cloud identity sign-in logs reveal credential abuse, impossible-travel, and the account pivots that mark lateral movement.
• Network. Flow data, firewall, and proxy logs show destinations, volumes, and timing that endpoint data alone misses — critical for unmanaged devices that carry no agent.

Centralizing these in a SIEM so they can be queried and correlated together is what turns four disconnected log piles into a huntable dataset. A hunt that has to pivot manually between five consoles dies of friction before it finds anything.

Three hunts worth running

Living-off-the-land

Attackers increasingly skip dropping malware and instead abuse signed, built-in Windows binaries — certutil, rundll32, regsvr32, mshta, bitsadmin, wmic — to download, execute, and persist (ATT&CK T1218). These "LOLBins" appear constantly in legitimate use, so the hunt is about context, not the binary itself. Look for certutil pulling a file from the internet, rundll32 launched with no arguments, mshta reaching out to a remote URL, or PowerShell running encoded or heavily obfuscated command lines. The signal is a trusted tool doing an untrusted thing.

Unusual parent-child processes

Process lineage is one of the highest-yield hunts you can run. A few parent-child pairs are almost always worth investigating:

• winword.exe or excel.exe spawning cmd.exe or powershell.exe — the classic malicious-macro pattern from a phished document.
• w3wp.exe or another web-server process spawning a command shell — a likely web shell.
• Any non-standard process opening a handle to lsass.exe — credential dumping.

Baseline what normal lineage looks like across your fleet first, then hunt the outliers against that baseline.

Beaconing

Command-and-control traffic tends to be periodic: a compromised host phones home at a steady interval, often with random jitter added to disguise the rhythm (ATT&CK T1071). Hunt for repeated connections to a single destination at suspiciously regular intervals, small and consistent payload sizes, long-lived low-volume sessions, or bursts of high-entropy DNS queries to a domain first seen days ago. Beaconing rewards analyzing timing and frequency across many connections, not inspecting any single one.

Turning findings into detections

A hunt that ends with "we found nothing" is not a failure — a disproven hypothesis is a genuine result that narrows your uncertainty. But the most valuable output of any hunt, positive or negative, is a durable improvement to your detection coverage. Every hunt should produce at least one of these:

1. A new detection rule in the SIEM or EDR that codifies the pattern you searched by hand, so it fires automatically next time. Treat these as detection-as-code: version-controlled, tested, and peer-reviewed.
2. A tuning change to an existing rule, cutting the false positives that were burying real signal.
3. A visibility-gap ticket when the hunt reveals you cannot see a technique at all — the fix is a new log source or sensor, not a new rule.
4. A documented baseline of what normal looks like, which makes the next hunt faster and sharper.

Aim high on the Pyramid of Pain. Detections built on attacker behavior survive far longer than those pinned to a specific file hash or IP address the adversary can rotate in seconds.

Staffing the hunt

Hunting is a discipline, not a task squeezed between ticket queues. It needs practitioners who understand both the environment and the adversary, a regular cadence — weekly or monthly hunts against prioritized techniques — and analyst time deliberately protected from interrupt-driven work so someone can actually think. For most organizations, standing up a dedicated hunt team is not realistic. The same retention and cost pressures that make a 24/7 security operations center hard apply doubly to senior hunters, who are among the scarcest people in security.

This is where a managed model earns its keep. A mature SOC runs hunting as a standing program across many client environments, so the hypotheses, baselines, and detections developed hunting one estate immediately sharpen the coverage of all of them. Delivered as part of managed detection and response, hunting stops being an occasional heroic effort and becomes a routine that continuously feeds your detection library.

Start with a hypothesis

The gap between an organization that gets breached quietly and one that catches an intruder early is rarely the tooling — it is whether anyone is actively looking beyond the alerts. Threat hunting is how you close that gap: a structured, ATT&CK-framed, evidence-driven search for the activity your rules were never written to catch, ending each time in a better rule.

If you want hunting run as a continuous program rather than a once-a-year exercise, that is exactly what intSignal builds into its managed detection and response service. When you are ready to find what your alerts are missing, talk to our security team.