In this section
Evidence Reliability and Tool Validation
Scenario
Your investigation has Prefetch evidence showing a credential harvesting tool executed (run count 1, loaded samlib.dll and wdigest.dll) and Shimcache evidence with execution flag True, but no Amcache entry for the tool. The executable is still on disk. Two sources confirm execution. Is the missing Amcache entry a concern? It could mean Amcache was cleared (cleanup indicator), the tool avoided Amcache registration, or a parsing error. You rate the finding HIGH, document the absence, and investigate why the third source is missing. The absence itself might reveal anti-forensic activity.
What "proves" means in forensic context
Figure WF0.6 — Evidence reliability hierarchy. High-confidence artifacts prove claims directly. Lower-confidence artifacts require corroboration. All critical findings should have at least two independent artifact sources.
Forensic proof is not mathematical proof. When an examiner states that Prefetch "proves" execution, they mean the existence of a Prefetch file created by SysMain, with execution timestamps and run count, establishes execution to the standard required for professional opinion. The proof is probabilistic: theoretical scenarios exist where Prefetch could be fabricated, but they are sufficiently unlikely and detectable that the evidence supports a reliable conclusion.
The confidence framework has four levels. High confidence: the artifact directly establishes the claimed fact through a well-understood mechanism resistant to casual manipulation. Moderate-high: strong support with minor caveats that should be noted. Moderate: supports the claim under stated conditions the examiner must verify. Low: consistent with the claim but does not prove it.
Filesystem artifact reliability
MFT existence (file existed): High confidence. An MFT record cannot be fabricated through normal operations. A "not in use" record proves the file existed but was deleted. $FN timestamps (creation time): High confidence. Set by the NTFS kernel driver, not modifiable through Windows API. Caveat: on copied files, $FN reflects copy time, not original creation. $SI timestamps: Moderate confidence. Modifiable by user-mode applications; cross-check against $FN and USN Journal for critical findings. USN Journal (file operations): Moderate-high. Append-only during normal operation, but wraps at maximum size and can be deleted entirely by administrators. Absence of entries does not prove absence of operations. $I30 slack (deleted filenames): Moderate. Reliable when present, but absence is not meaningful.
The distinction between "high confidence from present evidence" and "no conclusion from absent evidence" is fundamental. Prefetch presence proves execution. Prefetch absence does not prove non-execution: the file may have been deleted, the service disabled, or the directory at capacity (1024 files). Document the reason for absence whenever an expected artifact is missing.
Execution artifact reliability
Prefetch: High confidence. Created by SysMain, records last 8 execution timestamps (Windows 8+), run count, and referenced files. Strongest single-source execution evidence. Caveats: disabled by default on Windows Server, can be deleted. Amcache: Moderate-high. SHA1 hash is independently verifiable against threat intelligence. Exact population trigger has changed across Windows versions and some researchers found entries for scanned-but-not-executed files.
This is what an Amcache entry looks like when parsed with AmcacheParser. The SHA1 hash is the field that makes Amcache invaluable for threat hunting:
The SHA1 hash can be checked against VirusTotal, MISP, or any threat intelligence platform. The missing publisher for a file named svchost_update.exe is itself a finding. The MFT file reference (48271) links this Amcache entry to the same MFT record you would examine in MFTECmd output.
Anti-Pattern
Treating tool output as evidence without analysis
Tool output is data. Evidence is data that has been validated, interpreted in context, assessed for reliability, and documented with provenance and limitations. MFTECmd reporting a $SI timestamp is data. The examiner interpreting that timestamp after verifying against $FN, checking OS version context, assessing timestomping indicators, and documenting limitations is evidence. A forensic report that presents tool output without analysis is a data dump, not an examination.
Shimcache: Moderate on Windows 10+ (with execution flag), low on pre-Windows 10 (no execution flag, only compatibility evaluation). Populated on shutdown, not real time, so may miss executables deleted between shutdowns. BAM/DAM: Moderate-high when available. Provides user-level attribution (SID) that other execution artifacts lack. Introduced Windows 10 1709, behavior varies across builds. UserAssist: Moderate. GUI launches only (not command-line, not scheduled tasks, not services). Run count has known accuracy issues on some Windows versions.
User activity artifact reliability
ShellBags: Moderate-high. Prove folder navigation in Explorer. Persist after folder deletion. Caveats: timestamps indicate first/last access but may update from view settings changes. LNK files: Moderate-high. Prove a file was opened (not read, modified, or exfiltrated). Persist after target deletion. Machine identifier links activity to specific computer. Jump Lists: Moderate-high. Per-application file history. Distinguish between pinned items (intent) and recent items (access). Can be cleared by user.
The corroboration standard
Investigation Principle
Every critical finding in a forensic report should be supported by at least two independent artifact sources. A critical finding is any conclusion that determines scope (what was accessed), attribution (who did it), timeline (when it happened), or impact (what was the consequence). When opposing counsel challenges one source, the examiner responds with independent corroboration from the others. Conflicts between sources are informative, not problematic: investigating them often reveals evidence that single-source analysis would miss.
A single high-confidence source is sufficient for a reportable finding. But a critical finding that drives the investigation's conclusion should be supported by multiple sources. "The subject exfiltrated 4.7GB via OneDrive between March 1 and March 15" needs SRUM upload volumes, USN Journal file copy entries, ShellBag folder navigation, and MFT timestamps establishing the file creation timeline.
Limited evidence is reality, not a methodology failure. Assess what you have, rate confidence based on available sources, and document what is missing and why. A finding stated at moderate confidence with documented limitations is honest and defensible. A finding stated at high confidence when evidence only supports moderate will be exposed under scrutiny.
Common analysis issues
"Multi-artifact corroboration sounds ideal but impractical — I don't have time to check every finding against multiple sources." You don't corroborate every data point. You corroborate critical findings — the conclusions that drive the investigation's outcome. A typical investigation report has 5-15 critical findings. Corroborating each against 2-3 sources adds hours, not days, to the analysis. The alternative — presenting uncorroborated findings that collapse under challenge — costs far more in credibility and case outcome.
"What if the corroborating sources conflict?" Conflicts are informative, not problematic. If the MFT timestamp says the file was created on March 15 but the USN Journal shows a FILE_CREATE entry on March 28, you have discovered either timestomping, a copy operation, or a tool parsing discrepancy. Investigating the conflict often reveals evidence that a single-source analysis would have missed entirely. Document the conflict, analyze the cause, and report the assessment. A finding that acknowledges and resolves a conflict is stronger than a finding that never encountered one.
"Some investigations only have limited artifacts available: the system was reimaged, the logs were cleared, the MFT was partially overwritten." Limited evidence is reality, not a methodology failure. Assess what you have, rate your confidence based on the available sources, and document what is missing and why. A finding stated at moderate confidence with documented limitations is honest and defensible. A finding stated at high confidence when the evidence only supports moderate is dishonest and will be exposed under scrutiny.
Scenario
MFTECmd output shows a file with Created timestamp "0001-01-01 00:00:00," a null timestamp. The file is an attacker tool you need to establish a creation date for. Is the timestamp genuinely null (possibly set by the attacker), or did MFTECmd fail to parse the raw bytes? You open the MFT record in a hex editor, navigate to the $SI attribute, and read the 8-byte FILETIME. If the raw bytes are all zeros, the null is genuine. If they contain a valid FILETIME, you've found a parsing failure and recovered the real timestamp. You also check $FN Created, which the attacker may not have thought to zero.
Why good tools produce bad output
Figure WF0.8 — Four categories of parser errors. Each has a different detection method: hex comparison, visual inspection, OS version verification, or record count comparison.
A forensic parser is a software implementation of a specification. When the data conforms to the specification, which is the overwhelming majority of the time, the parser produces correct output. Errors occur when data deviates from what the parser expects: valid but uncommon structures, unusual character encodings, different OS format versions, or corrupted/malformed data.
The critical insight is that parser errors are silent. The CSV row containing an incorrect timestamp looks identical to the row containing a correct one. The only detection mechanism is the examiner's knowledge.
Structure misinterpretation: attribute ordering
The most common structure error in MFT parsing involves attribute ordering. NTFS does not mandate a specific order for attributes within a record. Most parsers assume $STANDARD_INFORMATION first, then $FILE_NAME (long name), then $FILE_NAME (short name). After disk repair with chkdsk, filesystem migration, or certain backup/restore sequences, the attribute order can change.
When a parser assumes the first $FILE_NAME is the long filename, it works correctly in 99% of cases. When the short name comes first, the parser reports CONFID~1.DOC instead of Confidential_Board_Report_Q3.docx. The validation is straightforward: when a filename looks like an 8.3 short name in tool output, check the raw MFT record for additional $FN attributes. MFTECmd handles this correctly in current versions, but the examiner should understand the underlying issue because other tools may not.
This example illustrates why raw validation matters. The tool truncated the fractional seconds, which in this case would have incorrectly flagged the file as a timestomping candidate (zero fractional seconds is a timestomping indicator from Section 1.9). The raw hex shows the timestamp has full nanosecond precision, indicating a natural file creation. Without raw validation, the examiner would have pursued a false lead.
A related issue involves extension records. When attributes don't fit in a single 1024-byte MFT record, NTFS allocates extension records linked via an $ATTRIBUTE_LIST. Parsers must follow these references to find all attributes. If the parser fails to follow a reference, it reports incomplete data: missing timestamps, missing data run information, or missing ADS references. Extension records are more common on files with long filenames, multiple ADS, or large security descriptors. When MFTECmd reports a file with missing columns, check whether the MFT record has an $ATTRIBUTE_LIST attribute pointing to extension records.
Encoding errors: when filenames break
Windows filenames use UTF-16LE encoding. Problems arise with characters outside the Basic Multilingual Plane (supplementary characters requiring surrogate pairs), embedded null characters, characters with special CSV meaning (commas, quotes, newlines in filenames), and filenames created by non-Windows systems writing to NTFS. A file named with Chinese, Arabic, or emoji characters that renders as ????.docx needs raw verification: open the MFT record in a hex editor and read the UTF-16LE bytes in the $FILE_NAME attribute directly.
Version mismatches: the Shimcache problem
Version errors are the most dangerous category because the tool reports a technically correct value that the examiner incorrectly interprets. The Shimcache is the canonical example: on Windows XP and 7, Shimcache entries correctly indicated execution. On Windows 10+, entries are created during the Application Compatibility lookup, which occurs when an executable's attributes are accessed, not necessarily when it executes. Browsing a directory containing an executable, copying it, or antivirus scanning it can create an entry. ShimCacheParser correctly reports the execution flag when present. The error occurs when the examiner treats presence as execution proof without checking the Windows version and the flag value.
Anti-Pattern
Using multiple tools to validate instead of raw hex
Running two tools on the same artifact and getting the same result does not validate the finding. Many forensic tools share parsing logic, common libraries, or the same specification interpretation. If the specification is ambiguous on an edge case, multiple tools make the same incorrect assumption. The definitive validation is comparing tool output against the raw binary in a hex editor. Two tools agreeing that a timestamp is "2026-01-15 09:00:00" means two parsers read the same bytes and produced the same result. It does not answer whether the timestamp is genuine or timestomped.
When to validate and when to trust
Always validate: Timestamps that establish critical timeline points. Artifacts that are the sole source for a critical finding. Anything that will be cited in testimony or a legal-facing report. Anything that shows characteristics inconsistent with its context.
Validate when suspicious: Filenames that appear truncated, garbled, or as 8.3 short names. Timestamps with zero nanoseconds. Records with unusual field values. Tool output reporting errors, warnings, or skipped records during parsing.
Trust without validation: Routine records used for context. Bulk data for pattern analysis. Artifacts from well-understood, stable formats on current OS versions with current tool versions.
Investigation Principle
You don't validate every artifact. You validate the artifacts that support critical findings. A typical investigation report has 5-15 critical findings. Validating each against raw data adds 5-15 minutes per finding, totaling 1-2 hours for the entire report. That is the cost of defensible findings. The alternative is presenting uncorroborated output that collapses when challenged.
When you find a tool error, document it precisely: tool name and version, input artifact, expected output from raw analysis, actual tool output, and the specific discrepancy. Report the issue to the tool developer. In your forensic report, use the raw-validated value. Eric Zimmerman has GitHub Issues pages for each tool and is responsive to well-documented bug reports. The fix benefits every examiner who uses the tools.
Common analysis issues
"I don't know hex well enough to read raw MFT records." You will by the end of WF1. This course teaches raw analysis progressively: WF0 introduces the concept, WF1 provides the MFT record walkthrough at the byte level, and subsequent modules cover each artifact format's binary structure. The investment in learning hex interpretation for a few key structures (MFT record header, $SI attribute, $FN attribute, USN record, EVTX record header) is manageable and pays returns across every investigation.
"What if I find a tool error: what do I do?" Document the error precisely: tool name and version, input artifact, expected output (from raw analysis), actual output (from the tool), and the specific discrepancy. Report the issue to the tool developer (Eric Zimmerman has a GitHub Issues page for each tool, and he is responsive to well-documented bug reports). In your forensic report, use the raw-validated value. Not the tool's output. Note the discrepancy in your methodology section if it is relevant to the finding.
"Tool versions update frequently: how do I keep track of which versions have which known issues?" Use the current version. Update before each engagement. The EZ Tools changelog documents every fix. Skim it when you update to understand what was corrected. For court testimony, document the exact tool version used in your examination notes. If a defense expert challenges a finding by citing a bug that existed in an earlier version, you can demonstrate you used a version where the bug was fixed.
Get weekly detection and investigation techniques
KQL queries, detection rules, and investigation methods — the same depth as this course, delivered every Tuesday.
No spam. Unsubscribe anytime. ~2,000 security practitioners.