Lesson 72 — One Query Found the Same Technique on Twelve Devices
Yesterday's hunt found one suspicious behaviour.
Browser activity followed by PowerShell execution.
So the analyst widened the query across the environment.
The result came back.
Twelve devices.
For a moment, the SOC room became very quiet.
Twelve compromised devices?
Twelve users affected?
A widespread attack?
Agent Foskett looked at the result count and asked:
“Does the query say twelve devices are compromised — or does it say twelve devices matched the query?”
Twelve matches are twelve questions.
Group the behaviour, compare context, identify clusters and turn a large result set into defensible scope.
Case briefing
Investigation objective
Scope one behavioural hunting pattern across the environment, reduce duplicate noise, identify meaningful clusters and determine which matching devices require deeper investigation.
Investigator's rule
A query result is scope for analysis — not scope for compromise.
Stage 1 — count devices before counting incidents
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName in~ (
"msedge.exe", "chrome.exe", "firefox.exe"
)
| summarize Events=count(),
FirstSeen=min(Timestamp),
LastSeen=max(Timestamp)
by DeviceId, DeviceName
| order by Events descWhy summarise by device?
Hundreds of matching process events can come from a small number of endpoints. Grouping first gives the analyst an environmental view before individual event rows dominate the investigation.
Preserve stable identifiers
Where available, keep DeviceId alongside DeviceName. Names can change or be reused; stable identifiers help preserve entity context during investigation.
Stage 2 — twelve devices do not mean twelve equal leads
| Group | Devices | Initial context |
|---|---|---|
| Development | 4 | PowerShell frequently used as part of expected workflows. |
| IT administration | 3 | Support activity likely, but commands still need validation. |
| Finance workstations | 3 | Behaviour unusual for these users and devices. |
| Shared kiosk | 1 | Unexpected scripting activity. |
| Build server | 1 | Automation may explain repeated execution. |
Context changes priority
The same technical behaviour can carry very different investigative weight on a developer workstation, an administrator device, a finance workstation or a kiosk.
Do not clear by job title alone
Administrators legitimately use PowerShell, but attackers do too. Context can lower or raise priority; it should not replace evidence.
Stage 3 — compare the command lines
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 Devices desc, Events descShared commands can reveal clusters
If the same unusual command line appears across several unrelated devices, the investigation changes. The analyst now has a possible common technique or source to explain.
Different commands can reveal benign diversity
If twelve devices match the broad parent-child pattern but each has an unrelated, explainable command, the initial result count may exaggerate the apparent commonality.
Stage 4 — a cluster appears
Similarity plus timing matters
Three finance devices showing a similar unusual command pattern within a narrow period is more informative than three unrelated matches spread across a week.
Correlation is not yet causation
The cluster strengthens the lead, but the SOC still needs to determine whether a shared business process, software deployment or malicious activity explains it.
Stage 5 — examine the cluster as a timeline
DeviceProcessEvents
| where Timestamp > ago(7d)
| where DeviceName in~ (
"FIN-WS-083", "FIN-WS-091", "FIN-WS-104"
)
| project Timestamp, DeviceName, AccountName,
FileName, ProcessCommandLine,
InitiatingProcessFileName
| order by Timestamp ascPut the devices on one clock
A combined timeline can expose sequencing: one device first, another minutes later, then a third. That pattern may suggest common delivery, propagation or coordinated user activity.
Compare the users too
Ask whether the same account appears across devices, whether different users received the same content or whether a shared service or application links the events.
Stage 6 — pivot beyond the original behaviour
Do not stay trapped in one table
The behaviour was discovered in process telemetry, but scoping may require file, network, identity, messaging or cloud evidence. Follow the entities and timeline.
Look for a common cause
When multiple devices share a technique, ask what connects them: software, user action, campaign, administrative tooling, shared content or attacker infrastructure.
Stage 7 — separate environmental matches from incident scope
| Device set | Classification | Action |
|---|---|---|
| 4 development devices | Behaviour explained by validated workflow | Document context; retain as baseline knowledge. |
| 3 IT devices | Validated support activity | Document and consider safe hunt refinement. |
| 1 build server | Expected automation | Record expected pattern. |
| 1 shared kiosk | Unresolved | Continue investigation. |
| 3 finance devices | Correlated suspicious cluster | Escalate into incident scoping. |
The hunt population can be larger than incident scope
All twelve devices belong in the hunt results. Only evidence-supported affected entities belong in confirmed incident scope.
Keep unresolved separate
The kiosk should not be silently cleared because it does not fit the finance cluster. Record it as unresolved and give it an explicit next action.
Stage 8 — ask whether the hunt needs refinement
Refinement should reduce known noise
Good exclusions remove repeatable, validated behaviour while preserving visibility into similar activity outside that context.
Never create blind spots casually
A broad exclusion such as “ignore all PowerShell from administrator devices” could remove exactly the activity an attacker wants you to miss.
Stage 9 — write a defensible scope statement
Numbers need definitions
If you report “twelve affected devices,” stakeholders may interpret that as confirmed compromise. Use language that distinguishes matching, suspicious, unresolved and confirmed entities.
Preserve the hunt period and logic
Scope statements should make clear when the query ran, what period it covered and what behaviour it actually searched for.
Stage 10 — the hunt creates the next hunt
Do not stop at the first successful query
A useful hunt result often creates better hypotheses. The SOC can now hunt adjacent techniques, earlier activity, alternate execution paths and related entities.
Keep the question connected to risk
Expansion should be deliberate. Every new hunt should explain what uncertainty it is trying to reduce or what attacker behaviour it is trying to expose.
Lesson 72 key takeaways
- A matching device is not automatically a compromised device.
- Summarise behavioural results by entity before investigating every event.
- Preserve useful stable identifiers such as DeviceId alongside device names.
- Context helps prioritise matching behaviour but does not replace evidence.
- Compare command lines, users and timestamps to identify clusters.
- Similarity plus temporal proximity can strengthen a hunting lead.
- Pivot beyond the original telemetry source when the evidence requires it.
- Separate expected, unresolved, suspicious and confirmed entities.
- Refine known noise carefully without creating broad blind spots.
- Write scope statements that define exactly what the numbers mean.
- A successful environmental hunt often creates the next hypothesis.
- Threat hunting is iterative, evidence-led scoping.
Module 8 — Threat Hunting: Looking Beyond the Alerts
Lesson 72 took one behavioural query and scoped it across the environment without confusing matches with compromise. Lesson 73 goes further: the alert queue may be quiet while proactive hunting uncovers related activity the alerts never surfaced.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 8: Threat Hunting: Looking Beyond the Alerts
How do threat hunters scope suspicious behaviour across multiple devices?
Lesson 72 of the Agent Foskett SOC Analyst Academy teaches analysts how to use Microsoft Defender XDR Advanced Hunting and KQL to scope one behavioural technique across an environment, group results by device and identify meaningful clusters.
How do you distinguish threat hunting matches from compromised devices?
Learn how to separate matching behaviour from confirmed incident scope, compare commands and timelines, validate expected workflows, investigate unresolved devices and write defensible environmental scope statements.
