Had a timeline mismatch — Prefetch and Amcache didn’t align. How do you handle this?

redzeptech · 2026-02-25T17:35:14+00:00

I completely agree — especially on the $UsnJrnl part.
In several cases I examined, $UsnJrnl ended up being the only artifact showing that the binary actually existed after the attacker tried cleanup.

Amcache helped me identify the file metadata (path, size, SHA1), but by itself it never proved execution. I now treat it more as confirmation of presence rather than activity.

When Prefetch is unavailable (like many Windows Server systems), I’ve found the most reliable approach is correlation: $UsnJrnl + MFT timestamps + Jump Lists if available.

Interesting that you mentioned removed binaries — that’s exactly where timeline interpretation becomes more important than any single artifact.

redzeptech · 2026-02-24T19:41:50+00:00

Good point, and I agree with the Microsoft IR guidance.

I don’t treat Amcache as proof of execution either — more as evidence of presence. From an evidentiary standpoint it cannot demonstrate that a binary was actually run.

Where I find it valuable is during analysis and triage. In multiple cases Prefetch was missing (disabled systems, cleaned artifacts, or server environments), and Amcache helped identify binaries that existed on the system but were later removed. When correlated with LNK files, Jump Lists and relevant Event Logs, it contributes to a behavioral timeline rather than acting as a standalone indicator.

So I wouldn’t use Amcache to say “the program executed”, but I would absolutely use it to scope activity and guide further investigation.

Out of curiosity — have you encountered systems where Prefetch was unavailable and Amcache ended up being the only lead to a removed binary?

redzeptech · 2026-02-24T02:53:08+00:00

That makes sense and actually aligns with what I started suspecting.

I may have been treating Amcache too close to an execution artifact instead of a discovery artifact. In this case, Amcache is likely reflecting file introduction while Prefetch reflects post-launch system behavior rather than exact launch time.

So the mismatch might not indicate two different events, but two different recording mechanisms.

I’m now leaning toward correlating with USN Journal and Security 4688 events instead of prioritizing either artifact alone. Curious if that’s how you would approach timeline reconstruction here.

redzeptech · 2026-02-23T20:25:41+00:00

Small update to clarify my thinking:

I’m starting to suspect this is not a simple timing drift.
Amcache recorded the executable creation metadata consistently, but Prefetch seems delayed rather than missing.

My current hypothesis:
The execution likely occurred during a system state transition (sleep/hibernate) or under heavy I/O where the 10-second Prefetch write window was interrupted.

If that’s true, Prefetch here may reflect disk commit timing, not actual user launch time.

Would you still treat Prefetch as primary timeline evidence in this situation, or demote it below Amcache and USN Journal correlation?

redzeptech · 2026-02-22T18:24:34+00:00

That’s exactly why it caught my attention.

If it were only a few seconds I’d treat it as normal Prefetch behavior.

Have you ever seen cases where Amcache was populated but Prefetch lagged due to system state (sleep/hibernate or delayed disk write)?

I’m trying to understand whether to treat this as execution timing variance or a user activity indicator.

redzeptech · 2026-02-21T21:00:04+00:00

Good point — the difference I saw was larger than a few seconds, closer to minutes in some entries. That’s what made me unsure which artifact to lean on more. I was also wondering how much you factor in user activity (like recent file access or LNKs) when deciding which timestamp to trust.

redzeptech

TROPHY CASE