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 — typically as a CSV, a table, or a formatted report. 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 — because the parser encountered an edge case it wasn't designed to handle, because the artifact format changed in a Windows update the parser hasn't accounted for, or because an attacker manipulated the artifact in a way the parser doesn't detect — 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. The examiner incorporates it into their findings because they have no reason to doubt it.

This distinction matters in exactly 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. A defense attorney's expert witness. A regulator's technical reviewer. An insurance company's forensic assessor. Opposing counsel in an employment dispute. Each of these adversarial reviewers has the ability and motivation to examine the raw artifact and compare it to the examiner's interpretation. 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.

Three failure modes of tool-dependent analysis

The first failure mode is 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. The parser was written to handle the common case correctly, and it does. But NTFS is a specification with decades of accumulated complexity, and forensic artifacts can exist in states that the parser's developer never encountered in testing. When the parser encounters these states, it either produces incorrect output silently or skips the record entirely.

Consider an MFT record with multiple $FILE_NAME attributes — one for the long filename and one for the short (8.3) filename. The common case has two $FN attributes: the long name first, the short name 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 — particularly after disk repair operations, file system migration, or certain backup/restore sequences — the short name can appear before the long name. A parser that assumes ordering extracts the 8.3 filename as the primary name: 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 — not because the conclusion was wrong (the file was accessed), but because the evidence was presented incorrectly.

The second failure mode is version-specific behaviors — the artifact's meaning changes across Windows versions, and the examiner applies the wrong interpretation. The most significant example is the 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 Windows 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. A Shimcache entry on Windows 10 proves the operating system evaluated the executable for compatibility. It does not prove the executable ran. An examiner who states "the Shimcache proves this program executed" on a Windows 10 system is making a factually incorrect claim that will be challenged by any competent opposing expert.

The third failure mode is anti-forensic evasion — the attacker modifies the artifact before the examiner collects it, and the tool reports the modified data as if it were genuine. Timestomping is the canonical example: the attacker uses a tool like SetMACE or PowerShell's Set-ItemProperty to modify the $STANDARD_INFORMATION timestamps on a malicious executable, setting the creation time to match other files in the same directory. The MFT parser dutifully reports the modified timestamps. The examiner builds a timeline that shows the executable was created six months ago, consistent with a legitimate installation. 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 MFT output 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 (which records the file creation at the real time), and identifies the timestomping. The tool reported the same data in both cases. The difference is what the examiner knows to look for.

When artifact knowledge is mandatory

Artifact-level understanding is not required for every investigation. Routine SOC triage — is this alert a true positive, does it require escalation, what's the initial scope — can be performed effectively with tool output alone. The volume and speed demands of SOC work make raw artifact analysis impractical for every alert. The triage analyst's job is to classify and escalate, not to produce court-defensible findings.

Artifact-level understanding becomes mandatory when the investigation's findings will face adversarial scrutiny. Four contexts trigger this requirement.

Court testimony. When the examiner testifies as an expert witness, opposing counsel will probe the methodology. "How do you know this timestamp is accurate?" "Could this artifact have been modified?" "Have you verified your tool's output against the raw data?" The examiner who answers "my tool reported this value" has provided a conclusion based on an intermediary's interpretation. The examiner who answers "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 entry at this USN offset" has provided a conclusion based on direct evidence examination.

Regulatory notification. GDPR Article 33 requires notification "without undue delay" with "the nature of the personal data breach" including "the categories and approximate number of data subjects concerned." The examiner's assessment of what data was accessed — based on filesystem artifacts — directly determines the notification scope. An incorrect assessment (over-reporting or under-reporting) has regulatory consequences. The artifact analysis must be accurate.

Insurance claims. Cyber insurance claims require documented evidence of the incident, the scope of impact, and the remediation performed. The insurer's forensic assessor will review the examiner's methodology and evidence. Findings that rely solely on tool output without raw verification can be challenged, potentially affecting claim resolution.

Internal investigations with consequences. When an employee faces termination, disciplinary action, or legal proceedings based on forensic findings, those findings must be defensible. Employment tribunals, arbitration proceedings, and internal grievance processes can all examine the quality of the forensic evidence. The standard may be lower than criminal court, but the methodology must still be sound.

The raw-first principle

This course follows a raw-first principle: every artifact is first examined at the binary level — in a hex editor, with the field structure annotated — before any tool output is shown. This is not because tools are bad. It is because understanding what the tool is parsing 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 the first timestamp is creation time, the second is modification time, the third is entry modification time (MFT record change), and the fourth is access time. 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 output, you know exactly what it parsed and from where. If the timestamp looks suspicious, you know to check the $FILE_NAME attribute's timestamps for comparison, because $FN timestamps are set at file creation and modified only by the NTFS driver — not by user-mode applications.

Without this understanding, the MFTECmd output is a black box. The CSV contains timestamps, and you trust them because the tool is reputable. The raw-first approach converts that black box into a transparent process where every output value traces to a specific location in the raw artifact.

.\KAPE\kape.exe --tsource C: --tdest C:\Evidence\MFT --target MFT --vhdx MFT_Extract

What this course builds

This course builds three capabilities that tool-dependent analysis cannot provide.

The first is 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. This is not about memorizing hex offsets. It is about understanding the data structure well enough that when you see a tool's output, you know what the tool parsed and whether the interpretation is correct for your specific evidence and OS version.

The second is anti-forensic detection — the ability to identify when an artifact has been manipulated, deleted, or fabricated. Tools report what they find. They do not report what is suspicious about what they find. A timestomped file, a cleared event log, a deleted Prefetch folder — each leaves traces that artifact-aware analysis can detect and tool-dependent analysis cannot.

The third is multi-artifact correlation — the ability to corroborate findings across independent artifact sources. A single artifact source provides a data point. Two independent sources providing consistent data points provide evidence. Three or more independent sources provide strong evidence. Correlation is not just about building a more complete timeline — it is about building a more defensible one, where every key finding has independent corroboration.

Troubleshooting

"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.