The Windows Forensic Toolstack: 58 Free Tools, Four Stages, and Why Parsers Are Single-Purpose

Introduction

This section is about the tools this course actually runs its commands with, which is a shorter and considerably more specific list than a survey of what exists in the field.

By the end of this section you will be able to place any forensic tool you encounter into one of four stages and know what it therefore cannot do, say why Windows artifact parsers are single-purpose programs rather than one integrated suite, name the suite that does most of the work here and the concentration risk that comes with relying on it, state the validation step that belongs before a case rather than after somebody disputes a value, and know that nothing in the ninety-three content subs requires a purchase to follow.

The tools here were not chosen for coverage. They were chosen because the course runs commands, those commands have to work on a machine you own, and a tool behind a purchase order is a tool most readers cannot follow along with.

Every tool in this course does exactly one of four things, and knowing which of the four a given tool does prevents the commonest confusion in this field, which is expecting a parser to find something for you.

Read the arrows. The stages are sequential and a tool that skips one is usually doing it badly, which is why an all-in-one suite tends to be weaker at each stage than the specialists are.

  STAGE     WHAT IT PRODUCES                 WHAT IT CANNOT DO

  Acquire   a copy you can work on safely    tell you anything
                                             about the contents

  Parse     rows from a proprietary format   decide what matters

  Search    the subset that matches          explain why it matched

  Present   something readable and citable   change the evidence

  58 distinct tools appear in the code blocks of this course.
  25 of them belong to one suite.

The four stages, what each produces, and what each cannot do.

The right-hand column is the useful half. A parser produces rows and has no opinion about which of them matter, so asking a parsing tool to find the compromise is asking it to do the stage after its own.

There is a scoping note about this section worth stating plainly. It is not a manual for any of these tools and it does not teach their syntax, which is what the ten modules do as each artifact arrives. What it establishes is the shape of the stack, so that a command in Module 4 reads as a member of a known category rather than as a new thing to memorize.

There is a reason the stages are worth learning as a frame rather than as a list of names. Tools in this field are numerous and they change, and a new one arriving is much easier to place if the question asked of it is which of four things it does. That question also exposes tools that claim to do all four, which are usually weakest at the one you needed.

The four stages also map onto where the risk sits. Acquisition is where a mistake is unrecoverable, parsing is where a mistake is silent, searching is where a mistake looks like an absence of evidence, and presentation is where a mistake becomes a finding. Only the first of those is obvious while it is happening.

Four tools from four stages, chained on one file format.

C:\> MFTECmd.exe -f "E:\C\$MFT" --csv C:\out --csvf mft.csv
C:\> chainsaw.exe hunt C:\out\evtx --sigma rules\ --csv C:\out\hits
C:\> TimelineExplorer.exe C:\out\hits\hits.csv

  ACQUIRE  E:\ is a mounted read-only image, from Module 1
  PARSE    MFTECmd wrote 1,043,882 rows to a CSV
  SEARCH   chainsaw read those rows and returned 88
  PRESENT  Timeline Explorer opened the 88 read-only

  Four tools, four stages, one CSV convention between them.
  No conversion step anywhere in the chain.

The mounted image in the first line is where the acquisition stage ended and it is not a detail. Everything downstream operates on a read-only copy, so no tool in that chain can modify evidence however it is invoked, which is the guarantee the first module exists to establish.

A million rows reduced to eighty-eight and then opened for reading, using four unrelated programs that were never designed together.

The search step is also where the detection content of the wider field plugs in. The rules that tool applied are written in a vendor-neutral format maintained by a community, so the search stage improves without any of the parsing tools changing at all.

The absence of a conversion step is the whole argument for the uniform output convention. Each stage consumes what the previous one wrote, which is what makes a pile of single-purpose tools behave like a suite.

There is a question about commercial suites that this section should answer rather than dodge. They are not absent because they are inferior; the large ones are genuinely capable and they handle case management, reporting and mobile evidence that this stack does not touch at all. They are absent because a reader without one could not run a single command in this course, and because a result you can explain switch by switch is easier to defend than one produced by a pipeline you did not see.

There is a fifth category some readers will expect that does not appear in the four. Reporting tools that assemble findings into a document are real and several exist, and none is in this course because the reporting module argues that the structure of a finding is the examiner's work rather than a template's.

There is one more property of the stage model worth having. A tool that does two stages is not automatically wrong, and the collection tools in the first module do both acquisition and parsing by orchestrating other people's parsers, which is a legitimate design because it keeps the parsers separable.

There is a fifth thing people expect to find in that table and it is deliberately absent. Nothing here interprets, meaning nothing takes rows and tells you what happened, because that is the examiner's job and a tool that offers to do it is offering a conclusion you will have to defend without knowing how it was reached.

Fifty-eight tools is a large number and it is not a reading list. Most appear once or twice for a specific format, and about a dozen carry the majority of the work.

A Windows forensic stack is a pile of small single-purpose programs rather than one application, and that is a choice rather than an accident of history. Four things.

There is an upside to that history worth putting alongside the inconvenience. Because each tool was written by somebody who had just solved that format, the parsers tend to be unusually faithful to the artifact rather than to a product's internal model, and the fields they emit are the fields the format actually contains.

There is a consequence for how you learn the stack that follows from that history. There is no single manual, no consistent argument convention across authors, and no guarantee that two tools name the same field the same way, so the course teaches each tool where its artifact arrives rather than in one place up front.

There is a historical reason for this shape that explains why it looks unusual. Windows forensic tooling grew from researchers publishing a parser for whatever format they had just worked out, rather than from a vendor designing a product line, so the stack is an accumulation of individual solutions to individual problems and its coherence came afterwards.

The first row is worth taking literally, because people assume otherwise. A registry hive is a tree of keys in a binary format with its own transaction logs, a prefetch file is a compressed structure listing file references, and the master file table is an array of fixed-size records with variable attributes inside them. Writing a parser for one teaches you nothing about the next.

The second row is the property that makes the stack coherent. Uniform output means the analysis skills transfer across every artifact in the course even though the formats have nothing in common.

The fourth row matters more than it sounds once a finding is contested. Being able to say which tool, which version, which switches and which field is what makes a result reproducible, and a suite that ingests an image and presents an answer makes that account harder to give.

The third row is the practical argument and it is the reason this course teaches formats alongside commands. When a parser breaks on a new Windows build, knowing what the format contains is what tells you whether the output is wrong or merely different.

Twenty-five of the fifty-eight tools that appear in this course come from a single author, and pretending otherwise would misrepresent what you are actually being taught to use.

  TOOL           APPEARS IN N CODE BLOCKS   ARTIFACT

  MFTECmd                  63               $MFT, $J, $LogFile
  EvtxECmd                 38               Windows event logs
  RECmd                    15               registry hives
  SrumECmd                 11               SRUM database
  PECmd                    11               prefetch
  AmcacheParser             8               Amcache hive
  LECmd                     9               shortcut files

  25 of the 58 tools in this course share one author and one
  output convention. The other 33 come from everywhere.

The seven parsers this course runs most, counted from its own code blocks.

Six of the seven most-used tools in the course are from the same suite, and that is a real concentration rather than an accident of my selection. They are used because they are current, they handle formats others do not, and their output convention is consistent.

The suite installed, and the version of every binary in it recorded.

C:\> Get-ZimmermanTools.ps1 -Dest C:\tools -NetVersion 6

  Downloading 25 tools...  complete.

C:\> Get-ChildItem C:\tools -Filter *.exe |
      ForEach-Object { "{0,-24} {1}" -f $_.BaseName,
        $_.VersionInfo.FileVersion } | Select -First 6

MFTECmd                  1.3.0.0
EvtxECmd                 1.5.0.0
RECmd                    2.1.0.0
PECmd                    1.5.0.0
SrumECmd                 0.6.0.0
AmcacheParser            1.5.1.0

C:\> Get-ChildItem C:\tools -Filter *.exe | Measure-Object -Line
Lines : 25

The installer is itself part of the suite, which is worth knowing because it also updates. Running it again fetches current versions, and a stack that is a year old will fail on artifact formats Windows has revised since, so this is a command to run before a case rather than once.

Twenty-five binaries from one command, and a second command that writes down what each of them is. The second is the one that matters later.

The runtime requirement in that first command is worth noticing too. These are compiled against a specific framework version, and picking the wrong one produces a tool that installs cleanly and refuses to run, which is a confusing failure on a machine being prepared under time pressure.

Version numbers recorded at install time cost nothing and answer a question that arrives months afterwards. A finding produced by version 1.3.0.0 is reproducible; a finding produced by whatever was on the machine at the time is not.

The counts in that table were taken from this course's own content rather than from any survey of the field. They say how often each tool is actually run in a code block here, which is a different question from which tools are most respected or most capable.

The concentration is worth stating rather than hiding. A stack resting substantially on one author's work is exposed if that work stops, and the mitigation is knowing the formats well enough to move to an alternative rather than assuming one exists.

A tool that produces a plausible wrong answer is considerably worse than one that fails outright, and establishing which of those you have is a step that belongs before a case rather than in the middle of one.

C:\> MFTECmd.exe -f "E:\C\$MFT" --csv C:\val --csvf a.csv
C:\> python -m analyzeMFT -f "E:\C\$MFT" -o C:\val\b.csv

C:\> Import-Csv C:\val\a.csv | Where {$_.EntryNumber -eq 184229} |
      Select Created0x10,Created0x30
2026-06-08 17:38:02.1147290   2026-06-08 17:38:02.1147290

C:\> Import-Csv C:\val\b.csv | Where {$_.RecordNumber -eq 184229} |
      Select StdInfoCreate,FilenameCreate
2026-06-08 17:38:02   2026-06-08 17:38:02

  Same values. One tool reports seven decimal places and
  the other truncates to the second.

One master file table, two parsers, one record compared.

Two independent implementations agreeing on the value, which is the strongest evidence available that either of them is reading the format correctly. Neither is wrong and one carries precision the other discards.

Six artifacts with the tool this course uses and an unrelated alternative.

  ARTIFACT              PRIMARY           INDEPENDENT SECOND

  $MFT                  MFTECmd           analyzeMFT, TSK istat
  Windows event logs    EvtxECmd          python-evtx, Chainsaw
  Registry hives        RECmd             RegRipper, yarp
  Prefetch              PECmd             Zircolite, w10pfdecomp
  Shortcut files        LECmd             TSK, lnkinfo
  Amcache               AmcacheParser      RegRipper plugin

  Every primary in this course has at least one unrelated
  implementation. That is what makes validation possible.

The alternatives are not equivalents and the table does not claim they are. Several are slower, several cover less of the format, and one or two produce output that needs converting before it is comparable. What they provide is independence, which is the property validation needs rather than parity.

The right-hand column is the answer to the concentration problem from the previous section. Every format this course parses has at least one implementation by somebody unconnected to the primary tool.

Two of those alternatives are search tools rather than parsers, which is worth noticing. They parse the format in order to search it, so they can be used as a second implementation even though that is not what they were built for.

That column is also the migration path if the primary suite ever stops. The formats would still be parseable and the work would still be possible, which is a materially different position from a stack with no alternatives.

The two tools in that block are genuinely independent implementations rather than two builds of one codebase, which is the whole requirement. Two front ends over the same parsing library agreeing tells you nothing at all.

The point of running two is not that one of them might be broken, which is rare. It is that agreement between independent implementations is evidence about the format itself, and that is the position the confidence module asks you to be in before a finding is challenged rather than after.

That difference is exactly the kind that surfaces in the scenario. Two examiners quoting the same record from different tools produce timestamps that disagree in their last digits, and the disagreement is a formatting decision rather than a factual one.

Four properties of this stack shape how the work gets done, and one of them is a hazard. Four things.

A fifth property is implied by all four and worth stating. This stack has no case management, no shared database and no concept of an examination as an object, so the organization of a case is a directory structure and a set of notes that you maintain, which the first module covers because nothing else will do it for you.

These four are worth reading before installing anything rather than afterwards, because two of them change how a workstation should be prepared and one of them is a hazard that has damaged real evidence.

The first row is a constraint rather than a boast, and it does exclude things. Several commercial suites are genuinely excellent and one of them may well be what your organization uses, and this course does not cover them because a reader without one would be reading rather than doing.

The second row is a genuine hazard rather than an inconvenience. Running Windows tools against a Windows image on a Windows workstation means the operating system will happily mount, index and modify evidence unless it is prevented from doing so.

The third row will feel like a step backwards to anybody used to a graphical suite, and the reason is worth understanding. A command with arguments is a record of exactly what was done, which can be pasted into notes, repeated by somebody else and quoted in a report, and none of those is true of a sequence of clicks.

The fourth row is the property that ties the stack together. Every tool in the four stages emits or consumes the same tabular format, which is why the output of a parser feeds a search tool and then a presentation tool without any conversion step.

The dispute over a single creation time, with what each examiner reported, the version each was running, and a third artifact that settles which of them describes the evidence.

  EXAMINER A: "The file was created at 17:38:02."
  EXAMINER B: "The file was created at 17:38:02.114."

C:\> MFTECmd.exe --version
  MFTECmd version 1.3.0.0

C:\> Import-Csv C:\val\a.csv | Where {$_.EntryNumber -eq 184229} |
      Select Created0x10
2026-06-08 17:38:02.1147290

C:\> Import-Csv C:\out\j.csv | Where {$_.EntryNumber -eq 184229} |
      Select -First 1 Timestamp
2026-06-08 17:38:02.1147290

  The journal, written by NTFS itself, carries the same
  precision. The truncation is the tool, not the artifact.

The two reported values, the tool version, and a third artifact that settles it.

Both examiners are correct about what their tool reported and neither reported what the artifact contains. The table stores the timestamp at sub-second precision and one tool displayed it that way.

The version command is doing more work than it appears to. A tool version recorded at the time of the examination is what makes the result reproducible, and it answers two of the eight cross-examination approaches the reporting module covers, for the cost of one line.

The third command settles it without preferring either tool. NTFS wrote the same value into the change journal, so the precision is a property of the artifact, and a report that quoted the truncated value understated what the evidence establishes.

Every tool in this course does one of four things. Acquisition produces a copy you can work on safely and tells you nothing about its contents. Parsing turns a proprietary format into rows and has no opinion about which rows matter. Searching returns the subset that matched and cannot explain why. Presentation makes a result readable and citable without changing it. Knowing which stage a tool serves prevents the commonest confusion, which is expecting a parser to find the compromise for you.

Fifty-eight distinct tools appear in the code blocks of this course and every one of them is free, which is a deliberate constraint rather than a virtue: a course you cannot follow along with teaches reading rather than doing. The parsers are single-purpose because each artifact format is genuinely its own problem, and the payoff is that a format change breaks one tool rather than a suite, and that tool can be fixed the week Windows changes rather than in its vendor's next quarterly release. Their output is uniform even though their inputs share nothing, which is what lets a stack of small tools behave like a suite without being one.

Twenty-five of those fifty-eight come from a single author, including six of the seven most-used tools in the course, and that concentration is worth stating rather than hiding. The mitigation is knowing the formats well enough to move if you need to. And validation belongs before casework rather than after a dispute: parsing one artifact with two independent tools and comparing a single record is the strongest available evidence that either is reading the format correctly, and where they differ the difference is usually formatting rather than fact, which is exactly the disagreement that gets two examiners quoting different timestamps for one record.