Study Guide

GCFA Study Guide: Matching Windows Artifacts to…

A GCFA study approach built on artifact-to-question mapping: NTFS layers, execution evidence, memory triage, timelines, and anti-forensics, with worked…

Updated September 20269 min readStudy GuideCert Forensic
Diana Mason

Diana Mason

Cert Forensic Editorial Team

Study the GCFA by building a mapping from investigative questions to the artifacts that answer them: execution evidence (Prefetch, ShimCache, AmCache), filesystem change history ($MFT, $UsnJrnl, $LogFile), memory-resident activity (processes, handles, injection), and timeline corroboration. Then drill scenarios where the obvious artifact gives a misleading answer and a second artifact corrects it. Use the readiness checks at the end as milestones, not score predictions.

Problem 1: You know the artifact names but not which question each one answers

Organize your study around questions, not tool lists. Each Windows artifact answers a narrow question about execution, modification, connection, or account use; knowing that mapping is what lets you triage a system quickly.

Start with four question families: what ran, what changed, what connected, and who did it. Evidence-of-execution artifacts such as Prefetch and AmCache address the first; $UsnJrnl and $LogFile address the second; network artifacts in memory and logs address the third; registry and event log artifacts address the fourth. Write your own table mapping every artifact in the GCFA objectives to the question it answers and the one it does not.

Then test the mapping in reverse. Pick an artifact and ask what it cannot tell you: Prefetch does not prove a program succeeded, ShimCache does not by itself prove execution, and the $MFT alone cannot show that file content changed. Building both directions of the mapping turns recall into decision-making, which is what a scenario-based forensics exam and a real intrusion both demand.

  • What ran: Prefetch, AmCache, ShimCache, memory process list
  • What changed: $MFT, $UsnJrnl, $LogFile, registry transaction logs
  • What connected: memory network artifacts, event logs, jump lists
  • Who did it: event log account correlation, registry user artifacts
ArtifactQuestion it answersQuestion it does NOT answer
PrefetchDid this executable run, and which files did it touch early?Whether the run succeeded or when it was installed
ShimCache (AppCompatCache)Was this binary present and interacted with by the loader?Execution by itself; entries can exist without a run
AmCacheWhat was installed or executed, with paths and SHA1 hashes?Every execution; coverage depends on Windows version
$UsnJrnlWhat file changes occurred, in what order, on the volume?Why the change happened or which process did it alone
$MFTWhat files exist(ed) and what do both timestamp sets say?Content of the file or the modifying process
Memory process listWhat is running right now, including injected code?What already exited and left only disk traces

Problem 2: Timestomping hides in the gap between two NTFS timestamp sets

NTFS stores four timestamps in $STANDARD_INFORMATION and a second, kernel-maintained set in $FILE_NAME. Anti-forensic tools edit the first set; comparing both sets is how you detect and correct manipulated times.

Worked scenario: a timeline shows a malicious DLL created at 2020-01-01 00:00, suspiciously matching the OS install date. A plausible mistake is to accept the $MFT created time and place the implant in the wrong era. The better decision is to compare $STANDARD_INFORMATION against $FILE_NAME for the same MFT record: $FILE_NAME cannot be edited by the common user-mode timestomping APIs, so a large mismatch is strong evidence of tampering, and the $FILE_NAME times approximate true file-system events.

This matters because a compromised timeline poisons every downstream conclusion, including scope and containment decisions. Note the limits of the inference: $FILE_NAME updates are conditional and not a perfect substitute, so corroborate with $UsnJrnl entries around the suspected event and with evidence from a second system. Practice computing both timestamp sets from a raw MFT record until the comparison is automatic rather than an afterthought.

Problem 3: Execution artifacts disagree, and the disagreement is the finding

Prefetch, ShimCache, and AmCache record different lifecycle events with different retention and deletion behavior. Treat their agreement as corroboration and their disagreement as an investigative lead, never as a tool error.

Worked scenario: an attacker ran a renamed copy of a living-off-the-land binary and then deleted the original. Prefetch still shows the renamed executable with its loaded-file list; ShimCache shows the binary's path from when it first appeared; AmCache may retain the original path and hash. The plausible mistake is declaring the finding unreliable because timestamps differ by hours. The better decision is to explain the difference: each artifact captures a different moment, so the spread itself reconstructs the sequence of installation, execution, and cleanup.

This distinction matters for attribution and for scoping. If you report only the earliest ShimCache time as the execution time, you may understate how long an implant persisted or miss that the file was renamed during the intrusion. Rehearse writing one sentence per artifact stating what event it records; if you cannot, the artifact does not yet belong in your timeline.

Problem 4: Memory triage must answer the normal-versus-abnormal question before tool output convinces you otherwise

Memory forensics requires preserving volatility first, then differentiating normal Windows behavior from injected code, hollowed processes, and rootkits, starting with baseline processes, their parents, and their command lines.

Worked scenario: a memory image shows svchost.exe running from a user-writable path with an unusual parent. The plausible mistake is treating any svchost listing as noise because the name is familiar. The better decision is to check the structural expectations that the objectives emphasize: the legitimate image path, the parent process, the session, the handle set, and whether the process has executable memory regions that do not map to a file on disk.

Order of operations matters as much as the finding. Collecting volatile data means documenting what you ran, hashing output, and capturing the most volatile state first, because shutdown destroys memory evidence and reboots hand the attacker a clean slate. Drill with a lab image: list processes, flag deviations from your baseline expectations, then verify one flagged process with a second plugin or method before calling it malicious.

  • Baseline first: expected process names, paths, parent-child chains, sessions
  • Cross-check executable regions against on-disk files to surface injection
  • Document collection commands and hash outputs to preserve integrity
  • Verify one abnormal finding with an independent artifact before reporting

Problem 5: A raw timeline is data, not analysis, until you normalize and pivot

Timeline analysis means collecting time sources from multiple layers, normalizing them into one clock, and then pivoting on a single suspicious event to expand context in both directions.

Build timelines from more than the $MFT: layer in $UsnJrnl change-journal entries, event logs, registry transaction activity, and memory-resident command-line artifacts. Each source has its own time basis and gaps, so the working skill is superposition: placing entries from different sources in one sequence and marking which source each entry came from so conflicting times stay visible instead of being silently overwritten.

Then practice the pivot that the objectives call rapid assessment: choose one high-signal event, such as an unexpected service creation, and expand forward and backward around it across all sources. Limit each pivot window so the timeline stays readable, and annotate which conclusions rest on one source versus corroboration. Rehearse this on a small image until you can produce a defensible narrative paragraph, not just a spreadsheet of rows.

Problem 6: Anti-forensics is compensated for with redundancy, not with a single clever check

Attackers clear logs, timestomp files, and use in-memory tooling. Compensation comes from layered, independent sources whose deletion leaves traces, plus documented reasoning about what is missing.

For each anti-forensic action, learn the counter-trace rather than the counter-tool. Clearing event logs produces its own event; timestomping leaves the $STANDARD_INFORMATION to $FILE_NAME mismatch; deleting a file touches $UsnJrnl even when the file content is gone; memory-resident execution leaves no Prefetch but does leave process artifacts in a captured image. Frame each pair as an attacker action followed by the residual artifact you can still query.

Equally important is stating limits honestly in your analysis. If a source is absent, record whether it was cleared, rolled by log size, or never present on that configuration, because those are different conclusions with different scoping implications. Practice writing a one-paragraph gap statement for an image where the attacker cleared logs: what you can still support, what you cannot, and what additional system you would collect next.

Problem 7: A preparation sequence that rehearses decisions, not flashcards alone

Sequence your preparation in four passes: objectives mapping, artifact drills on real images, timed scenario decisions, and a final readiness check against a rubric. Admin details live with the issuer, not this guide.

Weeks one and two: take the published objective statements from GIAC and write your own artifact-to-question table for each, filling gaps with hands-on work on freely available forensic images. Weeks three and four: drill the three scenario types above, NTFS timestamp comparison, execution-artifact disagreement, and memory triage, writing a short justification for each decision as if for a report. Note for administrative specifics such as format, scheduling, and passing standards for your attempt, rely on your GIAC account and the issuer's page.

Final phase: run a full triage exercise on one image under a self-imposed time limit, then score it with the rubric below. Treat the rubric as a learning milestone: it checks whether your reasoning is complete, not whether you will hit a passing score. Repeat the cycle on a fresh image until the mapping decisions feel routine, then use practice exam style questions to tune pacing and question-reading.

  • Rubric check 1: For every finding, you can name the artifact and the question it answers
  • Rubric check 2: Every timestamp claim states both NTFS timestamp sets or explains why only one is available
  • Rubric check 3: Every abnormality is corroborated by a second independent source or flagged as unverified
  • Rubric check 4: Gaps in evidence are explained with one of: cleared, aged out, or not present by design
  • Rubric check 5: Your timeline narrative fits in a paragraph a non-specialist could follow

References and further reading

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

Continue your preparation

FAQ

Frequently Asked Questions

Practical answers to help you apply the guidance for GIAC Certified Forensic Analyst (GCFA).

How is the GCFA different from other digital forensics certifications?
GCFA, per GIAC's overview, focuses on advanced incident response scenarios: APT intrusions, anti-forensic techniques, memory forensics, and timeline analysis, rather than broad multi-platform forensics. Anchor your study to the published objective statements rather than to generic forensics checklists.
Do I need to memorize every registry key and structure offset?
Prioritize understanding what each artifact records, when it updates, and how it can be spoofed or lost. Exact offsets are best learned by parsing a real MFT record once or twice; conceptual behavior is what lets you answer scenario questions and justify decisions.
How should I practice memory forensics safely and legally?
Work only with images you are authorized to use, such as publicly published sample memory images and your own lab virtual machines. Practice the full sequence: capture or acquire documentation, baseline the process list, then investigate abnormalities with corroborating output.
How do I know when my preparation is sufficient?
Use the readiness rubric in the final section: if you can consistently produce an artifact-to-question mapping, a two-timestamp analysis, and a corroborated finding narrative on a fresh image without notes, your reasoning is in exam-relevant shape. Treat any score-like milestone as a learning gauge, not a passing prediction.
Which tools should I learn for GCFA-level work?
Learn at least one memory analysis framework, one timeline creation pipeline, and one NTFS parser, and know where their outputs overlap. The decision skill, choosing which artifact answers which question, transfers across tools; tool-specific quirks you can re-look up in the lab.

Keep Reading

Related Study Guides

Explore related guides and preparation topics.