I closed the ticket myself, in about nine minutes. A contractor's virtual private network (VPN) account had logged in from an unexplained IP three weeks earlier; we reset the password and moved on. Then I read Intel 471's Q2 2026 report, which flagged valid-account abuse, living-off-the-land execution, and supply-chain compromise as top trends that quarter.
The closed ticket stopped feeling closed, so I reached for the threat hunting techniques I trust when a detection is not yet automated: a hypothesis, run by hand against old logs. I spent two weeks hunting WinRM lateral movement and found nothing, and that mattered only after I verified which servers were producing the telemetry my query needed.
A null hunt is not proof that nothing happened, only evidence about a defined behavior and time window, and only when you first prove the telemetry could have shown it. What follows is the set of threat hunting techniques we ran, and the coverage check that made the empty result worth more than most of the true positives I have escalated.
In brief:
- A null hunt result supports a conclusion only for the hosts, data sources, and time window where you verified the telemetry could have shown the behavior.
- Our empty Windows Remote Management (WinRM) lateral-movement hunt exposed a log source we thought we had, plus a legacy server segment with no endpoint detection and response (EDR) agent at all.
- Stack counting and baselining did their job, but verifying coverage after the queries came back clean is what gave the null result meaning.
- A hunt's durable output is an improved detection, a validated baseline, or a documented telemetry gap, recorded in the hunt so another hunter can repeat it.
The hypothesis, and why we chased it
One anomalous login and one intel report prompted the hypothesis.
The adversary behavior we thought we would find
Remote services were the behavior we targeted. Valid-account abuse and native administrative tooling can shrink an attacker's malware footprint, so behavioral detections that do not depend on a known malware artifact matter here. Our contractor-account anomaly matched the front half of that pattern, and nobody could prove the back half had not happened.
I scoped the hunt with ABLE from the PEAK framework (Prepare, Execute, and Act with Knowledge): actor (optional), behavior, location, evidence. The hypothesis: if the contractor credentials were used, EDR telemetry on VPN-reachable servers would show wsmprovhost.exe spawning child processes within 30 days. The pattern is a lead, not a verdict, since approved remoting generates it too. Falsifiable and time-bound, it named its data sources up front.
The threat hunting techniques we actually used
We ran the querying first and the statistics second, and the order matters. A targeted query only returns what you already know to name. So I started with the specific artifacts WinRM and PsExec leave behind, then widened to baselining and frequency analysis to catch chains I had not thought to name.
Where we looked, and how we queried it
We queried EDR process-creation telemetry for the fields we would expect from Sysmon Event ID 1: image, parent image, command line, user, and host. We hunted children of wsmprovhost.exe, plus PsExec-related service creation including PSEXESVC.exe and service-executed shell activity. I aimed at ground our automated rules did not yet cover with confidence. Our security information and event management (SIEM) system had nothing watching WinRM session hosts.
I then correlated anything interesting against the network logon events from the VPN address pool, two data sources and one join across 30 days of history. That was the last targeted step before we widened into anomaly work.
Baselining and frequency analysis to surface the anomaly
We ran a frequency analysis of wsmprovhost.exe child command lines and parent-child process pairs, inspecting the least common results first, since rare activity tends to land in that tail. I compared the 30-day hunt window against a 14-day baseline from the same server segment and flagged any pair that had not appeared before. The rarest chains were review leads, not verdicts.
The long tail was a patch-management job doing something ugly but documented and one admin's inventory script, both benign after corroboration. Rare activity needs separate evidence before you can call it malicious, and many environmental anomalies have legitimate business explanations. After two rounds of hypothesis refinement, which our PEAK process treats as normal work within scope, I had zero evidence of the behavior.
Why we found nothing
My empty result left two materially different possibilities: the activity had not occurred during the search window, or the environment had failed to record what my query needed. The first could reduce uncertainty; the second required engineering work.
Absence of evidence, read carefully
A validated negative result does not prove an attack path is inactive; it raises confidence that a specified behavior was not observed in a defined population and time window. A clean query is inconclusive until coverage is verified. Before trusting it, I check reporting and onboarding on every in-scope device, then confirm retention covers the window. My order was backwards: two weeks of behavioral queries before I verified coverage, and I have fixed it since.
So I hunted the telemetry instead of the threat. If those came back empty for active endpoints, I read the silence as a visibility problem, not a finding. I found two: roughly forty legacy servers had no EDR agent, and nobody was collecting Microsoft-Windows-WinRM/Operational, the channel that shows attempted versus successful remote management. On verified hosts I found no evidence of the WinRM pattern; on the legacy segment I had no basis for a conclusion.
Why nothing was still worth the time
The hunt's value split into two deliverables: a blind spot we could now name, and detection changes that outlived the hunt itself.
A validated blind spot beats a false sense of coverage
Coverage assumptions fail silently: an organization can hold enough telemetry to detect a behavior while lacking a working detection that uses it. I have sat in coverage reviews where the MITRE ATT&CK heatmap showed green over remote services. The green square was theoretical visibility with nothing tested behind it, and it covered forty servers that produced not one event. Pull up your own heatmap and ask which hosts sit behind the square you trust most.
Empty hunts are common in any real program, and many of mine come back empty. The good ones still change something.
What the hunt fed back into our detections
The hunt closed with four concrete changes. We onboarded the WinRM operational log to the SIEM and opened an EDR deployment ticket for the legacy segment. We shipped a new detection for wsmprovhost.exe spawning shell processes through our detection-as-code pipeline, and filed a baseline record of normal WinRM activity. The rule was version-controlled, peer-reviewed, and tested against the baseline I had already built.
A mature hunt should produce a durable output: an improved detection, a validated baseline, a telemetry fix, a risk decision, or an incident. PEAK emphasizes turning hunt knowledge into lasting defensive improvement, which is the point David Bianco has made about the framework. The value came from the changes that followed, not from a hunt deck, and closing the distance between showing security and doing it is what our security culture work is about.
How to run hunts that pay off even when they're empty
We made our null result useful by following a repeatable sequence that needs no new tooling, because a behavioral query cannot compensate for missing data. Most of the work is deciding what the result can legitimately say.
- Write the hypothesis with ABLE scoping and make it falsifiable, with named data sources and a time bound.
- Before the first behavioral query, verify telemetry: hunt for the events' existence first, then for the adversary.
- State upfront what a null result will mean, and which hosts and data sources it will and will not speak for.
- Record negative findings in the hunt so another hunter can repeat it later.
- Measure durable outcomes: telemetry gaps closed, detections created or improved, baselines validated. Track hunt-generated incidents separately, and do not treat incident count as the main success metric. The SANS 2025 Threat Hunting Survey found only 51% of organizations formally measured hunt effectiveness, down from 64% the year before.
The write-up from that empty hunt is two pages, and I still hand it to new detection engineers before anything else. Pick a technique your coverage map marks as covered, then test whether the telemetry behind it is actually present, retained, and searchable. Run that hunt before you trust the green square.
Frequently asked questions about threat hunting techniques
What are the main threat hunting techniques?
Our hypothesis-driven hunts test falsifiable claims about adversary behavior, while baseline hunts define normal and search for deviations, and machine learning (ML) can surface leads for model-assisted hunting. Inside these, the workhorse analytical technique is frequency analysis: stack counting a field's distinct values and reviewing the least common first. We also run MITRE ATT&CK-mapped queries against EDR, identity, and network telemetry.
Is a threat hunt that finds nothing a failure?
No. A well-scoped hunt can succeed with an empty result by raising confidence that a specific behavior was not present on verified hosts, or by exposing a visibility gap, and both outputs are actionable. On our team a hunt counts as complete when the investigation can support or reject its hypothesis, consistent with the PEAK completion standard. The null is only meaningful if the hypothesis was falsifiable and your telemetry could have shown the behavior.
How do you turn a hunt into a detection?
Convert the hunt's queries and findings into production detection logic during the close-out phase. Outputs range from manual documentation to fully codified rules, and one hunt can produce several. In detection-as-code environments those rules enter version control and peer review before automated deployment. If the hunt found nothing, the durable output is a baseline record of normal behavior plus tickets for any telemetry gaps.
How do you form a hunting hypothesis?
Start from threat intelligence, your own domain expertise, or an anomaly you have observed. Then scope it with ABLE: name the behavior, the location where it would appear, and the evidence that would confirm or refute it, with the actor optional. A usable hypothesis maps to specific MITRE ATT&CK techniques, names its data sources, and carries a time bound, so it can actually be proven wrong.