CAWFE Study Guide: Corroborating Windows Artifacts

Study the CAWFE domains as an evidence-corroboration problem: for every Windows artifact, learn its location, what it semantically records, and its interpretation limit, then practice reconciling disagreeing sources — file system structures, registry hives, execution artifacts, memory, and event logs — before stating any finding.

From Tool Output to Corroborated Findings: the Core Study Shift

Advanced Windows forensics rewards examiners who can state what each artifact records, where it lives, and how independent artifacts confirm or contradict one finding before it becomes a conclusion.

IACIS describes its Advanced Windows Forensic Examiner (AWFE) course as a detailed study of the Windows operating system, going deeper and more specific than its foundational training. That depth translates into a study method: for each artifact you learn, write three lines — its storage location, what it semantically records, and its interpretation limit. A corroboration chain then links a primary artifact to an independent one that must agree before you accept the finding.

Apply this by trying to disprove your own conclusion, not just support it. If you believe a program ran, ask what would appear if it had not: a missing Prefetch entry, an absent Amcache record, no related event log activity. Building the disproof list for each artifact family is artifact-specific knowledge you can rehearse, and it directly mirrors the analytical reasoning an advanced Windows curriculum emphasizes over button-pushing.

When $MFT, $UsnJrnl:$J, and $LogFile Disagree on File Timestamps

File system timestamp conflicts arise because $MFT, the USN change journal, and $LogFile record different events through different mechanisms; resolve disagreements by understanding what each structure logs and when.

In $MFT, each file record carries timestamps in both the $STANDARD_INFORMATION and $FILE_NAME attributes, and the two are updated by different kinds of events — which is precisely why timestomping tools that alter one attribute leave the other comparatively intact. The $UsnJrnl:$J change journal records file system operations with reason codes such as file create, data extend, rename, and close, so a sequence of entries explains how a file reached its current state. $LogFile journals transactions and can preserve evidence of operations even where other structures were altered.

Practice this as a reconciliation drill. Pick one file in a lab image and trace its creation, modification, rename, and deletion history across all three sources. Every disagreement should be explainable by a named mechanism: a rename updates $FILE_NAME but may not touch $STANDARD_INFORMATION; a direct override of SI timestamps will not produce USN entries for the change itself. If you cannot explain a conflict with a mechanism, that gap — not a new tool — is what to study next.

What ShimCache and Amcache Actually Record — and What They Do Not

ShimCache rows and Amcache entries record different evidence — file paths with metadata versus installation or first-run indications — and neither should stand alone as proof that a program executed.

ShimCache (the AppCompatCache value under the SYSTEM hive's Session Manager key) stores file paths together with the file's last-modified time, and on some Windows versions additional execution-related flags. Amcache.hve, associated with the application compatibility infrastructure, records binaries with metadata such as file size and hashes, and on some versions first-execution times. Both structures behave differently across Windows versions, so an interpretation valid for one build can be wrong for another — a fact to verify per version, not assume.

Worked scenario: an examiner finds malware.exe in ShimCache with a timestamp on the incident date and reports that the program executed at that moment. The mistake: ShimCache's timestamp reflects the file's last-modified time, not an execution time, and entries can exist without any execution. The better decision is to corroborate before concluding: check Prefetch for run counts and last-run times, look for the binary in Amcache, and review process-creation event records where auditing was enabled. Why it matters: a report asserting execution when only presence is shown overstates the evidence and is vulnerable under review.

Attributing User Activity: ShellBags, LNK Files, and Jump Lists

User-activity questions map to specific artifacts: ShellBags show folder access per user, LNK files and Jump Lists show file interaction, and device-attachment evidence lives elsewhere.

ShellBags — stored under a user's UsrClass.dat hive — record Explorer's view settings for folders, revealing that a folder existed and was browsed, including folders on removable media or since deleted. LNK files record interaction with documents and carry volume and path information; Jump Lists aggregate per-application recent-file data in automatic destinations files. Choosing the right artifact is a mapping exercise: 'did this user browse this folder' points to that user's ShellBags; 'was this file opened' points to LNK and Jump List evidence; 'was this device attached' points to setupapi.dev.log and USB storage registry keys.

Attribution depends on hive context. A registry hive loaded from a profile directory must be tied back to that profile's security identifier and the user it maps to on the system; quoting ShellBag data without establishing that mapping weakens the finding. Also note that some ShellBag timestamps carry local-time quirks discussed in the bias section below. Practice by taking one user question and listing every artifact that could answer it, then eliminating those that answer a different question — folder presence, file opening, device attachment, or account usage.

Linking Volatile Memory Findings Back to Disk Artifacts

Memory evidence — process lists, network activity, injected code — becomes defensible when reconciled with on-disk artifacts such as Prefetch, binaries, event logs, and registry-based usage data.

Memory shows what was running at capture time: the process list, parent-child relationships, open handles, network connections, and code executing in regions not backed by a file on disk. Disk shows what was installed, run, and configured over time. The linkage concept is process-to-file reconciliation: match the image path observed in memory to the binary on disk, its Prefetch evidence, and its recorded installation or first-run data. An anomaly visible only in memory, such as executable code in an unbacked region of a system process, prompts a different follow-up than an anomaly visible only on disk.

Worked scenario: a memory summary shows a svchost-hosted service with an unusual parent process and an outbound connection. The plan: confirm the binary path on disk, check Prefetch for that path, review network usage records such as SRUM where present, and check process-creation event records — noting the conditional that such events exist only if process auditing was enabled on that system. Stating that conditionality in your notes is part of the skill: an absent event log record means nothing without knowing the audit configuration.

Timestamp Bias: Keeping a Timeline Coherent Across Time Zones

Most Windows timestamps are FILETIME values in UTC, but some artifacts record local time or are interpreted with registry bias values; a timeline built without checking bias can misplace events by hours.

FILETIME is a count of 100-nanosecond intervals since 1601, and NTFS and most registry timestamps store UTC. Local-time representation appears in some artifacts — certain ShellBag timestamp handling and some file formats that use MS-DOS-style timestamps are common examples. The SYSTEM hive's TimeZoneInformation key holds Bias, ActiveTimeBias, and DaylightBias, and ActiveTimeBias changes across daylight-saving transitions, so one constant offset may be wrong for part of your timeline.

Worked scenario: on a machine configured for a UTC+9:30 zone, an examiner reads a document LNK timestamp showing 02:00 on the 14th and places user activity at that moment. A UTC event log shows a logon at 16:30 on the 13th. The mistake: mixing a local-time artifact with UTC log data without extracting the bias from the SYSTEM hive. The better decision is to normalize every source to a common reference using the recorded bias values, then re-check the ordering. Why it matters: a nine-and-a-half-hour shift moves activity to a different calendar day, which changes the account of when the keyboard was in use.

A Preparation Sequence, Reconciliation Exercise, and Readiness Rubric

Prepare in artifact-family cycles that each end with a timeline reconciliation task, then measure readiness by whether you can produce mechanism-level explanations without notes.

A practical sequence: week one, file system structures and timestamp attributes; week two, registry hives and user attribution; week three, execution and user-activity artifacts; week four, memory-to-disk linkage; week five, event logs and network usage data. End every cycle with the same exercise on your own lawful lab media: pick one user action, find it in three independent artifacts, explain every disagreement with a named mechanism, and write the disproof list from section one. For administrative facts about the certification itself, rely on the issuer at iacis.com rather than secondhand summaries.

Expected observations and a self-check rubric (learning milestones, not pass predictions): you can map each hive — SYSTEM, SOFTWARE, SAM, NTUSER.DAT, UsrClass.dat — to the investigative questions it answers; you can explain an $MFT versus USN disagreement by mechanism; you can state the interpretation limit of ShimCache, Amcache, Prefetch, LNK, and ShellBags from memory; and you can normalize a mixed-bias timeline and show the arithmetic. If any explanation requires an artifact to behave contrary to its documented behavior, that artifact family goes back on the study list.

• Rubric item 1: hive-to-question map completed for all five major hives, with attribution caveats noted.
• Rubric item 2: one file's full history reconciled across $MFT, $UsnJrnl:$J, and $LogFile with mechanism-level explanations.
• Rubric item 3: disproof lists written for execution, folder access, and device attachment findings.
• Rubric item 4: a mixed local-time/UTC timeline normalized using ActiveTimeBias, with the daylight-saving boundary checked.
• Rubric item 5: each artifact's version-dependent behavior verified against a reference for the Windows build in your lab image.

References and further reading

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

• iacis.com

Continue your preparation

• Iacis Certified Advanced Windows Forensic Examiner Cawfe
• Study Guides