Lesson 77 — The Hunt Found Nothing — Was It Still Useful?
The hypothesis was reasonable.
The query worked.
The telemetry was available.
The scope was clear.
And the hunt returned... nothing.
No matching devices.
No matching accounts.
No second occurrence.
One analyst sighed.
“Well, that was a waste of time.”
Agent Foskett looked at the empty results.
“Was it? Or did we just learn something?”
No results is still a result.
The value depends on what was searched, where it was searched, how far back the data goes and whether the telemetry could have observed the behaviour.
Case briefing
Investigation objective
Interpret a hunt that returns no additional matches, validate that the negative result is meaningful, document its boundaries and use it to refine incident scope without claiming more than the evidence supports.
Investigator's rule
“We found nothing” is not the same as “nothing happened.”
Stage 1 — define what a negative result actually means
| What you can say | What you cannot automatically say |
|---|---|
| The query returned no matching events. | The behaviour never occurred. |
| No additional matches were observed in the selected period. | No other device was affected. |
| The tested telemetry did not show the hunted pattern. | The environment is clean. |
| The result may reduce the currently observed scope. | The incident is fully contained. |
Negative evidence is bounded evidence
A zero-result hunt tells you something about the query, telemetry, entities and period tested. Its value disappears if those boundaries are forgotten.
Language matters
Prefer “no matching activity was identified” over “there was no activity.” The first describes the evidence. The second makes a much broader claim.
Stage 2 — rerun the behavioural hunt
DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName in~ (
"msedge.exe", "chrome.exe", "firefox.exe"
)
| where DeviceName !~ "FIN-WS-204"
| project Timestamp, DeviceId, DeviceName,
AccountName, ProcessCommandLine,
InitiatingProcessFileName
| order by Timestamp ascThe question is intentionally narrow
This hunt asks whether the same broad browser-to-PowerShell relationship appeared on other devices during the available fourteen-day period. It does not test every possible execution technique.
A good negative finding starts with a good question
If the hypothesis is vague, a zero result has little meaning. Define exactly which behaviour you expected to observe and why.
Stage 3 — validate that the query could find a known event
Positive controls matter
If possible, confirm that the hunting logic identifies a known example of the behaviour. A query that cannot find the event that inspired it should not be trusted when it returns zero elsewhere.
Check syntax and assumptions
A misspelled process name, wrong field, overly strict filter or incorrect time window can manufacture an empty result. Validate the logic before interpreting the absence.
Stage 4 — ask whether the telemetry could observe the behaviour
| Coverage question | Why it matters |
|---|---|
| Were the relevant devices onboarded? | An unmanaged or unonboarded device cannot contribute expected endpoint telemetry. |
| Was telemetry available during the full period? | Collection interruptions can create apparent absence. |
| Does retention cover the suspected attack window? | Older activity may simply no longer be queryable. |
| Is this the right data source? | The behaviour may exist in identity, email, cloud or network telemetry instead. |
| Could the attacker use a different technique? | A behavioural variation may evade an overly specific hunt. |
Visibility determines confidence
A negative result from well-covered endpoint telemetry is more meaningful than the same result across a population where half the devices are not visible.
Absence of telemetry is not negative evidence
If a device produced no data because it was offline, unmanaged or outside retention, you have a visibility gap — not evidence that the behaviour did not occur.
Stage 5 — measure the population you actually searched
DeviceProcessEvents
| where Timestamp > ago(14d)
| summarize FirstObserved=min(Timestamp),
LastObserved=max(Timestamp),
ProcessEvents=count()
by DeviceId, DeviceName
| order by DeviceName ascKnow your observable population
This does not prove continuous sensor health, but it helps establish which devices contributed process telemetry during the hunting period.
Document coverage limitations separately
If expected devices are missing or sparsely represented, record that limitation rather than allowing the zero-result hunt to imply complete environmental coverage.
Stage 6 — broaden the hypothesis carefully
Do not stop at one exact pattern
If the attack objective could be achieved through plausible behavioural variants, test those variants where the telemetry supports them.
Do not broaden until the hunt means nothing
A query for every process on every device will certainly return data but may no longer test the hypothesis. Broaden deliberately, one assumption at a time.
Stage 7 — use another data source
Independent negative findings can reinforce each other
If multiple relevant telemetry sources fail to reveal related activity, the current scope may reasonably narrow — provided each source had adequate visibility for the question being tested.
Do not combine unknowns into certainty
Three incomplete data sources do not automatically equal one complete view. Assess the quality of each negative finding before using them together.
Stage 8 — negative findings can change response decisions
| Finding | Possible effect |
|---|---|
| No additional behavioural matches with good endpoint coverage | Current observed endpoint scope remains limited. |
| No additional targeted recipients identified | Messaging scope may remain narrow. |
| No related identity activity found | May reduce evidence for broader account compromise. |
| Major telemetry gaps discovered | Confidence decreases; additional evidence sources are needed. |
| Known incident behaviour not found by the hunt query | Query must be fixed before its negative result is useful. |
Negative findings reduce uncertainty
They may support decisions about scope, containment priority and where investigative effort should move next. That is useful operational evidence.
They can also reveal visibility problems
A hunt that finds nothing because expected telemetry is missing has still produced a valuable result: the SOC has discovered a monitoring or data-coverage gap.
Stage 9 — know when to stop expanding the hunt
Stopping is part of good hunting
A hunt should not expand forever simply because certainty is impossible. Once reasonable hypotheses have been tested with adequate data, document the result and move on unless new evidence changes the question.
Keep the hunt repeatable
Save the hypothesis, queries, scope and limitations. If new intelligence arrives tomorrow, another analyst should be able to rerun or extend the work.
Stage 10 — write the negative finding properly
This is useful evidence
The hunt has constrained the current observed scope, tested plausible alternatives and documented what was not found. That is far more useful than simply writing “zero results.”
Sometimes the logs do not find another attacker
And that is fine. The job is not to make every hunt dramatic. The job is to ask a defensible question and follow the evidence wherever it leads.
Lesson 77 key takeaways
- A zero-result hunt is not automatically a failed hunt.
- “No matches identified” is different from “the activity did not occur.”
- Negative findings are bounded by query logic, telemetry and time.
- Validate hunting logic against a known positive example where possible.
- Check onboarding, telemetry availability and retention before trusting absence.
- Missing telemetry is a visibility gap, not negative evidence.
- Test plausible behavioural variants without making the hunt meaningless.
- Independent negative findings can help constrain current scope.
- Multiple weak data sources do not automatically create complete visibility.
- Negative hunts can expose monitoring and telemetry gaps.
- Know when enough reasonable hypotheses have been tested.
- Document scope, assumptions, limitations and exact wording of the finding.
Module 8 — Threat Hunting: Looking Beyond the Alerts
Lesson 77 showed how a hunt that finds no additional activity can still reduce uncertainty and produce defensible evidence. Lesson 78 tackles attacker adaptation: the infrastructure and indicators change, but the underlying behaviour remains recognisable.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 8: Threat Hunting: Looking Beyond the Alerts
Is a threat hunt still useful when it finds nothing?
Lesson 77 of the Agent Foskett SOC Analyst Academy teaches analysts how to interpret zero-result threat hunts as bounded negative evidence, validate query logic and understand telemetry, retention and coverage limitations.
How should SOC analysts document negative threat hunting findings?
Learn how to use positive controls, measure observable device populations, test related hypotheses, constrain incident scope and write defensible negative findings without claiming that an absence of matches proves an absence of malicious activity.
