MCFE Study Guide: Build Artifact-to-Source Discipline

Study for the MCFE by building artifact-to-source discipline: for every finding you report, practice stating the originating artifact, where it lives, how its timestamps encode time, and its evidentiary limits. Compare similar artifacts side by side, work through realistic scenarios where the obvious interpretation is the fragile one, and check readiness with a rubric rather than a guessed score.

From Tool Finding to Defensible Source: Attribution as the Core MCFE Skill

Examiner-level work requires connecting each reported value to a named artifact, a storage path, a timestamp encoding, and a stated limitation. Training yourself to make those four attributions for every finding converts tool output into evidence reasoning you can defend.

Artifact-to-source discipline means that whenever you see a value in your analysis tool, you stop and record four things: the artifact name (for example UserAssist or a browser visits table), the file or hive it came from, the timestamp encoding used by that record, and what the artifact structurally can and cannot prove. Run this as a written drill on practice images rather than as mental shorthand, because under assessment conditions the naming step is what separates a matched finding from a matched guess.

Contrast two findings to see the difference in confidence: a parsed row in a live application database is structurally different from a string match in unallocated space, even when both point to the same activity. The first supports a claim about a specific record with its own encoded timestamp; the second supports only a claim that the data existed somewhere in the image. Practicing this contrast on the same image, with both findings written up in full, is the fastest way to internalize why attribution wording changes with the source.

Windows Execution Artifacts: Shimcache, Amcache, Prefetch, and UserAssist Distinguished

These artifacts all relate to program activity but record different events with different limitations. Confusing them leads to overstated conclusions, so learn each one's structure, storage location, and timestamp behavior as a distinct unit.

Shimcache (the Application Compatibility Cache) stores file paths and file metadata used by the application compatibility subsystem; its recorded timestamps relate to file modification times and its entries do not by themselves prove a program was executed. Amcache records information about installed binaries and drivers and associated first-run metadata. Prefetch provides execution evidence on client Windows systems through files that record program runs and loaded resources. UserAssist tracks graphical launches of user-facing programs under each user's hive, with counts and last-execution times. Each belongs to a specific hive, folder, or system component, which is exactly the attribution detail to drill.

Scenario 1: The investigation question is whether a specific remote-access utility ran on a workstation on a given date. A plausible mistake is citing the Shimcache entry's timestamp as the moment the program was executed. The better decision is to treat Shimcache as evidence the file was present and processed by the compatibility subsystem, then corroborate execution with Prefetch files and Amcache entries, noting which artifact carries which kind of time. This matters because a report claiming execution occurred at a specific time based on Shimcache alone can assert timing the artifact does not structurally support, and a competent challenge would expose that gap. Drill the distinctions with the table below rather than flashcard definitions, because the difficulty lives in the overlap: several artifacts can be cited for the same program, and your job is choosing the one that supports the specific claim being made.

• Shimcache: file paths and metadata from the compatibility subsystem; not an execution log.
• Amcache: installed binary and driver information plus associated first-run metadata.
• Prefetch: execution evidence on client Windows systems, including resource loads per run.
• UserAssist: user-specific GUI launch records with counts and last-execution times.

Timestamp Semantics: File System Times, Epoch Encodings, and Time Zones

A timestamp is meaningless until you know its source, its encoding, and its time zone handling. File system times, browser epoch values, and application timestamps behave differently, and hand-conversion practice exposes assumptions your tool hides.

NTFS file system timestamps record access, modification, creation, and record-change events, and they shift when files are copied or moved in ways that depend on how the operation was performed. Browser and application databases use their own encodings: Chrome-family history uses a 64-bit value counting 100-nanosecond intervals since 1601, while many Unix-lineage formats count seconds since 1970. Practice converting both by hand, then set your tool's time zone deliberately and confirm you understand whether it is re-rendering the same instant or merely relabeling it.

Exercise: take ten rows from a practice browser history database and convert each raw timestamp manually to UTC, then compare against your tool's displayed value under two different time zone settings. Expected observations: the tool's rendered wall-clock time changes with the setting while the underlying instant does not; the 1601-based values convert to dates roughly 369 years earlier in their epoch than 1970-based values of similar magnitude; and values that display identically in the tool may have come from artifacts with different encodings. Self-check: you can convert both encodings unaided and state, for any displayed time, which encoding produced it.

Internet and Email Artifacts: History, Cache, Cookies, and Recovered Records

Web history, cache, and cookies answer different questions about user activity, and deleted-record recovery is a separate interpretive step. Reporting strength should match which artifact produced the finding and whether the record was active or recovered.

History tables record visit events with page titles, URLs, and their own timestamps; cache stores retrieved content that may persist after the visit record is gone; cookies record site state and can outlive both. Deleted-record recovery reads records marked deleted that remain in database free pages, while carving finds data structures without their original database context. Treat these as four different claim types: a visit occurred, this content was retrieved, the site stored state, and deleted records were recoverable in a given state.

Application drill: on a practice image, find one URL that appears in history, in cache, and in a recovered deleted record, then write three report sentences, one per source, each with different evidentiary wording. A plausible mistake to practice against is reporting a recovered deleted history row as a user visit at the row's timestamp without noting its deleted state; the better decision phrases it as a deleted record present in the database with that recorded time. This matters because the deleted-state qualifier changes what the finding can support about user intent and timing, and conflating active with recovered records is an interpretation error, not a tool error.

What Memory Adds: Volatile Evidence Disk Images Cannot Show

Memory captures running processes, active network connections, loaded code, and decrypted content at a single instant. Knowing what memory uniquely contributes, and that it is a snapshot, lets you pair it correctly with disk artifacts.

A memory image can show processes running at capture time with their full paths, network connections in flight, code injected into legitimate processes, and content that only existed decrypted in RAM, such as open documents or keys held by running software. Console history and other session state may also survive in memory but not on disk. These are categories to learn structurally: process-level, connection-level, code-level, and content-level volatile evidence, each answering a different investigative question.

Pairing drill: take a practice scenario with both disk and memory sources and cross-check the process list against file system artifacts for the same binaries. Expected observations: a process in memory whose binary path has no corresponding Shimcache or Prefetch activity may indicate a different launch mechanism; a binary present on disk with no process in memory shows the snapshot limitation of memory in the other direction. State in your write-up that memory reflects only the capture instant, because a reviewer needs to know that absence of activity in memory does not mean absence of activity overall.

Mobile Extractions: Matching Finding Strength to Logical, File System, and Physical Data

Logical, file system, and physical mobile extractions reach different data and support different deletion claims. Choose the extraction level that fits the question, and interpret application databases with their journal and write-ahead structures in mind.

A logical extraction retrieves accessible data through device interfaces; a file system extraction reaches deeper structures and can include data not exposed at the logical level, including some deleted records depending on the method; a physical image captures the raw storage where supported. Device models, operating system versions, and access methods determine what any given approach yields, so the same technique is not equally available across devices. The attribution habit from earlier applies directly: name the extraction level, the data store, and the record state.

Scenario 2: The question is whether a deleted chat message existed and when it was sent. A plausible mistake is reading a message timestamp from a recovered database row and reporting it as the send time of a deleted message. The better decision is to examine the database's journal and write-ahead log files to establish the record's state, phrase the finding as a record present in the application database with a recorded timestamp of that value, and note the extraction level that made the record visible. This matters because the WAL can hold transaction content not yet merged into the main database, so record state and timestamp semantics both change what the finding can honestly support.

A Four-Week Preparation Sequence with Readiness Checks and a Self-Check Rubric

Sequence preparation by artifact family rather than by tool feature: acquisition and file systems first, then registry, then internet, email, and memory, then mobile and integration. Close each week with a written exercise and score yourself against a rubric of milestones.

Adaptable sequence: Week 1, work an acquisition-and-preservation module, then practice file system analysis by identifying timestamp behavior for copied and moved files on a practice image. Week 2, registry week: build the execution-artifact table yourself and run the Shimcache scenario end to end. Week 3, internet and email artifacts in the first half, memory pairing in the second. Week 4, mobile extraction levels and the chat-message scenario, then a capstone integrating one finding from each family into a single short report. Shift the weekly weighting toward whichever topics your own baseline rubric scores lowest.

Rubric and readiness checks: score each category from 1 to 4, where 4 means you produced the attribution in under three minutes without notes. Check that you can, unaided: name the artifact, path, timestamp encoding, and limitation for any finding you highlight; convert both epoch formats by hand; distinguish active records from recovered deleted records in your wording; explain the three mobile extraction levels and what each supports about deletion; and pair a memory finding with a disk artifact in a two-sentence report note. These scores are learning milestones for pacing your own study, not predictions of any exam result.

For administrative details of the credential itself, such as current eligibility, scheduling, and format questions, rely on the issuer's own materials at magnetforensics.com rather than third-party summaries, since those logistics change and are outside the scope of this study approach.

• Week 1: acquisition, preservation, and file system timestamp behavior.
• Week 2: Windows registry artifacts and the execution-artifact comparison.
• Week 3: internet and email artifacts, then memory-to-disk pairing.
• Week 4: mobile extraction levels, integration capstone, and full rubric run.
• Readiness check: every finding in a practice report names artifact, path, timestamp semantics, and limitation.

References and further reading

Use these references to explore the concepts and check the latest information from the relevant organizations.

• magnetforensics.com

Continue your preparation

• Magnet Certified Forensics Examiner Mcfe
• Study Guides