Windows Artifact Analysis practice questions

ShimCache (AppCompatCache)

Why it fails: ShimCache records file metadata to ensure application compatibility, but it does not track execution counts or indicate the specific user context of the launch. It is useful for identifying the presence of a file on the system, but it cannot definitively distinguish between manual execution and automated background processes.

Amcache.hve

Why it fails: Amcache provides detailed metadata for executed binaries, including SHA1 hashes and file paths. While highly valuable for identification, it lacks the specific user context required to differentiate between a manual launch and a process triggered by a background service or task, making it insufficient for this specific analytical objective.

SRUM (System Resource Usage Monitor)

Why it fails: SRUM tracks network and energy usage per application over time. While it confirms a process ran and consumed resources, it does not record the specific launch command or the user identity associated with the initiation of the execution event, failing to meet the requirement of identifying the user's manual action.

Event Log 7040

Why it fails: Event ID 7040 indicates a change in the start type of a service. While useful for auditing configuration changes, it does not track user file system activity or interaction with documents. This artifact is primarily used to identify persistence mechanisms rather than reconstructing user-level file access patterns.

SAM Hive

Why it fails: The Security Accounts Manager (SAM) hive stores local user account information, password hashes, and group memberships. It does not record file system operations or user interaction with documents, making it entirely irrelevant for determining what files were being accessed or viewed prior to a system shutdown event.

System Resource Usage Monitor (SRUM)

Why it fails: While SRUM tracks total application resource consumption, its data is stored in a database that is updated periodically and is not synchronized to disk in real-time. Consequently, the most recent activity immediately preceding a sudden crash may not be fully committed, making it less reliable than registry-based artifacts.

The file was deleted immediately after being created.

Why it fails: The USN Journal output does not include a 'FileDelete' or 'Close (Delete)' flag. The 'Close' flag simply indicates that the handle to the file was released by the process, which is standard behavior after any file write operation, not an indication that the file was removed.

The file was moved from a different volume.

Why it fails: A file move operation across volumes or within the same volume would trigger specific flags like 'FileCreate' in the destination and 'FileDelete' in the source. Since there is no 'FileDelete' or evidence of a move operation in the exhibit, this conclusion is not supported by the provided data.

The file is currently open by an active process.

Why it fails: The 'Close' flag in the USN Journal explicitly signifies that the file handle was closed by the application. If the file were currently open by an active process, the journal would not show a 'Close' operation for that specific handle until the process finished accessing it.

Prefetch files

Why it fails: Prefetch files track application execution to optimize launch times. They contain metadata about loaded modules, but they do not record registry modifications or internal key timestamps. They are irrelevant for detecting timestomping of registry keys because they are not involved in the registry write or update process.

Windows Event Logs

Why it fails: While Event Logs capture significant system events, they do not record low-level registry key modifications by default unless specialized auditing policies are enabled. Even with auditing, attackers often clear logs or use techniques that avoid triggering events, making the USN Journal a much more reliable source for discovery.

ShimCache

Why it fails: ShimCache tracks binary metadata to ensure compatibility but does not store information about registry key modification times. It is a memory-based structure that is flushed to the SYSTEM hive on shutdown and does not provide visibility into the history of manual registry edits performed by an attacker.

The user's password hash

Why it fails: Jump Lists store file interaction history, not user credentials or password hashes. Password hashes are stored in the SAM hive or the LSASS memory process. Including this as an option is a distractor, as Jump Lists are strictly for tracking user activity, not for harvesting authentication materials.

The system's BIOS version

Why it fails: System information like the BIOS version is stored in the Registry under HKLM\HARDWARE and is not captured within the Jump List files. Jump Lists are user-centric artifacts designed to improve navigation and workflow, not to inventory low-level hardware or firmware configuration details of the host system.

Software Hive (Services)

Why it fails: The Software hive contains service configurations, but network adapter settings are specifically managed within the SYSTEM hive. While checking services for malicious drivers is important, the registry keys that manage the actual network interface properties and identities are found in the SYSTEM hive, not the Software hive.

SAM Hive

Why it fails: The SAM hive is restricted to user account information and does not maintain records of hardware or network configurations. Attacker changes to network interfaces, such as adding a bridge or a VPN adapter, will not be reflected in the SAM database, making it the wrong place to look.

Amcache.hve

Why it fails: Amcache tracks the execution and properties of files, specifically binaries and drivers. While it might list the presence of a driver file for a network adapter, it does not record the network configuration or the existence of network profiles themselves, which is the key information required here.

The system will automatically reboot every hour.

Why it fails: The 'SpecialPollInterval' registry key controls how often the Windows Time service requests a time update from an external NTP server. It does not govern system power states or scheduling tasks, and modifying this value will not trigger an automatic reboot or system shutdown at the specified interval.

The registry key change triggers a System Audit log.

Why it fails: Changing the SpecialPollInterval is a local registry modification that does not, by default, trigger a specific security event in the Windows logs unless advanced registry auditing has been explicitly configured. Most standard Windows installations will not capture this modification in the Event Logs, making manual hive analysis necessary.

The system will be unable to connect to the domain.

Why it fails: While significant time skew can cause authentication issues with Kerberos, modifying the poll interval alone does not immediately break domain connectivity. The system will continue to function normally, but the reliability of the system's temporal evidence becomes questionable, which is the primary concern for the forensic investigator.

SAM Hive

Why it fails: The SAM hive contains local account information and has no visibility into process execution or command-line arguments. It is entirely ineffective for identifying LotL activity, as it does not track what programs are run or how they are manipulated by users or malicious scripts.

Software Hive

Why it fails: The Software hive stores system-wide application settings and configurations. While it may contain information about installed software, it does not record execution history or command-line activity. Relying on this hive for LotL detection will fail because it does not maintain dynamic records of process invocation or script execution.

It shows when the file 'Cruzer_Glide' was last run.

Why it fails: The USBSTOR entry is a device registry key, not a file execution record. It tracks the hardware's presence and installation on the OS, not the execution of any binaries located on that device. The LastWrite time refers to the registry key modification, not an application execution event.

It indicates the time the device was safely removed.

Why it fails: Windows does not automatically update the 'LastWrite' time of the USBSTOR registry key when a device is safely removed. The registry key remains in place as a historical record of the hardware's previous connection, so this timestamp does not reflect the disconnection event for the external storage device.

It confirms that the user deleted the device driver.

Why it fails: The registry key exists precisely because the device was installed and registered by the OS. If a user deleted the driver, the registry structure would remain intact unless explicitly cleaned by an administrator. The LastWrite time simply reflects a registry change, not the deletion of the device driver.

The file was executed from a network share.

Why it fails: ShimCache tracks file metadata for locally executed binaries to ensure application compatibility. It does not distinguish between local and remote file execution in this way. An empty Last Modified time is not an indicator of the file's source location, but rather an artifact of the caching process.

The file is a system binary protected by Windows.

Why it fails: System binaries are tracked just like any other executable in the ShimCache. The absence of a timestamp is not a property of Windows-protected files; rather, it is a structural anomaly caused by a failure in the caching or shutdown process, regardless of the file's origin or type.

The file was recently deleted from the system.

Why it fails: ShimCache only tracks files that have been loaded into memory for execution. Deleting a file does not affect the ShimCache's timestamp values. The absence of a Last Modified time is strictly related to the persistence of the cache from memory to disk, not the file's current existence.

NTUSER.DAT RecentDocs

Why it fails: RecentDocs tracks individual files accessed through the Windows shell, not the folder-level view settings or navigation history. While useful for document-centric investigations, it fails to record the specific folder view preferences that are explicitly managed and stored within the ShellBags registry structure.

Prefetch files

Why it fails: Prefetch files track application execution to optimize performance. They do not record user file system navigation, folder access, or view settings. Since ShellBags are specifically designed for folder view persistence, Prefetch is not the correct artifact for this type of user-behavior reconstruction.

Amcache.hve

Why it fails: Amcache tracks binary metadata and program execution. It does not monitor the Windows Explorer folder navigation or the GUI-based settings associated with folder views. Because it is binary-focused, it lacks the context required to identify when a user last viewed a specific folder or changed its display preferences.

Shimcache

Why it fails: While Shimcache shows file presence and modification times, it does not confirm execution. It serves as an indicator of existence rather than a record of launch activity. Forensic analysts often mistakenly prioritize this for execution proof, leading to unreliable results when trying to build a solid case.

Amcache

Why it fails: Amcache provides detailed file metadata, including SHA1 hashes and installation paths, but it is not a direct record of execution. It is intended to help the Windows Application Experience service identify installers. While related to execution, it is less specific than UserAssist or Prefetch for proving user-initiated actions.

Registry 'Run' Keys

Why it fails: Run keys identify persistence mechanisms that trigger at login, not execution history. Identifying a file in a Run key shows how malware survives a reboot, but it does not confirm that a user manually executed the file. Relying on this leads to incorrect assumptions regarding user activity.

User security identifier (SID)

Why it fails: Prefetch files do not store user SID information. They are system-wide artifacts that focus on application performance metrics. Assuming SID association can lead to erroneous conclusions about which user account actually performed the execution, potentially misdirecting the investigation toward the wrong user or credentials.

Registry key path modification

Why it fails: Prefetch does not track registry modifications. It is purely for file-loading metrics to speed up software startup. Looking for registry changes in Prefetch will lead to wasted time, as those artifacts are found in logs like the Security or System event logs or in registry transaction files.

It stores user credentials used during application launch.

Why it fails: Amcache does not store credentials. Attempting to extract passwords from this hive will yield nothing and demonstrates a misunderstanding of what registry hives contain. Credentials are typically stored in the SAM database, LSA secrets, or Windows Vault, which are far more sensitive and require different analysis techniques.

It tracks the exact network connections made by an application.

Why it fails: Amcache is not a network traffic analyzer. It focuses on file metadata. If you need network connection data, you must examine Windows Firewall logs, PCAP files, or netstat history. Expecting network data in a file metadata registry hive will lead to missing critical evidence during the network analysis phase.

It records the full command-line arguments used for execution.

Why it fails: While it records the file path, it does not reliably store the command-line arguments used during execution. Relying on Amcache for command-line evidence is insufficient. Analysts should instead look at Process Creation events (Event ID 4688) with command-line auditing enabled for that level of detail.

The user's password hash

Why it fails: LNK files do not store user password hashes. This is a common misconception. If an analyst expects security credentials within a shortcut file, they are misunderstanding the purpose of the artifact, which is to provide navigation, not authentication, and they will fail to secure evidence that is stored elsewhere.

Full contents of the target file

Why it fails: A LNK file is a shortcut, not a container for the target file's content. It only points to the target. Expecting it to hold the full content would lead an analyst to ignore the target file itself, resulting in a failure to perform deep-dive analysis on the actual data.

Sysmon Event ID 1 (Process Creation)

Why it fails: Sysmon Event ID 1 logs process creation with rich details including command line, hashes, and parent process. While it can capture the command-line arguments of powershell.exe, it does not record the script block content executed within PowerShell. Sysmon is valuable for process lineage and command-line arguments, but it does not fulfill the requirement to recover the actual script code. Therefore, it is not one of the two best artifacts for this specific need.

PowerShell ConsoleHost_history.txt file

Why it fails: The ConsoleHost_history.txt file stores commands entered interactively in the PowerShell console, not script block content executed via scripts or command-line invocations. It is per-user and does not capture script blocks run by automated processes. While it can show commands typed by a user, it is not reliable for recovering script block content from a malicious script execution, especially if the script was run non-interactively.

PowerShell Operational log Event ID 4103

Why it fails: Event ID 4103 logs pipeline execution details, including command invocations and parameter binding, but it does not capture the full script block content. It is useful for understanding which cmdlets ran and their parameters, but it lacks the complete script code. For recovering the actual script block content, Event ID 4104 is the primary source. Thus, 4103 alone is insufficient for the analyst's goal of obtaining script block content.

The NTFS $UsnJrnl:$J alternate data stream

Why it fails: The USN change journal records volume-level change reasons such as FILE_CREATE and DATA_OVERWRITE, but it does not attribute those changes to a particular process. It can show that a file was created or modified, yet it cannot directly link the operation to the cloud-sync client. It is useful for timeline building, but it is not the most direct record of application-specific file operations here.

The $MFT record for the synced folder

Why it fails: The $MFT stores metadata such as timestamps, size, and parent directory for each file. It reflects the final state of a file but does not record which process created or modified it. While useful for establishing file existence and timestamps, it lacks the process attribution and operation detail needed to tie file additions to the cloud-sync client.

The Prefetch file for the cloud-sync client executable

Why it fails: Prefetch records the files and DLLs loaded when an executable starts, along with a last-run timestamp. It can show that the sync client ran, but it does not log individual file operations or the paths of files synced. It cannot provide the per-file timeline needed to correlate file additions with network activity.

$MFT and $LogFile

Why it fails: The Master File Table ($MFT) records file metadata, and the $LogFile records metadata transactions. While they can show that a file record was modified or marked as deleted, they do not directly provide the original full path and precise deletion time. The $MFT entry may be reused, and the $LogFile is complex to parse.

$Recycle.Bin and $I files

Why it fails: The Recycle Bin stores files deleted through the Explorer shell, not typically those deleted via command-line tools like del or Remove-Item. If the file was deleted from the command line, it would bypass the Recycle Bin. Thus $I files would not exist for that deletion.

$UsnJrnl:$J

Why it fails: The USN change journal records changes to files, including deletions, but it does not store the full original path or the exact deletion timestamp in a way that directly provides both. It records the file name and reason, but reconstructing the full path requires additional context. It is more useful for tracking changes over time.

The Windows Event Log service's 'Event ID 1102' in the System log

Why it fails: Event ID 1102 is written to the Security log when the Security log is cleared, not the System log. If the Security log itself was deleted, the clearing event may be lost unless it was forwarded or captured elsewhere. The System log does not record Security log clearing events, so this is not the correct artifact to examine.

The 'Event ID 104' in the System log indicating log clearing

Why it fails: Event ID 104 is generated when the System log is cleared, not the Security log. It does not provide information about the Security log being cleared. Therefore, examining the System log for Event ID 104 would not help determine if the Security log was cleared or recover its contents.

The $LogFile metadata file in the NTFS volume

Why it fails: The $LogFile is an NTFS metadata file that records file system transactions for recovery purposes. It does not store the contents of deleted event logs or track log clearing events. While it may contain remnants of file system operations, it is not a viable source for recovering cleared Security event log entries or determining if the log was cleared.

Amcache.hve

Why it fails: Amcache.hve stores metadata about executed or installed applications, including file paths and hashes, but it does not record which user account ran the program. It is system-wide and lacks user SID information for executions. While it can confirm that a program existed or ran, it cannot attribute the execution to a specific user, making it unsuitable for correlating a prefetch file to a user account.

UserAssist registry key

Why it fails: UserAssist tracks GUI-based program executions per user, storing data in the NTUSER.DAT hive under HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist. While it can show that a user ran a program, it does not directly link to prefetch files. Prefetch files are system-wide and do not contain user SIDs. UserAssist is user-specific but does not provide a direct correlation to a specific prefetch file's execution instance.

SRUM database

Why it fails: The SRUM database records resource usage per application and per user SID, but it does not directly reference prefetch files. It can show that a user ran an application, but the linkage to a specific prefetch file is indirect. SRUM data is aggregated over time and may not provide the precise execution timestamp matching the prefetch file. Thus, it is not the best artifact for direct correlation.