This assessment covers the core concepts from WF0 — The Forensic Artifact Landscape. All questions are scenario-based and test operational understanding, not terminology recall.
10 questions · Estimated completion: 15 minutes
Question 1. You are investigating a suspected ransomware incident on a Windows 11 workstation. The system is currently powered on and the user is logged in. You have 30 minutes before the system will be powered off for reimaging. Which collection sequence maximizes evidence preservation?
Full disk image first — this captures everything and you can analyze the image later. 30 minutes is enough for a 256GB SSD.
Memory dump first (5 minutes), then KAPE triage collection (10 minutes) while the system is still running. This captures volatile evidence (processes, connections, memory-resident malware) that will be destroyed at power off, plus locked files ($MFT, registry hives, Event Logs) that KAPE extracts from the live system. If time permits, begin a full disk image — but the volatile and KAPE collections are the priority.
KAPE triage collection first — it captures the forensic artifacts fastest. Memory dump can wait because the system isn't being shut down for 30 minutes.
Power off the system immediately by pulling the plug, then image the disk. This freezes the disk state perfectly and prevents any further evidence modification.
Question 2. An MFT record for a file named "staging.zip" shows: $SI Created = 2026-06-01 09:00:00.0000000, $FN Created = 2026-09-12 14:33:17.8274921. What is the most likely explanation?
The file was originally created on June 1 and then renamed on September 12. The rename operation updated the $FN timestamp but preserved the $SI timestamp.
The file was created on June 1 and copied to this volume on September 12. Copy operations create a new $FN timestamp (the copy time) while preserving the original $SI timestamp.
The file was likely created on September 12 (the $FN Created timestamp, which is set by the NTFS driver at file creation and cannot be modified via standard Windows APIs) and then timestomped to June 1 (the $SI Created timestamp, which was modified via SetFileTime() or a similar API). The zero nanoseconds (.0000000) in the $SI timestamp confirm programmatic setting — genuine file creation timestamps have sub-second precision from the system timer.
Both timestamps could be legitimate — different programs set timestamps differently. The $SI timestamp was set by the application that created the file, while the $FN timestamp was set by NTFS. A 3-month discrepancy can occur when applications buffer file operations.
Question 3. You are asked to determine whether an employee executed a specific program (data_export.exe) on their Windows 11 workstation. You find a Prefetch file (DATA_EXPORT.EXE-1F2E3D4C.pf) with a run count of 7 and last execution time of September 10, 2026. You also find an Amcache entry with a matching SHA1 hash. The Shimcache does not contain an entry for data_export.exe. What confidence level should you assign to the finding "data_export.exe was executed on this system"?
Moderate confidence — the absence of a Shimcache entry contradicts the Prefetch and Amcache evidence, suggesting the Prefetch file may have been fabricated to frame the employee. All three execution artifact sources should agree for high confidence.
High confidence. Prefetch provides high-confidence standalone execution evidence (created by the SysMain service, includes run count and timestamps). Amcache corroborates with a matching SHA1 hash. The absence of Shimcache is not contradictory — Shimcache is written at shutdown, and if the system rebooted multiple times since September 10, older Shimcache entries may have been rotated out of the cache. Two independent high-confidence sources (Prefetch + Amcache) support the finding.
Low confidence — Prefetch only proves that the program was in the Prefetch cache, not that it actually executed. On Windows 11, Prefetch files can be created by Defender's compatibility scanning without the program executing.
High confidence, but the run count of 7 should be reduced because Prefetch run counts are known to be inaccurate on Windows 11. Report execution but not frequency.
Question 4. During analysis of a SYSTEM registry hive, you find a service key "RemoteHealthSvc" with ImagePath pointing to C:\Windows\Temp\health_check.exe. The key's last write timestamp is September 15, 2026. The incident timeline suggests compromise began September 10. A colleague concludes the persistence was installed on September 15. Is this conclusion correct?
Not necessarily. The registry key's last write timestamp records the most recent modification to the key or any of its values — not the key's creation time. The service could have been created on September 10 (during the initial compromise) and then modified on September 15 (attacker changed the Start type, added a Description, or modified the ImagePath). To determine the actual creation time, corroborate with Event Log Event ID 7045 (service installation), the MFT creation timestamp for health_check.exe, and USN Journal entries for the executable file.
Yes — the last write timestamp on a service key is set when the service is registered, making September 15 the definitive installation date.
No — registry timestamps are unreliable because any process can modify them. The examiner should ignore the timestamp entirely and determine the creation time from Event Logs only.
The conclusion is correct because Windows only updates the Services key during service creation and deletion — not during service start, stop, or configuration changes.
Question 5. You need to prove that a user browsed the folder \\SRV-NGE-FS01\Engineering\Manufacturing\ on their Windows 11 workstation. Which artifact provides the most direct evidence of folder navigation?
The MFT, because directory entries in the MFT record for the user's profile will show references to the network share path.
ShellBags in the user's UsrClass.dat registry hive. ShellBags record every folder navigated to in Windows Explorer, including network share paths, with timestamps for first and last access. ShellBags persist even after the folder is inaccessible or the network share is offline.
The Security Event Log on the user's workstation, because network share access generates authentication events with the share path in the event data.
LNK files in the user's Recent folder, because browsing a folder creates a shortcut file pointing to the folder path.
Question 6. You discover that the Security Event Log on a compromised system has Event ID 1102 at 2026-10-22 06:12:44 UTC, indicating the log was cleared. The System Event Log shows Event ID 104 at the same time for the Security, Application, and PowerShell logs. What evidence opportunities remain, and what does the clearing event itself tell you?
All Event Log evidence is destroyed. The clearing events only tell you the logs were cleared at 06:12:44. Without the original log content, Event Log analysis is a dead end for this investigation.
Several evidence opportunities remain: (1) Volume Shadow Copies taken before 06:12:44 may contain the pre-clearing Event Logs. (2) Sysmon logs may survive if they were not cleared in the same operation — the listing shows Sysmon was deployed but wasn't mentioned in the Event ID 104 entries. (3) Centralized logs (Sentinel, WEF) contain copies of events forwarded before clearing. (4) $LogFile may contain EVTX write operations from the recent past. The clearing event itself provides: the time of cleanup (06:12:44), the logs that were cleared (Security, Application, PowerShell — but notably not System or Sysmon), and potentially the account that cleared them (Event ID 1102 includes the SubjectUserName and SubjectDomainName). The selective clearing pattern (leaving System and Sysmon intact) suggests the attacker knew to clear investigation-relevant logs but missed Sysmon — a common attacker mistake.
The clearing event tells you the attacker had administrator access (required to clear Security logs), but the evidence is limited to that single fact. The examiner should focus analysis on non-Event Log artifacts (MFT, Prefetch, Registry) instead.
Event ID 1102 is unreliable because it is generated by the clearing action itself and could have been fabricated by an attacker who injected the event to create a false cleanup narrative. The examiner should verify the clearing through independent means before reporting it.
Question 7. Your forensic report states: "Prefetch analysis confirms execution of mimikatz.exe on the compromised workstation." During peer review, a colleague asks: "Did you verify the Prefetch timestamp against the raw file?" You did not. What is the appropriate response?
Explain that PECmd is a well-validated industry tool and raw verification is not required for routine Prefetch analysis. The peer reviewer is being unnecessarily cautious.
Acknowledge the gap, go back to the evidence, and raw-validate the Prefetch timestamp. Mimikatz execution is a critical finding — it establishes credential harvesting activity and is likely to face scrutiny from opposing counsel, insurance assessors, or regulatory reviewers. Critical findings require raw validation per the five-step methodology. Update the examination notes with the validation result before finalizing the report.
Note the feedback for future reports but do not go back and validate this one — the finding is based on a reliable tool and the investigation timeline is tight. Add a general note that "tool output was relied upon without independent verification" to the methodology section.
Remove the finding from the report since it hasn't been validated. Without raw verification, the Prefetch evidence should not be cited as a finding — replace it with Amcache evidence if available.
Question 8. You are writing findings for an insider threat investigation and have strong evidence that the subject copied files to a USB device. The evidence includes: USN Journal FILE_CREATE entries to a removable volume, SYSTEM registry USBSTOR entries with the device serial number, MountPoints2 entries in NTUSER.DAT, and ShellBag entries showing navigation to the USB drive letter. However, you have no SRUM data — the SRUDB.dat file was not collected. How should you handle the missing SRUM evidence?
SRUM is not critical for USB exfiltration — the four sources you have are sufficient for high confidence. Do not mention the missing SRUM data in the report because it might raise unnecessary questions about collection completeness.
Document the SRUM data absence in the report's limitations section. Four independent sources (USN Journal, USBSTOR, MountPoints2, ShellBags) provide high confidence for the USB copy finding — SRUM would have added quantitative data transfer volume (bytes copied to the removable device) but is not required for the core finding. State: "SRUM data was not available for this examination. The data transfer volume to the USB device could not be quantified. The file copy activity is established at high confidence through four independent artifact sources as detailed below." This is honest, transparent, and does not undermine the finding.
Request a new KAPE collection that includes SRUDB.dat before proceeding with the report. The finding cannot be reported at high confidence without quantitative volume data from SRUM.
Estimate the data volume from the MFT file sizes of the copied files and report that estimate as the exfiltration volume. The MFT file sizes provide equivalent quantitative data to SRUM.
Question 9. On a Windows 10 system, you find a Shimcache entry for "lateral_move.exe" but no Prefetch file, no Amcache entry, and no Event Log process creation event. The Shimcache entry does NOT have the execution flag set. What can you conclude about whether this program executed?
The program executed — Shimcache presence is execution evidence on all Windows versions. The absence of Prefetch may indicate the Prefetch file was deleted as anti-forensics.
The program definitely did not execute — the absence of Prefetch, Amcache, and Event Log evidence, combined with no execution flag in Shimcache, proves the program was never run.
The evidence is inconclusive. On Windows 10, a Shimcache entry without the execution flag indicates the Application Compatibility subsystem evaluated the executable — but this can occur without execution (browsing the directory, copying the file, antivirus scanning). The absence of Prefetch, Amcache, and Event Logs is consistent with either non-execution or anti-forensic deletion of execution artifacts. The finding should be stated as: "lateral_move.exe was present on the system and evaluated by the Application Compatibility subsystem. Execution could not be confirmed or ruled out from available artifacts." Additional investigation should check the USN Journal for the executable's creation and deletion timestamps, and check for anti-forensic indicators (Prefetch directory gaps, Event Log clearing).
The Shimcache entry is false positive — on Windows 10, Shimcache entries without the execution flag are created by Windows Defender scanning and should be excluded from analysis entirely.
Question 10. You are assigned to INC-NE-2026-1130 (unauthorized access dispute). Sarah Williams denies accessing the HR\Compensation folder. Your analysis reveals: no ShellBag entries for the HR folder or any subfolder. No LNK files pointing to compensation documents. No Jump List entries for Excel files from the HR share. The file server Security Event Log shows no Event ID 4624 logon from Williams' workstation IP to SRV-NGE-FS01 during the relevant timeframe. What is the correct conclusion?
Williams definitely did not access the HR folder — four independent artifact sources all show no evidence of access. The finding is conclusive.
The absence of evidence is meaningless — artifacts could have been deleted. The examiner should assume access occurred and look for anti-forensic indicators that explain the missing artifacts.
The evidence is consistent with Williams' denial but does not definitively prove she did not access the folder. Report the finding as: "Four independent artifact sources (ShellBags, LNK files, Jump Lists, file server authentication logs) were examined for evidence of access to the HR\Compensation folder. None contained evidence of access during the relevant timeframe." Then document: whether anti-forensic indicators were checked (and the results), whether the artifact retention period covers the relevant timeframe, and whether alternative access methods (web browser via SharePoint, different workstation, mobile device) were considered. The absence across four sources is strong supporting evidence for Williams' denial — but the examiner states what the evidence shows, not what it proves, and acknowledges the limitations of proving a negative.
The ShellBag analysis is sufficient on its own — if Williams navigated to the HR folder in Explorer, the ShellBag entry would exist and cannot be deleted. Its absence proves she did not navigate to the folder via Explorer. Report this as a conclusive finding.
💬
How was this module?
Your feedback helps us improve the course. One click is enough — comments are optional.
You've built the foundations of artifact-level forensic analysis.
WF0 gave you the taxonomy, NTFS architecture, and the five-step methodology. WF1 took you inside the MFT at the binary level — every attribute, every timestamp, every edge case. From here, every artifact category gets the same raw-first treatment.
WF2–WF10: every major Windows artifact decoded at binary level — USN Journal, Prefetch, Amcache, Shimcache, ShellBags, LNK, Jump Lists, SRUM, Event Logs, and the Registry hives
INC-NE-2026-0915 (WF13) — Insider data exfiltration capstone. Work the complete investigation from USB history to OneDrive exfiltration evidence
INC-NE-2026-1022 (WF14) — Ransomware capstone. Three-host triage (FIN01 → IT03 → FS01) across the 72-hour attack chain
The lab pack — 25+ realistic evidence files in 10 formats, simulated KAPE triage pre-populated, both capstones deployable to your own VM
Anti-forensic detection methodology — defeat timestomping, log clearing, and Prefetch deletion with cross-artifact correlation
