Agent Foskett Academy • SOC Analyst Academy • Module 8 • Lesson 79 • Threat Hunting: Looking Beyond the Alerts

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.”

A good hunter knows when the current telemetry has reached its limit — and which data source should answer the next question.
Agent Foskett pivoting between security telemetry sources during a threat hunt
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.

✓ Question
✓ Limit
✓ Pivot
✓ Correlate

Case briefing

KNOWN: 09:18 WIN-WS-331 msedge.exe ↓ powershell.exe ↓ Suspicious command QUESTION: "How did the user reach the malicious content?" ENDPOINT TELEMETRY CAN SHOW: ✓ process execution ✓ command line ✓ parent process ✓ network activity BUT THE NEXT QUESTION IS: "Was a link delivered by email?" THAT QUESTION NEEDS MESSAGING EVIDENCE.

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

QuestionLikely 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

01-endpoint-execution.kql
12345678910111213
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 asc

What 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

ENDPOINT QUESTION: "What executed?" ↓ ANSWER AVAILABLE ENDPOINT QUESTION: "What network activity followed?" ↓ ANSWER MAY BE AVAILABLE ENDPOINT QUESTION: "Which email delivered the original link?" ↓ BOUNDARY REACHED DO NOT: Keep adding endpoint filters until the query looks clever. DO: Pivot to messaging evidence.

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

02-email-url-pivot.kql
123456789101112
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 asc

Now 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

08:57 EMAIL TELEMETRY Message delivered Recipient: alex@contoso.com URL: suspicious-example.test 09:16 BROWSER ACTIVITY / CONTEXT User session active on WIN-WS-331 09:18 ENDPOINT TELEMETRY msedge.exe ↓ powershell.exe 09:19 NETWORK TELEMETRY powershell.exe ↓ external connection ONE INCIDENT MULTIPLE SOURCES EACH SOURCE ANSWERS A DIFFERENT QUESTION.

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

NEW QUESTION: "Did the same account show unexpected sign-in activity before execution?" ENDPOINT: Useful context, but not the best answer. PIVOT: IDENTITY TELEMETRY NEW QUESTION: "Did the account download sensitive cloud files afterward?" PIVOT: CLOUD / SAAS TELEMETRY THE INVESTIGATION MOVES WITH THE QUESTION.

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”

SituationInterpretation
Relevant source queried with adequate coverage; no matchesA bounded negative finding may be meaningful.
Required source is not onboarded or collectedVisibility gap — the question cannot currently be answered.
Data retention expired before the suspected eventHistorical evidence is unavailable in that source.
Current table does not record the required activityWrong evidence source for the question.
Entity cannot be reliably correlated across sourcesRelationship 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

HUNT QUESTION MAP IDENTITY Who authenticated? From where? What changed? ↓ EMAIL What was delivered? To whom? Which URL/message? ↓ ENDPOINT What executed? What spawned it? What changed locally? ↓ NETWORK Where did it connect? Which process connected? ↓ CLOUD What data was accessed, downloaded or shared? THE BEST SOURCE DEPENDS ON THE QUESTION.

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

ConditionAction
Another available source can answer the questionPivot and correlate.
The source exists but access is restrictedEscalate or involve the appropriate team.
The data is outside retentionSeek alternate evidence and document the limitation.
The telemetry was never collectedRecord a visibility gap; do not invent a conclusion.
The question is no longer material to the incidentDocument 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

FINDING: Endpoint telemetry established suspicious PowerShell execution on WIN-WS-331 at approximately 09:18. Endpoint evidence alone could not establish whether the activity originated from a delivered email. Messaging telemetry was therefore reviewed and identified a message containing a relevant URL delivered to alex@contoso.com before the endpoint execution. The combined evidence strengthens the delivery-to-execution hypothesis. However, the reviewed evidence does not by itself prove the exact user interaction that connected the message to execution. LESSON: The hunt progressed when the question moved to the data source capable of answering it.

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.

Next: Lesson 80 — Turn the Successful Hunt into Team Capability

Continue your SOC Analyst training

Module 3 focuses on identity incidents, authentication, MFA, privilege, sessions and application access.

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.