Artefacts overview

Windows DFIR notes are no longer maintained on InfoSec-Notes. Updated versions can be found on: artefacts.help.

General

Name	Type	Description	Information / interpretation	Location	Tool(s)
Event Tracing	General	Overall system usage: Accounts authentication successes and failures, local accounts and groups management, Windows Services or scheduled tasks operations, PowerShell activity, etc. Various events of forensic interest across multiple providers are referenced in the present overview.	Event Tracing is broken into three distinct components: - Controllers: start and stop an event tracing session and enable providers. - Providers: provide the events. - Consumers: consume the events in real time. Events can eventually be written to event log channels (assimilable to the log file names), event tracing log files, or both. The provider itself defines the event log channel(s) to which events should be written (trough its "instrumentation manifest" for manifested-based providers). Providers can define new channels or import existing channels. While the provider may use different channels for different events, each event can only be written to a single channel (as specified in the event's event element in the instrumentation manifest). If no channel is defined for a given event, the event will not be written to an event log channel, but can still be consumed (in memory) by a consumer through a trace session. Event trace sessions record events by subscribing to one or more providers and may write to a log file. Events can only be written to one channel at a time, but can also be collected by up to 7 trace sessions. Security, System, and Application are legacy channels. Only the LSASS process can write to the Security channel. Four types of channels are supported: Admin, Operational, Analytic, and Debug. Provider example: Microsoft-Windows-TerminalServices-RemoteConnectionManager. Associated channel example: Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational.	Default location for EVTX files: %SystemRoot%\System32\winevt\Logs\* Lists the system's provider: logman.exe query providers Retrieves information about a provider, including its channel and the process sending events to it: logman.exe query providers "<PROVIDER_NAME>" Lists the providers the specified process emit evnets to: logman query providers -pid <PID> List the available channels and their associated event counts: Get-WinEvent -ListLog *	Tools for analyzing EVTX files: - Event Viewer: Windows built-in GUI events viewer utility. - Event Log Explorer: Proprietary GUI events viewer utility. - LogParser: to conduct SQL-like queries on EVTX files. Notable KAPE modules available that leverage LogParser: LogParser_LogonLogoffEvents, LogParser_RDPUsageEvents, and LogParser_DetailedNetworkShareAccess. - Winlogbeat: to parse EVTX into JSON or to ship them to ELK. - EvtxECmd: Utility to parse EVTX into CSV, JSON, or XML outputs (without doing a per fields extract however). - Chainsaw: Rust utility to parse and extract key information from EVTX files (notably with the use of Sigma rules). - Hayabusa: Rust utility to parse and extract key information from EVTX files in the form of a timeline (notably with the use of Sigma rules). Velociraptor: with modules dedicated to event logs analysis (such as Windows.EventLogs.CondensedAccountUsage, Windows.EventLogs.Chainsaw, Windows.EventLogs.Hayabusa, etc.).
Registry hives	General	Registry hives are system-wide or per users hierarchical databases used by the Windows operating system, and third-party applications, to store information. A registry hive is a group of keys, subkeys, and values in the registry, with supporting file(s) on disk. Registry hives are loaded in memory upon system boot or user logon from their associated files on disk. Before being written / committed to a file on disk, registry modifications can be written to Registry Transaction logs (notably if the hives cannot be written to directly due to locking). Transaction logs are files named, and stored in the same directory, as their corresponding registry hives. Such as SYSTEM.LOG1 and SYSTEM.LOG2 for the SYSTEM registry file.	The system-wide registry hives are stored in the HKEY_LOCAL_MACHINE (HKLM) hive. The following notable system-wide root keys are defined: HKEY_LOCAL_MACHINE\SYSTEM File on disk: %SystemRoot%\System32\config\SYSTEM. HKEY_LOCAL_MACHINE\SOFTWARE File on disk: %SystemRoot%\System32\config\SOFTWARE. HKEY_LOCAL_MACHINE\SECURITY File on disk: %SystemRoot%\System32\config\SECURITY. HKEY_LOCAL_MACHINE\SAM File on disk: %SystemRoot%\System32\config\SAM. HKEY_USERS Contains all the actively loaded user profile registry hives on the computer. The .DEFAULT key is populated from the %SystemRoot%\Users\Default\NTUSER.DAT file. File on disk: users' NTUSER.dat and UsrClass.dat files (of logon users). The SYSTEM, SOFTWARE, SECURITY, and SAM registry hives used to be backed up periodically (every 10 days by default) under the %SystemRoot%\System32\config\RegBack folder by the RegIdleBackup scheduled task. Starting with the Windows 10 operating system, this mechanism is no longer in use and no registry hive backups are stored under the RegBack folder. The user specific registry information are stored in the HKEY_CURRENT_USER (HKCU) root key. HKEY_CURRENT_USER File on disk %SystemDrive%:\Users\<USERNAME>\NTUSER.dat HKEY_CURRENT_USER\SOFTWARE\Classes File on disk %SystemDrive%:\Users\<USERNAME>\AppData\Local\Microsoft\Windows\UsrClass.dat HKEY_CLASSES_ROOT Define the programs and file extensions association. Mapped to the keys HKEY_LOCAL_MACHINE\SOFTWARE\Classes, for default settings, and HKEY_CURRENT_USER\SOFTWARE\Classes, for user specific settings that override the default settings.	-	RegistryExplorer RECmd RegRipper

System information

Name	Type	Description	Information / interpretation	Location	Tool(s)
HKLM\SYSTEM - ComputerName	System information	Name of the computer.	-	File: %SystemRoot%\System32\config\SYSTEM Registry key: HKLM\SYSTEM\CurrentControlSet\Control\ComputerName\ComputerName
HKLM\SOFTWARE - CurrentVersion (ProductName value)	System information	Version and Service pack number of the Windows operting system.	-	File: %SystemRoot%\System32\config\SOFTWARE Registry key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
HKLM\SYSTEM - Security Policy	System information	Basic information on the system: - Computer name and SID. - Computer's domain and domain SID (for domain-joined hosts).	Registry keys under HKLM\SECURITY\Policy: - PolAcDmN: computer name - PolAcDmS: computer SID - PolDnDDN: computer's domain name - PolPrDmS: computer's domain SID	File: %SystemRoot%\System32\config\SECURITY
HKLM\SYSTEM - TimeZoneInformation	System information	Time zone information.	-	File: %SystemRoot%\System32\config\SYSTEM Registry key: HKLM\System\CurrentControlSet\Control\TimeZoneInformation
HKLM\SYSTEM - Select	System information	ControlSet information for the CurrentControlSet, ControlSet002, ... registry keys: - Current ControlSet pointed by the CurrentControlSet key. - Last known good ControlSet.	-	File: %SystemRoot%\System32\config\SYSTEM Registry key: HKLM\SYSTEM\Select
HKLM\SYSTEM - Network interfaces (Interfaces)	System information	Basic information about network interfaces (interface name, associated IP address, default gateway, and DHCP lease and eventual domain). Additional network information is available in the NetworkList registry key.	-	File: %SystemRoot%\System32\config\SYSTEM Registry keys: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\*
HKLM\SYSTEM - LanmanServer\Shares	System information	Network SMB shares hosted by the system.	Each network share is associated with a REG_MULTI_SZ value. The value is named from the network share name. The share name is also defined in the ShareName field of the registry value's data. The share path on disk is defined in the in the Path field of the registry value's data.	File: %SystemRoot%\System32\config\SYSTEM Registry key: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
HKLM\SYSTEM - FirewallPolicy	System information	Windows local Firewall profiles (Public, Private, and Domain) status and configured rules.	-	File: %SystemRoot%\System32\config\SYSTEM Registry key: HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\*
HKLM\SOFTWARE / NTUSER - Installed applications (App Paths)	System information	Applications installed on the system, on a system-wide or per user basis. The entries are mainly used by the Windows operating system for two purposes: - Mapping an application file name to its executable full path. - Pre-pending information to the PATH environment variable on a per-application and per-process basis.	Applications installed system-wide have their information written in the HKLM\SOFTWARE registry hive, while applications installed per user have their information written in the user NTUSER hive. For each installed application the following notable information is available: - File name and full file path of the application executable. - Timestamp of installation.	For system-wide applications: File: %SystemRoot%\System32\config\SOFTWARE Registry key: Microsoft\Windows\CurrentVersion\App Paths For per-user applications: File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat Registry key: HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths
HKLM\SOFTWARE / NTUSER - Uninstall	System information	Applications installed on the system, on a system-wide or per user basis, as displayed in the "Add or remove programs" of the Windows Control Panel / Settings.	Applications installed system-wide have their information written in the HKLM\SOFTWARE registry hive, while applications installed per user have their information written in the user NTUSER hive. Each application installation data is defined in a dedicated subkey under Uninstall, identified by the application name. For each installed application the following notable information is available: - The application name. - The application installation location, display icon (often based directly on the application main executable, thus giving the full path of the application main program), full path of the uninstaller. - The date of the installation. The last write timestamp of the registry key can also be an indicator of when the application was installed (with better precision). - The size of the applicationn. - Various metadata on the application (provided by the application installer itself): version, publisher, ...	For system-wide applications: File: %SystemRoot%\System32\config\SOFTWARE Registry key: Microsoft\Windows\CurrentVersion\Uninstall For per-user applications: File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat Registry key: HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall
HKLM\SYSTEM - Installed services (Services)	System information	Windows services installed on the system. For more information: local persistence note.	Each service configuration is defined in a dedicated subkey under Services, identified by the service name. For each services, the following notable information is available (under the service name root key): - Service name and display name. - Services image path. - The service type: 0x1: Kernel driver 0x2 / 0x8: file system driver 0x10: standard Windows service that runs in a process by itself 0x20: Windows service that can share a process with other services. 0x50: "USER_OWN_PROCESS TEMPLATE" 0x60: "USER_SHARE_PROCESS TEMPLATE" 0x110: like 0x10 but can interact with users. 0x120: like 0x20 but can interact with users. - The service start mode: 0x0: "Boot Start" 0x01: "System Start" 0x02: "Auto Start" 0x03: "Manual" 0x04: "Disabled" - The Windows specific privileges required by the service (SeImpersonatePrivilege, SeDebugPrivilege, etc.). No privileges can be set, for exemple if the service runs as NT AUTHORITY\SYSEM. The last write timestamp of the service name root key can be an indicator of when the specific service configuration was last modified.	File: %SystemRoot%\System32\config\SYSTEM Registry key: HKLM\SYSTEM\CurrentControlSet\Services\<SERVICE_NAME>
HKLM\SOFTWARE - Configured scheduled tasks (Schedule\Taskcache)	System information	Scheduled tasks configured on the system as stored in the registry. For more information: local persistence note.	Each scheduled task configuration is defined in a dedicated subkey under Schedule\Taskcache\Tasks, identified by the task GUID. For each tasks, the following notable information is available (under the task GUID root key): - The task path. - Some lifecycle timestamps of the task: created on, last start, and last stop. - The task security descriptor (in SDDL notation). - The task trigger(s) and action(s) in binary, non human readable format. The mapping between a task name and its GUID can be done using the subkeys of the Schedule\Taskcache\Tree keys.	File: %SystemRoot%\System32\config\SOFTWARE Registry keys: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\Taskcache\Tasks HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\Taskcache\Tree
Configured scheduled tasks (Tasks folder)	System information	Scheduled tasks configured on the system, as stored in tasks XML files. For more information: local persistence note.	Each scheduled task configuration is defined in a XML file, eventually in an intermediate subfolder, under the Tasks folder. For each tasks, the following notable information is available: - The task name and GUID, in the task filename itself. - The task description. - The task trigger(s) and action(s) (executable / command to be executed and its parameters for instance) in human readable format. - The task status (enabled / disabled). - The additional parameters of the task (wake to run, execution timeout, ...).	Windows XP / Windows Server 2003 (Task Scheduler 1.0): %SystemRoot%\Windows\Tasks Starting from Windows 7 / Windows Server 2008 (Task Scheduler 2.0): %SystemRoot%\Windows\System32\Tasks

Filesystem

Name	Type	Description	Information / interpretation	Location	Tool(s)
MFT	Filesystem	The MFT, filename $MFT, is the main element of any NTFS partition. The MFT contains an entry for all existing files written on the partition. Deleted files that were once written on the partition may also still (temporally) have a record in the MFT. The Partition Boot Sector $Boot metadata file, which starts at sector 0 and can be up to 16 sectors long, describes the basic NTFS volume information and indicates the location of the $MFT. The $MFTMirr file is statically-located as the first entry in the MFT and contains the first 4 entries of the MFT (MFT, $MFTMir, $LogFile, and $Volume) as a recovery mechanism. The $Bitmap file tracks the allocation status (allocated or unused) of the clusters of the volume. Each cluster is associated with a bit, set to 0x1 if the cluster is in use. Upon deletion of a non resident file, the $Bitmap file is updated to tag the cluster(s) associated with the file as free. The clusters are not overwritten during the deletion process, and the file data can thus be carved as long as the cluster(s) are not re-used. For more information: MFT note.	Each file on an NTFS volume is represented in the MFT in a file record. Small files and directories (typically 512 bytes or smaller), can be entirely contained within their associated MFT file record. These files are called resident files. Files larger than . Directory records are stored within the master file table just like file records. Instead of data, directories contain index information. A file record (FILE0 data structure) notably includes: - The filename. - The file size. - The file unique (under the NTFS volume) Security ID in the $STANDARD_INFORMATION attribute. - Two or three set of timestamps: > The file creation, last modified, last accessed, last changed SI timestamps (MACB) in the $STANDARD_INFORMATION attribute. > The file creation, last modified, last accessed, last changed FN timestamps (MACB) in the $FILE_NAME attribute. Two sets of $FILE_NAME timestamps will be available for files with a short (DOS) and long filenames. > For more information on Windows timestamps: Windows timestamps note. - File access permissions. - One or multiple DATA attribute, that either contain the file data for resident file or reference the clusters of disk space where the file is stored for nonresident file. - Whether the file record is in use. When a file is deleted from the volume, its associated MFT file record is set as no longer in use, but is not directly deleted during the file deletion process. Metadata information, and content for MFT resident files, can thus be retrieved for recently deleted files (as long as the file record is not overwritten by a new entry).	%SystemDrive%:\$MFT	MFTECmd.exe
$Secure	Filesystem	The $Secure file contains the security descriptor for all the files and folders on a NTFS volume. The security descriptors are stored within the $SDS named data stream of the $Secure file. The $Secure file additionally defines two other named streams ($SDH and $SII) for lookup in the $SDS stream.	Each file or folder is referenced in the $Secure file with its volume-unique Security ID and security descriptor. The Security ID of the file is referenced in the MFT file record associated with the file (in the $STANDARD_INFORMATION attribute). While no metadata information are present in the $Secure file (only the file's security descriptor), the file's Security ID can be used to map the file's information / data from the MFT to its security descriptor in the $Secure file. The security descriptor (SECURITY_DESCRIPTOR data structure) references: - The owner of the file (as a pointer to a SID structure). - The access rights to the file in the Discretionary Access Control List (DACL) attribute. - The audit rights that control how access is audited (which access will generate events) in the System Access Control List (SACL) attribute.	$Secure	Secure2Csv
NTFS index attributes ($I30)	Filesystem	The NTFS index attributes are MFT attributes, of two distincts types, that index all the files / directories in a given directory (in a B-Tree data structure). Each directory contains one or more index attributes. The files and folders information displayed by the Windows Explorer are based on the index attribute(s) of the directory being accessed. The entries (files or subdirectories) in a directory's index attribute(s) are stored as index records structures, with one dedicated record for every entry. The index record structure contains a $FILE_NAME (0x30) attribute, in which are stored the information about the file or folder. There is two types of index attributes: - $INDEX_ROOT: for directories with a small number of entries. The $INDEX_ROOT attribute is always resident to the MFT and contains a small list of index records. A directory has at most one $INDEX_ROOT attribute. - $INDEX_ALLOCATION: additional structure for larger directories, with no limitation on the number of entries. The $INDEX_ALLOCATION attribute is non-resident and contains one or more index records. The INDEX_ALLOCATION structure starts with the INDX signature. The $INDEX_ALLOCATION attribute should not exist without an associated $INDEX_ROOT attribute. The $Bitmap attribute keep track of the index allocations. The $INDEX_ROOT, $INDEX_ALLOCATION, and $Bitmap attributes are collectively refered to as $I30.	Each index record contains information on the file it references in a $FILE_NAME (0x30) attribute: - Filename and parent directory. - File size. - A set of MACB timestamps. The $FILE_NAME attribute of a index record in a directory index attribute should be kept in sync with the MFT file record's $STANDARD_INFORMATION attribute of the corresponding entry. However, disparities may sometime occur, with the index record referencing older information. Due to their B-Tree data structure format and their frequent rebalancing, $INDEX_ALLOCATION attributes often contain a significant amount of slack space. Index records for deleted files no longer present in the MFT may be carvable from this slack space.	MFT's $INDEX_ROOT, $INDEX_ALLOCATION, and $Bitmap attributes.	MFTECmd.exe INDXRipper
$LogFile	Filesystem	The $LogFile is part of a journaling feature of NTFS, activated by default, which maintains a low-level record of changes made to the NTFS volume. Every disk operation is journalized prior to being committed. In case of failure, such as a crash during an update, the $LogFile can be used to revert disk operations.	As low-level operations are journalized, the $LogFile contains very limited historical data, usually only of the last few hours at most.	$LogFile
UsnJrnl	Filesystem	The UsnJrnl is part of a journaling feature of NTFS, activated by default on Vista and later, which maintains a record of changes made to the NTFS volume. The creation, deletion or modification of files or directories are, among other operations, journalized.	The records in the UsnJrnl are progressively overwritten once the max size of the journal has been reached. The UsnJrnl usually contains historical data on the last few days (1-3 days for system full time use, < 7 days for regular system use). The UsnJrnl is composed of two named data streams: - The $Max stream stores the meta data of the change. - The $J stream stores the actual change log records. Each change log record is notably composed of: - an Update Sequence Number (USN). - The timestamp of the change. - The reason / operation of the record (USN_REASON_FILE_CREATE, USN_REASON_FILE_DELETE, USN_REASON_DATA_OVERWRITE, USN_REASON_RENAME_NEW_NAME, etc.). - MFT reference and reference sequence number.	$Max and $J named data streams under \$Extend\$UsnJrnl	MFTECmd.exe
Windows Search database	Filesystem	The Windows Search database provides an index to the Windows Search feature to improve search speed by indexing content. The Windows Search index is used for searches made through Windows taskbar, the Windows Explorer, and some Universal Windows Platform (UWP) applications (such as Outlook, OneDrive, etc.). By default, only a subset of folders and files are indexed (to reduce the Windows Search database size and CPU usage). The folders scanned and number of items indexed can be consulted in the "Windows search settings" menu.	By default, only items from the following sources are scanned and indexed: - Files and folders from the Users folders. > Data available: file name, path, size, attributes, MAC timestamps. For small file, part of the content of the file may be indexed as well. - Outlook mail data (with timestamp of reception, possible mail content). - OneNote notes title. - Internet explorer history (URLs, timestamp of last visit).	Windows XP: %SystemDrive%:\Documents and Settings\All user\Application Data\Microsoft\Search\Data\Application\Windows\Windows.edb Starting from Windows 7: %SystemDrive%:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb
Recycle Bin	Filesystem (Deleted files)	Deleted files and folders (if deleted through a recycle bin aware application).	The deleted files are placed in a subfolder (under %SystemDrive%:\$Recycle.Bin) named after the SID of the user that performed the deletion. Deleted files can thus be associated with a given user. Two kind of files are present in the Recycle Bin: - $I (for "Information") files, which contain the path and timestamp of deletion of the original file. - $R (for "Resource") files, which contain the original file content.	%SystemDrive%:\$Recycle.Bin\<USER_SID>\*

Program execution

Name	Type	Description	Information / interpretation	Location	Tool(s)
EVTX - Security.evtx - Process creation	Programs execution	For more information: Program execution note.	Event 4688: A new process has been created Event 4689: Process Termination: Success and Failure Requires Audit Process Creation to be enabled. If the ProcessCreationIncludeCmdLine_Enabled audit policy is enabled, the command line specified at the process creation will be logged.	Security.evtx
HKLM\SYSTEM - Application Compatibility Cache (Shimcache)	Programs execution (before Windows 10 / Windows Server 2016) Executable presence	Application compatibility feature that aim to maintain support of existing software to new versions of the Windows operating system. A Shimcache entry is created whenever a program is executed from a specific path. However, starting from the Windows Vista and Windows Server 2008 operating systems, entries may also be created for files in a directory that is accessed interactively. Shimcache entries are only written to the registry upon shutdown of the system. The Shimcache entries generated since the last system boot are thus only stored in memory. Limited to 96 entries on Windows XP / Windows Server 2003, and 1024 entries starting from Windows Vista. For more information: Shimcache note.	Each Shimcache entries contain the following notable information: - The associated file full path. - On Windows 2003 / XP 64-bit and older, the file size. - The LastModifiedTime ($Standard_Information) timestamp of the file, which does not necessarily reflect the execution time. Indeed, Shimcache entries are not directly associated with an insert / executed timestamp. - The cache entry position, as a numerical value starting from 0, which represents the insertion position in the Shimcache. **The lower the value, the more recently the program was shimmed. - From Windows Vista / Windows Server 2008 to Windows 8.1 / Windows Server 2012 R2, the (undocumented) Insert Flag flag which, when set, seems to indicate that the entry was executed. This flag is no longer present starting from Windows 10 / Windows Server 2016, and thus a Shimcache entry does not necessarily reflect an execution (as entries may also be created for files in a directory that is accessed interactively). - On Windows XP 32-bit, the file Last Update Time timestamp.	File: %SystemRoot%\System32\config\SYSTEM Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache	AppCompatCacheParser.exe For entries present in memory: Volatility2's shimcache plugin.
Amcache RecentFileCache For DLL 6.1.7600, replaced by Amcache.hve on up-to-date systems. Starting from Windows 7 & Windows Server 2008 R2	Programs execution (for non up-to date system) Executable presence	Very complex artefact, linked to an application compatibility feature that aim to maintain support of existing software to new versions of the Windows operating system (like the Shimcache artefact). The Amcache is a standalone registry hive, with multiple root keys that contain various types of data. The Amcache behavior depends on the version of the associated libraries, and not the version of the operating system. The Amcache on an up-to-date Windows 7 and Windows 10 will thus behave the same way. A Amcache entry is created whenever a program is executed from a specific path. However, entries may also be created for files in "scanned" directory. For more information: Amcache note.	The Amcache.hve registry hive is split in a number of root keys, with keys being added, changed, or removed depending on the Amcache DLLs versions. The following notable root keys can be of forensic interest: - File then InventoryApplicationFile starting from the version 10.0.14913.1002 of the Amcache libraries (AmcacheParser outputs AssociatedFileEntries and UnassociatedFileEntries): > Data about program executions if they are shimmed, programs part of an installed application, and programs part of scanned directories (with out requiring execution of the associated programs). > AmcacheParser's AssociatedFileEntries output references programs associated with an application and UnassociatedFileEntries output references "loose" programs (that are not associated with an installed application). > Data available (depending on the Amcache libraries version): executable full path, program size, SHA1 of the first 30MB of the executable in the FileId value, binary type (x86 versus x64), the compilation date of the program in the LinkDate value. > Additional data for entries associated with an installed application is available in the InventoryApplication key. The ProgramId value from the InventoryApplicationFile subkey of a given program matches the subkey's name under the InventoryApplication key of the associated application. The InventoryApplication key provide metadata information about the application: name, publisher, install date, etc. > For non up-to-date systems still using a File key, the last write time of an entry key under the File key coincides with the execution time of an executable or the application installation time. For entries under the newer InventoryApplicationFile key, the last write time of the keys always coincides with an execution of Microsoft Compatibility Appraiser and is thus no longer a timestamp of execution time. - InventoryDeviceContainer and InventoryDevicePnp (AmcacheParser outputs DeviceContainers and DevicePnp): > Data about devices plugged in on the system. > Data available: device type (usb; Bluetooth, media, ...), device friendly name, self reported description, manufacturer, associated driver, ... - InventoryDriverBinary (AmcacheParser output DriveBinaries): > Data about installed drivers. > Data available: driver name, full path, size, associated service name, compilation timestamp (DriverTimestamp), driver file last write timestamp, ... - InventoryDriverPackage (AmcacheParser output DriverPackages): > Data about drivers package file (INF file) that contains information about the driver. > Data available: driver package file name, path, last write timestamp, ... - Programs then InventoryApplication (AmcacheParser output ProgramEntries): > Data about installed programs, as referenced in the Uninstall and / or a Run key of the SOFTWARE hive. > Data available: application name, executable full path and SHA1, publisher, install date, ... InventoryApplicationShortcut (AmcacheParser output ShortCuts): > Data about the shortcuts (LNK files) that were present at one time (and that may still be present or may have been removed) from a subset of scanned folders (Start Menu and / or Desktop folders). > Data available: full path of the shortcut. The last write timestamp of the associated subkey can also be a general indicator of when the activity occurred but does not seem to match any MACB timestamps of the shortcut file.	DLL 6.1.7600: %SystemRoot%\AppCompat\Programs\RecentFileCache.bcf %SystemRoot%\AppCompat\Programs\Amcache.hve	AmcacheParser.exe
PCA Introduced in Windows 11 22H2.	Programs execution (GUI programs only)	The Program Compatibility Assistant (PCA) is another application compatibility feature that aim to maintain support of existing desktop applications to new versions of the Windows operating system (like the Shimcache and Amcache artefacts). PCA is linked to the pcasvc service. Executions of programs with a graphical interface, installed or from a portable executable. Command line programs executed as GUI programs (such as by double clicking on the CLI executable from Windows Explorer) will also generate an entry.	The information stored by the PCA is split in 3 text based files: - PcaAppLaunchDic.txt: > Most valuable file from a forensic standpoint and reliable source of program execution. > One entry per line, containing the full path of the executable and the timestamp of execution in UTC (in a pipe separated string). > Example: %SystemRoot%\FOLDER\executable.exe|2023-05-25 01:20:30.123. - PcaGeneralDb0.txt and PcaGeneralDb1.txt: > Less entries than in the PcaAppLaunchDic.txt file, with most entries seemingly related to non 0x0 execution exit code. > One entry per line, containg the following information in a pipe delimited string: * Execution timestamp. * Execution status. * Full path of the executable. * Description of the executable and its vendor name. * File version. * ProgramId referenced in the Amcache registry hive (InventoryApplicationFile key). * Exit code of the execution.	Files under %SystemRoot%\appcompat\pca: PcaAppLaunchDic.txt PcaGeneralDb0.txt PcaGeneralDb1.txt
Prefetch Not present by default on Windows Server Operating Systems.	Programs execution	Prefetch is a performance enhancement feature that enables prefetching of applications to make system boots or applications startups faster. Limited to 128 entries (Prefetch files) on Windows XP to Windows 7, and 1024 entries starting from Windows 8. For more information: Prefetch note.	The Prefecth filenames are based on the executed program name and a hash, computed using a proprietary algorithm and based on the full path (and for some binaries, such as dllhost.exe or svchost.exe, command line parameters) of the executed program. Each Prefecth file can yield the following information: - The file name and size of the binary executed. - The first and, starting from Windows 8, the last eight executions timestamps - The Prefecth file NTFS created and last modified timestamps also indicate the first and last time the program was executed. - The run count (number of time the binary was executed). - The list of files and directories accessed during the first ten seconds of execution (including the eventual DLL loaded or PowerShell scripts for PowerShell execution). Whether the Prefect feature is enabled is configured by the EnablePrefetcher registry key: - 0x0 / undefined: disabled (default on Windows Server Operating Systems). - 0x1: Partially enabled (application prefetching only). - 0x2: Partially enabled (boot prefetching only). - 0x3: Enabled (application and boot prefetching).	Prefetch files (.PF) in: %SystemRoot%\Prefetch\* EnablePrefetcher: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters	PECmd.exe
System Resource Usage Monitor (SRUM) Introduced in Windows 8.	Programs execution	SRUM is a feature that records numerous metrics of system activities, with a limited subset of the available information displayed within the Windows Task Manager ("App history" tab). The SRUM database is a ESE database that notably yields information related to programs execution and executed programs' network usage. The SRUM database only stores data for the last 30 to 60 days. Entries are not associated with their timestamp of occurrence but with the timestamp of insertion in the SRUM database. As entries are only written to the SRUM database every hour, timestamps are thus precise to the hour (with multiple entries usually sharing the same insertion timestamp). For more information: SRUM note.	Related to program execution, the Application Resource Usage (GUID {D10CA2FE-6FCF-4F6D-848E-B2E99266FA89}) and App Timeline Provider (GUID {5C8CF1C7-7257-4F13-B223-970EF5939312}) tables track programs execution. For each entry in the Application Resource Usage table (SrumECmd's AppResourceUseInfo output), the following information may be recorded: - Timestamp of the SRUM entry creation. - Full path of the executable or application information / description for built-in components. - User SID of the user executing the process. - Metrics on CPU usage (CPU time in foreground and background). - Metrics on I/O operations (foreground / background number of read / write operations and bytes read / written). For each entry in the Application Resource Usage table (SrumECmd's AppTimelineProvider output), the following information may be recorded: - Timestamp of the SRUM entry creation. - Name of the executable and description for built-in components. - Timestamp of compilation of the executable. - User SID of the user executing the process. - Timestamp of seemingly approximate end of execution. - Total duration of execution (in milliseconds).	%SystemRoot%\System32\SRU\SRUDB.dat	SrumECmd
Windows 10 Timeline / ActivitiesCache.db Introduced in Windows 10's version 1803.	Programs execution	The Windows Activity history tracks a number of operations on the system: programs used, local files opened, SharePoint documents consulted, and websites browsed (using Internet Explorer / Microsoft Edge Legacy). The Activity history can be consulted in the Windows Timeline (Windows + Tab keys). The ActivitiesCache.db is a SQLite database that locally stores the activity for its associated user. The ActivitiesCache.db only stores data for the last 30 days by default.	The ActivitiesCache.db is composed of a number of tables, with the following tables being of interest: - Activity / ActivityOperation tables: data about various activities for different operation / activity type: program execution and opening of a file (5, ExecuteOpen), copy-pasting from a program (CopyPaste), application "in focus" (InFocus), ... > Data available, varying depending on the activity type: the activity ID (GUID), executable full path for program execution, display text and content info that may contain file name / SharePoint link, start (startedDateTime) and end (lastActiveDateTime) of the activity (in UTC), created and last modified timestamp of the associated file (local or on SharePoint), the user's device timezone, ... > An activity data can be present in either or both tables depending on the activity lifecycle. For example, a new activity will only be present in the Activity table, while an activity in the "upload queue" will be placed in the ActivityOperation table. - Activity_PackageId: data about the application(s) / program(s) linked to a specific activity (identified by its activity ID). > Data available: the activity ID (GUID), the application name / program filename, eventual program full path, activity expiration timestamp (timestamp of occurrence + 30 days by default). > Upon occurrence of an activity, one or multiple entries sharing the same activity ID will be created in the Activity_PackageId table, one for each program / application related to the activity.	%SystemRoot%\Users\<USERNAME>\AppData\Local\ConnectedDevicesPlatform\[L.<USERNAME> | *]\ActivitiesCache.db
NTUSER - UserAssist	Programs execution (GUI programs only)	The purpose of the UserAssist registry key is not officially documented. The registry key references executions of programs with a graphical interface, installed or from a portable executable.	One or two main registry subkeys can be found depending on the Windows OS version: - On Windows Xp, {75048700-EF1F-11D0-9888-006097DEACF9} linked to execution of executable files - Starting from Windows 7, {CEBFF5CD-ACE2-4F4F-9178-9926F41749EA} linked to execution of executable files and {F4E57C4B-2036-45F0-A9AB-443BCFE33D9F} linked to execution of shortcut files. Keys are ROT13 encoded, and contains the following notable information: - Full path of the executed program / shortcut. - Sometimes, the timestamp of the last execution. - An unreliable run counter and focus time.	File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat Registry key: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\<GUID>\Count
UsrClass - MUICache	Programs execution (GUI programs only)	Multilanguage User Interface (MUI) is a feature to allow applications to have a single executable for multiple languages. MUI files can be created, one per supported language, to switch the application display language. The registry key references executions of programs with a graphical interface, installed or from a portable executable.	Each execution is associated with two values under the MUICache registry key, both starting with the executable full path. The values data reference information retrieved from the executable's Version information from its resources section (.rsrc): - <PE_FULL_PATH>.FriendlyAppName: references the executable FileDescription. This can be used to identify renamed executable, as the original filename is likely going to be referenced by the FileDescription attribute. - <PE_FULL_PATH>.ApplicationCompany: references the executable CompanyName. The MUICache does not provide a timestamp of execution, and the last write timestamp of the key cannot be used to infer the timestamp of execution (as the entries are stored directly as registry values).	File: %SystemDrive%:\Users\<USERNAME>\AppData\Local\Microsoft\Windows\UsrClass.dat Registry keys: HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MUICache HKCU\Local Settings\MuiCache
HKLM\SYSTEM - Background Activity Moderator (BAM) / Desktop Activity Moderator (DAM) Introduced in Windows 10's Fall Creators update - version 1709.	Programs execution	BAM is a mostly undocumented feature that controls the programs executed in the background. DAM is a feature for devices supporting the "Connected Standby" mode (i.e when a device is turned on, but its display will be turned off). As a result, the BAM registry keys will contain data on any devices, while DAM registry keys will only contain data on mobile devices.	The BAM registry key contains multiple subkeys under bam\State\UserSettings, with one subkey per user, identified with the user SID. While the key is in the SYSTEM registry hive, program executions can thus still be tied to a specific user using this SID. Each user-specific key contains a list of executed programs, with their full path and timestamp of last execution. If a file is deleted, the eventual associated entry in the BAM is deleted as well after the system reboot. Additionally, BAM entries older than 7 days are deleted upon system boot. The BAM thus provides limited information on historic execution of programs. No entries are created in the BAM keys for executables on removable media and/or on network shares.	File: %SystemRoot%\System32\config\SYSTEM Registry key: HKLM\SYSTEM\CurrentControlSet\Services\bam\UserSettings\<SID>\* After from Win10 1809: HKLM\SYSTEM\CurrentControlSet\Services\bam\State\UserSettings\<SID>\* HKLM\SYSTEM\CurrentControlSet\Services\dam\UserSettings\<SID>\* After from Win10 1809: HKLM\SYSTEM\CurrentControlSet\Services\dam\State\UserSettings\<SID>\*
NTUSER - FeatureUsage Introduced in Windows 10's version 1903.	Programs execution	Feature linked to the Windows Task, storing a number of metrics related to the Task bar usage.	Each operation (detailed below) is associated with an entry composed of the program full path and operation run count. No timestamp of execution is available. Subregistry keys: - AppSwitched: number of times an application was brought to focus (application left-clicked on the taskbar). - ShowJumpView: number of times the jump menu of an application was opened (application right-clicked on the taskbar). - AppBadgeUpdated: number of times an application on the taskbar has have its icon updated (for example for notifications). - AppLaunch: number of times an application pinned on the taskbar has been executed. - TrayButtonClicked: numer of times a default taskbar button (such as the Windows start button) was clicked.	File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat Registry keys under HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FeatureUsage.
EVTX - PowerShell activity events	Programs execution and PowerShell activity	For more information: PowerShell activity note.	Microsoft-Windows-PowerShell%4Operational: - Event 4103, related to PowerShell modules. Requires PowerShell Module Logging to be enabled. - Event 4104, related to PowerShell script block. Requires PowerShell Script Block Logging to be enabled. By default, events will however be logged for potentially-malicious commands execution.	Microsoft-Windows-PowerShell%4Operational
PowerShell console activity ConsoleHost_history.txt Introduced in Windows 10 / PowerShell 5.	Programs execution and PowerShell activity	Starting with PowerShell v5 on Windows 10, the commands entered in a PowerShell console will be logged by the PSReadline module to an user-scoped ConsoleHost_history.txt file. Console-less PowerShell sessions, such as the content of PowerShell script or commands execution through the PowerShell ISE, will not be logged in this file. Bypassing PSReadline logging is also easy, as it simply requires to unload the PSReadline module (for instance with the Remove-Module PSReadline in an existing PowerShell session).	The ConsoleHost_history.txt file contains the commands entered, with one command per line and no associated timestamps (or any additional metadata). By default, the last 4096 commands are conserved.	%SystemDrive%:\Users\<USERNAME>\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt
.NET CLR UsageLogs	Programs execution	Following the execution (or in-memory injection) of a .NET assembly, the Common Language Runtime (CLR) creates a Usage Log file whose named is based on the name of the executed assembly. The file is written just prior the assembly execution terminate, and will thus not be written if the process does not gracefully exit.	The filename of the log file match the name of the assembly / binary executed. The file creation timestamp corresponds to the first time the associated assembly was executed and the file last modification timestamp corresponds to the last execution time of the assembly.	%SystemDrive%:\Users\<USERNAME>\AppData\Local\Microsoft\CLR_v<VERSION>\UsageLogs\<BINARY_NAME>.exe.log
NTUSER - RecentApps Introduced in Windows 10 1607 and removed in Windows 10 1709 (with the key not present on subsequent version).	Programs execution	Undocumented feature, added and (relatively) shortly after removed from the Windows operating system.	Each subkey, identified with a GUID, under the RecentApps key correspond to an executed program. In these application GUID subkeys, the filename, last access timestamp, and run count of the application are stored. Additionally, each application GUID subkey can have up to 10 subkeys, also identified with a GUID, that correspond to files accessed using the application. In these file GUID subkeys, the file name, file full path, and (on some OS version) an non-updated timestamp of last access. The last write timestamp of an application subkey can indicate when the program was last executed. While the last write timestamp of a file subkey can indicate when the file was accessed (with the associated program).	File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat Registry key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Search\RecentApps\<GUID>
Jumplist	Programs execution	Detailed in Files and folders access	-	-
NTUSER - Explorer - Common Dialogs - CIDSizeMRU	Programs execution	Recently executed programs, linked to Common Dialogs activities (pop boxes to open / save file, print, find / replace, ...).	The key contains an ordered Most Recently Used (MRU) list of executed programs, identified through their filename. The last write timestamp of the key thus corresponds to the timestamp of execution of the most recently executed program (first in the MRU list).	File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat Registry key: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\CIDSizeMRU
NTUSER - Explorer - Common Dialogs - LastVisitedMRU / LastVisitedPidlMRU LastVisitedPidlMRULegacy Renamed in Windows Vista and later.	Programs execution	Records the programs used to open / save (some of) the file tracked in the OpenSaveMRU / OpenSavePidlMRU registry key. Notably used to track the last folder used by a given program in an "Open File" / "Save File" Common Dialogs window.	Applications tracked are stored in an ordered Most Recently Used (MRU) list. The last write timestamp of the key thus corresponds to the timestamp of execution of the most recently executed program (first in the MRU list). For each application, the full path of the folder can be constructed from information blocks on each subfolder in the location. For exemple, for the "%SystemRoot%\Users\Public\Documents" location, three blocks will be present: "Users", "Public", and "Documents". For each block, the created and last accessed timestamps and the MFT entry / sequence associated with the folder are referenced.	File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat Registry key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedMRU HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRULegacy
NTUSER - RunMRU	Programs execution	Tacks items (program, files / folders, URL, ...) launched from the Windows Run launcher (Windows + R shortcut). Entries are added / updated in near real-time.	Each entry successfully launched trough the Windows Run launcher is stored in a dedicated value under the Explorer\RunMRU key. The values are ordered in a Most recently used (MRU) list, specified in the MRUList value. Example: MRUList equals to ba means that the entry tagged as b was launched last / the most recently, preceded by the entry tagged as a. The last write timestamp of the key thus indicates the timestamp of the most recently entered item.	File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat Registry key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

Files and folders access

Name	Type	Description	Information / interpretation	Location	Tool(s)
NTUSER & UsrClass - Shellbag	Folders access	Registry keys designed as an user experience enhancing feature to keep track of Windows explorer graphical display settings on a folder-by-folder basis. For instance, a Shellbag entry is used to store the "View" mode of a folder (details, list, small / medium / large icons) as well as the column displayed (entry names, dates, sizes, etc.) and their order. Shellbags contain folders and network shares to which a given user has navigated (using the Windows Explorer), but not files or subdirectories if they were not accessed. An exception is for ZIP files opened directly as folders through the Windows Explorer, that are stored as if they were folders (with their content thus partially referenced depending on the related activity). Shellbags entries are also generated for access to the Control Panel settings, on an interface-by-interface basis (Windows Firewall, Credential Manager). Shellbags entries are not deleted upon deletion of the related folders and can thus be a source of historical information. For more information: Shellbags note.	Various kinds of user activity may generate or update Shellbag entries (with different level of data depending on the activity): - First access or renaming of folders, removable devices, or network shares through the Windows Explorer systematically generate a Shellbag entry. - Graphical opening of compressed archives or ISOs. - ... Shellbag entries are stored in registry as a tree-like data structure, with the root target having the topmost BagMRU key. Each sub-target (sub directory for example) of the parent target are then represented with both: - A registry subkey, named with a numerical value (starting from 0). - A registry value (in the parent target's registry key), named with the same numerical value and associated with binary data that notably contains the target's name. Each Shellbag BagMRU registry key also contains a MRUListEx value, that maintains the entries visited order, i.e the order in which the sub targets of a target were accessed (the last sub target accessed having a MRU position of 0). Each Shellbags entry for a given target yield the following notable information: - The target name and absolute path. - The target modified, access, and created (MAC) timestamps (UTC), retrieved from the $MFT at the Shellbag entry creation (and not further updated). - Additionally the Shellbags BagMRU hierarchical nature and MRUListEx list can be used to deduce the first and last interacted timestamps for some targets: > For entries that do not have subkeys (i.e directory for which no subdirectory were accessed), the first interacted timestamp is equal to the key's LastWriteTime timestamp. This is due to the fact that the key is created when a target is first accessed, and further activity for that target (such as display settings modifications) will only update the key's values. When a subkey is created for the target (i.e when a subdirectory is accessed for that particular directory), the timestamp becomes unreliable as it reflect the creation of the subkey. > The last interacted timestamp can be deducted for the sub target that was last interacted with (MRU position 0), and is equal to the parent key's LastWriteTime timestamp. Major updates of the Windows operating system may however result in modification of ShellBags entries, resulting in updated last written timestamp.	Locations starting from Windows 7: Windows Explorer activity: File: %SystemDrive%:\Users\<USERNAME>\AppData\Local\Microsoft\Windows\UsrClass.dat Registry keys: HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\BagMRU HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags Desktop and Network locations activity: File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat Registry keys: HKCU\Software\Microsoft\Windows\Shell\BagMRU HKCU\Software\Microsoft\Windows\Shell\Bags	ShellBagsExplorer SBECmd.exe
Jumplist	Files and folders access	Linked to a taskbar user experience-enhancing feature that allows users to "jump" to files, folders or others elements by right clicking on open applications in the Windows taskbar. The Windows Explorer's Quick Access feature also stores entries in Jumplists. Two forms of Jumplists are created: - Automatic entries for items recently accessed through the application: <APP_IDENTIFIER>.automaticDestinations-ms files. - Custom entries for application defined or manually "pinned" elements: <APP_IDENTIFIER>.customDestinations-ms files. For both Jumplist types, the <APP_IDENTIFIER> is a Windows set unique identifier that is used to link a particular application with its Jumplists. While no official mapping is documented, JLECmd maintains a list of known application identifiers. For more information: Jumplist note.	An application is associated with one AutomaticDestinations file and one CustomDestinations file, that share the <APP_IDENTIFIER> of the application. A JumpList is assimilable to a series / list of shortcut files (LNK), each entry in the JumpList being a shortcut file structure. Thus the same level of information found in a shortcut file is available for each item referenced in an application AutomaticDestinations and CustomDestinations JumpLists.	%SystemDrive%:\Users\<USERNAME>\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\*.automaticDestinations-ms %SystemDrive%:\Users\<USERNAME>\AppData\Roaming\Microsoft\Windows\Recent\CustomDestinations\*.customDestinations-ms
LNK (shortcuts) Files	Files and folders access	Windows Shell Items that reference an original file, folder, or application. While shortcut files can be created manually, the Windows operating system also creates shortcut files under numerous user activities, such as opening of a non-executable file. For instance, a shortcut file is created under [...]\AppData\Roaming\Microsoft\Windows\Recent\ whenever a file is opened from the Windows Explorer. These automatically created and updated shortcut files are not deleted upon deletion of their associated files. For more information: LNKFile note.	The creation and modification timestamps of the shortcut file itself will usually respectively indicate when the target file was first and last opened. Each shortcut file additionally yield the following information: - The target file's absolute path, size and attributes (hidden, read-only, etc.). - The target file modified, access, and created (MAC) timestamps at the time of the last access to the target file. - Whether the target file was stored locally or on a remote network share. - Occasionally information on the volume of the target file: name, type (fixed vs removable storage media), serial number, and label / name if any. - Occasionally information on the host of the target file: system's NetBIOS hostname and MAC address.	Automatically created shortcut files for files opened from the Windows Explorer: %SystemDrive%:\Users\<USERNAME>\AppData\Roaming\Microsoft\Windows\Recent\*.lnk Documents opened using Microsoft Office: %SystemDrive%:\Users\<USERNAME>\AppData\Roaming\Microsoft\Office\Recent\*.lnk Shortcut files created automatically by the Windows Explorer are referenced in the NTUSER.DAT\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs registry keys. Startup folders items: %SystemDrive%:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp %SystemDrive%:\Users\<USERNAME>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup	LECmd exiftool
Windows 10 Timeline / ActivitiesCache.db Introduced in Windows 10's version 1803.	Files and folders access	Detailed in Program execution	-	-
WebCacheV01.dat	Files and folders access	Access to local files may appear in the WebCacheV01.dat ESE database. This database is mainly used to store browsing history, downloads, cache, and cookies (metadata) for the Microsoft Internet Explorer and Microsoft Edge (legacy) web browsers. However, access to local files, not necessarily through a web browser, may also appear in the WebCacheV01.dat database.	Access to local files will be identifiable by the file URI scheme (such as file:///<DRIVE_LETTER>:/folder/file).	%LocalAppData%\Microsoft\Windows\WebCache\WebCacheV01.dat	NirSoft's BrowsingHistoryView
NTUSER - Explorer - Common Dialogs - OpenSaveMRU OpenSavePidlMRU Renamed in Windows Vista and later.	Files and folders access	Information on files opened or saved through the "Open File" or "Save File" Common Dialogs window.	The OpenSaveMRU/ OpenSavePidlMRU keys has multiple subkeys, one for each different file extensions (for the files opened / saved on the given system). Each subkey contains an ordered Most recently used (MRU) list of opened / saved files (full path of the file). The list can go up to 20 entries, with entries over 20 being overwritten. The last write timestamp of each subkey thus corresponds to the timestamp of opening / saving of the file in MRU position 0 (for a given file extension).	File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat Registry key: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSaveMRU HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU
NTUSER - Explorer - RecentDocs	Files and folders access	Non-executable files opened through the Windows Explorer, stored as one subkey per file extension.	Each subkey contains the opened files of the given extension stored in a ordered Most Recently Used (MRU) list. The last written timestamp of the key correspond to the timestamp of the opening of the most recently accessed file (MRU position 0). Entry created under the RecentDocs registry keys are associated with a shortcut file under %SystemDrive%:\Users\<USERNAME>\AppData\Roaming\Microsoft\Windows\Recent\.	File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat Registry key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs
NTUSER - Explorer - TypedPaths	Files and folders access	Paths entered (typed, pasted, or auto-completed) in the Windows Explorer location search bars. Entries are not added / updated in real-time, but are seemingly added / updated on user logoff / system reboot.	The file paths are stored as url1 to url[N] in inversed chronological order. The last write timestamp of the key is thus the timestamp of visit of the most recently visited path. As program can be directly executed from the Windows Explorer search bar, traces of program executions may be found in the TypedPaths entries.	File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat Registry key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths
NTUSER - Explorer - WordWheelQuery Starting from Windows 7 and not present on Windows Server Operating Systems.	Files and folders access	Keywords searched in from the Windows Explorer search box, potentially resulting in files or folders access.	The entries are stored in a Most Recently Used (MRU) list. The last write timestamp of the key indicates the timestamp of the most recently searched keyword.	File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat Registry key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery
Windows Search database	Files and folders access	Detailed in Filesystem.	-	-
NTUSER - RunMRU	Files and folders access	Detailed in Program execution.	-	-
NTUSER - RecentApps Introduced in Windows 10 1607 and removed in Windows 10 1709 (with the key not present on subsequent version).	Files and folders access	Detailed in Program execution.	-	-
NTUSER - MountPoints2	Files and folders access	Currently or previously mapped drives (such as the system drive, USB devices, or network shares) mounted by the associated user.	Each drives is represented by a subkey, which is named as either the volume GUID, a letter, or, for network shares, using a specific nomenclature (##<IP | HOSTNAME>#<SHARE_NAME>). For more information on MountPoints2 related to devices, refer to Devices and USB activity.	File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat Registry key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2
NTUSER - Map Network Drive MRU	Files and folders access	Recently used network shares.	-	File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat Registry key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU
EVTX - Security.evtx - Network share access: Audit File Share	Network shared files and folders access	Events related to network shares: creation, deletion, modification, and access attempts of network shares. Do not track access to folders and files hosted on network shares. As there are no System Access Control Lists (SACLs) for shares, access to all shares on the system are audited.	Event 5140: A network share object was accessed Generated every time a network share is accessed, but only once per session (upon first access attempt). Object Type is always File for this event. Event 5140: A network share object was accessed Event 5142: A network share object was added Event 5143: A network share object was modified Event 5144: A network share object was deleted All events include information about the account that performed the operation: username, domain, and SID as well as the Logon ID associated with the logon. Events 5140 also include network information: source IP address and port. Requires Audit File Share to be enabled.	Security.evtx
EVTX - Security.evtx - Network share access: Audit Detailed File Share	Network shared files and folders access	Event related to access to folders and files hosted on network shares. The event is generated upon every access to a network shared file or folder. Failure events are generated only when access is denied at the file share level. The event may thus not indicate that the access to the shared folder or file was successful.	Event 5145: A network share object was checked to see whether client can be granted desired access Includes information about the account that performed the operation: username, domain, and SID, the Logon ID associated with the logon, and the source IP address and port. Requires Audit Detailed File Share to be enabled.	Security.evtx

Remote Access / Lateral movements

Name	Type	Description	Information / interpretation	Location	Tool(s)
Authentication - EVTX - Security.evtx Destination host	Remote Access / Lateral movements	For more information: accounts usage note.	Event 4624: An account was successfully logged on Event 4625: An account failed to log on Event 4672: Special privileges assigned to new logon Event 4647: User initiated logoff (used for logoffs from Interactive or RemoteInteractive logons) Event 4634: An account was logged off	Security.evtx
Authentication - EVTX - Security.evtx Source host	Remote Access / Lateral movements	For more information: accounts usage note.	Only logged whenever alternate credentials are used: Event 4648: A logon was attempted using explicit credentials The TargetServerName and TargetInfo fields can reference information about the remote server and service (such as TargetInfo set to TERMSRV/<HOSTNAME> for outgoing RDP). For runas /NetOnly (and similar) process execution: Event 4624: An account was successfully logged on With Logon Type 9 and the specified alternate credentials as Network Account Domain and Network Account Name.	Security.evtx
Authentication - EVTX - Security.evtx AD DS Domain Controller	Remote Access / Lateral movements	For authentication attempts from a source host to a Active Directory domain-joined destination host (which is not the Domain Controller). For more information: accounts usage note.	For NTLM successful or failed authentication attempts: Event 4776: The domain controller attempted to validate the credentials for an account If the Result Code field is not equal to 0x0 the authentication failed. The event is associated with the computer from which the logon attempt originated and does not identify the target service. This event is also logged for non Domain Controllers, on the target computer, for logon attempts with local SAM accounts. For Kerberos authentication: If the user has not already retrieved a TGT during the session opening on the source host: Event 4768: A Kerberos authentication ticket (TGT) was requested If the Result Code field is not equal to 0x0 the request failed (but not for a failed authentication). Event 4769: A Kerberos service ticket was requested The ServiceName and ServiceSid fields indicate the service the service ticket is requested for. However, for lateral movement, the service and service SID are often set to the destination machine account, with no information on the actual service targeted (RPC, CIFS, etc.). Event 4771: Kerberos pre-authentication failed For authentication failures. As the Domain Controller only handles the authentication, and will not open a login session in this scenario, no 4624 or 4625 events will be logged. However, for a remote interactive logon on the destination host, a 4624 event of logon type 3 (and 4768 + 4769 events) will be logged on a Domain Controller (potentially different than the one that processed the authentication from the source host) originating from the destination host (as part of the interactive session opening process).	Security.evtx
Authentication - User Access Logging (UAL) AD DS Domain Controller and destination host Windows Server only, introduced in Windows Server 2012.	Remote Access / Lateral movements	Feature that consolidates data on client activity. On Domain Controllers, yield information on sessions opening on domain-joined computers (if the given DC was reached for authentication / Group Policy retrieval). For more information: User Access Logging note.	The information is stored locally in up to five Extensible Storage Engine (ESE) database files (.mdb), including: - The Current.mdb file which contains data for the last 24-hour. - Up to three <GUID>.mdb files, which contain data for an entire year (first to last day), going back to 2 years. The CLIENTS table of the aforementioned databases contain notable information: - Accessed Windows Server role GUID and description (AD DS, AD CS, SMB / CIFS service notably) - The client domain and username. - Total number of access. - First, last, and daily access timestamps. - Client IPv4 or IPv6 address. On Domain Controllers, the hostname associated with a given IP address at that time may be retrievable as machine accounts of domain-joined computers also authenticate to AD DS.	Database files (.mdb) in %SystemRoot%\System32\Logfiles\SUM\
Remote Desktop - EVTX Destination host	Remote Access / Lateral movements	For more information: lateral movement note.	Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx: - Event 1149: Remote Desktop Services: User authentication succeeded. Access to the Windows login screen, not necessarily a successful session opening. This event is however only generated upon successful authentication if Network Level Authentication (NLA) is required. Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational: - Event 21: Remote Desktop Services: Session logon succeeded. - Event 22: Remote Desktop Services: Shell start notification received - Event 23: Remote Desktop Services: Session logoff succeeded - Event 25: Remote Desktop Services: Session reconnection succeeded Events with a source network address set to LOCAL can sometimes be generated for console, non RDP login. Microsoft-WindowsRemoteDesktopServicesRdpCoreTS%4Operational.evtx: - Event 131: The server accepted a new TCP connection from client <IP>. Introduced in >= Windows Server 2012, only indicate a network access to the RDS service. For the aforementioned events, a Source Network Address of ::%16777216 could indicate that a ngrok tunnel was used to make RDP access.	Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational Microsoft-WindowsRemoteDesktopServicesRdpCoreTS%4Operational.evtx
Remote Desktop - HKLM\SYSTEM - ProfileList Destination host	Remote Access / Lateral movements	SID to username correspondence for accounts that have interactively logged on the system (including for domain accounts).	The last write timestamp of each key indicates was the associated user last logged on the system.	File: %SystemRoot%\System32\config\SOFTWARE Registry key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
Remote Desktop - EVTX Source host	Remote Access / Lateral movements	For more information: lateral movement note.	Microsoft-WindowsTerminalServicesRDPClient%4Operational.evtx: - Event 1024: RDP ClientActiveX is trying to connect to the server (<HOSTNAME>) - Event 1102: The client has initiated a multi-transport connection to the server <IP> - Event 1029: Base64(SHA256(UserName)) is = <HASH> This CyberChef formula can be used to compute the hash.	Microsoft-WindowsTerminalServicesRDPClient%4Operational.evtx
Remote Desktop - NTUSER - Terminal Server Client\Servers Source host	Remote Access / Lateral movements	-	Each remote host the user connected to (from the local system) is referenced as a dedicated subkey under Terminal Server Client\Servers\<IP>. This subkey is named after the IP address of the remote host. For each host, the associated subkey references: - The eventual saved username for the connection in the UsernameHint value. Additionally, the last written timestamp may be an indicator of the first access to the remote host (but may have also be updated for various other reasons).	File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat Registry key: HKCU\SOFTWARE\Microsoft\Terminal Server Client\Servers\<IP>
Remote Desktop - RDP Bitmap Cache Source host	Remote Access / Lateral movements	Partial captures of the remote desktop screen from the Remote Desktop Client for RDP sessions. Implemented to reduce the amount of data sent by the server to save bandwidth usage. Bitmap caching be deactivated client-side in the Remote Desktop Client.	-	Windows XP / Windows Server 2003: %SystemDrive%:\Documents and Settings\<USERNAME>\Local Settings\Application Data\Microsoft\Terminal Server Client\Cache\* Windows 7 and later: %SystemDrive%:\Users\<USERNAME>\AppData\Local\Microsoft\Terminal Server Client\Cache\*
Windows services - EVTX Destination host	Remote Access / Lateral movements	For more information: local persistence note.	System.evtx: - Event 7045: A service was installed in the system - Event 7036: The <SERVICE_NAME> service entered the <running/stopped> state Security.evtx: - Event 4697: A service was installed in the system. Introduced in Windows Server 2016 and Windows 10, and requires advanced auditing policy.	System.evtx Security.evtx
Windows scheduled tasks - EVTX Destination host	Remote Access / Lateral movements	For more information: local persistence note.	Microsoft-Windows-TaskScheduler%4Operational.evtx, events introduced in Windows 7 / Windows 2008: - Event 106: User "<DOMAIN | WORKGROUP>\<USERNAME>" registered Task Scheduler task "\<TASK_NAME>" - Event 140: User "<DOMAIN | WORKGROUP>\<USERNAME>" updated Task Scheduler task "<TASKNAME>" - Event 200: Task Scheduler launched action "<EXECUTABLE>" in instance "<GUID>" of task "<TASKNAME>" - Event 201: Task Scheduler successfully completed task "<TASKNAME>", instance "<GUID>", action "<EXECUTABLE>" with return code <INT>" - Event 141: User "<DOMAIN | WORKGROUP>\<USERNAME>" deleted Task Scheduler task "<TASKNAME>" Security.evtx, requires advanced auditing policy: - Event 4698: A scheduled task was created - Event 4700: A scheduled task was enabled - Event 4701: A scheduled task was disabled - Event 4702: A scheduled task was updated - Event 4699: A scheduled task was deleted	Microsoft-Windows-TaskScheduler%4Operational.evtx Security.evtx
PowerShell remoting (WinRM) - EVTX Destination host	Remote Access / Lateral movements	For more information: PowerShell activity note.	Microsoft-Windows-PowerShell%4Operational: - Event 4103, related to PowerShell modules. Requires PowerShell Module Logging to be enabled. - Event 4104, related to PowerShell script block. Requires PowerShell Script Block Logging to be enabled. By default, events will however be logged for potentially-malicious commands execution. Microsoft-Windows-WinRM%4Operational.evtx: - Event 91: Creating WSMan shell on server with ResourceUri: http://schemas.microsoft.com/[...]	Microsoft-Windows-PowerShell%4Operational Microsoft-Windows-WinRM%4Operational.evtx
PowerShell remoting (WinRM) - wsmprovhost.exe execution Destination host	Remote Access / Lateral movements	The PowerShell host process (wsmprovhost.exe) is executed to hosts the active remote session on the destination system. If programs are executed through the WinRM session, they will be spawned as child of the wsmprovhost.exe process.	-
PowerShell remoting (WinRM) - EVTX Source host	Remote Access / Lateral movements	For more information: PowerShell activity note.	Microsoft-Windows-WinRM%4Operational.evtx: - Event 6: Creating WSMan Session. The connection string is: <REMOTE_HOST>/wsman?PSVersion=XXX - Event 33: Closing WSMan Session completed successfully - Events 8, 15, 16, and 31: other events that occur during the life-cycle of the WinRM session	Microsoft-Windows-WinRM%4Operational.evtx
WMI - wmiprvse.exe execution Destination host	Remote Access / Lateral movements	The WMI Provider Host (wmiprvse.exe) process is executed to run WMI commands. If programs are executed through WMI, they will be spawned as child of the wmiprvse.exe process.	-
SSH - SSHlogs Destination host	Remote Access / Lateral movements	OpenSSH for Windows logs in a text format. Not enabled by default (requires SyslogFacility LOCAL0 / LogLevel Debug3) to be set in the server sshd_config.	Contains information about users successful and unsuccessful authentication attempts (with the associated IP source).	%ProgramData%\ssh\logs
Port forwarding - HKLM\SYSTEM - PortProxy	Remote Access / Lateral movements	netsh port forwarding activity: listening host / port and remote host / port.	-	File: %SystemRoot%\System32\config\SYSTEM Registry key: HKLM\SYSTEM\CurrentControlSet\Services\PortProxy\v4tov4\tcp\*

Network usage

Name	Type	Description	Information / interpretation	Location	Tool(s)
System Resource Usage Monitor (SRUM) Introduced in Windows 8.	Network usage	Detailed in Program execution.	The Network Data Usage table (GUID {973F5D5C-1D90-4944-BE8E-24B94231A174}) tracks programs execution and network usage of the executed programs. For each entry in the Network Data Usage table (SrumECmd's NetworkUsages output), the following information may be recorded: - Timestamp of the SRUM entry creation. - Full path of the executable or application information / description for built-in components. - Metrics on network data usage (bytes sent and receive on a given network interface).	%SystemRoot%\System32\SRU\SRUDB.dat	SrumECmd
HKLM\SYSTEM - NetworkList	Network usage	Basic network historical information (network name and type, first and last connection, etc.)	-	File: %SystemRoot%\System32\config\SYSTEM Registry key: HKLM\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\

Local persistence

For artefacts on local persistence and AutoStart Extensibility Point (ASEP), refer to:

• The local persistence note.

• The persistence-info repository.

Web browsers usage

The web browsers related artefacts can be split in the following categories:

• User profile: web browsers, such as Chronium-based browsers and Firefox, implement a profile feature to store user's setttings, history, favourites, etc. The databases and files that store these information are usually stored under a user specific profile folder.

• History: web browsing history and download history.

• Cookies: web browsing cookies (session tokens).

• Cache: cache of resources downloaded from accessed websites (images, text content, HTML, CSS, Javascript files, etc.).

• Sessions: tabs and windows from a browsing session.

• Settings: configuration settings.

These files are often stored under %LocalAppData% (%SystemDrive%:\Users\<USERNAME>\AppData\Local\) and %AppData% (%SystemDrive%:\Users\<USERNAME>\AppData\Roaming\).

Name	Type	Description	Information / interpretation	Location	Tool(s)
NTUSER - TypedURLs	Web browsers usage	URL entered (typed, pasted, or auto-completed) in the Internet Explorer (IE) web browser search bar. Web searches do not generate entries, only typing of an URL will. Entries are added / updated in near real-time.	The URL are stored as url1 to url[N] in inversed chronological order. The last write timestamp of the key is thus the timestamp of visit of the most recently visited URL.	File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat Registry key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\TypedURLs
Microsoft Internet Explorer	Web browsers usage	Microsoft Internet Explorer artefacts. For more information: Browsers forensics note.	-	History, downloads, cache, and cookies metadata in a ESE database: %LocalAppData%\Microsoft\Windows\WebCache\WebCacheV01.dat > History: History table > Downloads: iedownload table. > Cache: content table > Cookies metadata: Cookies table. Local files access, not necessarily through the webbrowser, may also appear in the WebCacheV01.dat database with the file URI scheme (such as file:///<DRIVE_LETTER>:/folder/file). Cookies: %AppData%\Microsoft\Windows\Cookies Sessions: %LocalAppData%\Microsoft\Internet Explorer\Recovery\*.dat	NirSoft's BrowsingHistoryView
Microsoft Edge (Legacy)	Web browsers usage	Microsoft Edge (legacy version) artefacts. For more information: Browsers forensics note.	-	User profile(s): %LocalAppData%\Packages\Microsoft.MicrosoftEdge_XXX\AC History, downloads, cache, and cookies (file shared with Microsoft Internet Explorer): %LocalAppData%\Microsoft\Windows\WebCache\WebCacheV01.dat Cache: %LocalAppData%\Packages\Microsoft.MicrosoftEdge_XXX\AC#!XXX\MicrosoftEdge\Cache Sessions: %LocalAppData%\Packages\Microsoft.MicrosoftEdge_XXX\AC\MicrosoftEdge\User\Default\Recovery\Active Settings: %LocalAppData%\Packages\Microsoft.MicrosoftEdge_XXX\AC\MicrosoftEdge\User\Default\DataStore\Data\nouser1\XXX\DBStore\spartan.edb	NirSoft's BrowsingHistoryView
Microsoft Edge (Chronium-based)	Web browsers usage	Microsoft Edge (Chronium-based) artefacts. Since Edge version v79 (January 2020), Microsoft Edge uses a Chronium backend and shares similar artefacts to Google Chrome. For more information: Browsers forensics note.	-	User profile(s): %LocalAppData%\Microsoft\Edge\User Data\<Default | Profile X>\* With X ranging from one to n. History: %LocalAppData%\Microsoft\Edge\User Data\<Default | Profile X>\History Cookies: %LocalAppData%\Microsoft\Edge\User Data\<Default | Profile X>\Network\Cookies Cache: %LocalAppData%\Microsoft\Edge\User Data\<Default | Profile X>\Cache Sessions: %LocalAppData%\Microsoft\Edge\User Data\<Default | Profile X>\Sessions Settings: %LocalAppData%\Microsoft\Edge\User Data\<Default | Profile X>\Preferences	NirSoft's BrowsingHistoryView
Google Chrome	Web browsers usage	Google Chrome artefacts. For more information: Browsers forensics note.	-	User profile(s): %LocalAppData%\Google\Chrome\User Data\<Default | Profile X>\* With X ranging from one to n. History: %LocalAppData%\Google\Chrome\User Data\<Default | Profile X>\History Cookies: %LocalAppData%\Google\Chrome\User Data\<Default | Profile X>\Network\Cookies Cache: %LocalAppData%\Google\Chrome\User Data\<Default | Profile X>\Cache Sessions: %LocalAppData%\Google\Chrome\User Data\<Default | Profile X>\Sessions Settings: %LocalAppData%\Google\Chrome\User Data\<Default | Profile X>\Preferences	NirSoft's BrowsingHistoryView
Mozilla Firefox	Web browsers usage	Mozilla Firefox artefacts. For more information: Browsers forensics note.	-	User profile(s): %AppData%\Mozilla\Firefox\Profiles\<ID>.default-release\* History, downloads, and bookmarks in a SQLite database: %AppData%\Mozilla\Firefox\Profiles\<ID>.default-release\places.sqlite Cookies in a SQLite database: %AppData%\Mozilla\Firefox\Profiles\<ID>.default-release\cookies.sqlite Cache: %LocalAppData%\Mozilla\Firefox\Profiles\<ID>.default-release\cache2\* Sessions: %AppData%\Mozilla\Firefox\Profiles\<ID>.default-release\sessionstorebackups\* Settings: %AppData%\Mozilla\Firefox\Profiles\<ID>.default-release\prefs.js	NirSoft's BrowsingHistoryView

Devices and USB activity

Windows devices terminology:

• The vendor ID identifies a specific vendor, with a mapping available on devicehunt.com. The product ID (PID) identifies a product from that vendor.

• The device ID or hardware ID is "a vendor-defined identification string that Windows uses to match a device to a driver package". The identifier references the vendor and product names as well as the revision version. Example for a DataTraveler_3 USB key by Kingston: Ven_Kingston&Prod_DataTraveler_3.0&Rev_PMAP.

• The instance ID is "a device identification string that distinguishes a device from other devices of the same type on a computer". It contains the device serial number, if supplied, and otherwise "some kind of location information". Example of an instance ID for a device that does not supply a serial number: 5&2eab04ab&0&1.

• The device instance ID is "a system-supplied device identification string that uniquely identifies a device in the system". It is notably composed of the device's device ID and instance ID.

• The container ID is "a system-supplied device identification string that uniquely groups the functional devices associated with a single-function or multifunction device installed in the computer". Starting with Windows 7, the Plug and Play (PnP) manager uses the container ID to group one or more device nodes (devnodes) that originated from a particular physical device.

• The device interface class represents the type of the device (storage devices, USB devices, Bluetooth devices, etc.). Each device interface class is associated with a unique GUID, defined by Microsoft. The list of GUIDs by category of device can be found in the Microsoft documentation.

  • External physical storage GUID: {53f56307-b6bf-11d0-94f2-00a0c91efb8b}.

  • Logical volumes GUID: {53f5630d-b6bf-11d0-94f2-00a0c91efb8b}.

Devices and USB activity forensics artefacts

The information below originates from tests on Windows 10 Pro - 19045.2965 and Windows 11 Pro - build 22621.1702 systems.

Name	Type	Description	Information / interpretation	Location	Tool(s)
HKLM\SYSTEM - Enum\USB	Devices and USB activity	Contains system-wide information about the currently or previously connected USB devices.	Each USB devices is associated with a dedicated subkey under the Enum\USB key. This subkey is named after the device vendor ID (VID) and product ID (PID) of the device. Example: VID_1B1C&PID_4242. Underneath the VID / PID subkey, another subkey is named after the instance ID of the device (referencing either the device's serial number or location information). This subkey references in turn information and parameters for the USB device as values and under the Properties and Device Parameters subkeys, notably: - The ClassGUID key value references the device interface class GUID of the device. - The ContainerID key value references the container ID of the device. The Properties\{83da6326-97a6-4088-9453-a1923f573b29} subkey notably references three child subkeys of interest, each containing a timestamp value: > 0064 (starting from Windows 7): timestamp of when the device was first plugged-in / installed. > 0066 (starting from Windows 8): timestamp of when the device was last connected. > 0067 (starting from Windows 8): timestamp of when the device was last removed. This key can thus be used to: - Identity the vendor ID (VID) and product ID (PID) of an USB device from its serial number or location information (and vice versa). - Determine when the device was first and last plugged-in and last unplugged for Windows 7 / 8+.	File: %SystemRoot%\System32\config\SYSTEM Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\
HKLM\SYSTEM - Enum\USBSTOR	Devices and USB activity	Contains system-wide information about the currently or previously connected USB devices that are related to storage.	Each USB devices is associated with a dedicated subkey under the Enum\USBSTOR key. This subkey is named after the device device ID or hardware ID of the device, which references the vendor and product names. Example: Disk&Ven_SanDisk&Prod_Extreme&Rev_0001. Underneath the device ID subkey, another subkey is named after the instance ID of the device (referencing either the device's serial number or location information). This subkey in turn references: - The same information as the Enum\USB key. - A volume id for one of the device volume in the DiskId key value under the Device Parameters\Partmgr. This key can thus be used to: - Identity the device id (vendor and product names) of an USB device from its serial number or location information (and vice versa). - Determine when the device was first and last plugged-in and last unplugged for Windows 7 / 8+. - Retrieve a volume id for the (or one of the) volume(s) of the device.	File: %SystemRoot%\System32\config\SYSTEM Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR\
HKLM\SYSTEM - Enum\SWD\WPDBUSENUM	Devices and USB activity	Contains system-wide information about the currently or previously .	Each devices is associated with a dedicated subkey under the WPDBUSENUM key. This key is named with a string containing either: - The device's device instance ID (that includes the device's vendor and product names and serial number) and device interface class GUID. Example: SWD#WPDBUSENUM#_??_USBSTOR#DISK&VEN_SAMSUNG&PROD_TYPE-C&REV_1100#0376022080001660&0#{53F56307-B6BF-11D0-94F2-00A0C91EFB8B}. - The volume id. Example: SWD#WPDBUSENUM#{44B06C95-F0BA-11ED-9802-6C9466A63B90}#000000000C900000. This subkey references: - The same information as the Enum\USB key. - A "friendly name" or display name of the (or one of the) volume associated with the device in the FriendlyName key value. This key can thus be used to: - Identity the device id (vendor and product names) of an USB device from its serial number or location information (and vice versa). - Determine when the device was first and last plugged-in and last unplugged for Windows 7 / 8+. - Retrieve a friendly name of the (or one of the) volume associated with the device.	File: %SystemRoot%\System32\config\SYSTEM Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\SWD\WPDBUSENUM
HKLM\SYSTEM - MountedDevices	Devices and USB activity	The persistent database of the Mount manager (component responsible for managing volume names). Contains system-wide information about the currently or previously mounted drives (such as the system drive or USB devices).	Each devices is associated with a separate binary value, composed of: - The device volume GUID (as the key's value name). - The device / hardware ID, instance ID, and device interface class GUID in a # separated string (as the key's value data). > The device ID / hardware ID references the vendor and product names. > The instance ID contains the device's serial number or location information. > The device interface class represents the type of the device and each class is associated with a unique GUID. Full example value for an USB key: _??_USBSTOR#Disk&Ven_Kingston&Prod_DataTraveler_3.0&Rev_PMAP#60A44C42568CB041B98902A4&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b} This key can thus be used to identity the volume GUID or the drive letter associated with the device from its serial number or location information (and vice versa).	File: %SystemRoot%\System32\config\SYSTEM Registry key: HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices
HKLM\SYSTEM - DeviceClasses Introduced in Windows Vista.	Devices and USB activity	Contains system-wide information about the currently or previously connected plug and play devices (such as storage devices, volumes, network devices, Bluetooth devices, etc.).	Contains subkeys for each device classes (physical disk, volume, USB devices, Bluetooth devices, etc.). The subkeys are named after the device classes GUID. Under each GUID subkeys, the devices of the given type are referenced as their own subkey, whose name is a # separated string composed of the device / hardware ID, instance ID, and device interface class GUID of the device. An external physical storage would be referenced under the {53f56307-b6bf-11d0-94f2-00a0c91efb8b} GUID subkey. The logical volumes on the device would be referenced in the {53f5630d-b6bf-11d0-94f2-00a0c91efb8b} GUID subkey. Example of a {53f56307-b6bf-11d0-94f2-00a0c91efb8b} subkey: ##?#SCSI#Disk&Ven_Samsung&Prod_SSD_870_EVO_2TB#4&cd4f6d&0&040000#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}. Example of a {53f5630d-b6bf-11d0-94f2-00a0c91efb8b} subkey: ##?#STORAGE#Volume#{d446d066-ade9-11ed-8679-eae9fe3c14cf}#0000000000100000#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}. This key can thus be used to identity the device id (vendor and product names) of an USB device from its serial number or location information (and vice versa). The last written timestamp of a device subkey can be an indicator of when the device was last plugged on the system or the first time the device was plugged following a reboot. However, the subkey does not appear to be reliably written to on recent versions of the Windows operating system and thus the timestamp should not be considered by itself as a reliable indicator of the device's last activity.	File: %SystemRoot%\System32\config\SYSTEM Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses
HKLM\SOFTWARE - Windows Portable Devices	Devices and USB activity	Contains information on currently or previously attached media and storage devices, notably the device volume(s)'s "friendly name" or display name.	Each devices is associated with a dedicated subkey under the Windows Portable Devices\Devices key. This key is named with a string containing either: - The device's device instance ID (that includes the device's vendor and product names and serial number) and device interface class GUID. Example: SWD#WPDBUSENUM#_??_USBSTOR#DISK&VEN_SAMSUNG&PROD_TYPE-C&REV_1100#0376022080001660&0#{53F56307-B6BF-11D0-94F2-00A0C91EFB8B}. - The volume id. Example: SWD#WPDBUSENUM#{44B06C95-F0BA-11ED-9802-6C9466A63B90}#000000000C900000. The FriendlyName key value represents the "friendly name" or display name of the (or one of the) volume associated with the device. This key can thus be used to identity a volume friendly name from (a) a device serial number / location information or (b) a volume id (and vice versa).	File: %SystemRoot%\System32\config\SOFTWARE Registry key: HKLM\SOFTWARE\Microsoft\Windows NT\Windows Portable Devices
HKLM\SOFTWARE - VolumeInfoCache	Devices and USB activity	Contains information on currently or previously mounted volumes, notably a mapping between drive letters and the last associated volume(s)'s "friendly name" or display name.	Each previously referenced drive letter (A: to Z:, including C:) is associated with a dedicated subkey under the VolumeInfoCache key. This subkey contains information about the volume last associated with the corresponding drive letter: - The volume friendly name in the VolumeLabel value. - The associated drive type in the DriveType value. Both hard disks / SSDs and storage devices (such as USB keys) appear to be associated with the value 3 (on Windows 10). The last written timestamp of the key is an indicator of when a volume was last associated with a given drive letter. This key can thus be used to: - Identity a volume drive letter from a volume friendly name (and vice versa), if the volume was the last one to be associated with the given letter. - Determine when a volume was last associated with a given drive letter.	File: %SystemRoot%\System32\config\SOFTWARE Registry key: HKLM\SOFTWARE\Microsoft\Windows Search\VolumeInfoCache
HKLM\SOFTWARE - EMDMgmt Only available if the system drive is not an SSD	Devices and USB activity	Related to the ReadyBoost feature.	Each USB devices is associated with a dedicated subkey under the EMDMgmt key. This subkey is named after the device device ID or hardware ID of the device, which references the vendor and product names. Example: Disk&Ven_SanDisk&Prod_Extreme&Rev_0001. The subkey contains: - the device's serial number - The associtated volume serial number - Possibly the volume friendly name (if the mounted volume has a name). Example: Disk&Ven_Best_Buy&Prod_Geek_Squad_U3&Rev_6.15 > LastWrite: Sun Jul 17 12:13:25 2011 Z > SN: 0C90195032E36889&0 > Vol Name: TEST > VSN: 6403-CD1C	File: %SystemRoot%\System32\config\SOFTWARE Registry key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt
NTUSER - MountPoints2	Devices and USB activity	Currently or previously mapped drives (such as the system drive, USB devices, or network shares) mounted by the associated user.	Each drives is represented by a subkey, which is named as either the volume GUID, a letter, or, for network shares, using a specific nomenclature (##<IP | HOSTNAME>#<SHARE_NAME>). For devices, the volume GUID can be used to retrieve more information on the device from the HKLM\SYSTEM\MountedDevices registry key, including the device / hardware ID (vendor and product name) and instance ID (with the serial number if existing). This key can be used to determine which user interacted with a given USB device. However entries are not reliably created, so the absence of an entry is not an indicator that the given user didn't interact with the device.	File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat Registry key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2
setupapi logs	Devices and USB activity	Plaintext log files that track installation of devices and drivers. The logs are rotated and preserved, so historical data dating back to the system install should be available (if the logs were not deleted / tampered).	Device installation entries (generated when the device is plugged-in) contain various information, including the device: - serial number. - Device id (vendor and product names) or vendor ID (VID) + product ID (PID). Extract of an entry for the first time an USB device was plugged-in: >>> [Device Install (Hardware initiated) - SWD\WPDBUSENUM_??_USBSTOR#Disk&Ven_USB&Prod_Flash_Disk&Rev_1100#7&d2713f&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}] >>> Section start 2021/02/07 19:11:17.101 Device are sometimes "deleted" through the cleanmgr.exe utility: >>> [Delete Device - USB\VID_090C&PID_2000\8&1DBBAC39&0&3] >>> Section start 2023/03/16 16:55:26.426 cmd: "%SystemRoot%\Windows\system32\cleanmgr.exe" /autoclean /d C: <<< Section end 2023/03/16 16:55:26.473 The timestamps in the setupapi logs are in the local timezone of the system. The logs can be used to determine when a device was first plugged (in the local timezone of the system).	Windows XP: %SystemRoot%\setupapi.log Starting from Windows 7: %SystemRoot%\INF\setupapi.dev.log %SystemRoot%\INF\setupapi.dev.<YYYYMMDD-HMMSS>.log
EVTX - Microsoft-Windows-Storage-ClassPnP/Operational	Devices and USB activity	Provider: Microsoft-Windows-StorDiag.	Event 507: error events. > Generated multiple times, for every connection, and sometimes safe removal and while the device is plugged-in. As the event is generated upon errors, it may however not be reliably logged. Relevant information: - Device's vendor and product names. - Device serial number (which is however not the same as the one found in the registry and ofter shows up as AA00000000000489 for different USB storage devices). - Device number, which is an incremental number based on the number of devices plugged-in, for all devices, including the system drive (which would like be device number 1). - Device's DeviceGUID which can be used for correlation with other events. Other events, also generated upon errors and with similar information: 500, 502, 503, 504, 505, 506, and 510. These events, especially 507, can be used to: - Determine when a device was plugged using the device vendor and product names or serial number. - Retrieve (a version of) the device serial number (!= registry serial number) and its vendor and product names. - Identify the device DeviceGUID for correlation with other events.	Microsoft-Windows-Storage-ClassPnP%4Operational.evtx
EVTX - Microsoft-Windows-Kernel-PnP/Device Configuration	Devices and USB activity	Provider: Microsoft-Windows-Kernel-PnP. Contains information for all plug and play devices, not limited to USB storage devices.	Event 400: Device <DEVICE> was configured. Event 401: Device <DEVICE> failed configuration. Event 410: Device <DEVICE> was started. Event 411: Device <DEVICE> had a problem starting. Event 430: Device <DEVICE> requires further installation. > The events above appear to be generated when a device is first plugged-in to the system. Event 420: Device <DEVICE> was deleted. The <DEVICE> string is based on the event DeviceInstanceId field, which contains the device's vendor ID (VID), product ID (PID) and (registry) serial number or location information. These events can be used to: - Determine when a device was first plugged. - Identity the vendor ID (VID) and product ID (PID) of the device from its serial number or location information (and vice versa).	Microsoft-Windows-Kernel-PnP%4Configuration.evtx
EVTX - Microsoft-Windows-Kernel-PnP/Device Management Introduced in Windows 11.	Devices and USB activity	Provider: Microsoft-Windows-Kernel-PnP. Contains information for all plug and play devices, not limited to USB storage devices.	Event 1010: Device <DEVICE> has been surprise removed as it is reported as missing on the bus. The event is reliably generated when a device is removed / unplugged without prior ejection. Additionally, subsequent immediate event(s) are generated for each of the device volume(s). Relevant information: - For USB storage device: vendor ID (VID), product ID (PID), (registry) serial number or location information. Example: USB\VID_18A5&PID_0302\1601000001586259. - For volumes: the volume GUID of the volume. Example: STORAGE\Volume\<GUID>. If a device has been removed without prior ejection, these events can be used to: - Determine when a device was unplugged with out prior ejection, from the device (registry) serial number or location information. - Identity the vendor ID (VID) and product ID (PID) of the device from its serial number or location information (and vice versa). - Identify the volumes GUID associated with the device.	Microsoft-Windows-Kernel-PnP%4Device Management.evtx
EVTX - Microsoft-Windows-Partition/Diagnostic	Devices and USB activity	Provider: Microsoft-Windows-Partition.	Event 1006. The event is generated when a device is plugged and unplugged with or without prior ejection. This event contains key relevant information, and notably information that are not available in other sources: - Vendor and product names of the device. - vendor ID (VID), product ID (PID), and (registry) serial number or location of the device (in the ParentId field). - A volume id for one of the device volume in the RegistryId field. - (A version of) the device serial number (!= registry serial number). - The DeviceGUID of the device in the DiskId, for correlation with other events. - The size in bytes of the device in the Capacity field. The capacity is set to 0 if the event match a removal. - Raw dumps of the partition table (field PartitionTable), Master Boot Record (MBR) (field Mbr), and / or Volume Boot Record (VBR) (field VbrX) if available. The VBR dump can be used to reconstruct the Volume Serial Number of the device. This event can be used to determine when a drive was plugged / unplugged and to retrieve the aforementioned information.	Microsoft-Windows-Partition%4Diagnostic.evtx
EVTX - Microsoft-Windows-Ntfs/Operational	Devices and USB activity	Provider: Microsoft-Windows-Ntfs. These events are only generated for devices that have a NTFS volume.	Event 142: Summary of disk space usage, since last event. > This event is generated with a limited delay following the plugin of the device, one occurrence for each volume(s) of the device. Relevant information: - The volume friendly name and associated drive letter. - A volume id for one of the device volume. This event can thus be used to determine the volume friendly name(s) and drive letter(s) associated with a device, either using the volume GUIDs of the volumes on the device or time correlation with other events. Starting from Windows 11: Event 4: The NTFS volume has been successfully mounted. Event 9: NTFS scanned entire volume bitmap. Event 10: NTFS cached run statistics. Event 300: The NTFS volume dismount has started. Event 303: The NTFS volume has been successfully dismounted. > These events are reliably generated when a device is plugged and unplugged with or without prior ejection. Relevant information: - The volume friendly name and associated drive letter. - Vendor and product names of the device. - (A version of) the device serial number (!= registry serial number). - DeviceGuid (for correlation with other events). - Whether the drive was ejected ("Reason: Explicit lock") or directly unplugged ("Reason: Surprise removal"). These events can thus be used to: - Determine when a device was plugged / unplugged (and if it was with or without prior ejection) and its associated volumes mounted / dismounted - Identity the volume friendly name(s) and drive letter(s) associated with a device.	Microsoft-Windows-Ntfs%4Operational.evtx

Anti-vius and Remote Administration/Access applications

The ruler-project references numerous anti-virus products (20+) and remote administration/access applications (15+) artifacts.

Other third-party applications

The SANS institute "Windows Third-Party Apps Forensics" poster can be consulted for a list of artefacts from a number of popular Windows third-party applications (also including anti-vius and remote administration/access applications).

Name	Type	Description	Information / interpretation	Location	Tool(s)
Azure's PowerShell / CLI activity	Interaction with Azure though the Az PowerShell module and az CLI utility.	Folder telemetry: may contain information on azurecli commands (user Azure ID, raw command, etc.). Folder commands: similar to telemetry folder, with less data on the executed azure cli commands. Folder ErrorRecords: details on HTTP requests, and their associated response, that generated an error.	%SystemRoot%\Users\<USERNAME>\.azure\*

Defense evasion

Name	Type	Description	Information / interpretation	Location	Tool(s)
EVTX - Security.evtx - Security event log clear	Defense evasion	Generated upon the deletion of events in the Security logs. The absence of event 1102 should however not be taken as a sign of integrity of the Security events, as the generation of this event can be bypassed. For instance, the threads of the Event Log service threads (hosted by svchost.exe) can be suspended to prevent events generation while the threads are suspended (even though all events will be written upon resuming of the threads).	Event 1102: The audit log was cleared	Security.evtx
EVTX - System.evtx - Security event log clear	Defense evasion	Generated upon the deletion of events from event logs files (other than Security.evtx).	Event 104: The <PROVIDER> log file was cleared	System.evtx

Others

Name	Type	Description	Information / interpretation	Location	Tool(s)
Thumbs.db Thumbcache	Thumbnail previews of files	The Thumbs.db and Thumbcache files contain cached thumbnail previews for files (pictures, some document and media file types) in folders that were interactively accessed with the Windows Explorer. The thumbnail previews are stored in these databases as it takes less system resources (CPU time and memory) to retrieve an already generated thumbnail as opposed to generating it every time the directory is accessed. For a Thumbs.db file to be generated in a given folder, or for entries to be added to the central Thumbcache files, the access must have been done with some sort of files' thumbnail / icon preview enabled. The cached thumbnail previews persist even after deletion of the associated files. Some document types, such as PDF files, will have their first page as their thumbnail preview.	The Thumbs.db files are stored in their associated folders, with one individual Thumbs.db file per folder (that was interactively accessed with files preview). However, since Windows Vista, Thumbs.db files are only generated for access through UNC paths (such as \\<HOST>\<SHARE_NAME>\<FOLDER> or \\<HOST>\c$\<FOLDER>) in the remote / share directory. Each thumbnail created in a directory is represented in the Thumbs.db file as a small JPEG file, regardless of the file's original format. The images are resized to 96 × 96 pixels by default. As each Thumbs.db file is associated with a given directory, the location of the cached thumbnails can be easily deduced. Starting with Windows Vista, the Thumbcache files centralize thumbnails in a central location. Each Thumbcache file, labeled thumbcache_<RESOLUTION>.db, contains thumbnails from all locations. The <RESOLUTION> indicate the resolution of the thumbnail previews, such as the thumbcache_1280.db file for thumbnails in 1280 x 720 pixels resolution. The location of the file linked to a thumbnail is not stored in the Thumbcache file. However, each thumbnail in the Thumbcache file is associated with an unique identifier ThumbnailcacheID. This identifier / hash can be used to retrieve the location of the associated file, mostly for non deleted files: - By scanning and computing the identifier for every files on the volume. This requires the file to still be present on the volume. - By searching the Windows Search database (Windows.edb) for the ThumbnailcacheID, as a table of this database notably references the file original full path and size. As the Windows Search database is updated in near real time and does not store information on deleted files, this also requires the original file to still be present.	Thumbs.db: individual hidden files in their associated folders. Thumbcache: %SystemDrive%:\Users\<USERNAME>\AppData\Local\Microsoft\Windows\Explorer\thumbcache_<RESOLUTION>.db files.	Thumbs Viewer Thumbcache Viewer
Windows Push Notifications (WPN) Introduced in Windows 10.	Windows Push Notifications	The Windows Push Notification service allows applications to deliver / push notifications, in three differents forms: - Badge, tiny symbol that appears in the corner of an application's taskbar / hidden icon. Examples: the number of unreaded messages on Teams, Discord or other instant messaging applications. - Tile, rectangular shape that is displayed in the screen and linked to an application. - Toast, rectangular shaped pop-up box that can appear for a limited time (5 seconds by default) at the bottom right of the screen or be sent directly to the Windows Action Center. Examples: instant message applications (such as Teams) notifying of a new message. More information on the Windows Push Notifications can be found in the "A Digital Forensic View of Windows 10 Notifications" Digital Forensics paper.	Each notification is associated with a dedicated entry in the Notification table of the wpndatabase.db database. There are system-wide notifications and per-user notifications, stored in different databases (with one database per-user). Each entry contains notably the arrival and expery time as well as a "payload" associated with the notification. For toast notification, the payload contains the content of the notification. For instant message application, or social media / instant message web application accessed through a webbrowser, the payload may contain the message received. The notifications are short-lived and deleted from the database after their expiry time or following an end-user acknowledgement (closing of the pop-up or clearing from the Windows Action Center). The wpndatabase.db database thus provided very limited historical data. More information might be retrivable in the Write-Ahead Logging (WAL) file wpndatabase.db-wal and / or carved from the database (using tools such as bring2lite or fqlite).	Per user database and Write-Ahead Logging (WAL) files: %SystemDrive%:\Users\<USERNAME>\AppData\Local\Microsoft\Windows\Notifications\wpndatabase.db %SystemDrive%:\Users\<USERNAME>\AppData\Local\Microsoft\Windows\Notifications\wpndatabase.db-wal System-wide database and Write-Ahead Logging (WAL) files: %SystemDrive%:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Windows\Notifications\wpndatabase.db %SystemDrive%:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Windows\Notifications\wpndatabase.db-wal
EVTX - Microsoft-Windows-VHDMP-Operational.evtx - ISO mounting events	Phishing / malware execution	ISO image can be leveraged in phishing scenarios where the loader is packed in an ISO file to avoid the Mark-of-the-Web (on unpatched system).	Upon the mounting of an ISO image, the following events, containing the full path to the ISO and the responsible user, will be generated: - Event 22: Starting to create the handle for the file backing virtual disk <ISO_PATH> - Event 23: Handle for the file backing virtual disk <ISO_PATH> created successfully - Event 12: Handle for virtual disk <ISO_PATH> created successfully [...] - Event 25: Beginning to bring the <ISO_PATH> online (surface)	Microsoft-Windows-VHDMP-Operational.evtx
EVTX - Application.evtx - ESENT events	AD post exploitation	Active Directory ntds.dit dump with ntdsutil.	Upon execution of the ntdsutil command to dump the Active Directory ntds.dit database, the following events (containing the ntds keyword) will be generated: - Event 325: The database engine created a new database [...] - Event 326: The database engine attached a database [...] - Event 327: The database engine detached a database [...] - Event 206: A database location change was detected [...]	Application.evtx
EVTX - Security.evtx - DRSUAPI replication	AD post exploitation	Active Directory ntds.dit dump through DRSUAPI replication functions (DCSync).	Upon replication operations, such as the retrieval of Active Directory secrets (DCSync attack), the following events will be generated if the operation was not conducted under a Domain Controller identity: - Event 4662: An operation was performed on an object with the Property attribute equal to the 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 or 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 GUID.	Security.evtx

TODO

• IconCache.db

• Hidden local account HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList

• Bitsadmin

  • EVTX: Microsoft-Windows-Bits-Client%4Operational.evtx 59

  • Persistent files: %SystemRoot%\ProgramData\Microsoft\Network\Downloader\ https://www.sans.org/white-papers/39195/

• Syscache hive

• Small memory dumps: hiberfil.sys, pagefile.sys, swapfile.sys

• Registry LOG Files

---

References

https://nasbench.medium.com/a-primer-on-event-tracing-for-windows-etw-997725c082bf

https://blog.1234n6.com/2018/10/available-artifacts-evidence-of.html

SANS posters Windows forensics - https://www.sans.org/posters/windows-forensic-analysis/

https://www.scitepress.org/papers/2017/64167/64167.pdf

http://windowsir.blogspot.com/2013/07/howto-determine-program-execution.html

https://www.sans.org/blog/opensavemru-and-lastvisitedmru/

https://andreafortuna.org/2018/05/23/forensic-artifacts-evidences-of-program-execution-on-windows-systems/

https://dfir.ru/2020/04/08/bam-internals/

https://cellebrite.com/en/analyzing-program-execution-windows-artifacts/

https://blog.1234n6.com/2018/10/available-artifacts-evidence-of.html

https://crucialsecurity.wordpress.com/2011/03/14/typedurls-part-1/

https://www.crowdstrike.com/blog/how-to-employ-featureusage-for-windows-10-taskbar-forensics/

https://www.hexacorn.com/blog/2013/01/19/beyond-good-ol-run-key-part-3/

https://learn.microsoft.com/en-us/windows/win32/shell/app-registration

https://thinkdfir.com/2020/10/23/when-did-recentapps-go/

https://df-stream.com/2017/10/recentapps/

https://github.com/volatilityfoundation/community/blob/master/ThomasChopitea/autoruns.py

https://www.istrosec.com/blog/windows-10-timeline/

https://kacos2000.github.io/WindowsTimeline/WindowsTimeline.pdf

https://bohops.com/2021/03/16/investigating-net-clr-usage-log-tampering-techniques-for-edr-evasion/

https://www.youtube.com/watch?v=rioVumJB0Fo

https://www.youtube.com/watch?v=qxPoKNmnuIQ

https://www.13cubed.com/downloads/windows_registry_cheat_sheet.pdf

https://www.hecfblog.com/2013/08/daily-blog-67-understanding-artifacts.html

https://learn.microsoft.com/en-us/windows-hardware/drivers/storage/supporting-mount-manager-requests-in-a-storage-class-driver

https://www.sans.org/blog/computer-forensic-guide-to-profiling-usb-device-thumbdrives-on-win7-vista-and-xp/

http://windowsir.blogspot.com/2013/04/plugin-emdmgmt.html

https://www.hecfblog.com/2013/08/daily-blog-66-understanding-artifacts.html

http://website.bcmsystem.com/orion/wp-content/uploads/2019/05/Microsoft-Windows-10-USB-Forensic-Artefacts.pdf

https://lifars.com/wp-content/uploads/2020/04/LIFARS-WhitePaper-Windows-ShellBags-Forensics-Investigative-Value-of-Windows-ShellBags.pdf

https://aboutdfir.com/new-windows-11-pro-22h2-evidence-of-execution-artifact/

https://www.youtube.com/watch?v=rV8aErDj06A

https://www.netsurion.com/articles/following-a-users-logon-tracks-throughout-the-windows-domain

https://threathunterplaybook.com/hunts/windows/190511-RemotePwshExecution/notebook.html

https://www.ntfs.com/

https://github.com/jschicht/Secure2Csv

https://www.forensicsmyanmar.com/2022/08/ntfs-index-attributes.html

https://dfir.ru/2021/01/10/standard_information-vs-file_name/

https://en.wikipedia.org/wiki/Windows_thumbnail_cache

https://thumbcacheviewer.github.io/

https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2429795

https://www.13cubed.com/downloads/windows_browser_artifacts_cheat_sheet.pdf

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4776

https://mandiant.com/resources/blog/digging-up-the-past-windows-registry-forensics-revisited

https://www.mdpi.com/2673-6756/2/1/7