ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Investigation • Microsoft Defender XDR • DeviceProcessEvents • Cross-Device Hunting • Incident Scoping • KQL

The Defender Alert Was Closed — But the Same Command Ran on Three More Devices

The alert had been investigated.

The device had been checked.
The suspicious process was understood.
The alert was closed.

It looked finished.

Agent Foskett copied one fragment of the command line into Advanced Hunting.

The same command had run on three more devices.

Discuss endpoint security Back to investigations
Agent Foskett hunting the same suspicious command across multiple Defender XDR devices
Closing the Alert Is Not Scoping the Incident

An alert tells you where suspicious activity was detected. It does not automatically tell you everywhere the same behaviour occurred.

✓ Reconstruct the original execution
✓ Hunt the command across devices
✓ Scope related process, file and network activity

The original alert looked contained

The first investigation focused on the device named in the Defender alert. That was reasonable for triage, but it answered only one question: what happened on that endpoint? It did not answer whether the same execution existed elsewhere.
One alertThe analyst had a clear device and process to investigate.
One device checkedThe local activity was reviewed and the immediate alert was resolved.
Environment not yet scopedNo hunt had established whether the same behaviour appeared on other endpoints.

Reconstruct the command that triggered the investigation

Start with DeviceProcessEvents on the original device and incident window. Preserve the complete command line, hash, parent process and account context before reducing the behaviour to a hunting indicator.
original-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
  16. 16
  17. 17
let Device = "LAPTOP-042";
let StartTime = datetime(2026-08-26 09:00:00);
let EndTime = datetime(2026-08-26 11:00:00);
DeviceProcessEvents
| where Timestamp between (StartTime .. EndTime)
| where DeviceName =~ Device
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          ProcessCommandLine,
          SHA1,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

Turn the command line into a hunting pivot

A distinctive command-line fragment can be more useful for scoping than the alert title. Search that fragment across DeviceProcessEvents and summarise the executions by device, account, command and hash.
hunt-command-across-devices.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 SuspiciousFragment = "EncodedCommand";
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has SuspiciousFragment
| summarize FirstSeen=min(Timestamp),
            LastSeen=max(Timestamp),
            Executions=count()
    by DeviceName,
       AccountName,
       FileName,
       ProcessCommandLine,
       SHA1
| order by FirstSeen asc

Three more devices appeared

The wider hunt changed the incident. What had looked like a single-device alert was now repeated execution across multiple endpoints. The next task was to determine whether those executions shared the same binary, parent process and surrounding behaviour.
Device 1The endpoint from the original Defender alert.
Devices 2–4The same suspicious command fragment appeared on three additional devices.
Scope changedThe investigation was no longer about closing one alert. It was about explaining repeated execution.

Does the same file hash appear elsewhere?

If the original process has a useful hash, scope it separately. Matching command lines and matching hashes are different pieces of evidence. Together they can strengthen the relationship between executions, while differences may reveal multiple payloads or variants.
scope-process-hash.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
let SuspiciousHash = "PUT_SHA1_HERE";
DeviceProcessEvents
| where Timestamp > ago(30d)
| where SHA1 == SuspiciousHash
| summarize FirstSeen=min(Timestamp),
            LastSeen=max(Timestamp),
            Executions=count(),
            Accounts=make_set(AccountName, 20)
    by DeviceName
| order by FirstSeen asc

Compare the parent process on every device

Repeated command lines do not automatically prove one attack chain. Compare the initiating process and its command line across each affected endpoint. A common parent can reveal a shared delivery mechanism, script, software deployment path or persistence method.
compare-process-context.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 SuspiciousFragment = "EncodedCommand";
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has SuspiciousFragment
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          ProcessCommandLine,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          SHA1
| order by Timestamp asc

Did those processes contact the same destination?

Pivot from the suspicious process hash into DeviceNetworkEvents. Shared remote destinations across several affected devices can provide another strong correlation point and may reveal command-and-control, payload retrieval or follow-on activity.
network-by-process-hash.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 SuspiciousHash = "PUT_SHA1_HERE";
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessSHA1 == SuspiciousHash
| project Timestamp,
          DeviceName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          RemoteUrl,
          RemoteIP,
          RemotePort,
          ActionType
| order by Timestamp asc

Look around the affected devices for related file activity

Once the device set is known, inspect file creation and modification events around the same period. The objective is not to assume every new file is malicious, but to find evidence that helps explain how the suspicious execution reached or changed each endpoint.
affected-device-files.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
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
let SuspiciousFragment = "EncodedCommand";
let AffectedDevices =
    DeviceProcessEvents
    | where Timestamp > ago(7d)
    | where ProcessCommandLine has SuspiciousFragment
    | distinct DeviceId;
DeviceFileEvents
| where Timestamp > ago(7d)
| where DeviceId in (AffectedDevices)
| where ActionType in ("FileCreated", "FileModified")
| project Timestamp,
          DeviceName,
          ActionType,
          FileName,
          FolderPath,
          SHA1,
          InitiatingProcessFileName
| order by Timestamp asc

The alert boundary was not the incident boundary

Defender alerts are valuable starting points, but an analyst still has to establish scope. A detection may surface one device because that execution crossed an alert threshold while related activity elsewhere remains visible only in hunting telemetry.
Alert evidenceIdentified the activity that deserved investigation.
Hunting evidenceRevealed where the same or similar behaviour appeared elsewhere.
Correlation evidenceHashes, parents, files and network destinations helped determine how closely the executions were related.

What the evidence can and cannot prove

The same command fragment on several devices proves repeated matching telemetry. It does not by itself prove that every execution was malicious or originated from the same attacker. Hashes, parent processes, timing, files and network activity provide the context needed to make that determination.
ProvenThe same distinctive command fragment was observed on additional endpoints.
CorrelatedShared process and surrounding telemetry can strengthen the case that the executions belong to one incident.
Do not overclaimA matching string alone is not proof of common malicious intent.

Agent Foskett's investigation mindset

An alert is a clue, not a fence around the investigation. Once suspicious behaviour is understood, turn its strongest characteristics into hunting pivots and ask where else they appear.
Resolve the alertUnderstand what happened on the device that Defender surfaced.
Extract the pivotsUse distinctive commands, hashes, parents and destinations for wider hunting.
Establish the scopeDo not call the incident contained until you know how far the behaviour reached.

Investigation findings

The original Defender alert had been closed after the activity on one endpoint was reviewed. Advanced Hunting showed that the same distinctive command line had executed on three additional devices. Further process, hash, file and network pivots were then used to determine whether those executions formed part of the same incident. The important failure was not closing the first alert. It was treating that closure as proof that the environment had already been scoped.
The alert was realIt correctly surfaced suspicious activity on the original endpoint.
The scope was largerAdvanced Hunting found matching execution on three more devices.
The investigation had to reopenThe evidence now required cross-device scoping rather than single-alert closure.

Related Agent Foskett investigations

Continue with endpoint, process and cross-device investigations.
The Command Line Told a Different StorySee why process arguments can reveal what a familiar executable was really doing. The Process Tree Told the Real StoryFollow parent and child process relationships to reconstruct suspicious execution. Agent Foskett AcademyBuild practical Microsoft security investigation and KQL skills.
The alert was closed. The investigation wasn't finished.
Scope suspicious behaviour across the environment before deciding the incident ends at one device.
Continue the Investigation

Final thought

Closing an alert is an operational action. Scoping an incident is an investigative conclusion. They are not the same thing. Once you understand the suspicious command, process or file that Defender surfaced, use Advanced Hunting to ask the question the alert cannot answer on its own: where else did this happen? One extra query can turn a closed alert into the beginning of the real investigation.
What made the execution distinctive?Extract a reliable hunting pivot from the original alert.
Where else did it happen?Search across the environment rather than remaining on the alerting endpoint.
Is the incident really contained?Answer that only after the wider telemetry has been scoped.
Develop IT. Protect IT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The Defender Alert Was Closed — But the Same Command Ran on Three More Devices

This Agent Foskett investigation explores Microsoft Defender XDR, DeviceProcessEvents, cross-device Advanced Hunting, process hashes, command-line analysis and KQL.

Microsoft Defender XDR Cross-Device Investigation

The investigation starts with a closed Defender alert and uses the suspicious command line as a hunting pivot to discover matching execution on additional endpoints.

Advanced Hunting, DeviceProcessEvents And KQL

Alert closure does not establish incident scope. Cross-device hunting helps defenders determine whether suspicious process behaviour is isolated or part of a wider endpoint incident.