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
| Artifact | Question it answers | Question it does NOT answer |
|---|---|---|
| Prefetch | Did 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 |
| AmCache | What was installed or executed, with paths and SHA1 hashes? | Every execution; coverage depends on Windows version |
| $UsnJrnl | What file changes occurred, in what order, on the volume? | Why the change happened or which process did it alone |
| $MFT | What files exist(ed) and what do both timestamp sets say? | Content of the file or the modifying process |
| Memory process list | What 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.
