Agent Foskett Investigation • Microsoft Defender XDR • DeviceFileEvents • SMB • File Propagation • KQL
The File Was Downloaded Once — Then Appeared on 37 Devices
The security team found the same suspicious file on 37 devices.
The first explanation sounded obvious.
“Thirty-seven users downloaded it.”
But the Internet-download evidence did not agree.
Agent Foskett found one external download — and then asked the question that changed the investigation:
How did one copy become 37?
Copies Are Not Downloads
A file can enter the environment once and then move internally. Count the copies, but investigate the path that created them.
✓ Pivot on the file hash
✓ Separate Internet ingress from internal movement
✓ Identify the source device and transfer mechanism
Thirty-seven devices changed the question
The file was named update-helper.exe. Defender telemetry showed the same SHA-1 on workstations across several departments. Seeing 37 copies made the incident look like a mass-download campaign, but a device count is not a download count.
Same filenameUseful for orientation, but filenames can be changed or reused.
Same SHA-1The hash provided a much stronger pivot for tracing the same file across endpoints.
37 devicesThe blast radius was real. The assumed delivery mechanism was not yet proven.
Start with the hash, not the story
Microsoft Defender XDR DeviceFileEvents includes device identity, file hashes, origin information where available, the initiating process and network-file context such as SMB or NFS request details. Microsoft notes that SHA-256 is often not populated in this table, so this investigation uses SHA-1 when available.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
let FileHash = "9f2c7e1a4d8b6c3f5a0e7d2b1c9f4a6e8d3b5c7a";
DeviceFileEvents
| where Timestamp > ago(7d)
| where SHA1 == FileHash
| summarize FirstSeen=min(Timestamp),
LastSeen=max(Timestamp),
FileEvents=count()
by DeviceId, DeviceName
| order by FirstSeen asc
Agent Foskett rule: one hash on 37 devices proves distribution of that file content across those observed endpoints. It does not prove 37 separate Internet downloads.
Only one device showed the Internet origin
The next pivot was origin evidence. The earliest event was on ADMIN-WS01, where the file event included an external origin URL. The later copies appeared on other devices without the same external origin. That did not by itself prove SMB propagation, but it was enough to reject the assumption that every endpoint had independently downloaded the payload.
09:14update-helper.exe first appears on ADMIN-WS01 with external origin evidence.
09:19The same SHA-1 begins appearing on internal endpoints.
09:27File events show SMB request context from ADMIN-WS01 to multiple targets.
09:41The hash is now present on 37 devices.
09:44Process telemetry shows the payload beginning to execute on several endpoints.
Compare the origin evidence
FileOriginUrl, FileOriginReferrerUrl and FileOriginIP can help identify where a downloaded file originated when that information is available. They should not be treated as universally populated fields. Compare the earliest events and look for a change from external origin evidence to internal transfer context.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
let FileHash = "1111111111111111111111111111111111111111";
DeviceFileEvents
| where Timestamp > ago(7d)
| where SHA1 == FileHash
| project Timestamp, DeviceName, ActionType,
FileName, FolderPath,
FileOriginUrl, FileOriginIP,
RequestProtocol, RequestSourceIP,
InitiatingProcessFileName,
InitiatingProcessCommandLine
| order by Timestamp asc
The copies pointed back to one internal source
DeviceFileEvents can record RequestProtocol values including SMB and a RequestSourceIP for remote file activity. In this scenario, the later file events repeatedly pointed back to the address assigned to ADMIN-WS01. That changed the investigation from “37 downloads” to “one ingress followed by internal distribution.”
Initial acquisitionOne endpoint obtained the file from an external source.
Internal propagationSubsequent file events carried SMB request context from the same internal source.
Blast radiusThe same hash reached 37 devices even though the Internet ingress happened only once in the observed evidence.
Pivot on the source IP
Once a likely internal source appears, pivot on it across the file telemetry. This helps identify which targets received remote file activity and whether the timing lines up with the spread of the hash.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
let SourceIP = "10.20.5.14";
DeviceFileEvents
| where Timestamp > ago(7d)
| where RequestProtocol =~ "SMB"
| where RequestSourceIP == SourceIP
| project Timestamp, DeviceName, ActionType,
FileName, FolderPath, SHA1,
RequestProtocol, RequestSourceIP,
InitiatingProcessAccountName
| order by Timestamp asc
Do not turn correlation into certainty
The same hash, sequential timing and SMB request context can strongly support an internal propagation path, but investigators should still validate the source device, account, process activity and any legitimate deployment tooling. Software distribution systems, administrative shares, backup products and support tools can all create file activity across many endpoints.
37 copies?That establishes scope, not 37 user actions.
SMB present?Correlate the source, account, timing and process activity before deciding why it occurred.
One external origin?Useful evidence for initial ingress, but absence of origin metadata elsewhere is not proof that no other download occurred.
What Agent Foskett checked
File hashWas the content actually identical across all affected endpoints?
First seenWhich device recorded the earliest appearance of the hash?
Origin metadataWhere did Defender record an external source for the file?
SMB contextDid later events identify a remote source IP and network-file protocol?
Source endpointWhat account and processes were active on the device distributing the file?
ExecutionDid the file merely arrive, or did it execute on any of the 37 devices?
The investigation finding
The suspicious executable was observed on 37 endpoints, but the evidence did not support 37 independent Internet downloads. The earliest observed copy carried external origin information on ADMIN-WS01. Later DeviceFileEvents for the same SHA-1 contained SMB request context pointing back to that internal source. The file had entered once in the observed timeline and then propagated across the environment.
Investigation principle: do not count copies and assume downloads. Establish the initial ingress, then map the propagation path.
Related investigations
The File Was Never Downloaded — It Was SynchronisedAnother case where the observed file movement did not match the action investigators first expected.The User Didn't Upload the File — OneDrive Did It AutomaticallySeparate a cloud outcome from the user action assumed to have caused it.The Defender Alert Was Closed — But the Same Command Ran on Three More DevicesContinue investigating scope when the same activity appears elsewhere.
Final thought
Thirty-seven copies initially looked like thirty-seven downloads. They were not. The hash showed the same file across the estate, the earliest origin evidence identified the initial ingress, and the later SMB context exposed the internal path that multiplied one copy into many. One download can become 37 copies without 37 people clicking anything.
Count the devices — but investigate the movement.
The Logs Already Knew! 🔎
Count the devices — but investigate the movement.
The Logs Already Knew! 🔎
