Agent Foskett Investigation • Microsoft Defender XDR • Endpoint • File Events • Process Execution • Attack Timeline • KQL
The File Was Renamed Three Times Before It Executed
The alert showed an executable starting from the user's Downloads folder.
That looked suspicious enough. But the file name in the alert was not the name it arrived with.
It had been renamed three times.
Agent Foskett wanted the part of the story that happened before execution.
The File Timeline
Execution was only the final event. The real investigation began by following the file backwards through every name, folder and process that touched it.
Identify the executed file and SHA1
Trace earlier file names and locations
Correlate the file with the process tree
The alert started at 2:41 PM
Microsoft Defender XDR showed InvoiceViewer.exe executing from the user's Downloads folder. The analyst could have started with the process and moved forward. Agent Foskett moved backwards instead: where did this file come from, and had it always been called InvoiceViewer.exe?
The execution was realThe process event gave the investigation a precise device, user, timestamp, file name and hash.
The name was only a labelAttackers can rename payloads. A filename is useful context, but the hash and timeline can connect identities that the name hides.
The history matteredThe question became: what happened to this object before Windows executed it?
Start with the process that actually executed
Use DeviceProcessEvents to establish the execution point and capture the SHA1. In a real investigation, replace the sample device, user and time window with evidence from the alert.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
DeviceProcessEvents
| where Timestamp between (datetime(2026-08-25 14:30:00) .. datetime(2026-08-25 15:00:00))
| where FileName =~ "InvoiceViewer.exe"
| project Timestamp, DeviceName, AccountName,
FileName, FolderPath, SHA1,
ProcessCommandLine, InitiatingProcessFileName,
InitiatingProcessCommandLine
| order by Timestamp ascNow follow the hash backwards
The SHA1 becomes the pivot. Search DeviceFileEvents for the same hash before execution. This can expose earlier names, locations and file operations associated with the object.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
let SuspiciousSHA1 = "REPLACE_WITH_SHA1";
DeviceFileEvents
| where Timestamp > ago(24h)
| where SHA1 == SuspiciousSHA1
| project Timestamp, DeviceName, ActionType,
FileName, FolderPath,
PreviousFileName, PreviousFolderPath,
InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp ascThree names. One file.
The timeline changed the investigation. The object first appeared as document_4821.tmp, became invoice-August.pdf.exe, then update.exe, and finally InvoiceViewer.exe immediately before execution. The names changed. The hash connected the story.
document_4821.tmpThe earliest observed identity. This was the point to investigate delivery and the process that created the file.
invoice-August.pdf.exe → update.exeThe intermediate names suggested deliberate disguise and staging rather than normal user behaviour.
InvoiceViewer.exeThe final friendly-looking name was the one visible at execution — but it represented only the last few seconds of the file's history.
Who performed the renames?
File events are more useful when correlated with the initiating process. If a browser created the original download but a script host or command shell renamed it repeatedly, the investigation has moved from a suspicious file to a suspicious execution chain.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
let SuspiciousSHA1 = "REPLACE_WITH_SHA1";
DeviceFileEvents
| where Timestamp > ago(24h)
| where SHA1 == SuspiciousSHA1
| summarize FirstSeen=min(Timestamp), LastSeen=max(Timestamp),
Names=make_set(FileName, 20),
Actions=make_set(ActionType, 20),
Initiators=make_set(InitiatingProcessFileName, 20)
by DeviceName, SHA1
| order by FirstSeen ascThen rebuild the process tree around execution
The file history explains how the payload changed identity. DeviceProcessEvents explains what launched it and what it launched next. Search the surrounding minutes for the same device and account so the rename activity sits inside a complete endpoint timeline.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
let Device = "WORKSTATION-27";
let ExecutionTime = datetime(2026-08-25 14:41:00);
DeviceProcessEvents
| where DeviceName =~ Device
| where Timestamp between (ExecutionTime - 10m .. ExecutionTime + 10m)
| project Timestamp, AccountName, FileName,
ProcessCommandLine, SHA1,
InitiatingProcessFileName,
InitiatingProcessCommandLine
| order by Timestamp ascThe filename was not the identity
This is the central lesson. Filenames are mutable. Hashes, timestamps, process relationships and file telemetry let analysts follow an object even when an attacker tries to make it look different.
Pivot on stable evidenceUse hashes and device context to connect file events when names change.
Follow both directionsMove backwards to delivery and staging, then forwards from execution to child processes, network activity and persistence.
Do not investigate one tableDeviceFileEvents tells the file story. DeviceProcessEvents tells the execution story. Together they reveal the attack chain.
Investigation findings
The executable seen in the alert was not a newly created InvoiceViewer.exe. It was the final identity of a file that had already moved through several suspicious names. By following the SHA1 backwards, Agent Foskett reconstructed the staging activity before execution and identified the processes responsible for the changes.
The hash joined the evidenceFour filenames became one continuous object in the timeline.
The renames were part of the attackThe changes were not cosmetic trivia; they exposed staging behaviour immediately before execution.
The alert was the endingThe most useful evidence was already present in the minutes before the detection fired.
Related Agent Foskett investigations
Continue with endpoint, PowerShell and process-chain investigations.
The Browser Spawned PowerShellFollow suspicious parent-child process relationships from browser activity into PowerShell.The File Appeared Seconds Before It ExecutedInvestigate the relationship between file creation and rapid execution.Agent Foskett AcademyBuild practical Microsoft security investigation and KQL skills through structured lessons.
Final thought
An alert often shows the moment a threat became visible. Investigation is about reconstructing everything that made that moment possible. When a suspicious executable appears, do not ask only what it did next. Ask what it was called before, where it came from, which process touched it and what changed in the seconds before execution.
Start at executionCapture the device, user, time, path and hash.
Walk the file backwardsUse DeviceFileEvents to reconstruct names, locations and initiating processes.
Then follow it forwardsUse process and network telemetry to determine what the payload actually achieved.
