Forensic Working Practice: Verified Tools, Known-Data Validation and Reproducible Sessions

Introduction

The four sections before this one were about the evidence and where it lives. This one is about your own work rather than the machine's, which is the part that gets attacked first whenever a finding is disputed by somebody competent.

By the end of this section you will be able to establish that a forensic tool is the one its author actually published, validate a parser against data whose truth you established yourself rather than against another parser, record an analysis session so that somebody else can rebuild it from your notes months afterwards, and stop a Windows examination workstation from quietly writing to the evidence it is examining, then demonstrate that it did not.

None of this is about the artifacts. All of it is about being able to answer the question of how you know your own output is what the evidence says.

Forensic tools are downloaded from the internet by people who are about to run them directly against evidence, which makes them an unusually attractive thing for somebody to tamper with.

Read the three questions across the top. All of them are about your work rather than the machine you are examining, and all of them are answerable before a case arrives rather than during one.

C:\> certutil -hashfile C:\tools\MFTECmd.exe SHA256
SHA256 hash of C:\tools\MFTECmd.exe:
c81e728d9d4c2f636f067f89cc14862c8814a41c82b4d5e04c1f8a92b6d70389

  Compare against the hash published on the release page.

C:\> Get-AuthenticodeSignature C:\tools\MFTECmd.exe |
      Select Status,SignerCertificate

Status              SignerCertificate
Valid               CN=Eric R Zimmerman

C:\> Get-FileHash C:\tools\*.exe -Algorithm SHA256 |
      Export-Csv C:\case\tool-hashes.csv -NoTypeInformation

Two checks on one binary, and a record of both kept with the case.

Two independent checks on one binary. The hash establishes that the file matches what the publisher released and the signature establishes who signed it, and a tool that fails either does not go near evidence.

One session, recorded from the first command to the last.

C:\> Start-Transcript -Path C:\case\NGE-WKS-4471\session-2026-06-11.log
Transcript started, output file is
  C:\case\NGE-WKS-4471\session-2026-06-11.log

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

C:\> MFTECmd.exe -f "E:\C\$MFT" --csv C:\out --csvf mft.csv
Processed 1,043,882 records in 00:01:14

C:\> RECmd.exe -f "E:\C\Windows\System32\config\SYSTEM" --csv C:\out
Error: hive is dirty, replay transaction logs first

C:\> Stop-Transcript
Transcript stopped, output file is
  C:\case\NGE-WKS-4471\session-2026-06-11.log

The transcript filename carries the machine and the date, which matters once a case involves more than one endpoint. A single log covering three machines is considerably harder to use as evidence about any one of them than three logs are.

The version query as the first working command is a habit worth adopting. It puts the version into the same record as the commands it produced, which means the two can never drift apart the way a separately maintained tool inventory does.

Everything typed and everything returned, written to a file named for the machine and the date, from one command at the start of the session.

The record count on the successful command is worth having too. It states how much was parsed, so a later query returning fewer rows than expected can be checked against what the parse actually produced rather than against an assumption.

The failed command in the middle is the reason to keep the whole transcript rather than the successes. It records that a hive could not be parsed on this attempt, which explains a gap in the findings and shows the step that must have followed it.

There is a distinction worth drawing between the two checks in that block. A hash establishes that a file is byte-for-byte what was published, which requires knowing the published value. A signature establishes who signed the binary and that it has not been altered since, which requires nothing external at all, so it is the check available when you cannot find a published hash.

There is a related question about what to do when a tool has no published hash and no signature, which is common with research parsers. The answer is not to refuse it, because several of the best parsers in this field are somebody's personal project. It is to record where you obtained it, on what date, and its hash as you received it, so that at minimum the binary you used is identified even if its provenance is not certified.

There is an ordering point worth stating about this whole section. Everything in it happens before evidence arrives, and that is not a scheduling preference. A tool hashed after it has been used, a validation run after a finding, and a transcript started halfway through a session are each worth considerably less than the same act performed at the right time, and in the first case worth almost nothing.

There is a reason this threat is real rather than theoretical. Forensic tools are searched for by name and downloaded from whatever result appears first, which is a distribution channel an attacker can influence, and a tampered parser could alter output without any visible failure at all.

The third command is the one that matters later. Hashing every tool once, into a file kept with the case, answers a question that arrives months afterwards and cannot be reconstructed from memory.

The toolstack section established running two independent parsers over one artifact and comparing them. This is the other half of validation, which is running one parser over an artifact whose contents you already know because you created them.

  BUILD THE GROUND TRUTH

  1. On a clean virtual machine, note the time and run
     a distinctive binary once.
  2. Create a file with a known name in a known folder.
  3. Write a known registry value.
  4. Note all three times from your own clock.
  5. Shut down and image the disk.

  THEN PARSE IT

C:\> PECmd.exe -d E:\C\Windows\Prefetch --csv C:\val
C:\> Import-Csv C:\val\*_PECmd_Output.csv |
      Where {$_.ExecutableName -match "TESTBIN"} |
      Select RunCount,LastRun
1    2026-06-08 14:02:11

  Your notes say 14:02:11 and one execution. They agree.

Five actions performed and noted, then the parser run against the result.

Comparing two parsers tells you whether they agree. Comparing one parser against something you did yourself tells you whether it is right, which is a stronger statement and the only one available when a format has a single implementation.

There is a second class of thing a ground-truth image validates that has nothing to do with parsers. It validates you, because building one requires performing the actions this course examines and then looking for them, which is the fastest way to learn what an artifact looks like when the answer is already known.

There is a specific failure this catches that nothing else does. A parser that reads a format correctly and interprets a timestamp in the wrong zone produces output that is internally consistent, agrees with a second parser making the same assumption, and is wrong by a fixed offset, and only a comparison against a time you wrote down yourself exposes it.

There is a practical shortcut on the image that makes this achievable rather than aspirational. A small virtual machine, a handful of noted actions and a snapshot is an afternoon of work once, and the resulting image validates every parser you will ever add to the stack rather than only the ones you have today.

There is a second thing a ground-truth image gives you that is easy to overlook. Because you know exactly what happened on it, you also know what did not, so it establishes what an artifact records when nothing of interest occurred, which is the baseline every finding is implicitly compared against.

That distinction is worth keeping clear. Agreement between tools is evidence about the format; agreement with ground truth is evidence about reality, and a validation image built once is reusable across every case afterwards.

A record made while working is a different thing from an account written afterwards, and four properties separate them. Four things.

The first row is a distinction people collapse and should not. Recording that you installed version 1.3.0.0 says what was on the machine at some point; recording that this command was run by version 1.3.0.0 says what produced this column, and tools get updated in the middle of long cases.

The second row is why the command line is not a preference in this field. A sequence of clicks cannot be pasted into a log, and a command can, which is what makes a graphical step harder to account for than a typed one.

The fourth row is the difference between a record and an account, and it is the one that fails under questioning. Anything written afterwards is a reconstruction of what you would have done, which is honest and is not evidence, and the gap between the two only becomes visible when somebody disputes a step.

The third row is the one people edit out and should not. A parser that failed on one hive explains why a finding rests on four sources rather than five, and without the record the gap looks like an omission.

A Windows examination workstation is still a Windows machine, and Windows is built to be helpful to whatever storage it encounters, which on an evidence drive is precisely the wrong behavior.

  ATTACH AN EVIDENCE DRIVE TO AN UNPREPARED WINDOWS BOX

  the volume is mounted read-write automatically
  a System Volume Information folder is created
  the search indexer begins indexing it
  thumbnail caches are generated for image folders
  a recycle bin is created for the volume

C:\> reg query "HKLM\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies" ^
      /v WriteProtect
    WriteProtect    REG_DWORD    0x1

C:\> certutil -hashfile \\.\PhysicalDrive2 SHA256 > C:\case\pre.txt
  ... work ...
C:\> certutil -hashfile \\.\PhysicalDrive2 SHA256 > C:\case\post.txt
C:\> fc C:\case\pre.txt C:\case\post.txt
FC: no differences encountered

What an unprepared Windows machine does to an attached volume, then the two things that stop it.

Five modifications to evidence, none of them requested and all of them performed by a helpful operating system doing what it was designed to do. This is the hazard the toolstack section named and did not develop.

One case on disk, and which parts of it could be rebuilt.

  CASE DIRECTORY, ONE MACHINE

  C:\case\NGE-WKS-4471\
    evidence\      the image, and its hash on arrival
    out\           every CSV a parser produced
    val\           the ground-truth comparison for this case
    session-2026-06-11.log
    session-2026-06-12.log
    tool-hashes.csv
    notes.md       decisions, and why they were taken

  Everything except evidence\ is regenerable. Everything
  in notes.md is not, which is why it is the file to
  write in while working rather than afterwards.

The toolstack section noted that this stack has no case management and no concept of an examination as an object, which is what makes a directory layout necessary rather than tidy. Nothing will organize the case for you and nothing will notice if you do not.

A layout rather than a standard, and its value is that the same shape is used on every case so nothing has to be remembered about where a given thing was put.

The evidence directory is the one that has to be treated differently from the rest. It holds the image and the hash it arrived with, nothing in it is ever written to, and every tool in the course reads from a mounted copy rather than from the file itself, which is the arrangement the acquisition module establishes and everything afterwards depends on.

Two session logs rather than one is deliberate too. A case worked across several days produces a record per day, which keeps each file readable and makes the sequence of the examination visible in the filenames alone.

The distinction at the bottom is the useful one. Parsed output can be regenerated from the image at any time, so losing it costs an afternoon, and the reasoning behind a decision exists only if somebody wrote it down while taking it.

There is an indexing consequence specific to this course worth flagging. The search index section of the communications module reads an artifact that records file contents, and an unprepared workstation will happily index the evidence drive into its own search database, which is both a modification of evidence and a contamination of your own machine.

There is a wider habit implied here about the examination environment. Knowing what your own machine does unasked is a prerequisite for reading what a suspect machine did unasked, and the two are the same skill applied in two directions.

There is an ordering point about the registry setting worth knowing. It takes effect for devices attached after it is set rather than for anything already mounted, and it applies to removable devices rather than to everything, so a hardware write-blocker remains the stronger control and this is the software fallback.

The last three commands are the answer rather than the software write-blocker alone. Hashing the device before and after and comparing the two is what turns write protection from something you configured into something you can demonstrate.

Four practices that belong to this discipline are taught where they are used rather than listed here. Four things.

The first two rows are covered by this module rather than deferred, which is worth saying so the card is not read as four postponements. Corroboration and examination order both appear in the first section, and what the timeline module adds later is the arithmetic rather than the principle.

The third row is the one worth being explicit about. Integrity is a real practice and it is taught where an examiner meets a real challenge to it, because a list of principles read in an orientation module does not survive contact with a case.

The four in this card are also the four that get taught badly when they are taught early. Corroboration explained before a student has seen two artifacts disagree is a rule to memorize, and corroboration explained at the moment two sources conflict is a technique. Placement is doing real work here rather than saving space.

This card exists because an orientation module can easily become a summary of everything the course will say, which teaches nothing and reads as filler. Naming what is deliberately absent, and where it lives instead, is more useful than a preview of it.

The fourth row is the same argument applied to reporting. Every section in this course closes by saying what its evidence does not establish, so the habit is built ninety-three times rather than described once here.

The examiner asked which version produced a column, and whether the drive was protected.

  ASKED:  which version of the parser produced this column?
          was the evidence drive write-protected?

  WITHOUT RECORDS
    "I always use the current version."
    "I always enable write protection."
    Both are claims about habit rather than about this case.

  WITH RECORDS
C:\> Select-String -Path C:\case\session.log -Pattern "MFTECmd.exe -f"
2026-06-08 09:14:22  MFTECmd.exe -f E:\C\$MFT --csv C:\out --csvf mft.csv

C:\> Import-Csv C:\case\tool-hashes.csv | Where {$_.Path -match "MFTECmd"} |
      Select Version,Hash
1.3.0.0   c81e728d9d4c2f636f067f89cc14862c...

C:\> fc C:\case\pre.txt C:\case\post.txt
FC: no differences encountered

The two questions answered from habit, then answered from records.

Both questions are also entirely reasonable ones to ask. Neither implies the examiner did anything wrong, and both are the kind of routine verification any competent reviewer performs, which is why having the answer ready matters more than having done the thing.

The examiner very likely did both things correctly. Without a record there is no way to demonstrate it, and a claim about what you always do is an answer about your habits rather than about this examination.

Four standard challenges, and the file that answers each.

  ASKED IN CROSS-EXAMINATION        ANSWERED BY

  how do you know your tools were   the hash file, written
  not tampered with                 before the case

  how do you know the parser read   the ground-truth image,
  that field correctly              built before the case

  what exactly did you run          the session transcript

  did your workstation alter the    the before and after
  evidence                          device hashes

  Four questions, four files, none of them created
  in response to being asked.

Those four are drawn from the eight standard approaches to cross-examining an expert that the reporting module works through, and specifically from the four that attack the fact basis rather than the credentials. Half of that attack surface is closed by an afternoon of preparation before any case arrives.

Every answer in the right-hand column is a file, and every one of those files was created before anybody asked the question it answers.

The right-hand column also explains why this is the last section of the orientation module rather than a note in the first. It is the work that makes everything in the following ten modules defensible, and it has to be done before Module 1 rather than alongside it.

That is what separates this section from advice. None of these four can be produced on demand, so the practice is not a standard to aspire to but a set of artifacts that either exist by the time somebody asks or do not.

There is a pattern across all four practices in this section worth naming at the end. Each of them costs a few minutes at a moment when nothing appears to be at stake, and each of them is the entire answer to a question asked much later by somebody who is not inclined to take your word for it.

There is a second question in that pair that is harder than the first. Which version produced a column is answerable from a transcript, and whether the drive was protected is answerable only if somebody thought to hash the device at both ends, which is a step with no immediate payoff at the time it is taken.

There is a broader point in that contrast that goes past this course. An examiner's credibility rests on being able to account for their own process, and the eight-month gap is what makes memory useless, because everything an examiner remembers by then is their general practice rather than this particular case.

The three commands cost nothing at the time. A transcript line, a hash file written once and a pair of device hashes are minutes of work during the case and are the entire answer to a challenge eight months later.

The four sections before this one were about the evidence and this one is about your own work, which is what gets attacked first when a finding is disputed. Forensic tools are downloaded from the internet by people about to run them against evidence, which makes them worth tampering with, so a hash against the publisher's value and a signature check are what establish that the binary is the one its author released. Hashing every tool once into a file kept with the case answers a question that arrives months later and cannot be reconstructed from memory.

Validation has two halves and the toolstack section covered one of them. Running two parsers over one artifact establishes whether they agree, which is evidence about the format. Running one parser over an artifact you built yourself, with times you noted from your own clock, establishes whether it is right, which is evidence about reality and the only option when a format has a single implementation. A ground-truth image built once is reusable across every case afterwards.

A session record has to carry the version that produced this output rather than the version you installed, the exact command including every switch, and the things that failed as well as the things that worked, because an examination log containing only successes is a summary rather than a record. And the machine you work from is itself a hazard: an unprepared Windows workstation will mount an evidence volume read-write, create folders on it, index it and generate caches, all unasked and all because that is what Windows is for. Write protection is what stops it, and hashing the device before and after is what lets you demonstrate that it did.