The Artifact Analysis Methodology

Step 1: Identify — which artifacts answer this question?

Every analysis begins with a question — not with a tool. The investigation question determines which artifacts are relevant, which are primary, and which provide corroboration. Opening MFTECmd output before defining what you're looking for leads to data browsing. Defining the question first focuses the analysis.

The Identify step maps the investigation question to specific artifact categories using the artifact selection matrix from WF0.2 and the investigation scope from WF0.10. For the question "did the subject copy files to USB between March 1 and March 15?" the artifact mapping is: primary sources are USN Journal (FILE_CREATE events with parent references to removable media), MFT timestamps (files on the USB volume or copied from network to local), and SYSTEM registry USBSTOR (device connection history with timestamps). Corroborating sources are ShellBags (did the user navigate to the USB drive?), LNK files (did the user open files from the USB?), SRUM (data transfer volumes to the removable media device), and Event Logs (USB device connection events 20001/20003).

The quality gate for this step: at least two independent artifact sources must be identified as potentially answering the question before analysis proceeds. If only one source exists, the finding will be limited to a single-source confidence level — which should be documented in advance, not discovered at the end.

Step 2: Extract — collect the raw artifacts

The Extract step collects the specific artifacts identified in Step 1 from the evidence source. If the evidence is a KAPE collection, the artifacts may already be extracted — the $MFT, registry hives, Prefetch files, and Event Logs are in the KAPE output directory. If the evidence is a forensic image, mount the image read-only and extract the needed artifacts.

Document the extraction: what was extracted, from where (image name, partition, path), when (UTC), the extraction tool and version, and the hash of the extracted file. This documentation is your provenance chain — it traces every analysis result back to a specific location in the original evidence.

The quality gate: every extracted artifact file has a verified hash recorded in the examination log. If an artifact file is corrupted (bad hash, truncated, zero bytes), document the corruption and note which analysis capabilities are affected.

Step 3: Parse — process and validate

The Parse step processes raw artifacts into human-readable form using forensic tools, then validates critical findings against the raw data.

Run the appropriate tool: MFTECmd for the $MFT, PECmd for Prefetch files, SBECmd for ShellBags, EvtxECmd for Event Logs, RECmd or Registry Explorer for registry hives, SrumECmd for the SRUM database. Output to the case's output\ directory in CSV format for analysis in Timeline Explorer.

After parsing, identify the records that answer the investigation question. These are the critical records — the specific MFT entries, Prefetch files, ShellBag entries, or Event Log records that will support findings in the report. For each critical record, perform raw validation: open the original artifact in a hex editor, navigate to the record, and confirm the tool's interpretation matches the raw data. Document the validation result.

The quality gate: every critical finding has been raw-validated. Non-critical findings (contextual data, pattern analysis across thousands of records) do not require individual validation but should be spot-checked for consistency.

Step 4: Correlate — cross-reference across sources

The Correlate step is where single-source data points become multi-source evidence. For each critical finding from Step 3, identify the corroborating evidence from independent artifact sources and verify consistency.

Correlation works at the temporal level (do the timestamps from different sources agree within expected tolerances?), the entity level (do the file references, paths, and user identifiers from different sources refer to the same file, folder, or user?), and the logical level (do the findings from different sources tell a consistent narrative, or are there contradictions that need investigation?).

Conflicts between sources are informative. If the MFT timestamp says a file was created on January 15 but the USN Journal shows a FILE_CREATE entry on March 28, the conflict itself is a finding — it indicates either timestomping, a copy operation with timestamp preservation, or (rarely) a parsing error. Investigate the conflict before concluding.

The quality gate: every critical finding in the report is supported by at least two independent artifact sources, and any conflicts between sources have been investigated and resolved (or documented as unresolved with the impact on finding confidence stated).

Step 5: Conclude — state the finding with confidence

The Conclude step produces the finding statement: a precise claim about what the evidence proves, at what confidence level, supported by what sources, subject to what limitations, and having considered what alternative explanations.

A well-formed finding has five components: the claim (what the evidence proves — stated precisely), the confidence level (high, moderate-high, moderate, low — with rationale based on source reliability and corroboration), the evidence sources (specific artifacts, specific records, specific fields), the limitations (what the evidence does not prove, what artifacts were unavailable, what assumptions were made), and the alternative explanations (other interpretations of the evidence that were considered and assessed).

The quality gate: every finding has documented alternative explanations. This is not pro forma — the examiner genuinely considers how else the evidence could be interpreted and documents why the stated conclusion is more supported than the alternatives. This practice prevents confirmation bias and prepares the examiner for cross-examination, where the first question will be "is there an alternative explanation for this evidence?"

Troubleshooting

"The five-step process seems slow for triage situations." The methodology scales to the context. For SOC triage: Identify (which artifact answers "is this a true positive?" — 30 seconds), Extract (the artifact is already in the EDR or SIEM — 0 seconds), Parse (query or tool output — 1 minute), Correlate (check one additional source — 2 minutes), Conclude (true positive/false positive — 30 seconds). Total: 4 minutes. For a court-facing examination: each step takes hours. The methodology is the same; the depth scales to the consequence of the findings.

"What if I find something unexpected during Step 3 that changes the investigation questions?" Good — that's how real investigations work. Document the new finding, add the new question to the investigation scope, and loop back to Step 1 for the new question. The methodology is iterative, not linear. A ransomware investigation may start with "how did the attacker get in?" and, during MFT analysis, discover evidence of data exfiltration that adds "was personal data exfiltrated?" to the scope. Document the scope change and continue.

"How detailed should the examination documentation be?" Detailed enough that a different examiner can reproduce your analysis from your notes. This means: the specific tool commands you ran (or screenshots), the specific filters you applied, the specific records you examined, the raw validation results, and the correlation logic. If the finding is "Prefetch proves 7z.exe executed on March 15 at 14:22:18" your notes should include the PECmd command, the relevant CSV row, the raw validation of the timestamp, and the corroborating USN Journal entry. For non-critical contextual analysis, a summary is sufficient.