GCFE Study Guide: Correlating Windows Forensic Artifacts

Treat GCFE preparation as learning to correlate Windows artifacts, not to recite their paths. GIAC's published scope covers Windows forensics and triage, Registry forensics, USB devices, shell items, email, event logs, advanced browser analysis for Chrome, Edge, and Firefox, and cloud storage artifacts, delivered through CyberLive performance-based labs. Organize study around the investigative questions each objective answers, build an indexed artifact map you test yourself, and practice chaining artifacts into a timeline on Windows lab images you create and verify in your own environment. Administrative details such as scheduling and exam parameters belong to GIAC's certification page and your account.

Frame every GCFE topic as an investigative question

Organize GCFE study around questions an investigation actually asks — did this program run, was this USB device attached, what did the user browse — then learn which artifacts answer each question and what each alone cannot prove.

GIAC's published objectives group the domain into fundamentals, file and program analysis, system and device analysis, user artifacts, browser forensics, email, event logs, cloud storage, and triage techniques. Translate each grouping into a question: File and Program Analysis becomes what ran, when, and from where; System and Device Analysis becomes what was connected and who touched it. This mapping converts a long objective list into a retrieval structure you can navigate while working inside CyberLive virtual machines.

While you study each objective, maintain an indexed artifact map: for every question, list the candidate artifacts, their file or hive locations, their semantics, and their caveats. During hands-on challenges the map functions as a triage checklist rather than a memory test, and during preparation it exposes gaps immediately. Whenever you add an entry, verify it against a real Windows system in your lab, because tool behavior and artifact presence differ across Windows versions and configurations.

Map Registry hives to investigative questions, not key paths

Study the Registry by asking which hive answers which question: NTUSER.DAT and USRCLASS.DAT hold per-user activity, while SYSTEM, SOFTWARE, and SAM describe the machine, installed software, and accounts. Correlation starts here.

NTUSER.DAT captures one user's interaction history: typed Run commands, recently opened documents, GUI program launches, and per-user device mappings. USRCLASS.DAT, also user-specific, holds shell-related data such as folder browsing records and jump list components. SYSTEM records machine-wide facts including mounted volumes and attached device identity. SOFTWARE records installed programs, and SAM holds local account data. Framing each hive as the answer to a question — who, what ran, what was connected — makes cross-referencing natural during analysis.

Practical application matters because a single hive rarely stands alone. A per-user Explorer drive-letter mapping gains meaning only when paired with machine-level device identity data in SYSTEM. Also account for hive mechanics: user hives loaded from an acquired image can be marked dirty and carry transaction log files, so a parser that ignores those logs may show a stale or partial view. Verify in your lab that your tooling merges transaction logs before you trust any key value in coursework or practice.

• NTUSER.DAT: user-level launches, recent documents, typed commands, per-user volume mappings
• USRCLASS.DAT: shell and folder browsing behavior, jump list components
• SYSTEM: mounted devices, attached device identity, machine configuration
• SOFTWARE: installed applications; SAM: local account data

Execution artifacts prove different things: Prefetch vs Shimcache vs Amcache

Prefetch, Shimcache, Amcache, and UserAssist each record execution-adjacent activity with different semantics, locations, and reliability limits. Conflating them is the conceptual trap; each artifact needs its own interpretation.

Prefetch files record that a program executed, with run counts and loaded-file references, but Prefetch can be disabled and its files deleted. Shimcache, the AppCompatCache in the SYSTEM hive, records files with execution-like characteristics in order, yet entries flush lazily and a Shimcache entry does not by itself prove a program ran successfully. Amcache associates a binary with first-execution information and can include hash data. UserAssist, in NTUSER.DAT, records GUI launches by one user with counts and last-run times. Distinguishing executed from touched from associated is the core skill.

Scenario 1: tasked to determine whether an archiving utility ran, an examiner finds no Shimcache entry and concludes the tool never executed. That is a mistake, because Shimcache's lazy flushing and recording behavior make absence a weak negative. The better decision is to search the Prefetch directory for the tool, check UserAssist for a GUI launch, consult Amcache for a binary association and hash, and pivot to file-system evidence around the suspected window. Why it matters: converging artifacts, not one absent entry, make the conclusion defensible.

USB attribution: chain machine identity to a specific user profile

USB questions need two chains joined together: machine-level evidence identifying the device, and user-level evidence showing who interacted with it. Answering either half alone overstates what the evidence shows.

Machine-side, the SYSTEM hive records attached device identity and mounted volume relationships, and the setupapi device log captures driver installation events for connected hardware. User-side, shell items, shortcut files, and jump lists in a user's profile record interaction with files and folders, and NTUSER.DAT may hold per-user drive mappings. Each artifact answers a different slice of the question: what the device is, when the machine saw it, and which user's activity touches files consistent with it.

Scenario 2: an examiner finds shortcut files referencing a removable drive inside one user's profile and reports that this user copied the files onto the device. That overreaches — shortcuts show interaction with linked locations, not that writes occurred, and the profile where a shortcut appears is not proof the same user performed the underlying action. The better decision is to first establish the device identity and attachment timeline from SYSTEM and setupapi data, then correlate that timeline with shell item and registry evidence within the user's profile, and phrase the report as correlated activity rather than a single-cause conclusion.

Chrome, Edge, and Firefox: same questions, different structures

Chromium browsers (Chrome, Edge) share a structure; Firefox does not. Learn the data each engine records for visits, downloads, and sessions, and practice parsing all three, because artifact names will not match across them.

For Chromium-based browsers, history, downloads, and related records live in SQLite databases, alongside cache, session data, and preferences that reveal settings and synced account context. Firefox organizes equivalents differently, with its own SQLite schemas for places and cookies and distinct session files. The investigative questions stay constant — which sites were visited, what was downloaded, when, under which profile — but the file layout, table names, and interpretation details change, so study the engines separately and note the differences in your artifact map.

Two interpretation habits pay off. First, distinguish a history visit from a download: a URL in browsing history does not mean a file was saved, so pair history rows with the browser's download records before describing file transfer. Second, remember that browser activity is one input to user-activity questions: timestamps and site context should be checked against other user artifacts for consistency. GIAC's objectives also include cloud storage clients, so note which desktop sync solutions leave local configuration, log, or database artifacts alongside the browsers and extend your map to them.

Email and event logs: read the source format before interpreting

Email evidence varies by source — desktop client containers, webmail exports, and cloud-hosted mailboxes each store and expose data differently. Event logs likewise split by channel, each with its own purpose and forensic value.

For email, distinguish client-side containers such as Outlook data files from web-based and cloud-hosted mail such as Microsoft 365, because the artifacts you can collect and the metadata available differ between them. Practice extracting sender and recipient details, timestamps, and message content from the formats in your lab, and study how headers support tracing origin and routing. GIAC's objectives also mention mobile email sources, so note how mobile clients create server-side and device-side records that differ from desktop containers.

For event logs, learn the purpose of the major Windows channels — System, Security, and application and service-specific logs — and what each typically contributes: account activity, service and driver events, application behavior. Interpretation must respect configuration: audit settings determine what was recorded, so an event's absence is not proof of absence of activity. A useful correlation habit is matching logon-type events in Security logs against the timing of user artifacts elsewhere, so a machine-side record and a user-side record confirm one another in your timeline.

Correlation map exercise, self-check rubric, and a preparation sequence

Consolidate everything with a correlation map exercise on a lab image, score yourself against a rubric, then sequence preparation from fundamentals through browser, email, and log analysis, ending with timed triage practice.

Exercise: build or obtain a Windows lab image and generate activity yourself — install and run two programs, attach a removable device you designate, browse several sites in Chrome and Firefox, and send test email if your lab supports it. For five investigative questions (program execution, USB use, browsing, user logons, email), collect the relevant artifacts with your chosen tools, merge them into one timeline, and write a one-paragraph conclusion per question stating what the artifacts jointly support and their caveats. Expected observations include Prefetch run counts matching your launches, device records in SYSTEM matching your attachment window, and browser history rows matching your session times.

Self-check rubric — score each conclusion 0 to 2: (2) at least three independent artifacts corroborate the account and caveats are stated; (1) two artifacts or caveats missing; (0) one artifact or an unsupported claim. Aim for consistent 2s across all five questions before calling the topic complete. Suggested sequence: weeks one and two, fundamentals plus Registry hives and execution artifacts; week three, USB and shell items; week four, browsers and cloud storage; week five, email and event logs; week six, full triage runs on a fresh image under a self-imposed time limit, using GIAC's practice tests to become familiar with question style as the vendor recommends.

• Rubric milestone: three corroborating artifacts per conclusion, caveats stated explicitly
• Readiness check 1: you can merge transaction logs and explain why a hive view might be stale
• Readiness check 2: you can state what Shimcache absence does and does not support
• Readiness check 3: your USB conclusion names both device identity and user-side evidence
• Readiness check 4: your timeline reconciles event log timestamps with user artifact timestamps

References and further reading

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

• giac.org

Continue your preparation

• Giac Certified Forensic Examiner Gcfe
• Study Guides