The Windows Artifact Taxonomy

Filesystem artifacts: what happened to files

Filesystem artifacts answer the fundamental forensic question: what files existed, when were they created, modified, accessed, or deleted, and how did they get there. On NTFS — the filesystem used by every modern Windows installation — the primary source is the Master File Table ($MFT), which contains a record for every file and directory on the volume. Each record stores multiple timestamps, the file path (via parent directory references), the file size, and for small files, the file content itself.

The $MFT is the single most important forensic artifact on a Windows system. It persists until the volume is formatted. It records files that have been deleted (the MFT record is marked as free but not zeroed). It provides nanosecond-precision timestamps that reveal the exact sequence of file operations. And it stores two independent sets of timestamps — $STANDARD_INFORMATION and $FILE_NAME — that can be compared to detect timestomping.

Supporting the $MFT are two change logs: the USN Journal ($UsnJrnl:$J) and the NTFS transaction log ($LogFile). The USN Journal records every change to every file on the volume — creation, modification, rename, deletion, security change — with a timestamp and a reason code that identifies the type of change. The $LogFile records NTFS transactions at a lower level, providing redo/undo operations that can recover file operations even when the USN Journal has been cleared.

The directory index ($I30) provides an additional source of deleted file evidence. When a file is deleted from a directory, its entry is removed from the active directory index, but the index slack space often retains the deleted entry — including the filename and timestamps. This evidence persists until the directory index is compacted or the slack space is overwritten.

Execution artifacts: what programs ran

Execution artifacts answer the second fundamental question: what programs ran on this system, when did they run, how many times did they run, and what did they access during execution. Windows maintains multiple independent records of program execution, each capturing different aspects of the event.

Prefetch is the most commonly cited execution artifact. Located in C:\Windows\Prefetch\, each .pf file records the executable name, a hash of the executable path, the last 8 execution timestamps (Windows 8+), the total execution count, and a list of files and directories referenced during the first 10 seconds of each execution. Prefetch provides the strongest single-source evidence of program execution — the file is created by the Windows Task Scheduler service (SysMain/Superfetch), not by the program itself, and its existence is independent of user action.

Amcache.hve is a registry hive located at C:\Windows\appcompat\Programs\Amcache.hve. It records program metadata including the file path, SHA1 hash, file size, publisher, product name, and a timestamp. On Windows 10 and later, Amcache is populated when a program is first executed or installed. The SHA1 hash is particularly valuable — it provides a cryptographic identifier that can be compared against threat intelligence databases.

Shimcache (Application Compatibility Cache) is stored in the SYSTEM registry hive. It records executables that were evaluated by the Application Compatibility subsystem. On Windows 10 and 11, the cache includes an execution flag that indicates whether the program was actually executed. On earlier versions, presence in the Shimcache does not definitively prove execution — only that the executable was evaluated for compatibility.

Background Activity Moderator (BAM) and Desktop Activity Moderator (DAM) are registry keys introduced in Windows 10 version 1709. They record full executable paths with execution timestamps and are associated with specific user SIDs, providing user-level execution attribution that Prefetch and Amcache lack.

UserAssist records GUI program execution in the NTUSER.DAT registry hive. Entries are ROT13 encoded (a trivial obfuscation, not encryption) and include execution count and last execution timestamp. UserAssist specifically records programs launched through the Windows shell — Explorer, Start Menu, Desktop shortcuts — providing evidence of interactive user execution as opposed to automated or service-based execution.

User activity artifacts: what the user interacted with

User activity artifacts answer the question that matters most in insider threat and unauthorized access investigations: what did the user see, touch, and interact with? These artifacts record folder navigation, file opening, and application-specific file history — evidence that persists even after the files themselves are deleted.

ShellBags are registry entries stored in NTUSER.DAT and UsrClass.dat that record every folder the user navigated to in Windows Explorer. Each ShellBag entry includes the folder path (encoded as a shell item ID list), timestamps for first and last access, and the folder's view settings (icon size, sort order, column layout). ShellBags persist after the folder is deleted — the registry entry remains, providing evidence that the user accessed a folder that no longer exists.

LNK (shortcut) files are created automatically in the user's Recent folder when a file is opened. Each LNK file contains the target file's full path, three sets of timestamps (target file creation, modification, access), the target file's size, the volume serial number and type (local, removable, network), and the machine's NetBIOS name. LNK files persist after the target file is deleted — the shortcut remains in the Recent folder with the original file's metadata, including timestamps from the moment the file was last accessed.

Jump Lists are per-application recent file lists stored in the user's AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\ and CustomDestinations\ directories. Each Jump List is identified by an AppID (a hash of the application's path) and contains LNK entries for files recently accessed by that specific application. Jump Lists provide application-specific file history — proving not just that a file was accessed, but which application was used to access it.

System artifacts: what the operating system recorded

System artifacts capture operating system events — authentication, process execution, service management, scheduled tasks, and configuration changes. The primary system artifacts are Windows Event Logs and the Windows Registry.

Windows Event Logs (EVTX format) provide timestamped records of security events (logon/logoff, process creation, privilege use, object access), system events (service state changes, driver loading, shutdown/restart), and application events (including PowerShell script execution, Sysmon telemetry, and Windows Defender detections). Event Logs are the most commonly targeted artifact in anti-forensic operations — clearing the Security log is often the attacker's first post-compromise action.

The Windows Registry stores system configuration, user preferences, application settings, and — critically for forensics — evidence of persistence mechanisms, USB device connections, network history, user accounts, and installed software. Five hive files contain the bulk of forensic evidence: SYSTEM (hardware config, services, USB, network), SOFTWARE (installed programs, network profiles, OS info), SAM (user accounts, logon data), NTUSER.DAT (per-user settings, MRU lists, UserAssist, TypedPaths), and UsrClass.dat (per-user class registration, ShellBags).

Network artifacts: what external communication occurred

Network artifacts bridge the gap between endpoint activity and external communication. They answer questions about what the system connected to, how much data was transferred, and what external resources were accessed.

SRUM (System Resource Usage Monitor) is the most underutilized forensic artifact in most investigations. Stored in C:\Windows\System32\sru\SRUDB.dat, it records per-application network usage (bytes sent and received), CPU time, memory usage, and energy consumption — with hourly granularity over 30-60 days. In data exfiltration investigations, SRUM provides quantitative evidence of how much data was transferred by each application, replacing the imprecise "the user could have exfiltrated data" with "OneDrive.exe sent 4.7GB between March 1 and March 15."

Browser artifacts (history, downloads, cache, cookies) provide evidence of web-based activity. Cloud storage artifacts (OneDrive, Dropbox, Google Drive sync logs) provide evidence of cloud-based file transfer. DNS cache provides evidence of recent name resolution. Wi-Fi profiles provide evidence of network connections.

Volatile artifacts: what exists only in memory

Volatile artifacts exist only while the system is running. They are lost at shutdown and cannot be recovered from a powered-off disk image. Running processes, active network connections, loaded DLLs, clipboard contents, in-memory registry keys, and decrypted file contents — all are volatile.

Volatile artifacts have the highest reliability of any category — they represent the system's actual runtime state, unmediated by filesystem metadata or registry interpretation. A process running in memory with a specific PID, parent PID, command line, and loaded modules is direct evidence of execution. An active network connection to a specific IP on a specific port is direct evidence of communication.

The catch is that volatile evidence must be collected before the system is powered off, and the collection itself modifies the volatile state (the collection tool runs as a process, uses memory, generates network traffic). This is the first law of digital forensics: observation changes the observed system. The examiner must balance the forensic value of volatile collection against the risk of modifying evidence.

Troubleshooting

"This taxonomy has too many artifact types — I can't learn them all." You don't analyze all artifact types in every investigation. The taxonomy is a reference that ensures you know what exists so you can select the right artifacts for each investigation type. An insider threat investigation focuses on user activity and network artifacts. A ransomware investigation focuses on execution and system artifacts. The selection matrix at the end of this subsection maps investigation types to artifact priorities.

"We use EDR — our EDR captures all of this." EDR captures process telemetry, file operations, network connections, and registry modifications in real time. What EDR does not capture: ShellBag history (folder browsing), SRUM data transfer volumes, Amcache SHA1 hashes for files that were deleted before EDR ingested them, LNK file metadata for files accessed before EDR was deployed, or MFT resident data for small files. EDR is a powerful current-state telemetry source. Forensic artifacts are a historical record that predates and extends beyond EDR's collection window.

"Volatile artifacts are too fragile — we should focus on disk artifacts." For historical investigations (what happened over the last 30 days), disk artifacts are primary. For active compromise investigations (what is the attacker doing right now), volatile artifacts are essential. The decision depends on the investigation timeline: if you're reconstructing past activity, prioritize disk artifacts. If you're investigating an ongoing compromise, collect volatile evidence first — then image the disk.