ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Case File • Microsoft Defender XDR • Advanced Hunting • Scope Expansion • KQL

The Defender Alert Named One Device — The Evidence Found Six

The Microsoft Defender alert named one endpoint.

One device.
One detection.
One obvious place to investigate.

Agent Foskett did not stop there.

He extracted the evidence from the alert — the file hash, command line, account, URL and network indicators — and searched across the environment.

The alert named one device. The evidence found six.

Discuss Microsoft SecurityBack to investigations
Agent Foskett expanding a Microsoft Defender XDR alert across multiple endpoints using Advanced Hunting
The Alert Was The Starting Point

An alert tells you where a detection fired. It does not automatically tell you the full scope of the activity. Scope comes from pivoting on the evidence.

✓ One alerted device
✓ Multiple hunting pivots
✓ Six related endpoints

One alert can create a dangerous assumption

The incident opened with a familiar picture: Microsoft Defender XDR had raised an alert against a single device.

It would have been easy to investigate that endpoint, contain it and close the incident.

But the alert represented where the detection logic had produced a result. It did not prove that the behaviour existed nowhere else.

Agent Foskett treated the device as patient zero for the investigation — not necessarily patient zero for the activity.
Alert scopeOne device was named by the detection.
Evidence scopeThe alert contained indicators that could be hunted across the estate.
Incident scopeThe real question was how many other devices shared those indicators.

Start with the alerted device

Agent Foskett first established the endpoint timeline around the detection. DeviceProcessEvents provided the process name, command line, account, hashes and parent-process context that could become hunting pivots.
alerted-device-processes.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
let AlertedDevice = "WS-017";
DeviceProcessEvents
| where Timestamp > ago(7d)
| where DeviceName =~ AlertedDevice
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          SHA256,
          ProcessCommandLine,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

Pivot #1 — hunt the hash everywhere

A file hash is one of the strongest pivots when the same file may have reached multiple endpoints. Instead of searching only the alerted device, Agent Foskett searched DeviceFileEvents across the environment and summarised the devices where the hash appeared.
hash-scope.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
let IndicatorSHA256 = "SHA256-HERE";
DeviceFileEvents
| where Timestamp > ago(30d)
| where SHA256 == IndicatorSHA256
| summarize
    FirstSeen=min(Timestamp),
    LastSeen=max(Timestamp),
    Events=count()
    by DeviceName, FileName, FolderPath
| order by FirstSeen asc

Pivot #2 — the command line can reveal variants

Hashes are powerful, but attackers can change a file and produce a new hash. Behaviour can survive that change. Agent Foskett extracted a distinctive command-line fragment from the alerted process and hunted for the same pattern across other endpoints.
command-line-scope.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
let CommandFragment = "suspicious-fragment";
DeviceProcessEvents
| where Timestamp > ago(30d)
| where ProcessCommandLine has CommandFragment
| summarize
    FirstSeen=min(Timestamp),
    LastSeen=max(Timestamp),
    Executions=count()
    by DeviceName, AccountName, FileName
| order by FirstSeen asc

Pivot #3 — follow the network destination

The alerted process had also communicated externally. Agent Foskett searched DeviceNetworkEvents for the same remote URL, domain or IP address. This can expose devices that contacted the same infrastructure even when their file or process evidence differs.
network-scope.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
let RemoteIndicator = "suspicious.example";
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl has RemoteIndicator
| summarize
    FirstSeen=min(Timestamp),
    LastSeen=max(Timestamp),
    Connections=count()
    by DeviceName,
       InitiatingProcessFileName,
       InitiatingProcessAccountName
| order by FirstSeen asc

Pivot #4 — follow the account

If the same account appears across several endpoints, that may connect otherwise separate events. Agent Foskett used the account as another scope pivot — while remembering that a shared account, administrator or service identity can also create legitimate overlap.
account-scope.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
let Account = "jsmith";
DeviceProcessEvents
| where Timestamp > ago(30d)
| where AccountName =~ Account
| summarize
    FirstSeen=min(Timestamp),
    LastSeen=max(Timestamp),
    Processes=count()
    by DeviceName, FileName
| order by FirstSeen asc

Six devices did not mean six identical infections

The expanded hunt produced evidence across six endpoints, but that did not mean every device had the same level of compromise.

One device had the original alert. Another contained the matching file. Two had matching command-line behaviour. Others contacted the same infrastructure.

Those differences mattered. Scope expansion identifies systems that deserve investigation; it does not automatically assign the same verdict to all of them.
Device 1Original Defender alert and full process evidence.
Devices 2–3Matching file or process indicators requiring validation.
Devices 4–6Related behavioural or network evidence requiring individual investigation.

Build the scope table

Agent Foskett turned the pivots into an investigation matrix. For each device he recorded which indicators were present, the first and last observed timestamps, the account involved and whether follow-on activity existed.

That made the incident easier to reason about than six disconnected hunting results.

The objective was not to collect more telemetry. It was to determine the boundaries of the incident.

What Agent Foskett checked

HashesDid the same file appear on additional endpoints?
Command linesDid the same behaviour appear even when file hashes differed?
URLs and IPsWhich devices communicated with related external infrastructure?
AccountsDid one identity connect activity across multiple devices?
TimelineWhich endpoint showed the earliest evidence?
Follow-on activityDid each device show execution, persistence, credential access or only an isolated indicator?

What the evidence can and cannot prove

A shared hash, URL, IP address or command-line fragment is a hunting lead, not automatically proof that every matching endpoint is compromised.

Shared infrastructure, software deployment, administrator activity and common binaries can create legitimate overlap. Each pivot needs context.

Likewise, the absence of a second Defender alert does not prove another device is clean. Different telemetry, timing, prevention actions and detection conditions can produce different alert outcomes.

Scope expansion finds the systems that require answers.

The lesson

The alert said one device.

Agent Foskett asked whether the evidence agreed.

It didn't.

By pivoting across file, process, network and identity telemetry, the investigation expanded from one endpoint to six systems requiring review.

An alert tells you where to start. Threat hunting tells you how far the incident reaches.
Investigation principle: Never confuse the scope of the alert with the scope of the incident.

Related investigations

Agent Foskett InvestigationsContinue through the complete collection of real-world Microsoft security investigations.KQL Threat HuntingExplore practical hunting techniques across Microsoft Defender XDR and Microsoft Sentinel.SOC Analyst AcademyBuild practical investigation and triage skills across identity, endpoint, email and cloud security.
The alert named one device. The evidence found six.
Start with the detection. Then hunt for the scope.
Continue the Investigation

Final thought

Security products are excellent at telling analysts where something interesting happened.

Investigators still have to determine whether that event is isolated or part of something larger.

Extract the indicators. Pivot across the estate. Compare the timelines. Validate every match.

Follow the evidence. Build the timeline.

The Logs Already Knew! 🔎
Develop IT.. Protect IT.. GEMXIT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The Defender Alert Named One Device — The Evidence Found Six

This Agent Foskett investigation demonstrates how to expand the scope of a Microsoft Defender XDR alert by hunting across multiple endpoints instead of assuming the alerted device represents the entire incident.

Microsoft Defender XDR Threat Hunting With KQL

Use DeviceProcessEvents, DeviceFileEvents and DeviceNetworkEvents to pivot on SHA256 hashes, command-line patterns, remote infrastructure and accounts across an environment.

How To Expand Incident Scope From One Defender Alert

A Defender alert is a starting point. Extract its indicators, hunt them across endpoint telemetry, build a scope table and validate each related device before determining the true boundaries of the incident.