What Windows Field Forensics Is: Evidence-Based Investigation

Forensic analysis is the discipline of reconstructing what happened on a system using the evidence the system left behind.

That scenario is the core of this discipline. You receive evidence. You produce findings. Everything between those two points is forensic analysis.

Estimated time: 25 minutes.

The discipline, not the tools

Most forensic training starts with tools. Open this parser, run this command, read this output. That teaches tool operation. It does not teach forensic analysis.

Forensic analysis is the reasoning that connects evidence to conclusions. A Prefetch file tells you a binary executed. Amcache tells you the hash of that binary. The event log tells you the user account context. SRUM tells you the network bytes transferred during that session. None of those individual findings answers an investigation question by itself. The analysis is the process of connecting them into a narrative that can be challenged, tested, and defended.

The difference between someone who can run PECmd and a forensic examiner is not the ability to parse a Prefetch file. It is the ability to look at the output and decide what it means in the context of the investigation, what other evidence sources to check, what to do when the sources contradict each other, and how confident the conclusion should be.

This course teaches that reasoning. The tools are how you access the evidence. The analysis is what you do with it.

Consider a concrete example. You find a Prefetch entry for update.exe that ran once at 03:17 UTC from C:\Users\Public\. A tool operator records "update.exe executed at 03:17" and moves on. A forensic examiner asks: why is an executable named update.exe running from a user-writable directory at 03:17 in the morning? What DLLs did it load? Does the loaded files list match a legitimate updater or a known attacker tool? What does Amcache say about its hash? Is there a corresponding process creation event with a command line? Did SRUM record network activity during that window? Each question leads to another artifact, and each artifact either strengthens or weakens the conclusion. The examiner follows the evidence chain until the finding is defensible or documented as inconclusive.

That process is forensic analysis. The tools are interchangeable. The reasoning is the skill.

Evidence-based reconstruction

Every finding in a forensic investigation rests on evidence. Not on assumptions, not on probability, not on "the attacker probably did X." On artifacts that exist in the data you collected.

This creates a discipline that works differently from most security analysis. In SOC operations, you form a hypothesis and investigate until you have enough confidence to act. In forensic analysis, you document what the evidence proves, what it suggests, and what it cannot answer. The distinction matters because forensic findings may need to survive legal scrutiny, peer review, or executive challenge.

Three levels of confidence apply to every finding:

Definitive. Multiple independent artifacts corroborate the same conclusion. Prefetch shows the binary executed at 03:14. Event log 4688 shows the process creation at 03:14 with the matching command line. Amcache records the SHA1 hash matching a known tool. SRUM shows 2.4 MB of network transfer during the same hour. Four independent sources, one conclusion. This finding is defensible.

Probable. A single artifact supports the conclusion and no contradicting evidence exists. Prefetch shows execution at 03:14 but event logs have rolled and Amcache has no entry. The Prefetch evidence alone is strong (Tier 1 in the execution hierarchy) but a single source can be challenged. Document the finding, note the single-source limitation, and identify what corroborating evidence would strengthen it.

Inconclusive. Evidence is ambiguous or contradictory. Shimcache shows the binary was present on the system but Shimcache does not prove execution. Amcache records the hash but Amcache entries can be created during installation without execution. The evidence establishes presence, not execution. Document what the evidence shows and what it does not.

This three-level framework applies to every artifact you analyse in this course. When a sub teaches you to read Prefetch output, it also teaches you what Prefetch can prove, what it can suggest, and where you need a second source.

The investigation question approach

Traditional forensic courses organize content by artifact type. One module on the registry, one on the filesystem, one on event logs. You learn what each artifact contains and how to parse it. Then you're expected to figure out how to combine them during an actual investigation.

This course organizes content by investigation question. Each module asks a question that an investigator needs to answer:

• What ran on this system?
• Who was here and what did they do?
• How did the attacker get in and move?
• What did they install to stay?
• What data left the network?
• What happened on the filesystem?
• What did they try to hide?

Every artifact is taught in the context of answering one of these questions. Prefetch is not a standalone topic. It is taught in the module that answers "What ran on this system?" alongside Amcache, Shimcache, BAM, SRUM, and process creation events. You learn to use these sources together because that is how you use them during an investigation.

The result is that by the end of each module, you can answer the investigation question from real evidence. Not describe the artifacts that might help. Actually answer the question.

Corroboration across sources

The most common mistake junior examiners make is building a finding on a single artifact. Prefetch shows the binary ran. Report written. Investigation closed.

A senior examiner treats every artifact as one data point and looks for independent corroboration from sources that operate through different mechanisms. Prefetch is a filesystem artifact. Event logs are system-generated audit records. Amcache is a registry hive. SRUM is an ESE database. When three sources that operate through completely different subsystems all point to the same conclusion, the finding is strong. When only one source supports it, the finding is provisional.

This course teaches cross-artifact corroboration as a default practice, not as an advanced technique. Every artifact sub shows you what that artifact can answer on its own and where you need a second source. Every module summary shows how the sources within that module connect to reinforce or challenge each other's evidence.

By Module 9, you will build complete investigation timelines from multiple artifact types across multiple hosts. That skill starts here, with the understanding that a single artifact tells you something happened. Multiple corroborating artifacts tell you it happened, when, how, and with what confidence.

What forensic findings look like

A forensic finding is not a log entry or a tool output. It is a statement about what happened, supported by evidence, with a confidence level attached.

A weak finding reads: "Mimikatz was found on the system." Found where? When? How do you know it was Mimikatz and not a renamed legitimate binary? What did it do? A weak finding invites questions it cannot answer.

A defensible finding reads: "A binary named svchost.exe executed once from C:\Users\Public\ at 03:14 UTC on March 15. The Prefetch loaded files list shows credential access DLLs (SAMLIB.DLL, VAULTCLI.DLL, WDIGEST.DLL, DPAPI.DLL) consistent with Mimikatz. Amcache records SHA1 hash 27304b246c matching Mimikatz v2.2.0. SRUM records 2.4 MB of network transfer from psexec.exe in the same hour. No contradicting evidence identified. Confidence: definitive."

Every module in this course teaches you to build findings at that level. The artifact subs teach you where the evidence comes from. The analysis methods teach you how to connect the sources. The confidence framework teaches you how to assess and communicate what the evidence supports.

Next: Section 0.2 explains how this course is structured and how to use the investigation-question approach, the Fieldcraft procedures, and the Forensic Lab to get the most from the material.