My Top 5 DFIR Artifacts and How to Parse Them

When I first started getting into Windows forensics, the number of artifacts I was supposed to know felt ridiculous. Prefetch, MFT, Shimcache, Amcache, Registry hives, event logs — the list never seemed to end. And nobody was really telling me which ones actually mattered in practice versus which ones were just good to know about theoretically.

So this post is what I wish someone had handed me early on. These are the five artifacts I keep coming back to on real investigations. Not because they’re the most obscure or impressive, but because they’re reliable, well-supported by tooling, and between them they answer most of the questions you’re going to have on a Windows case.

Everything here uses Eric Zimmerman’s tools. If you’re doing Windows forensics and you’re not already using EZ Tools, that’s your first homework assignment. Head to ericzimmerman.github.io and grab them. They’re free and they’re the industry standard.

1. Prefetch Files

What it tells you: A program ran on this machine, when it last ran, how many times it’s been run, and what files it touched during execution.

Where to find it: C:\Windows\Prefetch\ — files end in .pf

Prefetch is usually one of the first places I look when I need to answer the question “was this actually executed?” Even if the malware has been deleted off the system, the Prefetch file might still be sitting there telling you exactly when it ran. That’s incredibly useful.

A few things worth knowing before you dig in. Prefetch is enabled by default on workstations but disabled on servers — so don’t panic when it’s missing on a server endpoint, that’s normal. Windows also only keeps the most recent 128 Prefetch files, so on a busy system older ones will get rotated out. And the filename format — EXECUTABLENAME-HASH.pf — the hash is based on the path the binary ran from. So if the same executable ran from two different locations, you’ll see two separate Prefetch files. That detail actually matters a lot when you’re hunting for masquerading.

How to parse it:

PECmd.exe -f "C:\Windows\Prefetch\POWERSHELL.EXE-022A1004.pf"

To parse everything in the Prefetch directory at once and dump it to CSV:

PECmd.exe -d "C:\Windows\Prefetch" --csv "C:\output" --csvf prefetch_results.csv

When you’re looking at the output, focus on three things: the last run time, the run count, and the files referenced section. A run count of 1 on something suspicious is worth flagging. The files referenced list can point you toward staging directories or dropped payloads that the process touched during execution — stuff you might not have found otherwise.

2. The Master File Table ($MFT)

What it tells you: Everything about every file and directory on an NTFS volume — filenames, timestamps, file sizes, and whether something has been deleted.

Where to find it: $MFT lives at the root of every NTFS volume. You can’t just browse to it — you’ll need to collect it with something like FTK Imager, KAPE, or Velociraptor.

The MFT is the ground truth for file system activity on Windows. If a file ever existed on this volume, there’s a record of it in the MFT. Even deleted files leave an entry behind until that space gets reused — and on a lot of systems, especially ones that aren’t under heavy load, that can take a while.

Here’s something that trips up a lot of newer analysts: Windows timestamps are not trustworthy on their own. Attackers use timestomping tools to backdating files and make them look like they’ve been on the system forever. The timestamps you see in Explorer — those come from the $STANDARD_INFORMATION attribute, and they can be manipulated pretty easily. But every file also has a $FILE_NAME attribute with its own set of timestamps, and those are much harder to fake without leaving traces. When you’re in MFTECmd output and you see a big gap between the two sets of timestamps on the same file — that’s a red flag worth digging into.

How to parse it:

MFTECmd.exe -f "C:\Evidence\$MFT" --csv "C:\output" --csvf mft_results.csv

What to pay attention to:

• Files showing up in %TEMP%, %APPDATA%, C:\ProgramData, or C:\Users\Public — these are classic attacker-favored directories because they’re writable without admin rights.
• Timestamp mismatches between $STANDARD_INFORMATION and $FILE_NAME — possible timestomping.
• Entries marked IsDeleted = True — the file is gone but the metadata is still there.
• Executables or DLLs sitting in weird places — a .exe in a user’s Downloads or AppData folder that has no business being there.

3. Registry Hives

What it tells you: Basically everything about the system and its users — installed software, USB devices that have been connected, recently accessed files, what’s set to run at startup, local account information, and a lot more.

Where to find them:

The Registry is one of those artifacts that feels overwhelming at first because there are hundreds of forensically relevant keys spread across multiple hives. The trick is knowing which keys matter most for the type of investigation you’re running. Persistence hunting? Go straight to the Run keys. USB investigation? Hit USBSTOR. Trying to figure out what documents a user opened recently? RecentDocs.

How to parse it:

The fastest way to hit all the high-value keys in one shot is RECmd with a batch file:

RECmd.exe -d "C:\Evidence\Registry" --bn BatchExamples\kroll_batch.reb --csv "C:\output"

The Kroll batch file covers most of the forensically relevant keys out of the box. If you want to dig into a specific key — say, UserAssist for GUI execution history — you can query it directly:

RECmd.exe -f "C:\Evidence\NTUSER.DAT" --kn "SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UserAssist" --csv "C:\output"

If you prefer a GUI, RegistryExplorer is excellent for browsing interactively.

Keys to bookmark:

• Persistence: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run and RunOnce
• USB devices: HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR
• Recent documents: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs
• Typed URLs: HKCU\SOFTWARE\Microsoft\Internet Explorer\TypedURLs
• GUI execution history: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UserAssist

4. USN Journal ($UsnJrnl)

What it tells you: A chronological log of every file system change on the volume — creations, deletions, renames, modifications, attribute changes. Think of it as a running changelog for the file system.

Where to find it: $Extend\$UsnJrnl:$J — lives on every NTFS volume alongside the MFT. You’ll need a forensic collection tool to grab it.

This is the artifact that gives you sequencing. The MFT can tell you a file existed — the USN Journal tells you the order things happened in. Did the attacker drop a file, execute it, then delete it? The journal captured all three events. Did a new directory get created right before a bunch of files appeared in it? Journal has that too.

It’s also really useful for recovering evidence of deleted files. The MFT entry for a deleted file can get overwritten pretty quickly on a busy system. But the USN Journal entry recording that deletion sticks around longer — the journal is circular and overwrites itself, but the rotation is different from the MFT.

One thing to keep in mind: on a very active system, the journal might only cover the last few hours. On a quieter endpoint it could go back days or even weeks. It varies a lot.

How to parse it:

MFTECmd handles the USN Journal too:

MFTECmd.exe -f "C:\Evidence\$J" --csv "C:\output" --csvf usn_results.csv

To look for a specific filename:

MFTECmd.exe -f "C:\Evidence\$J" --csv "C:\output" --csvf usn_results.csv --fn "malware.exe"

What to look for:

• A FileCreate entry followed almost immediately by a FileDelete — classic dropper behavior, something was written and then cleaned up.
• Rename events — renaming a binary is one of the oldest tricks for masquerading as a legitimate process.
• Activity in staging directories — cross-reference with MFT entries to build a complete picture.

5. Shellbags

What it tells you: Which folders a user opened in Windows Explorer — including folders on external drives, network shares, and folders that no longer exist on the system.

Where to find them:

Stored in the Registry under two locations:

• HKCU\SOFTWARE\Microsoft\Windows\Shell\BagMRU and Bags (in NTUSER.DAT)
• HKCU\SOFTWARE\Classes\Local Settings\Software\Microsoft\Windows\Shell\BagMRU (in UsrClass.dat)

Shellbags are one of my favorite artifacts for proving user intent. If someone tells you they never accessed a particular folder or plugged in an external drive — Shellbags can very quickly say otherwise. They persist even after the folder or drive is gone. The system remembers that you opened it regardless of whether it’s still there.

They’re also great for lateral movement investigations. If a user browsed to a network share — \\FILESERVER\Finance, for example — that path gets recorded in Shellbags. That can help you understand which systems an insider threat or compromised account was poking around on.

How to parse it:

Use SBECmd:

SBECmd.exe -d "C:\Evidence\Registry" --csv "C:\output" --csvf shellbags.csv

For a live system targeting the current user:

SBECmd.exe -l --csv "C:\output" --csvf shellbags.csv

What to look for:

• External drive paths like E:\ or F:\ — someone plugged something in and browsed it.
• Network share paths — \\SERVERNAME\sharename — tells you what remote resources they accessed.
• Paths that no longer exist — if the folder is gone but Shellbags recorded it, that absence is actually evidence.
• First and last interaction timestamps — useful for building a timeline around a specific event.

How These Five Fit Together

Here’s the mental model I use when I’m starting a Windows investigation:

• Prefetch → Did this binary actually run?
• MFT → What files existed and when?
• USN Journal → What was the order of events?
• Registry → What persisted, what devices connected, what did the user open?
• Shellbags → Where did the user browse?

No single artifact gives you the full picture. But these five together cover execution evidence, file system history, a timeline, persistence, and user behavior. That’s the foundation of most Windows investigations.

Get comfortable with these and you’ll be in a much better position than most people just starting out in the field.

Tools referenced:

• Eric Zimmerman’s Tools — PECmd, MFTECmd, RECmd, SBECmd, RegistryExplorer
• KAPE — artifact collection

Questions or want to talk shop? Reach me at [email protected] or on LinkedIn.