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 "\
Lists the providers the specified process emit evnets to:logman query providers -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 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.datHKEY\_CURRENT\_USER\SOFTWARE\Classes
File on disk %SystemDrive%:\Users\<USERNAME>\AppData\Local\Microsoft\Windows\UsrClass.datHKEY\_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.
RegistryExplorerRECmdRegRipper
HKLM\SYSTEM
-ComputerName
File: %SystemRoot%\System32\config\SYSTEM
Registry key: HKLM\SYSTEM\CurrentControlSet\Control\ComputerName\ComputerName
HKLM\SOFTWARE
-CurrentVersion (ProductName value)
File: %SystemRoot%\System32\config\SOFTWARE
Registry key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
HKLM\SYSTEM
-
Security Policy
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
HKLM\SYSTEM
-TimeZoneInformation
File: %SystemRoot%\System32\config\SYSTEM
Registry key: HKLM\System\CurrentControlSet\Control\TimeZoneInformation
HKLM\SYSTEM
-Select
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)
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
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
File: %SystemRoot%\System32\config\SYSTEM
Registry key: HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\*
HKLM\SOFTWARE / NTUSER
-
Installed applications (App Paths)
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
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)
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 driver0x2 / 0x8: file system driver0x10: standard Windows service that runs in a process by itself0x20: 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)
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\TasksHKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\Taskcache\Tree
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
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).
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.
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.
MFTECmd.exeINDXRipper
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.
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.
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
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.
EVTX
-Security.evtx
-
Process creation
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.
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.
AmcacheRecentFileCache
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
PCA
Introduced in Windows 11 22H2.
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.txtPcaGeneralDb0.txtPcaGeneralDb1.txt
Prefetch
Not present by default on Windows Server Operating Systems.
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
System Resource Usage Monitor (SRUM)
Introduced in Windows 8.
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).
Windows 10 Timeline / ActivitiesCache.db
Introduced in Windows 10's version 1803.
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.
NTUSER
-UserAssist
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
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):
- \: 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.
- \: 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\MUICacheHKCU\Local Settings\MuiCache
HKLM\SYSTEM
-Background Activity Moderator (BAM)
/Desktop Activity Moderator (DAM)
Introduced in Windows 10's Fall Creators update - version 1709.
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.
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
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.
PowerShell console activity ConsoleHost\_history.txt
Introduced in Windows 10 / PowerShell 5.
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.
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.
NTUSER
-RecentApps
Introduced in Windows 10 1607 and removed in Windows 10 1709 (with the key not present on subsequent version).
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>
NTUSER
-Explorer
-
Common Dialogs
-CIDSizeMRU
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
/LastVisitedPidlMRULastVisitedPidlMRULegacy
Renamed in Windows Vista and later.
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\LastVisitedMRUHKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRUHKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRULegacy
NTUSER
-RunMRU
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
NTUSER & UsrClass
-Shellbag
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\BagMRUHKCU\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\BagMRUHKCU\Software\Microsoft\Windows\Shell\Bags
ShellBagsExplorerSBECmd.exe
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: \ files.
- Custom entries for application defined or manually "pinned" elements: \ files.
For both Jumplist types, the \ 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 \ 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
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\*.lnkShortcut 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
LECmdexiftool
Windows 10 Timeline / ActivitiesCache.db
Introduced in Windows 10's version 1803.
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.
NTUSER
-Explorer
-
Common Dialogs
-OpenSaveMRUOpenSavePidlMRU
Renamed in Windows Vista and later.
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\OpenSaveMRUHKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU
NTUSER
-Explorer
-RecentDocs
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
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.
File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat
Registry key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery
NTUSER
-RunMRU
NTUSER
-RecentApps
Introduced in Windows 10 1607 and removed in Windows 10 1709 (with the key not present on subsequent version).
NTUSER
-MountPoints2
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 (##\).
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
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
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.
EVTX
-Security.evtx
-
Network share access:Audit Detailed File Share
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.
Authentication
-EVTX
-Security.evtx
Destination host
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
Authentication
-EVTX
-Security.evtx
Source host
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/\ 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.
Authentication
-EVTX
-Security.evtx
AD DS Domain Controller
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).
Authentication
-User Access Logging (UAL)
AD DS Domain Controller and destination host
Windows Server only, introduced in Windows Server 2012.
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 \ 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.
Remote Desktop
-EVTX
Destination host
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 \. 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.evtxMicrosoft-Windows-TerminalServices-LocalSessionManager%4OperationalMicrosoft-WindowsRemoteDesktopServicesRdpCoreTS%4Operational.evtx
Remote Desktop
-HKLM\SYSTEM
-ProfileList
Destination host
File: %SystemRoot%\System32\config\SOFTWARE
Registry key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
Remote Desktop
-EVTX
Source host
For more information:
lateral movement note.
Microsoft-WindowsTerminalServicesRDPClient%4Operational.evtx:
- Event 1024: RDP ClientActiveX is trying to connect to the server (\
- Event 1102: The client has initiated a multi-transport connection to the server \
- Event 1029: Base64(SHA256(UserName)) is = \
This CyberChef formula can be used to compute the hash.
Remote Desktop
-NTUSER
-Terminal Server Client\Servers
Source host
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
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
For more information:
local persistence note.
System.evtx:
- Event 7045: A service was installed in the system
- Event 7036: The \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.evtxSecurity.evtx
Windows scheduled tasks
-EVTX
Destination host
For more information:
local persistence note.
Microsoft-Windows-TaskScheduler%4Operational.evtx, events introduced in Windows 7 / Windows 2008:
- Event 106: User "\
- Event 140: User "\
- Event 200: Task Scheduler launched action "\
- Event 201: Task Scheduler successfully completed task "\
- Event 141: User "\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.evtxSecurity.evtx
PowerShell remoting (WinRM)
-EVTX
Destination host
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:
Microsoft-Windows-PowerShell%4OperationalMicrosoft-Windows-WinRM%4Operational.evtx
PowerShell remoting (WinRM)
-wsmprovhost.exe execution
Destination host
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
For more information:
PowerShell activity note.
Microsoft-Windows-WinRM%4Operational.evtx:
- Event 6: Creating WSMan Session. The connection string is: \
- 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
WMI
-wmiprvse.exe execution
Destination host
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
Port forwarding
-HKLM\SYSTEM
-PortProxy
File: %SystemRoot%\System32\config\SYSTEM
Registry key: HKLM\SYSTEM\CurrentControlSet\Services\PortProxy\v4tov4\tcp\*
System Resource Usage Monitor (SRUM)
Introduced in Windows 8.
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).
HKLM\SYSTEM
-NetworkList
File: %SystemRoot%\System32\config\SYSTEM
Registry key: HKLM\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\
NTUSER
-TypedURLs
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 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:///\).
Cookies:%AppData%\Microsoft\Windows\Cookies
Sessions:%LocalAppData%\Microsoft\Internet Explorer\Recovery\*.dat
Microsoft Edge
(Legacy)
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
Microsoft Edge
(Chronium-based)
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
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
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
HKLM\SYSTEM
-Enum\USB
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
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
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
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.
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
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
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
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
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 (##\).
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
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.\
EVTX
-Microsoft-Windows-Storage-ClassPnP/Operational
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.
EVTX
-Microsoft-Windows-Kernel-PnP/Device Configuration
Provider: Microsoft-Windows-Kernel-PnP.
Contains information for all plug and play devices, not limited to USB storage devices.
Event 400: Device \.
Event 401: Device \.
Event 410: Device \.
Event 411: Device \.
Event 430: Device \.
> The events above appear to be generated when a device is first plugged-in to the system.
Event 420: Device \.
The \ 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).
EVTX
-Microsoft-Windows-Kernel-PnP/Device Management
Introduced in Windows 11.
Provider: Microsoft-Windows-Kernel-PnP.
Contains information for all plug and play devices, not limited to USB storage devices.
Event 1010: Device \.
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.
EVTX
-Microsoft-Windows-Partition/Diagnostic
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.
EVTX
-Microsoft-Windows-Ntfs/Operational
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.
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.
EVTX
-Security.evtx
-
Security event log clear
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).
EVTX
-System.evtx
-
Security event log clear
Generated upon the deletion of events from event logs files (other than Security.evtx).
Thumbs.dbThumbcache
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 \\\ or \\\) 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\_\, contains thumbnails from all locations. The \ 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\_\ files.
Thumbs ViewerThumbcache Viewer
Windows Push Notifications (WPN)
Introduced in Windows 10.
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
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 \
- Event 23: Handle for the file backing virtual disk \
- Event 12: Handle for virtual disk \
- Event 25: Beginning to bring the \
EVTX
-Application.evtx
-ESENT events
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 \[...]
EVTX
-Security.evtx
-DRSUAPI replication
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.