Why Artifacts Matter More Than Tools

The tool is not the evidence

A forensic tool is a parser. It reads a binary structure, interprets the fields according to a specification, and outputs human-readable results. MFTECmd reads the Master File Table and outputs file records with timestamps, paths, sizes, and attributes. PECmd reads Prefetch files and outputs execution timestamps, run counts, and referenced files. AmcacheParser reads the Amcache.hve registry hive and outputs program execution records with SHA1 hashes and file paths.

The tool is not the evidence. The artifact is the evidence. The MFT record is the evidence. The Prefetch file is the evidence. The Amcache entry is the evidence. The tool is an intermediary that translates binary data into human-readable form. When the translation is accurate, the tool saves hours of manual analysis. When the translation is inaccurate, the tool produces incorrect output that looks exactly like correct output. There is no warning. There is no error flag. The CSV row looks like every other row.

This distinction matters in four professional contexts: court testimony, regulatory notification, insurance claims, and internal investigations with HR or legal consequences. In each context, the examiner's findings will be examined by someone whose job is to find weaknesses. If the examiner's interpretation was based entirely on tool output, and the tool output was wrong, the finding collapses and it takes every other finding in the report with it, because the examiner's methodology is now in question.

The history of digital forensics confirms this. EnCase had known issues with timestamp interpretation in certain NTFS configurations. FTK had Unicode filename rendering issues that caused evidence attribution errors. Even Eric Zimmerman's tools have had version-specific bugs identified only through raw artifact comparison. MFTECmd version 1.2.2.0 had an issue with certain $FILE_NAME attribute orderings where multiple hard links existed. The bug was identified, reported, and fixed because a practitioner compared tool output against raw hex. The point is not that tools are unreliable. The tools are excellent. The point is that every parser is a software implementation of a specification, and software implementations have bugs.

Three failure modes of tool-dependent analysis

Parser errors. The tool misinterprets the binary structure of the artifact. This happens most commonly with edge cases: MFT records with unusual attribute ordering, Prefetch files from uncommon Windows versions, registry values with non-standard encoding, Event Log records that span chunk boundaries.

Consider an MFT record with multiple $FILE_NAME attributes. The common case has two $FN attributes: the long filename first, the short (8.3) filename second. A parser that assumes this ordering and extracts the "primary" filename from the first $FN attribute works correctly in 99% of cases. But NTFS does not guarantee this ordering. In certain conditions (disk repair operations, filesystem migration, certain backup/restore sequences) the short name can appear before the long name. A parser that assumes ordering extracts IMPORT~1.XLS instead of Important_Financial_Data_Q3_2026.xlsx. The examiner's report states the subject accessed a file named IMPORT~1.XLS. The defense's expert opens the same MFT record in a hex editor, identifies both $FN attributes, and correctly identifies the long filename. The examiner's credibility is damaged.

Version-specific behaviors. The artifact's meaning changes across Windows versions, and the examiner applies the wrong interpretation. The most significant example is Shimcache (Application Compatibility Cache). On Windows XP and Windows 7, a program's presence in the Shimcache was widely cited as evidence of execution. On Windows 10 and 11, the Shimcache records programs that are in the execution path but may not have actually executed. The cache is populated during the executable compatibility lookup, which occurs before execution. An examiner who states "the Shimcache proves this program executed" on a Windows 10 system is making a factually incorrect claim.

Version-specific behavior affects nearly every artifact category. Prefetch files have had four major format versions (17 in XP, 23 in Vista/7, 26 in 8/8.1, 30 in 10/11). Amcache underwent a complete restructure between Windows 8 and Windows 10. BAM and DAM registry keys that provide excellent execution evidence on Windows 10 versions 1709-1809 were deprecated in later versions. The examiner who treats all Windows versions as identical will eventually produce an incorrect finding.

Anti-forensic evasion. The attacker modifies the artifact before collection, and the tool reports the modified data as genuine. Timestomping is the canonical example: the attacker modifies the $STANDARD_INFORMATION timestamps on a malicious executable, setting the creation time to match other files in the directory. The MFT parser reports the modified timestamps. The examiner builds a timeline showing the executable was created six months ago. The actual creation time, preserved in the $FILE_NAME attribute which timestomping tools typically do not modify, was two hours ago.

A tool-dependent examiner reads the CSV, sees the timestamps, and builds their timeline around them. An artifact-aware examiner compares the $SI timestamps against the $FN timestamps, notices the discrepancy, correlates with the USN Journal, and identifies the timestomping. The tool reported the same data in both cases. The difference is what the examiner knows to look for.

This is what the discrepancy looks like in MFTECmd output. The Created0x10 column is the $SI timestamp (user-modifiable). The Created0x30 column is the $FN timestamp (NTFS-driver only):

Entry  ParentPath                     FileName              Created0x10                 Created0x30
48271  .\Windows\Temp                 svchost_update.exe    2025-08-15 09:00:00.0000000 2026-03-18 02:13:02.3456789  ◄ $SI predates $FN by 7 months
48272  .\Windows\Temp                 config.log            2026-03-18 02:13:04.1234567 2026-03-18 02:13:04.1234567
48273  .\Windows\Temp                 debug_output.txt      2026-03-18 02:14:11.8901234 2026-03-18 02:14:11.8901234
48274  .\Windows\System32             notepad.exe           2024-09-14 17:22:08.4567890 2024-09-14 17:22:08.4567890

Record 48271 is the finding. The $SI Created timestamp (2025-08-15) predates the $FN Created timestamp (2026-03-18) by seven months. Normal files have $SI and $FN Created within the same second. The $SI timestamp also has zero nanoseconds (.0000000), indicating programmatic timestamp setting rather than a genuine file operation. The surrounding files (48272-48274) show normal sub-second precision and matching $SI/$FN values. This is a classic timestomping pattern: the attacker backdated svchost_update.exe to blend with legitimate system files.

When artifact knowledge is mandatory

Artifact-level understanding is not required for every investigation. Routine SOC triage can be performed effectively with tool output alone. The volume and speed demands of SOC work make raw artifact analysis impractical for every alert.

Artifact knowledge becomes mandatory when findings face adversarial scrutiny. Court testimony requires the examiner to explain provenance: "I verified this value against the raw MFT record at offset 0x38 of attribute type 0x10, and I confirmed it through cross-correlation with the USN Journal." Regulatory notification under GDPR Article 33 requires accurate assessment of what data was accessed, directly determining notification scope. Insurance claims require documented evidence methodology that the insurer's forensic assessor will review. Internal investigations with termination or legal consequences require findings that survive employment tribunals and grievance processes.

The raw-first principle

This course follows a raw-first principle: every artifact is first examined at the binary level before any tool output is shown. This is not because tools are bad. It is because understanding what the tool parses is a prerequisite for trusting what the tool reports.

When you examine an MFT record in hex and identify the $STANDARD_INFORMATION attribute at offset 0x38, you understand that the four timestamps starting at that offset are 8-byte Windows FILETIME values representing 100-nanosecond intervals since January 1, 1601. You understand that these timestamps are in the $SI attribute, which is modifiable by user-mode applications including timestomping tools. When MFTECmd reports these timestamps in its CSV, you know exactly what it parsed and from where. Without this understanding, the output is a black box.

What this course builds

This course builds three capabilities that tool-dependent analysis cannot provide. Artifact interpretation: the ability to read a forensic artifact at the binary level and understand what each field means, what created it, and what it proves. Anti-forensic detection: the ability to identify when an artifact has been manipulated, deleted, or fabricated. Multi-artifact correlation: the ability to corroborate findings across independent artifact sources, building defensible conclusions where every key finding has independent corroboration.

You don't examine every artifact at the raw level. You use tools for bulk processing and raw analysis for critical findings: the malware executable, the staging directory, the exfiltration path, the critical timeline entries. A typical investigation might process 10,000 MFT records with MFTECmd and raw-verify 15 of them. The raw verification adds minutes, not hours. The defensibility it provides is permanent.

Common analysis issues

"I've been doing DFIR for years with tools and never had a finding challenged." That may be true, and it may reflect that your findings were accurate — tools are correct most of the time. It may also reflect that your findings were never subjected to adversarial scrutiny. The shift from internal triage to legal proceedings, insurance claims, or regulatory notification changes the standard. The question is not "has my methodology been challenged?" but "would my methodology survive challenge?"

"Raw analysis takes too long for real investigations." You don't examine every artifact at the raw level. You use tools for bulk processing and raw analysis for critical findings — the ones that determine scope, attribution, or timeline. A typical investigation might process 10,000 MFT records with MFTECmd and raw-verify 15 of them: the malware executable, the staging directory, the exfiltration path, and the critical timeline entries. The raw verification adds minutes, not hours. The defensibility it provides is permanent.

"The tools I use are well-maintained and frequently updated." They are. Eric Zimmerman's tools are among the best-maintained forensic parsers available. That doesn't eliminate edge cases — it reduces them. The changelog for any EZ Tools release includes bug fixes that were only identified because users compared tool output against raw data. Those bug fixes are evidence that the tools are not infallible — and that the forensic community's standard practice includes raw verification.