Lesson 71 — The Hunt Started with a Behaviour, Not an IOC
There was no malicious IP address.
No known bad hash.
No suspicious domain from a threat-intelligence feed.
No alert conveniently telling the SOC where to look.
But an analyst had noticed something during another investigation.
Several users had launched PowerShell shortly after browser activity.
Most of it might be legitimate.
Agent Foskett asked:
“What if we hunt for the behaviour instead of waiting for the attacker to reuse an indicator?”
Hunt the technique, not just the indicator.
Start with a behaviour, turn it into a hypothesis, query the available telemetry and let the evidence determine the next pivot.
Case briefing
Investigation objective
Turn a suspicious behavioural pattern into a clear, testable threat-hunting hypothesis and use endpoint telemetry to identify where else that behaviour occurred.
Investigator's rule
An IOC tells you what was seen before. Behaviour can help you look for what the attacker does next.
Stage 1 — IOC hunting versus behavioural hunting
| Indicator-focused question | Behaviour-focused question |
|---|---|
| Which devices contacted this known IP? | Which devices showed an unusual browser-to-script execution chain? |
| Where did this known hash execute? | Where did downloaded or browser activity lead to suspicious command execution? |
| Who visited this domain? | Which users showed the same execution pattern regardless of destination? |
| Did this exact artefact appear elsewhere? | Did this technique appear elsewhere? |
IOCs are still valuable
Known hashes, domains and IP addresses can provide fast, precise pivots. The limitation is that attacker infrastructure and artefacts can change.
Behaviour adds another dimension
If an attacker changes a domain or payload but repeats a recognisable technique, behavioural telemetry may still expose related activity.
Stage 2 — write the hypothesis before the query
A hypothesis gives the hunt boundaries
Without a hypothesis, hunting can become endless searching for anything unusual. State what behaviour you expect to observe and what evidence would support or weaken the idea.
Do not write the verdict into the hypothesis
Browser-spawned PowerShell is not automatically malicious. The hypothesis identifies a pattern worth testing; context determines whether individual results are benign, suspicious or malicious.
Stage 3 — translate behaviour into telemetry
Can the data answer the question?
A hunt hypothesis is only useful if available telemetry can test it. Identify the relevant data source and understand what it records — and what it does not.
Start broad enough to see context
Avoid over-filtering before you understand the environment. Excessively narrow conditions can remove the variation that makes the behaviour interesting.
Stage 4 — run the first behavioural hunt
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName in~ (
"msedge.exe", "chrome.exe", "firefox.exe"
)
| project Timestamp, DeviceName, AccountName,
FileName, ProcessCommandLine,
InitiatingProcessFileName
| order by Timestamp descThe query finds candidates, not attackers
The result set contains events matching the behaviour you described. Each candidate still needs context before it becomes a finding.
Expect legitimate results
Administrators, developers, support workflows and legitimate software can create unusual-looking process chains. Hunting deliberately enters areas where benign and malicious activity may overlap.
Stage 5 — summarise before chasing every row
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName in~ (
"msedge.exe", "chrome.exe", "firefox.exe"
)
| summarize Events=count(), Devices=dcount(DeviceId)
by ProcessCommandLine
| order by Events ascFrequency helps prioritise
A rare command line may deserve attention, but rarity is not proof of maliciousness. Likewise, common behaviour is not automatically safe.
Look for useful differences
Compare devices, users, command lines, timing and initiating processes. The goal is to identify which candidates deserve a deeper pivot.
Stage 6 — one result stands out
Prioritise with context
The finance workstation becomes interesting because the behaviour is unusual for that device and user, not simply because PowerShell exists.
Pivot from behaviour to incident evidence
Review the process tree, nearby file events, network connections, identity activity and related alerts around the candidate timestamp.
Stage 7 — inspect the suspicious candidate
DeviceProcessEvents
| where Timestamp > ago(7d)
| where DeviceName =~ "FIN-WS-083"
| project Timestamp, AccountName, FileName,
ProcessCommandLine,
InitiatingProcessFileName
| order by Timestamp ascContext changes meaning
The broader process timeline may show whether the candidate followed a download, administrative action or another legitimate workflow.
Keep the original hypothesis visible
Deep investigation can pull the analyst into a single device. Record the candidate, then return to the environmental hunt so the original question is still answered.
Stage 8 — refine without overfitting
Improve discrimination
Add conditions because evidence shows they help separate useful candidates from noise — not merely because they reproduce one known event perfectly.
Document exclusions
If known legitimate workflows are excluded, record why. An unexplained exclusion can hide future malicious activity or make the hunt difficult for another analyst to review.
Stage 9 — decide what the hunt proved
| Finding | Defensible conclusion |
|---|---|
| 23 matching events | The behaviour occurred 23 times in the queried period. |
| 21 explained by known workflows | Most observed matches had identified legitimate context. |
| 1 remains unresolved | Further investigation is required. |
| 1 confirmed malicious | The behavioural hunt identified malicious activity requiring response. |
| No matching events | No matches were observed in the queried telemetry and period — not proof the technique never occurred. |
Do not overstate negative results
A hunt that returns nothing is bounded by its data sources, query logic, retention period and visibility. Record those limits.
Do not overstate positive results
A matching behaviour is evidence for investigation. It does not automatically prove intent, compromise or attribution.
Stage 10 — record the hunt so it can evolve
A hunt should leave something behind
Even before it becomes a detection, a useful hunt can improve understanding of normal behaviour, expose telemetry gaps, create reusable queries and give the SOC new investigative pivots.
Threat hunting is evidence-led curiosity
The analyst begins with a reasoned question, tests it against telemetry and changes direction when the evidence demands it. The goal is not to prove the original idea correct.
Lesson 71 key takeaways
- A threat hunt does not need to begin with a known IOC.
- Behavioural hypotheses help analysts look for techniques that may survive infrastructure changes.
- Write the hypothesis before building the query.
- Define what telemetry can test the hypothesis.
- Query matches are hunting candidates, not automatic malicious verdicts.
- Use environmental context to prioritise unusual candidates.
- Summarisation can reveal rare or interesting patterns.
- Refine hunts without overfitting them to the first suspicious event.
- Document legitimate exclusions and hunt limitations.
- Negative findings are bounded evidence, not proof of absence.
- Positive behavioural matches still require investigation.
- A successful hunt should improve future SOC capability.
Module 8 — Threat Hunting: Looking Beyond the Alerts
Lesson 71 started with a behavioural hypothesis rather than an indicator. In Lesson 72, the SOC will take one useful query and discover that the same technique appears across twelve devices.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 8: Threat Hunting: Looking Beyond the Alerts
How do you start a behavioural threat hunt?
Lesson 71 of the Agent Foskett SOC Analyst Academy teaches analysts how to turn suspicious behaviour into a testable threat-hunting hypothesis and investigate it with Microsoft Defender XDR Advanced Hunting.
Threat hunting without a known IOC
Learn how behavioural hunting differs from indicator-based searching, how to translate a hypothesis into endpoint telemetry and KQL, how to triage hunting candidates and how to document findings without overstating the evidence.
