ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Investigation • Microsoft Defender XDR • DeviceFileEvents • DeviceProcessEvents • DeviceNetworkEvents • KQL

The File Was Clean When It Arrived — It Became Malicious Later

The file appeared on the endpoint in the morning.

Nothing obvious happened.

No suspicious process chain.
No outbound connection.
No incident tied to the original arrival.

Hours later, a file with the same name and path executed and triggered the investigation.

It looked like Defender had missed it the first time.

Agent Foskett checked the hashes.

It wasn't the same file anymore.

Discuss endpoint security Back to investigations
Agent Foskett investigating a file whose contents changed before malicious execution
A Filename Is Not a File Identity

The same path can contain different content at different times. Hashes and file-event history are what prove whether the binary actually changed.

✓ Reconstruct the file timeline
✓ Compare hashes across versions
✓ Follow the version that executed

The first observation looked harmless

The earlier file event did not line up with suspicious execution or network activity. That made the later alert easy to misread: same filename, same path, therefore same file. Agent Foskett needed to prove whether that assumption was true.
Same filenameThe later executable used the same familiar name.
Same pathThe file still existed in the location seen earlier.
Different evidenceThe hash history showed that the content underneath that name had changed.

Start with every file event

Use DeviceFileEvents to reconstruct the complete history of the filename on the affected endpoint. Do not jump straight to the alerting process. First establish when the file appeared, when it changed and which process wrote it.
file-timeline.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 File = "QuarterlyReport.exe";
DeviceFileEvents
| where Timestamp > ago(7d)
| where DeviceName =~ Device
| where FileName =~ File
| project Timestamp,
          ActionType,
          FolderPath,
          FileName,
          SHA1,
          SHA256,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

Compare the hashes over time

A filename and path are labels. The hashes identify the observed content. If multiple hashes appear for the same file path, the investigation now has evidence that different versions existed.
hash-history.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
DeviceFileEvents
| where Timestamp > ago(7d)
| where DeviceName =~ "LAPTOP-042"
| where FileName =~ "QuarterlyReport.exe"
| summarize FirstSeen=min(Timestamp),
            LastSeen=max(Timestamp),
            Events=count()
    by FolderPath,
       SHA1,
       SHA256
| order by FirstSeen asc

The content changed before execution

The timeline showed one hash when the file first appeared and another shortly before the suspicious process launched. That changed the question from “Why was this malicious file missed?” to “What replaced or modified the original file?”
09:12 — first observedThe file appeared with the original recorded hash.
14:37 — content changedA later file event at the same path recorded a different hash.
14:41 — process executedThe later hash became part of the suspicious process chain.

What wrote the later version?

The initiating process attached to the creation, modification or rename event becomes the next pivot. That process may explain whether the change came from a legitimate update path, a script, an archive extraction, a browser download or another suspicious execution chain.
file-change-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
  16. 16
  17. 17
DeviceFileEvents
| where Timestamp > ago(7d)
| where DeviceName =~ "LAPTOP-042"
| where FileName =~ "QuarterlyReport.exe"
| where ActionType in
    ("FileCreated", "FileModified", "FileRenamed")
| project Timestamp,
          ActionType,
          SHA1,
          SHA256,
          FolderPath,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          InitiatingProcessAccountName
| order by Timestamp asc

Follow the version that actually ran

Now pivot into DeviceProcessEvents. Capture the hash of the executing file, its command line, parent process and user context. This ties the suspicious behaviour to the correct file version rather than to the earlier content that happened to use the same filename.
executed-version.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
DeviceProcessEvents
| where Timestamp > ago(7d)
| where DeviceName =~ "LAPTOP-042"
| where FileName =~ "QuarterlyReport.exe"
| project Timestamp,
          DeviceName,
          FileName,
          FolderPath,
          SHA1,
          SHA256,
          ProcessCommandLine,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          AccountName
| order by Timestamp asc

What did the later version do?

Once the suspicious hash is known, use it to follow network activity from the executing process. This helps establish what the later version actually did after launch.
network-by-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_LATER_SHA1_HERE";
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessSHA1 == SuspiciousHash
| project Timestamp,
          DeviceName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          RemoteUrl,
          RemoteIP,
          RemotePort,
          ActionType
| order by Timestamp asc

Was the later hash seen elsewhere?

Scope the executed hash across the environment. The same content may have appeared on additional devices, possibly under different paths or through another delivery mechanism.
scope-executed-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
let SuspiciousHash = "PUT_LATER_SHA1_HERE";
DeviceProcessEvents
| where Timestamp > ago(30d)
| where SHA1 == SuspiciousHash
| summarize FirstSeen=min(Timestamp),
            LastSeen=max(Timestamp),
            Executions=count()
    by DeviceName,
       FolderPath,
       FileName,
       ProcessCommandLine
| order by FirstSeen asc

The first verdict did not apply to the later file

If the content changed, an earlier reputation result, lack of alert or prior observation belongs to the earlier hash. It should not automatically be carried forward to a different binary just because the filename stayed the same.
FilenameUseful for finding the path, but not enough to prove file identity.
HashSeparates the content observed at one point in time from another version later.
BehaviourProcess and network telemetry show what the later version actually did.

What the evidence can and cannot prove

Different hashes at the same path prove that different content was observed. They do not automatically prove how the replacement occurred, and the absence of an initial alert does not prove the first version was benign. Keep each conclusion tied to the evidence available for that version.
ProvenThe same filename and path contained different recorded content over time.
CorrelatedThe later hash was observed shortly before the suspicious process and network activity.
Do not overclaim“No alert earlier” does not mean “the original file was proven clean.”

Agent Foskett's investigation mindset

Do not let a familiar filename collapse two different moments into one story. Files can be overwritten, replaced or modified while keeping exactly the same name and path.
Follow the hashDetermine which content existed at each point in the timeline.
Follow the writerIdentify the process that changed the content.
Follow the executed versionAttribute suspicious behaviour to the file version that actually ran.

Investigation findings

The suspicious executable shared a filename and path with a file observed earlier, but DeviceFileEvents showed different hashes. A later write event changed the content shortly before execution, and the later hash was the version tied to the suspicious process and network activity. The investigation therefore separated the original arrival from the later replacement rather than treating the filename as proof of identity.
The path stayed the sameThat initially made the activity look like one continuous file story.
The hash changedThe content evidence proved that another version existed later.
The later version drove the incidentExecution and network telemetry were tied to the changed file.

Related Agent Foskett investigations

Continue with endpoint, process and file investigations.
The File Appeared Seconds Before It ExecutedReconstruct suspicious endpoint execution using file and process timing. The Process Was Signed By MicrosoftInvestigate why trusted signatures do not automatically make behaviour trusted. Agent Foskett AcademyBuild practical Microsoft security investigation and KQL skills.
The name stayed the same. The evidence underneath it changed.
In file investigations, compare hashes and behaviour across time — not just filenames.
Continue the Investigation

Final thought

When a file appears harmless at one point and suspicious later, do not assume one verdict applies forever. Reconstruct the file history, compare the hashes, identify what changed the content and then follow the version that actually executed. The filename tells you where to look. The hash tells you whether you are still looking at the same file.
Was it the same content?Compare hashes across the timeline.
What changed it?Investigate the process that wrote the later version.
Which version behaved maliciously?Connect the process and network activity to the correct hash.
Develop IT. Protect IT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The File Was Clean When It Arrived — It Became Malicious Later

This Agent Foskett investigation explores Microsoft Defender XDR file timelines, DeviceFileEvents, DeviceProcessEvents, DeviceNetworkEvents, file hashes and KQL.

Microsoft Defender File Investigation

The investigation compares hashes observed at the same file path over time and follows the later version into execution and network telemetry.

File Hashes, Endpoint Evidence And KQL

Filenames can remain unchanged while content is replaced or modified. Hash and timeline evidence help defenders distinguish file versions and attribute suspicious behaviour to the correct binary.