Lesson 79 — The Hunt Needs Another Data Source
The endpoint hunt looked convincing.
A suspicious PowerShell process had executed.
The command suggested that content had been retrieved.
But there was a problem.
The analyst wanted to know:
“Which user originally received the link?”
They kept searching endpoint telemetry.
Different query.
More filters.
Another join.
Still no answer.
Agent Foskett looked at the question again.
“Perhaps the query isn't the problem. Perhaps we're asking the wrong logs.”

The right question may require different telemetry.
Endpoint, identity, email, cloud and network evidence each describe different parts of the incident. Hunting means knowing when to pivot.
Case briefing
Investigation objective
Recognise when a hunting question cannot be answered confidently by the current telemetry, identify the evidence source that can answer it, and correlate the resulting evidence without inventing relationships between datasets.
Investigator's rule
Do not force one data source to answer a question it was never designed to answer.
Stage 1 — separate the question from the query
| Question | Likely evidence source |
|---|---|
| What process executed? | Endpoint process telemetry |
| Which external host did it contact? | Endpoint/network telemetry |
| Who signed in and from where? | Identity sign-in telemetry |
| Was a suspicious message delivered? | Email/message telemetry |
| Which SharePoint files were accessed? | Cloud/SaaS activity telemetry |
| Was the same account active across services? | Correlation across relevant identity and workload sources |
The hunt begins with a question
KQL is not the investigation. It is one way of asking available telemetry a question. If the telemetry cannot observe the event, rewriting the query will not manufacture the missing evidence.
Know what your table represents
Before interpreting a result, understand which activity the data source records, which entities it exposes, how long it is retained and what collection gaps may exist.
Stage 2 — endpoint evidence establishes execution
DeviceProcessEvents
| where Timestamp between (
datetime(2026-09-05 09:10:00) ..
datetime(2026-09-05 09:30:00)
)
| where DeviceName =~ "WIN-WS-331"
| where FileName in~ ("powershell.exe", "pwsh.exe")
| project Timestamp, DeviceId, DeviceName,
AccountName, FileName,
ProcessCommandLine,
InitiatingProcessFileName
| order by Timestamp ascWhat this can establish
The process telemetry can show that PowerShell executed, which account context was recorded, the command line and the initiating process.
What it cannot automatically establish
It does not by itself prove that a particular email delivered a link, that the user clicked that exact message, or who originally sent it.
Stage 3 — recognise the telemetry boundary
A boundary is not a failure
Knowing what the current evidence cannot tell you is part of competent analysis. It prevents unsupported conclusions and points directly to the next investigative step.
Document the unanswered question
Write it explicitly: “Endpoint evidence establishes execution but does not establish delivery mechanism.” Now another analyst understands why a new data source is required.
Stage 4 — pivot to messaging telemetry
EmailUrlInfo
| where Timestamp between (
datetime(2026-09-05 08:30:00) ..
datetime(2026-09-05 09:30:00)
)
| where RecipientEmailAddress =~
"alex@contoso.com"
| project Timestamp, NetworkMessageId,
RecipientEmailAddress,
Url, UrlDomain
| order by Timestamp ascNow the question fits the data
Messaging telemetry can identify URLs associated with messages delivered to the user. The NetworkMessageId provides a useful pivot into related email evidence where available.
Do not claim a click yet
A URL appearing in message telemetry establishes message context, not necessarily user interaction. The analyst still needs evidence appropriate to the click or subsequent navigation question.
Stage 5 — reconstruct the evidence chain
Correlation builds the story
The investigation becomes stronger when independent telemetry sources align around the same user, device and time window.
Correlation is not permission to fill gaps
If the evidence shows message delivery and later execution but does not prove the exact user interaction between them, preserve that uncertainty in the timeline.
Stage 6 — another question, another source
Think in evidence domains
Identity, endpoint, messaging and cloud telemetry are not competing versions of the truth. They are different views of activity that can be correlated when the investigation crosses those boundaries.
Use the smallest necessary pivot
Do not query every table simply because it exists. Pivot when the current question requires evidence the existing source cannot provide.
Stage 7 — distinguish “no evidence” from “no telemetry”
| Situation | Interpretation |
|---|---|
| Relevant source queried with adequate coverage; no matches | A bounded negative finding may be meaningful. |
| Required source is not onboarded or collected | Visibility gap — the question cannot currently be answered. |
| Data retention expired before the suspected event | Historical evidence is unavailable in that source. |
| Current table does not record the required activity | Wrong evidence source for the question. |
| Entity cannot be reliably correlated across sources | Relationship remains uncertain. |
This distinction protects the conclusion
“We searched and found no message” is different from “we do not retain messaging telemetry for that period.” One is a finding; the other is a limitation.
Telemetry gaps are findings too
If the SOC repeatedly cannot answer important questions because a required source is missing, that becomes a visibility and capability issue worth documenting.
Stage 8 — build a source map before a complex hunt
Source mapping saves time
Before writing a complicated hunt, identify the evidence required to prove or disprove the hypothesis and which telemetry should contain it.
It also exposes missing visibility early
If a required source is unavailable, the analyst can change the investigation plan immediately instead of discovering the gap after hours of query tuning.
Stage 9 — decide whether the hunt can continue
| Condition | Action |
|---|---|
| Another available source can answer the question | Pivot and correlate. |
| The source exists but access is restricted | Escalate or involve the appropriate team. |
| The data is outside retention | Seek alternate evidence and document the limitation. |
| The telemetry was never collected | Record a visibility gap; do not invent a conclusion. |
| The question is no longer material to the incident | Document it and prioritise higher-value investigative work. |
Not every gap must be solved immediately
Prioritise according to incident risk and the decision the missing evidence would affect. Hunting should support action, not become an endless search for perfect knowledge.
Know when another team owns the evidence
Some telemetry may require messaging, identity, network, cloud or application specialists. Good SOC work includes knowing when to involve them.
Stage 10 — write the hunting finding
The query was never the real problem
The original endpoint query had already answered the endpoint question. The investigation stalled because the analyst kept asking it for messaging evidence.
Follow the evidence — across the boundary
Sometimes the next clue is not hidden deeper in the same table. It is waiting in another part of the security estate.
Lesson 79 key takeaways
- Start with the investigative question, not the query.
- Understand what each telemetry source can and cannot observe.
- Do not force one table to answer a question outside its evidence domain.
- Endpoint telemetry can establish execution without proving message delivery.
- Messaging telemetry can establish message context without automatically proving a click.
- Correlate sources using defensible entity and timeline relationships.
- Do not fill evidence gaps merely because the surrounding story looks convincing.
- Distinguish a negative finding from unavailable telemetry.
- Missing or expired telemetry is a visibility limitation.
- Map important hunting questions to likely evidence sources before complex hunts.
- Involve other teams when they own the evidence required.
- The investigation should move with the question.
Module 8 — Threat Hunting: Looking Beyond the Alerts
Lesson 79 recognised when the current telemetry could no longer answer the hunting question and pivoted to another evidence source. Lesson 80 finishes Module 8 by turning a successful hunt into something the whole SOC can repeat.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 8: Threat Hunting: Looking Beyond the Alerts
When does a threat hunt need another data source?
Lesson 79 of the Agent Foskett SOC Analyst Academy teaches analysts how to recognise telemetry boundaries and pivot between endpoint, identity, messaging, network and cloud evidence when the current data cannot answer the hunting question.
Correlating security telemetry in Microsoft Defender XDR
Learn how to map investigative questions to evidence sources, distinguish negative findings from visibility gaps, correlate entities and timelines, and avoid unsupported conclusions when telemetry is incomplete.
