Artefacts overview
Windows DFIR notes are no longer maintained on InfoSec-Notes. Updated versions can be found on: artefacts.help.
General
Event Tracing
General
Overall system usage: Accounts authentication successes and failures, local accounts and groups management, Windows Services or scheduled tasks operations, PowerShell activity, etc. Various events of forensic interest across multiple providers are referenced in the present overview.
Default location for EVTX
files:
%SystemRoot%\System32\winevt\Logs\*
Lists the system's provider:
logman.exe query providers
Retrieves information about a provider, including its channel and the process sending events to it:
logman.exe query providers "<PROVIDER_NAME>"
Lists the providers the specified process emit evnets to:
logman query providers -pid <PID>
List the available channels
and their associated event counts:
Get-WinEvent -ListLog *
Registry hives
General
Registry hives are system-wide or per users hierarchical databases used by the Windows operating system, and third-party applications, to store information.
A registry hive is a group of keys, subkeys, and values in the registry, with supporting file(s) on disk. Registry hives are loaded in memory upon system boot or user logon from their associated files on disk.
Before being written / committed to a file on disk, registry modifications can be written to Registry Transaction logs
(notably if the hives cannot be written to directly due to locking). Transaction logs
are files named, and stored in the same directory, as their corresponding registry hives. Such as SYSTEM.LOG1
and SYSTEM.LOG2
for the SYSTEM
registry file.
The system-wide registry hives are stored in the HKEY_LOCAL_MACHINE
(HKLM
) hive. The following notable system-wide root keys are defined:
HKEY_LOCAL_MACHINE\SYSTEM
File on disk: %SystemRoot%\System32\config\SYSTEM
.
HKEY_LOCAL_MACHINE\SOFTWARE
File on disk: %SystemRoot%\System32\config\SOFTWARE
.
HKEY_LOCAL_MACHINE\SECURITY
File on disk: %SystemRoot%\System32\config\SECURITY
.
HKEY_LOCAL_MACHINE\SAM
File on disk: %SystemRoot%\System32\config\SAM
.
HKEY_USERS
Contains all the actively loaded user profile registry hives on the computer. The .DEFAULT
key is populated from the %SystemRoot%\Users\Default\NTUSER.DAT
file.
File on disk: users' NTUSER.dat
and UsrClass.dat
files (of logon users).
The SYSTEM
, SOFTWARE
, SECURITY
, and SAM
registry hives used to be backed up periodically (every 10 days by default) under the %SystemRoot%\System32\config\RegBack
folder by the RegIdleBackup
scheduled task. Starting with the Windows 10 operating system, this mechanism is no longer in use and no registry hive backups are stored under the RegBack
folder.
The user specific registry information are stored in the HKEY_CURRENT_USER
(HKCU
) root key.
HKEY_CURRENT_USER
File on disk %SystemDrive%:\Users\<USERNAME>\NTUSER.dat
HKEY_CURRENT_USER\SOFTWARE\Classes
File on disk %SystemDrive%:\Users\<USERNAME>\AppData\Local\Microsoft\Windows\UsrClass.dat
HKEY_CLASSES_ROOT
Define the programs and file extensions association.
Mapped to the keys HKEY_LOCAL_MACHINE\SOFTWARE\Classes
, for default settings, and HKEY_CURRENT_USER\SOFTWARE\Classes
, for user specific settings that override the default settings.
-
RegistryExplorer
RECmd
RegRipper
System information
HKLM\SYSTEM
-
ComputerName
System information
Name of the computer.
-
File: %SystemRoot%\System32\config\SYSTEM
Registry key: HKLM\SYSTEM\CurrentControlSet\Control\ComputerName\ComputerName
HKLM\SOFTWARE
-
CurrentVersion
(ProductName
value)
System information
Version and Service pack number of the Windows operting system.
-
File: %SystemRoot%\System32\config\SOFTWARE
Registry key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
HKLM\SYSTEM
-
Security Policy
System information
Basic information on the system:
- Computer name and SID
.
- Computer's domain and domain SID
(for domain-joined hosts).
Registry keys under HKLM\SECURITY\Policy
:
- PolAcDmN
: computer name
- PolAcDmS
: computer SID
- PolDnDDN
: computer's domain name
- PolPrDmS
: computer's domain SID
File: %SystemRoot%\System32\config\SECURITY
HKLM\SYSTEM
-
TimeZoneInformation
System information
Time zone information.
-
File: %SystemRoot%\System32\config\SYSTEM
Registry key: HKLM\System\CurrentControlSet\Control\TimeZoneInformation
HKLM\SYSTEM
-
Select
System information
ControlSet
information for the CurrentControlSet
, ControlSet002
, ... registry keys:
- Current ControlSet
pointed by the CurrentControlSet
key.
- Last known good ControlSet
.
-
File: %SystemRoot%\System32\config\SYSTEM
Registry key: HKLM\SYSTEM\Select
HKLM\SYSTEM
-
Network interfaces (Interfaces
)
System information
Basic information about network interfaces (interface name, associated IP address, default gateway, and DHCP lease and eventual domain).
Additional network information is available in the NetworkList
registry key.
-
File: %SystemRoot%\System32\config\SYSTEM
Registry keys: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\*
HKLM\SYSTEM
-
LanmanServer\Shares
System information
Network SMB shares hosted by the system.
Each network share is associated with a REG_MULTI_SZ
value.
The value is named from the network share name. The share name is also defined in the ShareName
field of the registry value's data.
The share path on disk is defined in the in the Path
field of the registry value's data.
File: %SystemRoot%\System32\config\SYSTEM
Registry key: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
HKLM\SYSTEM
-
FirewallPolicy
System information
Windows local Firewall profiles (Public, Private, and Domain) status and configured rules.
-
File: %SystemRoot%\System32\config\SYSTEM
Registry key: HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\*
HKLM\SOFTWARE
/ NTUSER
-
Installed applications (App Paths
)
System information
Applications installed on the system, on a system-wide or per user basis.
The entries are mainly used by the Windows operating system for two purposes:
- Mapping an application file name to its executable full path.
- Pre-pending information to the PATH
environment variable on a per-application and per-process basis.
Applications installed system-wide have their information written in the HKLM\SOFTWARE
registry hive, while applications installed per user have their information written in the user NTUSER
hive.
For each installed application the following notable information is available:
- File name and full file path of the application executable.
- Timestamp of installation.
For system-wide applications:
File:
%SystemRoot%\System32\config\SOFTWARE
Registry key: Microsoft\Windows\CurrentVersion\App Paths
For per-user applications:
File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat
Registry key: HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths
HKLM\SOFTWARE
/ NTUSER
-
Uninstall
System information
Applications installed on the system, on a system-wide or per user basis, as displayed in the "Add or remove programs" of the Windows Control Panel / Settings.
Applications installed system-wide have their information written in the HKLM\SOFTWARE
registry hive, while applications installed per user have their information written in the user NTUSER
hive.
Each application installation data is defined in a dedicated subkey under Uninstall
, identified by the application name.
For each installed application the following notable information is available:
- The application name.
- The application installation location, display icon (often based directly on the application main executable, thus giving the full path of the application main program), full path of the uninstaller.
- The date of the installation. The last write timestamp of the registry key can also be an indicator of when the application was installed (with better precision).
- The size of the applicationn.
- Various metadata on the application (provided by the application installer itself): version, publisher, ...
For system-wide applications:
File:
%SystemRoot%\System32\config\SOFTWARE
Registry key: Microsoft\Windows\CurrentVersion\Uninstall
For per-user applications:
File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat
Registry key: HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall
HKLM\SYSTEM
-
Installed services (Services
)
System information
Each service configuration is defined in a dedicated subkey under Services
, identified by the service name.
For each services, the following notable information is available (under the service name root key):
- Service name and display name.
- Services image path.
- The service type:
0x1
: Kernel driver
0x2
/ 0x8
: file system driver
0x10
: standard Windows service that runs in a process by itself
0x20
: Windows service that can share a process with other services.
0x50
: "USER_OWN_PROCESS TEMPLATE"
0x60
: "USER_SHARE_PROCESS TEMPLATE"
0x110
: like 0x10
but can interact with users.
0x120
: like 0x20
but can interact with users.
- The service start mode:
0x0
: "Boot Start"
0x01
: "System Start"
0x02
: "Auto Start"
0x03
: "Manual"
0x04
: "Disabled"
- The Windows specific privileges required by the service (SeImpersonatePrivilege
, SeDebugPrivilege
, etc.). No privileges can be set, for exemple if the service runs as NT AUTHORITY\SYSEM
.
The last write timestamp of the service name root key can be an indicator of when the specific service configuration was last modified.
File: %SystemRoot%\System32\config\SYSTEM
Registry key: HKLM\SYSTEM\CurrentControlSet\Services\<SERVICE_NAME>
HKLM\SOFTWARE
-
Configured scheduled tasks (Schedule\Taskcache
)
System information
Each scheduled task configuration is defined in a dedicated subkey under Schedule\Taskcache\Tasks
, identified by the task GUID.
For each tasks, the following notable information is available (under the task GUID root key):
- The task path.
- Some lifecycle timestamps of the task: created on, last start, and last stop.
- The task security descriptor (in SDDL
notation).
- The task trigger(s) and action(s) in binary, non human readable format.
The mapping between a task name and its GUID can be done using the subkeys of the Schedule\Taskcache\Tree
keys.
File: %SystemRoot%\System32\config\SOFTWARE
Registry keys:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\Taskcache\Tasks
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\Taskcache\Tree
Configured scheduled tasks (Tasks
folder)
System information
Each scheduled task configuration is defined in a XML
file, eventually in an intermediate subfolder, under the Tasks
folder.
For each tasks, the following notable information is available:
- The task name and GUID, in the task filename itself.
- The task description.
- The task trigger(s) and action(s) (executable / command to be executed and its parameters for instance) in human readable format.
- The task status (enabled / disabled).
- The additional parameters of the task (wake to run, execution timeout, ...).
Windows XP
/ Windows Server 2003
(Task Scheduler 1.0
):
%SystemRoot%\Windows\Tasks
Starting from Windows 7
/ Windows Server 2008
(Task Scheduler 2.0
):
%SystemRoot%\Windows\System32\Tasks
Filesystem
MFT
Filesystem
%SystemDrive%:\$MFT
MFTECmd.exe
$Secure
Filesystem
The $Secure
file contains the security descriptor
for all the files and folders on a NTFS
volume.
The security descriptors
are stored within the $SDS
named data stream of the $Secure
file. The $Secure
file additionally defines two other named streams ($SDH
and $SII
) for lookup in the $SDS
stream.
Each file or folder is referenced in the $Secure
file with its volume-unique Security ID
and security descriptor
.
The Security ID
of the file is referenced in the MFT
file record associated with the file (in the $STANDARD_INFORMATION
attribute). While no metadata information are present in the $Secure
file (only the file's security descriptor
), the file's Security ID
can be used to map the file's information / data from the MFT
to its security descriptor
in the $Secure
file.
The security descriptor
(SECURITY_DESCRIPTOR
data structure) references:
- The owner of the file (as a pointer to a SID
structure).
- The access rights to the file in the Discretionary Access Control List (DACL)
attribute.
- The audit rights that control how access is audited (which access will generate events) in the System Access Control List (SACL)
attribute.
$Secure
NTFS index attributes
($I30
)
Filesystem
The NTFS
index attributes
are MFT
attributes, of two distincts types, that index all the files / directories in a given directory (in a B-Tree data structure). Each directory contains one or more index attributes
. The files and folders information displayed by the Windows Explorer
are based on the index attribute(s) of the directory being accessed.
The entries (files or subdirectories) in a directory's index attribute(s)
are stored as index records
structures, with one dedicated record for every entry. The index record
structure contains a $FILE_NAME
(0x30
) attribute, in which are stored the information about the file or folder.
There is two types of index attributes
:
- $INDEX_ROOT
: for directories with a small number of entries. The $INDEX_ROOT
attribute is always resident to the MFT
and contains a small list of index records
. A directory has at most one $INDEX_ROOT
attribute.
- $INDEX_ALLOCATION
: additional structure for larger directories, with no limitation on the number of entries. The $INDEX_ALLOCATION
attribute is non-resident and contains one or more index records
. The INDEX_ALLOCATION
structure starts with the INDX
signature. The $INDEX_ALLOCATION
attribute should not exist without an associated $INDEX_ROOT
attribute.
The $Bitmap
attribute keep track of the index allocations.
The $INDEX_ROOT
, $INDEX_ALLOCATION
, and $Bitmap
attributes are collectively refered to as $I30
.
Each index record
contains information on the file it references in a $FILE_NAME
(0x30
) attribute:
- Filename and parent directory.
- File size.
- A set of MACB
timestamps.
The $FILE_NAME
attribute of a index record
in a directory index attribute
should be kept in sync with the MFT
file record's $STANDARD_INFORMATION
attribute of the corresponding entry. However, disparities may sometime occur, with the index record
referencing older information.
Due to their B-Tree data structure format and their frequent rebalancing, $INDEX_ALLOCATION
attributes often contain a significant amount of slack space. Index records
for deleted files no longer present in the MFT
may be carvable from this slack space.
MFT
's $INDEX_ROOT
, $INDEX_ALLOCATION
, and $Bitmap
attributes.
$LogFile
Filesystem
The $LogFile
is part of a journaling feature of NTFS
, activated by default, which maintains a low-level record of changes made to the NTFS
volume.
Every disk operation is journalized prior to being committed. In case of failure, such as a crash during an update, the $LogFile
can be used to revert disk operations.
As low-level operations are journalized, the $LogFile
contains very limited historical data, usually only of the last few hours at most.
$LogFile
UsnJrnl
Filesystem
The UsnJrnl
is part of a journaling feature of NTFS
, activated by default on Vista and later, which maintains a record of changes made to the NTFS
volume. The creation, deletion or modification of files or directories are, among other operations, journalized.
The records in the UsnJrnl
are progressively overwritten once the max size of the journal has been reached. The UsnJrnl
usually contains historical data on the last few days (1-3 days for system full time use, < 7 days for regular system use).
The UsnJrnl
is composed of two named data streams:
- The $Max
stream stores the meta data of the change.
- The $J
stream stores the actual change log records.
Each change log record is notably composed of:
- an Update Sequence Number (USN)
.
- The timestamp of the change. - The reason / operation of the record (USN_REASON_FILE_CREATE
, USN_REASON_FILE_DELETE
, USN_REASON_DATA_OVERWRITE
, USN_REASON_RENAME_NEW_NAME
, etc.).
- MFT reference and reference sequence number.
$Max
and $J
named data streams under \$Extend\$UsnJrnl
MFTECmd.exe
Windows Search
database
Filesystem
The Windows Search
database provides an index to the Windows Search feature to improve search speed by indexing content. The Windows Search index is used for searches made through Windows taskbar, the Windows Explorer, and some Universal Windows Platform (UWP)
applications (such as Outlook, OneDrive, etc.).
By default, only a subset of folders and files are indexed (to reduce the Windows Search database size and CPU usage). The folders scanned and number of items indexed can be consulted in the "Windows search settings" menu.
By default, only items from the following sources are scanned and indexed:
- Files and folders from the Users folders.
> Data available: file name, path, size, attributes, MAC
timestamps. For small file, part of the content of the file may be indexed as well.
- Outlook mail data (with timestamp of reception, possible mail content).
- OneNote notes title.
- Internet explorer history (URLs, timestamp of last visit).
Windows XP:
%SystemDrive%:\Documents and Settings\All user\Application Data\Microsoft\Search\Data\Application\Windows\Windows.edb
Starting from Windows 7:
%SystemDrive%:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb
Recycle Bin
Filesystem (Deleted files)
Deleted files and folders (if deleted through a recycle bin aware application).
The deleted files are placed in a subfolder (under %SystemDrive%:\$Recycle.Bin
) named after the SID
of the user that performed the deletion. Deleted files can thus be associated with a given user.
Two kind of files are present in the Recycle Bin
:
- $I
(for "Information") files, which contain the path and timestamp of deletion of the original file.
- $R
(for "Resource") files, which contain the original file content.
%SystemDrive%:\$Recycle.Bin\<USER_SID>\*
Program execution
EVTX
-
Security.evtx
-
Process creation
Programs execution
Event 4688
: A new process has been created
Event 4689
: Process Termination: Success and Failure
Requires Audit Process Creation
to be enabled.
If the ProcessCreationIncludeCmdLine_Enabled
audit policy is enabled, the command line specified at the process creation will be logged.
Security.evtx
HKLM\SYSTEM
-
Application Compatibility Cache
(Shimcache
)
Programs execution (before Windows 10 / Windows Server 2016) Executable presence
Each Shimcache
entries contain the following notable information:
- The associated file full path.
- On Windows 2003 / XP 64-bit and older, the file size.
- The LastModifiedTime
($Standard_Information
) timestamp of the file, which does not necessarily reflect the execution time. Indeed, Shimcache
entries are not directly associated with an insert / executed timestamp.
- The cache entry position, as a numerical value starting from 0, which represents the insertion position in the Shimcache
. **The lower the value, the more recently the program was shimmed.
- From Windows Vista / Windows Server 2008 to Windows 8.1 / Windows Server 2012 R2, the (undocumented) Insert Flag
flag which, when set, seems to indicate that the entry was executed. This flag is no longer present starting from Windows 10 / Windows Server 2016, and thus a Shimcache
entry does not necessarily reflect an execution (as entries may also be created for files in a directory that is accessed interactively).
- On Windows XP 32-bit
, the file Last Update Time
timestamp.
File: %SystemRoot%\System32\config\SYSTEM
Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache
AppCompatCacheParser.exe
For entries present in memory:
Volatility2
's shimcache
plugin.
Amcache
RecentFileCache
For DLL
6.1.7600, replaced by Amcache.hve
on up-to-date systems.
Starting from Windows 7 & Windows Server 2008 R2
Programs execution (for non up-to date system) Executable presence
The Amcache.hve
registry hive is split in a number of root keys, with keys being added, changed, or removed depending on the Amcache
DLLs
versions.
The following notable root keys can be of forensic interest:
- File
then InventoryApplicationFile
starting from the version 10.0.14913.1002
of the Amcache
libraries (AmcacheParser
outputs AssociatedFileEntries
and UnassociatedFileEntries
):
> Data about program executions if they are shimmed, programs part of an installed application, and programs part of scanned directories (with out requiring execution of the associated programs).
> AmcacheParser
's AssociatedFileEntries
output references programs associated with an application and UnassociatedFileEntries
output references "loose" programs (that are not associated with an installed application).
> Data available (depending on the Amcache
libraries version): executable full path, program size, SHA1
of the first 30MB of the executable in the FileId
value, binary type (x86 versus x64), the compilation date of the program in the LinkDate
value.
> Additional data for entries associated with an installed application is available in the InventoryApplication
key. The ProgramId
value from the InventoryApplicationFile
subkey of a given program matches the subkey's name under the InventoryApplication
key of the associated application. The InventoryApplication
key provide metadata information about the application: name, publisher, install date, etc.
> For non up-to-date systems still using a File
key, the last write time of an entry key under the File
key coincides with the execution time of an executable or the application installation time. For entries under the newer InventoryApplicationFile
key, the last write time of the keys always coincides with an execution of Microsoft Compatibility Appraiser
and is thus no longer a timestamp of execution time.
- InventoryDeviceContainer
and InventoryDevicePnp
(AmcacheParser
outputs DeviceContainers
and DevicePnp
):
> Data about devices plugged in on the system.
> Data available: device type (usb; Bluetooth, media, ...), device friendly name, self reported description, manufacturer, associated driver, ...
- InventoryDriverBinary
(AmcacheParser
output DriveBinaries
):
> Data about installed drivers.
> Data available: driver name, full path, size, associated service name, compilation timestamp (DriverTimestamp
), driver file last write timestamp, ...
- InventoryDriverPackage
(AmcacheParser
output DriverPackages
):
> Data about drivers package file (INF file) that contains information about the driver.
> Data available: driver package file name, path, last write timestamp, ...
- Programs
then InventoryApplication
(AmcacheParser
output ProgramEntries
):
> Data about installed programs, as referenced in the Uninstall
and / or a Run
key of the SOFTWARE
hive.
> Data available: application name, executable full path and SHA1, publisher, install date, ...
InventoryApplicationShortcut
(AmcacheParser
output ShortCuts
):
> Data about the shortcuts (LNK
files) that were present at one time (and that may still be present or may have been removed) from a subset of scanned folders (Start Menu and / or Desktop folders).
> Data available: full path of the shortcut. The last write timestamp of the associated subkey can also be a general indicator of when the activity occurred but does not seem to match any MACB
timestamps of the shortcut file.
DLL
6.1.7600:
%SystemRoot%\AppCompat\Programs\RecentFileCache.bcf
%SystemRoot%\AppCompat\Programs\Amcache.hve
AmcacheParser.exe
PCA
Introduced in Windows 11 22H2.
Programs execution (GUI programs only)
The Program Compatibility Assistant (PCA)
is another application compatibility feature that aim to maintain support of existing desktop applications to new versions of the Windows operating system (like the Shimcache
and Amcache
artefacts). PCA
is linked to the pcasvc
service.
Executions of programs with a graphical interface, installed or from a portable executable. Command line programs executed as GUI programs (such as by double clicking on the CLI executable from Windows Explorer
) will also generate an entry.
The information stored by the PCA
is split in 3 text based files:
- PcaAppLaunchDic.txt
:
> Most valuable file from a forensic standpoint and reliable source of program execution.
> One entry per line, containing the full path of the executable and the timestamp of execution in UTC
(in a pipe separated string).
> Example: %SystemRoot%\FOLDER\executable.exe|2023-05-25 01:20:30.123
.
- PcaGeneralDb0.txt
and PcaGeneralDb1.txt
:
> Less entries than in the PcaAppLaunchDic.txt
file, with most entries seemingly related to non 0x0
execution exit code.
> One entry per line, containg the following information in a pipe delimited string:
* Execution timestamp.
* Execution status.
* Full path of the executable.
* Description of the executable and its vendor name.
* File version.
* ProgramId
referenced in the Amcache
registry hive (InventoryApplicationFile
key).
* Exit code of the execution.
Files under %SystemRoot%\appcompat\pca
:
PcaAppLaunchDic.txt
PcaGeneralDb0.txt
PcaGeneralDb1.txt
Prefetch
Not present by default on Windows Server Operating Systems.
Programs execution
The Prefecth
filenames are based on the executed program name and a hash, computed using a proprietary algorithm and based on the full path (and for some binaries, such as dllhost.exe
or svchost.exe
, command line parameters) of the executed program.
Each Prefecth
file can yield the following information:
- The file name and size of the binary executed.
- The first and, starting from Windows 8, the last eight executions timestamps
- The Prefecth
file NTFS
created and last modified timestamps also indicate the first and last time the program was executed.
- The run count (number of time the binary was executed).
- The list of files and directories accessed during the first ten seconds of execution (including the eventual DLL
loaded or PowerShell scripts for PowerShell execution).
Whether the Prefect
feature is enabled is configured by the EnablePrefetcher
registry key:
- 0x0
/ undefined: disabled (default on Windows Server Operating Systems).
- 0x1
: Partially enabled (application prefetching only).
- 0x2
: Partially enabled (boot prefetching only).
- 0x3
: Enabled (application and boot prefetching).
Prefetch
files (.PF
) in:
%SystemRoot%\Prefetch\*
EnablePrefetcher
:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters
PECmd.exe
System Resource Usage Monitor (SRUM)
Introduced in Windows 8.
Programs execution
Related to program execution, the Application Resource Usage
(GUID {D10CA2FE-6FCF-4F6D-848E-B2E99266FA89}
) and App Timeline Provider
(GUID {5C8CF1C7-7257-4F13-B223-970EF5939312}
) tables track programs execution.
For each entry in the Application Resource Usage
table (SrumECmd
's AppResourceUseInfo
output), the following information may be recorded:
- Timestamp of the SRUM
entry creation.
- Full path of the executable or application information / description for built-in components.
- User SID
of the user executing the process.
- Metrics on CPU usage (CPU time in foreground and background).
- Metrics on I/O operations (foreground / background number of read / write operations and bytes read / written).
For each entry in the Application Resource Usage
table (SrumECmd
's AppTimelineProvider
output), the following information may be recorded:
- Timestamp of the SRUM
entry creation.
- Name of the executable and description for built-in components.
- Timestamp of compilation of the executable.
- User SID
of the user executing the process.
- Timestamp of seemingly approximate end of execution.
- Total duration of execution (in milliseconds).
%SystemRoot%\System32\SRU\SRUDB.dat
SrumECmd
Windows 10 Timeline / ActivitiesCache.db
Introduced in Windows 10's version 1803.
Programs execution
The Windows Activity history tracks a number of operations on the system: programs used, local files opened, SharePoint documents consulted, and websites browsed (using Internet Explorer / Microsoft Edge Legacy). The Activity history can be consulted in the Windows Timeline (Windows + Tab keys).
The ActivitiesCache.db
is a SQLite
database that locally stores the activity for its associated user.
The ActivitiesCache.db
only stores data for the last 30 days by default.
The ActivitiesCache.db
is composed of a number of tables, with the following tables being of interest:
- Activity
/ ActivityOperation
tables: data about various activities for different operation / activity type: program execution and opening of a file (5, ExecuteOpen
), copy-pasting from a program (CopyPaste
), application "in focus" (InFocus
), ...
> Data available, varying depending on the activity type: the activity ID (GUID), executable full path for program execution, display text and content info that may contain file name / SharePoint link, start (startedDateTime
) and end (lastActiveDateTime
) of the activity (in UTC
), created and last modified timestamp of the associated file (local or on SharePoint), the user's device timezone, ...
> An activity data can be present in either or both tables depending on the activity lifecycle. For example, a new activity will only be present in the Activity
table, while an activity in the "upload queue" will be placed in the ActivityOperation
table.
- Activity_PackageId
: data about the application(s) / program(s) linked to a specific activity (identified by its activity ID).
> Data available: the activity ID (GUID), the application name / program filename, eventual program full path, activity expiration timestamp (timestamp of occurrence + 30 days by default).
> Upon occurrence of an activity, one or multiple entries sharing the same activity ID will be created in the Activity_PackageId
table, one for each program / application related to the activity.
%SystemRoot%\Users\<USERNAME>\AppData\Local\ConnectedDevicesPlatform\[L.<USERNAME> | *]\ActivitiesCache.db
NTUSER
-
UserAssist
Programs execution (GUI programs only)
The purpose of the UserAssist
registry key is not officially documented.
The registry key references executions of programs with a graphical interface, installed or from a portable executable.
One or two main registry subkeys can be found depending on the Windows OS version:
- On Windows Xp, {75048700-EF1F-11D0-9888-006097DEACF9}
linked to execution of executable files
- Starting from Windows 7, {CEBFF5CD-ACE2-4F4F-9178-9926F41749EA}
linked to execution of executable files and {F4E57C4B-2036-45F0-A9AB-443BCFE33D9F}
linked to execution of shortcut files.
Keys are ROT13
encoded, and contains the following notable information:
- Full path of the executed program / shortcut.
- Sometimes, the timestamp of the last execution.
- An unreliable run counter and focus time.
File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat
Registry key: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\<GUID>\Count
UsrClass
-
MUICache
Programs execution (GUI programs only)
Multilanguage User Interface (MUI)
is a feature to allow applications to have a single executable for multiple languages. MUI
files can be created, one per supported language, to switch the application display language.
The registry key references executions of programs with a graphical interface, installed or from a portable executable.
Each execution is associated with two values under the MUICache
registry key, both starting with the executable full path.
The values data reference information retrieved from the executable's Version
information from its resources section (.rsrc
):
- <PE_FULL_PATH>.FriendlyAppName
: references the executable FileDescription
. This can be used to identify renamed executable, as the original filename is likely going to be referenced by the FileDescription
attribute.
- <PE_FULL_PATH>.ApplicationCompany
: references the executable CompanyName
.
The MUICache
does not provide a timestamp of execution, and the last write timestamp of the key cannot be used to infer the timestamp of execution (as the entries are stored directly as registry values).
File:
%SystemDrive%:\Users\<USERNAME>\AppData\Local\Microsoft\Windows\UsrClass.dat
Registry keys:
HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MUICache
HKCU\Local Settings\MuiCache
HKLM\SYSTEM
-
Background Activity Moderator (BAM)
/
Desktop Activity Moderator (DAM)
Introduced in Windows 10's Fall Creators update - version 1709.
Programs execution
BAM
is a mostly undocumented feature that controls the programs executed in the background. DAM
is a feature for devices supporting the "Connected Standby" mode (i.e when a device is turned on, but its display will be turned off). As a result, the BAM
registry keys will contain data on any devices, while DAM
registry keys will only contain data on mobile devices.
The BAM
registry key contains multiple subkeys under bam\State\UserSettings
, with one subkey per user, identified with the user SID
. While the key is in the SYSTEM
registry hive, program executions can thus still be tied to a specific user using this SID
.
Each user-specific key contains a list of executed programs, with their full path and timestamp of last execution.
If a file is deleted, the eventual associated entry in the BAM
is deleted as well after the system reboot. Additionally, BAM
entries older than 7 days are deleted upon system boot. The BAM
thus provides limited information on historic execution of programs.
No entries are created in the BAM
keys for executables on removable media and/or on network shares.
File: %SystemRoot%\System32\config\SYSTEM
Registry key:
HKLM\SYSTEM\CurrentControlSet\Services\bam\UserSettings\<SID>\*
After from Win10 1809: HKLM\SYSTEM\CurrentControlSet\Services\bam\State\UserSettings\<SID>\*
HKLM\SYSTEM\CurrentControlSet\Services\dam\UserSettings\<SID>\*
After from Win10 1809: HKLM\SYSTEM\CurrentControlSet\Services\dam\State\UserSettings\<SID>\*
NTUSER
-
FeatureUsage
Introduced in Windows 10's version 1903.
Programs execution
Feature linked to the Windows Task, storing a number of metrics related to the Task bar usage.
Each operation (detailed below) is associated with an entry composed of the program full path and operation run count. No timestamp of execution is available.
Subregistry keys:
- AppSwitched
: number of times an application was brought to focus (application left-clicked on the taskbar).
- ShowJumpView
: number of times the jump menu of an application was opened (application right-clicked on the taskbar).
- AppBadgeUpdated
: number of times an application on the taskbar has have its icon updated (for example for notifications).
- AppLaunch
: number of times an application pinned on the taskbar has been executed.
- TrayButtonClicked
: numer of times a default taskbar button (such as the Windows start button) was clicked.
File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat
Registry keys under HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FeatureUsage
.
EVTX
-
PowerShell activity events
Programs execution and PowerShell activity
Microsoft-Windows-PowerShell%4Operational
:
- Event 4103
, related to PowerShell modules. Requires PowerShell Module Logging
to be enabled.
- Event 4104
, related to PowerShell script block. Requires PowerShell Script Block Logging
to be enabled. By default, events will however be logged for potentially-malicious commands execution.
Microsoft-Windows-PowerShell%4Operational
PowerShell console activity ConsoleHost_history.txt
Introduced in Windows 10 / PowerShell 5.
Programs execution and PowerShell activity
Starting with PowerShell v5
on Windows 10
, the commands entered in a PowerShell console will be logged by the PSReadline
module to an user-scoped ConsoleHost_history.txt
file.
Console-less PowerShell sessions, such as the content of PowerShell script or commands execution through the PowerShell ISE
, will not be logged in this file.
Bypassing PSReadline
logging is also easy, as it simply requires to unload the PSReadline
module (for instance with the Remove-Module PSReadline
in an existing PowerShell session).
The ConsoleHost_history.txt
file contains the commands entered, with one command per line and no associated timestamps (or any additional metadata).
By default, the last 4096 commands are conserved.
%SystemDrive%:\Users\<USERNAME>\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt
.NET CLR UsageLogs
Programs execution
Following the execution (or in-memory injection) of a .NET assembly, the Common Language Runtime (CLR)
creates a Usage Log
file whose named is based on the name of the executed assembly.
The file is written just prior the assembly execution terminate, and will thus not be written if the process does not gracefully exit.
The filename of the log file match the name of the assembly / binary executed. The file creation timestamp corresponds to the first time the associated assembly was executed and the file last modification timestamp corresponds to the last execution time of the assembly.
%SystemDrive%:\Users\<USERNAME>\AppData\Local\Microsoft\CLR_v<VERSION>\UsageLogs\<BINARY_NAME>.exe.log
NTUSER
-
RecentApps
Introduced in Windows 10 1607 and removed in Windows 10 1709 (with the key not present on subsequent version).
Programs execution
Undocumented feature, added and (relatively) shortly after removed from the Windows operating system.
Each subkey, identified with a GUID, under the RecentApps
key correspond to an executed program. In these application GUID subkeys, the filename, last access timestamp, and run count of the application are stored.
Additionally, each application GUID subkey can have up to 10 subkeys, also identified with a GUID, that correspond to files accessed using the application. In these file GUID subkeys, the file name, file full path, and (on some OS version) an non-updated timestamp of last access.
The last write timestamp of an application subkey can indicate when the program was last executed. While the last write timestamp of a file subkey can indicate when the file was accessed (with the associated program).
File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat
Registry key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Search\RecentApps\<GUID>
Jumplist
Programs execution
Detailed in Files and folders access
-
-
NTUSER
-
Explorer
-
Common Dialogs
-
CIDSizeMRU
Programs execution
Recently executed programs, linked to Common Dialogs
activities (pop boxes to open / save file, print, find / replace, ...).
The key contains an ordered Most Recently Used (MRU)
list of executed programs, identified through their filename.
The last write timestamp of the key thus corresponds to the timestamp of execution of the most recently executed program (first in the MRU list).
File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat
Registry key: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\CIDSizeMRU
NTUSER
-
Explorer
-
Common Dialogs
-
LastVisitedMRU
/
LastVisitedPidlMRU
LastVisitedPidlMRULegacy
Renamed in Windows Vista and later.
Programs execution
Records the programs used to open / save (some of) the file tracked in the OpenSaveMRU
/ OpenSavePidlMRU
registry key.
Notably used to track the last folder used by a given program in an "Open File" / "Save File" Common Dialogs
window.
Applications tracked are stored in an ordered Most Recently Used (MRU)
list. The last write timestamp of the key thus corresponds to the timestamp of execution of the most recently executed program (first in the MRU list).
For each application, the full path of the folder can be constructed from information blocks on each subfolder in the location. For exemple, for the "%SystemRoot%\Users\Public\Documents" location, three blocks will be present: "Users", "Public", and "Documents". For each block, the created and last accessed timestamps and the MFT entry / sequence associated with the folder are referenced.
File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat
Registry key:
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedMRU
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRULegacy
NTUSER
-
RunMRU
Programs execution
Tacks items (program, files / folders, URL
, ...) launched from the Windows Run
launcher (Windows + R shortcut).
Entries are added / updated in near real-time.
Each entry successfully launched trough the Windows Run
launcher is stored in a dedicated value under the Explorer\RunMRU
key.
The values are ordered in a Most recently used (MRU)
list, specified in the MRUList
value.
Example: MRUList
equals to ba
means that the entry tagged as b
was launched last / the most recently, preceded by the entry tagged as a
.
The last write timestamp of the key thus indicates the timestamp of the most recently entered item.
File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat
Registry key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RunMRU
Files and folders access
NTUSER
& UsrClass
-
Shellbag
Folders access
Various kinds of user activity may generate or update Shellbag
entries (with different level of data depending on the activity):
- First access or renaming of folders, removable devices, or network shares through the Windows Explorer systematically generate a Shellbag
entry.
- Graphical opening of compressed archives or ISOs.
- ...
Shellbag
entries are stored in registry as a tree-like data structure, with the root target having the topmost BagMRU
key. Each sub-target (sub directory for example) of the parent target are then represented with both:
- A registry subkey, named with a numerical value (starting from 0
).
- A registry value (in the parent target's registry key), named with the same numerical value and associated with binary data that notably contains the target's name.
Each Shellbag
BagMRU
registry key also contains a MRUListEx
value, that maintains the entries visited order, i.e the order in which the sub targets of a target were accessed (the last sub target accessed having a MRU position
of 0).
Each Shellbags
entry for a given target yield the following notable information:
- The target name and absolute path.
- The target modified, access, and created (MAC
) timestamps (UTC), retrieved from the $MFT
at the Shellbag
entry creation (and not further updated).
- Additionally the Shellbags
BagMRU
hierarchical nature and MRUListEx
list can be used to deduce the first and last interacted timestamps for some targets:
> For entries that do not have subkeys (i.e directory for which no subdirectory were accessed), the first interacted timestamp is equal to the key's LastWriteTime
timestamp. This is due to the fact that the key is created when a target is first accessed, and further activity for that target (such as display settings modifications) will only update the key's values. When a subkey is created for the target (i.e when a subdirectory is accessed for that particular directory), the timestamp becomes unreliable as it reflect the creation of the subkey.
> The last interacted timestamp can be deducted for the sub target that was last interacted with (MRU
position 0
), and is equal to the parent key's LastWriteTime
timestamp.
Major updates of the Windows operating system may however result in modification of ShellBags
entries, resulting in updated last written timestamp.
Locations starting from Windows 7:
Windows Explorer
activity:
File:
%SystemDrive%:\Users\<USERNAME>\AppData\Local\Microsoft\Windows\UsrClass.dat
Registry keys:
HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\BagMRU
HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags
Desktop and Network locations activity:
File:
%SystemDrive%:\Users\<USERNAME>\NTUSER.dat
Registry keys:
HKCU\Software\Microsoft\Windows\Shell\BagMRU
HKCU\Software\Microsoft\Windows\Shell\Bags
ShellBagsExplorer
SBECmd.exe
Jumplist
Files and folders access
An application is associated with one AutomaticDestinations
file and one CustomDestinations
file, that share the <APP_IDENTIFIER>
of the application.
A JumpList
is assimilable to a series / list of shortcut files (LNK)
, each entry in the JumpList
being a shortcut file
structure. Thus the same level of information found in a shortcut file
is available for each item referenced in an application AutomaticDestinations
and CustomDestinations
JumpLists
.
%SystemDrive%:\Users\<USERNAME>\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\*.automaticDestinations-ms
%SystemDrive%:\Users\<USERNAME>\AppData\Roaming\Microsoft\Windows\Recent\CustomDestinations\*.customDestinations-ms
LNK (shortcuts) Files
Files and folders access
The creation and modification timestamps of the shortcut file itself will usually respectively indicate when the target file was first and last opened.
Each shortcut file additionally yield the following information:
- The target file's absolute path, size and attributes (hidden, read-only, etc.).
- The target file modified, access, and created (MAC
) timestamps at the time of the last access to the target file.
- Whether the target file was stored locally or on a remote network share.
- Occasionally information on the volume of the target file: name, type (fixed vs removable storage media), serial number, and label / name if any.
- Occasionally information on the host of the target file: system's NetBIOS hostname and MAC address.
Automatically created shortcut files
for files opened from the Windows Explorer:
%SystemDrive%:\Users\<USERNAME>\AppData\Roaming\Microsoft\Windows\Recent\*.lnk
Documents opened using Microsoft Office
:
%SystemDrive%:\Users\<USERNAME>\AppData\Roaming\Microsoft\Office\Recent\*.lnk
Shortcut files
created automatically by the Windows Explorer
are referenced in the NTUSER.DAT\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs
registry keys.
Startup folders
items:
%SystemDrive%:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp
%SystemDrive%:\Users\<USERNAME>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
LECmd
exiftool
Windows 10 Timeline / ActivitiesCache.db
Introduced in Windows 10's version 1803.
Files and folders access
Detailed in Program execution
-
-
WebCacheV01.dat
Files and folders access
Access to local files may appear in the WebCacheV01.dat
ESE
database.
This database is mainly used to store browsing history, downloads, cache, and cookies (metadata) for the Microsoft Internet Explorer
and Microsoft Edge
(legacy) web browsers. However, access to local files, not necessarily through a web browser, may also appear in the WebCacheV01.dat
database.
Access to local files will be identifiable by the file
URI
scheme (such as file:///<DRIVE_LETTER>:/folder/file
).
%LocalAppData%\Microsoft\Windows\WebCache\WebCacheV01.dat
NTUSER
-
Explorer
-
Common Dialogs
-
OpenSaveMRU
OpenSavePidlMRU
Renamed in Windows Vista and later.
Files and folders access
Information on files opened or saved through the "Open File" or "Save File" Common Dialogs
window.
The OpenSaveMRU
/ OpenSavePidlMRU
keys has multiple subkeys, one for each different file extensions (for the files opened / saved on the given system).
Each subkey contains an ordered Most recently used (MRU)
list of opened / saved files (full path of the file). The list can go up to 20 entries, with entries over 20 being overwritten.
The last write timestamp of each subkey thus corresponds to the timestamp of opening / saving of the file in MRU position 0 (for a given file extension).
File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat
Registry key:
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSaveMRU
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU
NTUSER
-
Explorer
-
RecentDocs
Files and folders access
Non-executable files opened through the Windows Explorer, stored as one subkey per file extension.
Each subkey contains the opened files of the given extension stored in a ordered Most Recently Used (MRU)
list. The last written timestamp of the key correspond to the timestamp of the opening of the most recently accessed file (MRU position 0).
Entry created under the RecentDocs registry keys are associated with a shortcut file under %SystemDrive%:\Users\<USERNAME>\AppData\Roaming\Microsoft\Windows\Recent\
.
File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat
Registry key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs
NTUSER
-
Explorer
-
TypedPaths
Files and folders access
Paths entered (typed, pasted, or auto-completed) in the Windows Explorer location search bars. Entries are not added / updated in real-time, but are seemingly added / updated on user logoff / system reboot.
The file paths are stored as url1
to url[N]
in inversed chronological order.
The last write timestamp of the key is thus the timestamp of visit of the most recently visited path.
As program can be directly executed from the Windows Explorer search bar, traces of program executions may be found in the TypedPaths
entries.
File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat
Registry key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths
NTUSER
-
Explorer
-
WordWheelQuery
Starting from Windows 7 and not present on Windows Server Operating Systems.
Files and folders access
Keywords searched in from the Windows Explorer
search box, potentially resulting in files or folders access.
The entries are stored in a Most Recently Used (MRU)
list. The last write timestamp of the key indicates the timestamp of the most recently searched keyword.
File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat
Registry key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery
Windows Search
database
Files and folders access
Detailed in Filesystem
.
-
-
NTUSER
-
RunMRU
Files and folders access
Detailed in Program execution
.
-
-
NTUSER
-
RecentApps
Introduced in Windows 10 1607 and removed in Windows 10 1709 (with the key not present on subsequent version).
Files and folders access
Detailed in Program execution
.
-
-
NTUSER
-
MountPoints2
Files and folders access
Currently or previously mapped drives (such as the system drive, USB devices, or network shares) mounted by the associated user.
Each drives is represented by a subkey, which is named as either the volume GUID
, a letter, or, for network shares, using a specific nomenclature (##<IP | HOSTNAME>#<SHARE_NAME>
).
For more information on MountPoints2
related to devices, refer to Devices and USB activity
.
File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat
Registry key:
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2
NTUSER
-
Map Network Drive MRU
Files and folders access
Recently used network shares.
-
File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat
Registry key:
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU
EVTX
-
Security.evtx
- Network share access:
Audit File Share
Network shared files and folders access
Events related to network shares: creation, deletion, modification, and access attempts of network shares. Do not track access to folders and files hosted on network shares.
As there are no System Access Control Lists
(SACLs
) for shares, access to all shares on the system are audited.
Event 5140
: A network share object was accessed
Generated every time a network share is accessed, but only once per session (upon first access attempt).
Object Type
is always File
for this event.
Event 5140
: A network share object was accessed
Event 5142
: A network share object was added
Event 5143
: A network share object was modified
Event 5144
: A network share object was deleted
All events include information about the account that performed the operation: username, domain, and SID
as well as the Logon ID
associated with the logon.
Events 5140
also include network information: source IP address and port.
Requires Audit File Share
to be enabled.
Security.evtx
EVTX
-
Security.evtx
-
Network share access:
Audit Detailed File Share
Network shared files and folders access
Event related to access to folders and files hosted on network shares. The event is generated upon every access to a network shared file or folder. Failure events are generated only when access is denied at the file share level. The event may thus not indicate that the access to the shared folder or file was successful.
Event 5145
: A network share object was checked to see whether client can be granted desired access
Includes information about the account that performed the operation: username, domain, and SID
, the Logon ID
associated with the logon, and the source IP address and port.
Requires Audit Detailed File Share
to be enabled.
Security.evtx
Remote Access / Lateral movements
Authentication
-
EVTX
-
Security.evtx
Destination host
Remote Access / Lateral movements
Event 4624
: An account was successfully logged on
Event 4625
: An account failed to log on
Event 4672
: Special privileges assigned to new logon
Event 4647
: User initiated logoff
(used for logoffs from Interactive
or RemoteInteractive
logons)
Event 4634
: An account was logged off
Security.evtx
Authentication
-
EVTX
-
Security.evtx
Source host
Remote Access / Lateral movements
Only logged whenever alternate credentials are used:
Event 4648: A logon was attempted using explicit credentials
The TargetServerName
and TargetInfo
fields can reference information about the remote server and service (such as TargetInfo
set to TERMSRV/<HOSTNAME>
for outgoing RDP
).
For runas /NetOnly
(and similar) process execution:
Event 4624
: An account was successfully logged on
With Logon Type
9
and the specified alternate credentials as Network Account Domain
and Network Account Name
.
Security.evtx
Authentication
-
EVTX
-
Security.evtx
AD DS Domain Controller
Remote Access / Lateral movements
For NTLM
successful or failed authentication attempts:
Event 4776
: The domain controller attempted to validate the credentials for an account
If the Result Code
field is not equal to 0x0
the authentication failed. The event is associated with the computer from which the logon attempt originated and does not identify the target service. This event is also logged for non Domain Controllers, on the target computer, for logon attempts with local SAM
accounts.
For Kerberos
authentication:
If the user has not already retrieved a TGT
during the session opening on the source host:
Event 4768
: A Kerberos authentication ticket (TGT) was requested
If the Result Code
field is not equal to 0x0
the request failed (but not for a failed authentication).
Event 4769
: A Kerberos service ticket was requested
The ServiceName
and ServiceSid
fields indicate the service the service ticket
is requested for. However, for lateral movement, the service and service SID
are often set to the destination machine account, with no information on the actual service targeted (RPC
, CIFS
, etc.).
Event 4771
: Kerberos pre-authentication failed
For authentication failures.
As the Domain Controller only handles the authentication, and will not open a login session in this scenario, no 4624
or 4625
events will be logged. However, for a remote interactive logon on the destination host, a 4624
event of logon type 3
(and 4768
+ 4769
events) will be logged on a Domain Controller (potentially different than the one that processed the authentication from the source host) originating from the destination host (as part of the interactive session opening process).
Security.evtx
Authentication
-
User Access Logging (UAL)
AD DS Domain Controller and destination host
Windows Server only, introduced in Windows Server 2012.
Remote Access / Lateral movements
The information is stored locally in up to five Extensible Storage Engine (ESE)
database files (.mdb
), including:
- The Current.mdb
file which contains data for the last 24-hour.
- Up to three <GUID>.mdb
files, which contain data for an entire year (first to last day), going back to 2 years.
The CLIENTS
table of the aforementioned databases contain notable information:
- Accessed Windows Server role GUID
and description (AD DS
, AD CS
, SMB / CIFS
service notably)
- The client domain and username.
- Total number of access.
- First, last, and daily access timestamps.
- Client IPv4
or IPv6
address.
On Domain Controllers, the hostname associated with a given IP
address at that time may be retrievable as machine accounts of domain-joined computers also authenticate to AD DS
.
Database files (.mdb
) in %SystemRoot%\System32\Logfiles\SUM\
Remote Desktop
-
EVTX
Destination host
Remote Access / Lateral movements
Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx
:
- Event 1149
: Remote Desktop Services: User authentication succeeded
. Access to the Windows login screen, not necessarily a successful session opening. This event is however only generated upon successful authentication if Network Level Authentication (NLA)
is required.
Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational
:
- Event 21
: Remote Desktop Services: Session logon succeeded
.
- Event 22
: Remote Desktop Services: Shell start notification received
- Event 23
: Remote Desktop Services: Session logoff succeeded
- Event 25
: Remote Desktop Services: Session reconnection succeeded
Events with a source network address set to LOCAL
can sometimes be generated for console, non RDP login.
Microsoft-WindowsRemoteDesktopServicesRdpCoreTS%4Operational.evtx
:
- Event 131
: The server accepted a new TCP connection from client <IP>
. Introduced in >= Windows Server 2012
, only indicate a network access to the RDS service.
For the aforementioned events, a Source Network Address
of ::%16777216
could indicate that a ngrok
tunnel was used to make RDP access.
Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx
Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational
Microsoft-WindowsRemoteDesktopServicesRdpCoreTS%4Operational.evtx
Remote Desktop
-
HKLM\SYSTEM
-
ProfileList
Destination host
Remote Access / Lateral movements
SID
to username correspondence for accounts that have interactively logged on the system (including for domain accounts).
The last write timestamp of each key indicates was the associated user last logged on the system.
File: %SystemRoot%\System32\config\SOFTWARE
Registry key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
Remote Desktop
-
EVTX
Source host
Remote Access / Lateral movements
Microsoft-WindowsTerminalServicesRDPClient%4Operational.evtx
Remote Desktop
-
NTUSER
-
Terminal Server Client\Servers
Source host
Remote Access / Lateral movements
-
Each remote host the user connected to (from the local system) is referenced as a dedicated subkey under Terminal Server Client\Servers\<IP>
. This subkey is named after the IP address of the remote host.
For each host, the associated subkey references:
- The eventual saved username for the connection in the UsernameHint
value.
Additionally, the last written timestamp may be an indicator of the first access to the remote host (but may have also be updated for various other reasons).
File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat
Registry key: HKCU\SOFTWARE\Microsoft\Terminal Server Client\Servers\<IP>
Remote Desktop
-
RDP Bitmap Cache
Source host
Remote Access / Lateral movements
Partial captures of the remote desktop screen from the Remote Desktop Client for RDP sessions. Implemented to reduce the amount of data sent by the server to save bandwidth usage. Bitmap caching be deactivated client-side in the Remote Desktop Client.
-
Windows XP / Windows Server 2003:
%SystemDrive%:\Documents and Settings\<USERNAME>\Local Settings\Application Data\Microsoft\Terminal Server Client\Cache\*
Windows 7 and later: %SystemDrive%:\Users\<USERNAME>\AppData\Local\Microsoft\Terminal Server Client\Cache\*
Windows services
-
EVTX
Destination host
Remote Access / Lateral movements
System.evtx
:
- Event 7045
: A service was installed in the system
- Event 7036
: The <SERVICE_NAME> service entered the <running/stopped> state
Security.evtx
:
- Event 4697
: A service was installed in the system
. Introduced in Windows Server 2016 and Windows 10, and requires advanced auditing policy.
System.evtx
Security.evtx
Windows scheduled tasks
-
EVTX
Destination host
Remote Access / Lateral movements
Microsoft-Windows-TaskScheduler%4Operational.evtx
, events introduced in Windows 7
/ Windows 2008
:
- Event 106
: User "<DOMAIN | WORKGROUP>\<USERNAME>" registered Task Scheduler task "\<TASK_NAME>"
- Event 140
: User "<DOMAIN | WORKGROUP>\<USERNAME>" updated Task Scheduler task "<TASKNAME>"
- Event 200
: Task Scheduler launched action "<EXECUTABLE>" in instance "<GUID>" of task "<TASKNAME>"
- Event 201
: Task Scheduler successfully completed task "<TASKNAME>", instance "<GUID>", action "<EXECUTABLE>" with return code <INT>"
- Event 141
: User "<DOMAIN | WORKGROUP>\<USERNAME>" deleted Task Scheduler task "<TASKNAME>"
Security.evtx
, requires advanced auditing policy:
- Event 4698
: A scheduled task was created
- Event 4700: A scheduled task was enabled
- Event 4701
: A scheduled task was disabled
- Event 4702
: A scheduled task was updated
- Event 4699
: A scheduled task was deleted
Microsoft-Windows-TaskScheduler%4Operational.evtx
Security.evtx
PowerShell remoting (WinRM
)
-
EVTX
Destination host
Remote Access / Lateral movements
Microsoft-Windows-PowerShell%4Operational
:
- Event 4103
, related to PowerShell modules. Requires PowerShell Module Logging
to be enabled.
- Event 4104
, related to PowerShell script block. Requires PowerShell Script Block Logging
to be enabled. By default, events will however be logged for potentially-malicious commands execution.
Microsoft-Windows-WinRM%4Operational.evtx
:
- Event 91
: Creating WSMan shell on server with ResourceUri: http://schemas.microsoft.com/[...]
Microsoft-Windows-PowerShell%4Operational
Microsoft-Windows-WinRM%4Operational.evtx
PowerShell remoting (WinRM
)
-
wsmprovhost.exe
execution
Destination host
Remote Access / Lateral movements
The PowerShell host process (wsmprovhost.exe
) is executed to hosts the active remote session on the destination system.
If programs are executed through the WinRM
session, they will be spawned as child of the wsmprovhost.exe
process.
-
PowerShell remoting (WinRM
)
-
EVTX
Source host
Remote Access / Lateral movements
Microsoft-Windows-WinRM%4Operational.evtx
:
- Event 6
: Creating WSMan Session. The connection string is: <REMOTE_HOST>/wsman?PSVersion=XXX
- Event 33
: Closing WSMan Session completed successfully
- Events 8
, 15
, 16
, and 31
: other events that occur during the life-cycle of the WinRM session
Microsoft-Windows-WinRM%4Operational.evtx
WMI
-
wmiprvse.exe
execution
Destination host
Remote Access / Lateral movements
The WMI Provider Host
(wmiprvse.exe
) process is executed to run WMI
commands.
If programs are executed through WMI
, they will be spawned as child of the wmiprvse.exe
process.
-
SSH
-
SSHlogs
Destination host
Remote Access / Lateral movements
OpenSSH
for Windows logs in a text format. Not enabled by default (requires SyslogFacility LOCAL0
/ LogLevel Debug3
) to be set in the server sshd_config
.
Contains information about users successful and unsuccessful authentication attempts (with the associated IP source).
%ProgramData%\ssh\logs
Port forwarding
-
HKLM\SYSTEM
-
PortProxy
Remote Access / Lateral movements
netsh
port forwarding activity: listening host / port and remote host / port.
-
File: %SystemRoot%\System32\config\SYSTEM
Registry key: HKLM\SYSTEM\CurrentControlSet\Services\PortProxy\v4tov4\tcp\*
Network usage
System Resource Usage Monitor (SRUM)
Introduced in Windows 8.
Network usage
Detailed in Program execution
.
The Network Data Usage
table (GUID {973F5D5C-1D90-4944-BE8E-24B94231A174}
) tracks programs execution and network usage of the executed programs.
For each entry in the Network Data Usage
table (SrumECmd
's NetworkUsages
output), the following information may be recorded:
- Timestamp of the SRUM
entry creation.
- Full path of the executable or application information / description for built-in components.
- Metrics on network data usage (bytes sent and receive on a given network interface).
%SystemRoot%\System32\SRU\SRUDB.dat
SrumECmd
HKLM\SYSTEM
-
NetworkList
Network usage
Basic network historical information (network name and type, first and last connection, etc.)
-
File: %SystemRoot%\System32\config\SYSTEM
Registry key: HKLM\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\
Local persistence
For artefacts on local persistence and AutoStart Extensibility Point (ASEP)
, refer to:
Web browsers usage
The web browsers related artefacts can be split in the following categories:
User profile: web browsers, such as
Chronium
-based browsers andFirefox
, implement a profile feature to store user's setttings, history, favourites, etc. The databases and files that store these information are usually stored under a user specific profile folder.History: web browsing history and download history.
Cookies: web browsing cookies (session tokens).
Cache: cache of resources downloaded from accessed websites (images, text content,
HTML
,CSS
,Javascript
files, etc.).Sessions: tabs and windows from a browsing session.
Settings: configuration settings.
These files are often stored under %LocalAppData%
(%SystemDrive%:\Users\<USERNAME>\AppData\Local\
) and %AppData%
(%SystemDrive%:\Users\<USERNAME>\AppData\Roaming\
).
NTUSER
-
TypedURLs
Web browsers usage
URL
entered (typed, pasted, or auto-completed) in the Internet Explorer (IE)
web browser search bar.
Web searches do not generate entries, only typing of an URL
will.
Entries are added / updated in near real-time.
The URL
are stored as url1
to url[N]
in inversed chronological order.
The last write timestamp of the key is thus the timestamp of visit of the most recently visited URL
.
File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat
Registry key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\TypedURLs
Microsoft Internet Explorer
Web browsers usage
-
History, downloads, cache, and cookies metadata in a ESE
database:
%LocalAppData%\Microsoft\Windows\WebCache\WebCacheV01.dat
> History: History
table
> Downloads: iedownload
table.
> Cache: content
table
> Cookies metadata: Cookies
table.
Local files access, not necessarily through the webbrowser, may also appear in the WebCacheV01.dat
database with the file
URI
scheme (such as file:///<DRIVE_LETTER>:/folder/file
).
Cookies:
%AppData%\Microsoft\Windows\Cookies
Sessions:
%LocalAppData%\Microsoft\Internet Explorer\Recovery\*.dat
Microsoft Edge
(Legacy)
Web browsers usage
-
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)
Web browsers usage
-
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
Web browsers usage
-
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
Web browsers usage
-
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
Devices and USB activity
Windows devices terminology:
The
vendor ID
identifies a specific vendor, with a mapping available on devicehunt.com. Theproduct ID (PID)
identifies a product from that vendor.The
device ID
orhardware ID
is "a vendor-defined identification string that Windows uses to match a device to a driver package". The identifier references the vendor and product names as well as the revision version. Example for aDataTraveler_3
USB key by Kingston:Ven_Kingston&Prod_DataTraveler_3.0&Rev_PMAP
.The
instance ID
is "a device identification string that distinguishes a device from other devices of the same type on a computer". It contains the deviceserial number
, if supplied, and otherwise "some kind of location information". Example of aninstance ID
for a device that does not supply a serial number:5&2eab04ab&0&1
.The
device instance ID
is "a system-supplied device identification string that uniquely identifies a device in the system". It is notably composed of the device'sdevice ID
andinstance ID
.The
container ID
is "a system-supplied device identification string that uniquely groups the functional devices associated with a single-function or multifunction device installed in the computer". Starting with Windows 7, thePlug and Play (PnP) manager
uses thecontainer ID
to group one or more device nodes (devnodes
) that originated from a particular physical device.The
device interface class
represents the type of the device (storage devices, USB devices, Bluetooth devices, etc.). Eachdevice interface class
is associated with a uniqueGUID
, defined by Microsoft. The list ofGUIDs
by category of device can be found in the Microsoft documentation.External physical storage
GUID
:{53f56307-b6bf-11d0-94f2-00a0c91efb8b}
.Logical volumes
GUID
:{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}
.
Devices and USB activity forensics artefacts
The information below originates from tests on Windows 10 Pro - 19045.2965
and Windows 11 Pro - build 22621.1702
systems.
HKLM\SYSTEM
-
Enum\USB
Devices and USB activity
Contains system-wide information about the currently or previously connected USB devices.
Each USB devices is associated with a dedicated subkey under the Enum\USB
key. This subkey is named after the device vendor ID (VID)
and product ID (PID)
of the device. Example: VID_1B1C&PID_4242
.
Underneath the VID
/ PID
subkey, another subkey is named after the instance ID
of the device (referencing either the device's serial number
or location information). This subkey references in turn information and parameters for the USB device as values and under the Properties
and Device Parameters
subkeys, notably:
- The ClassGUID
key value references the device interface class
GUID
of the device.
- The ContainerID
key value references the container ID
of the device.
The Properties\{83da6326-97a6-4088-9453-a1923f573b29}
subkey notably references three child subkeys of interest, each containing a timestamp value:
> 0064
(starting from Windows 7): timestamp of when the device was first plugged-in / installed.
> 0066
(starting from Windows 8): timestamp of when the device was last connected.
> 0067
(starting from Windows 8): timestamp of when the device was last removed.
This key can thus be used to:
- Identity the vendor ID (VID)
and product ID (PID)
of an USB device from its serial number
or location information (and vice versa).
- Determine when the device was first and last plugged-in and last unplugged for Windows 7 / 8+.
File: %SystemRoot%\System32\config\SYSTEM
Registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\
HKLM\SYSTEM
-
Enum\USBSTOR
Devices and USB activity
Contains system-wide information about the currently or previously connected USB devices that are related to storage.
Each USB devices is associated with a dedicated subkey under the Enum\USBSTOR
key. This subkey is named after the device device ID
or hardware ID
of the device, which references the vendor and product names. Example: Disk&Ven_SanDisk&Prod_Extreme&Rev_0001
.
Underneath the device ID
subkey, another subkey is named after the instance ID
of the device (referencing either the device's serial number
or location information). This subkey in turn references:
- The same information as the Enum\USB
key.
- A volume id
for one of the device volume in the DiskId
key value under the Device Parameters\Partmgr
.
This key can thus be used to:
- Identity the device id
(vendor and product names) of an USB device from its serial number
or location information (and vice versa).
- Determine when the device was first and last plugged-in and last unplugged for Windows 7 / 8+.
- Retrieve a volume id
for the (or one of the) volume(s) of the device.
File: %SystemRoot%\System32\config\SYSTEM
Registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR\
HKLM\SYSTEM
-
Enum\SWD\WPDBUSENUM
Devices and USB activity
Contains system-wide information about the currently or previously .
Each devices is associated with a dedicated subkey under the WPDBUSENUM
key.
This key is named with a string containing either:
- The device's device instance ID
(that includes the device's vendor and product names and serial number
) and device interface class
GUID
. Example: SWD#WPDBUSENUM#_??_USBSTOR#DISK&VEN_SAMSUNG&PROD_TYPE-C&REV_1100#0376022080001660&0#{53F56307-B6BF-11D0-94F2-00A0C91EFB8B}
.
- The volume id
. Example: SWD#WPDBUSENUM#{44B06C95-F0BA-11ED-9802-6C9466A63B90}#000000000C900000
.
This subkey references:
- The same information as the Enum\USB
key.
- A "friendly name" or display name of the (or one of the) volume associated with the device in the FriendlyName
key value.
This key can thus be used to:
- Identity the device id
(vendor and product names) of an USB device from its serial number
or location information (and vice versa).
- Determine when the device was first and last plugged-in and last unplugged for Windows 7 / 8+.
- Retrieve a friendly name of the (or one of the) volume associated with the device.
File: %SystemRoot%\System32\config\SYSTEM
Registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\SWD\WPDBUSENUM
HKLM\SYSTEM
-
MountedDevices
Devices and USB activity
The persistent database of the Mount manager
(component responsible for managing volume names).
Contains system-wide information about the currently or previously mounted drives (such as the system drive or USB devices).
Each devices is associated with a separate binary value, composed of:
- The device volume GUID
(as the key's value name).
- The device / hardware ID
, instance ID
, and device interface class
GUID
in a #
separated string (as the key's value data).
> The device ID
/ hardware ID
references the vendor and product names.
> The instance ID
contains the device's serial number
or location information.
> The device interface class
represents the type of the device and each class
is associated with a unique GUID
.
Full example value for an USB key: _??_USBSTOR#Disk&Ven_Kingston&Prod_DataTraveler_3.0&Rev_PMAP#60A44C42568CB041B98902A4&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}
This key can thus be used to identity the volume GUID
or the drive letter associated with the device from its serial number
or location information (and vice versa).
File: %SystemRoot%\System32\config\SYSTEM
Registry key:
HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices
HKLM\SYSTEM
-
DeviceClasses
Introduced in Windows Vista.
Devices and USB activity
Contains system-wide information about the currently or previously connected plug and play devices (such as storage devices, volumes, network devices, Bluetooth devices, etc.).
File: %SystemRoot%\System32\config\SYSTEM
Registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses
HKLM\SOFTWARE
-
Windows Portable Devices
Devices and USB activity
Contains information on currently or previously attached media and storage devices, notably the device volume(s)'s "friendly name" or display name.
Each devices is associated with a dedicated subkey under the Windows Portable Devices\Devices
key.
This key is named with a string containing either:
- The device's device instance ID
(that includes the device's vendor and product names and serial number
) and device interface class
GUID
. Example: SWD#WPDBUSENUM#_??_USBSTOR#DISK&VEN_SAMSUNG&PROD_TYPE-C&REV_1100#0376022080001660&0#{53F56307-B6BF-11D0-94F2-00A0C91EFB8B}
.
- The volume id
. Example: SWD#WPDBUSENUM#{44B06C95-F0BA-11ED-9802-6C9466A63B90}#000000000C900000
.
The FriendlyName
key value represents the "friendly name" or display name of the (or one of the) volume associated with the device.
This key can thus be used to identity a volume friendly name from (a) a device serial number
/ location information or (b) a volume id
(and vice versa).
File: %SystemRoot%\System32\config\SOFTWARE
Registry key: HKLM\SOFTWARE\Microsoft\Windows NT\Windows Portable Devices
HKLM\SOFTWARE
-
VolumeInfoCache
Devices and USB activity
Contains information on currently or previously mounted volumes, notably a mapping between drive letters and the last associated volume(s)'s "friendly name" or display name.
File: %SystemRoot%\System32\config\SOFTWARE
Registry key: HKLM\SOFTWARE\Microsoft\Windows Search\VolumeInfoCache
HKLM\SOFTWARE
-
EMDMgmt
Only available if the system drive is not an SSD
Devices and USB activity
Related to the ReadyBoost feature.
File: %SystemRoot%\System32\config\SOFTWARE
Registry key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt
NTUSER
-
MountPoints2
Devices and USB activity
Currently or previously mapped drives (such as the system drive, USB devices, or network shares) mounted by the associated user.
Each drives is represented by a subkey, which is named as either the volume GUID
, a letter, or, for network shares, using a specific nomenclature (##<IP | HOSTNAME>#<SHARE_NAME>
).
For devices, the volume GUID
can be used to retrieve more information on the device from the HKLM\SYSTEM\MountedDevices
registry key, including the device / hardware ID
(vendor and product name) and instance ID
(with the serial number
if existing).
This key can be used to determine which user interacted with a given USB device. However entries are not reliably created, so the absence of an entry is not an indicator that the given user didn't interact with the device.
File: %SystemDrive%:\Users\<USERNAME>\NTUSER.dat
Registry key:
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2
setupapi
logs
Devices and USB activity
Plaintext log files that track installation of devices and drivers. The logs are rotated and preserved, so historical data dating back to the system install should be available (if the logs were not deleted / tampered).
Device installation entries (generated when the device is plugged-in) contain various information, including the device:
- serial number
.
- Device id
(vendor and product names) or vendor ID (VID)
+ product ID (PID)
.
Extract of an entry for the first time an USB device was plugged-in:
>>> [Device Install (Hardware initiated) - SWD\WPDBUSENUM_??_USBSTOR#Disk&Ven_USB&Prod_Flash_Disk&Rev_1100#7&d2713f&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}]
>>> Section start 2021/02/07 19:11:17.101
Device are sometimes "deleted" through the cleanmgr.exe
utility:
>>> [Delete Device - USB\VID_090C&PID_2000\8&1DBBAC39&0&3]
>>> Section start 2023/03/16 16:55:26.426
cmd: "%SystemRoot%\Windows\system32\cleanmgr.exe" /autoclean /d C:
<<< Section end 2023/03/16 16:55:26.473
The timestamps in the setupapi
logs are in the local timezone of the system.
The logs can be used to determine when a device was first plugged (in the local timezone of the system).
Windows XP: %SystemRoot%\setupapi.log
Starting from Windows 7:
%SystemRoot%\INF\setupapi.dev.log
%SystemRoot%\INF\setupapi.dev.<YYYYMMDD-HMMSS>.log
EVTX
-
Microsoft-Windows-Storage-ClassPnP/Operational
Devices and USB activity
Provider: Microsoft-Windows-StorDiag
.
Event 507
: error events.
> Generated multiple times, for every connection, and sometimes safe removal and while the device is plugged-in. As the event is generated upon errors, it may however not be reliably logged.
Relevant information:
- Device's vendor and product names.
- Device serial number
(which is however not the same as the one found in the registry and ofter shows up as AA00000000000489
for different USB storage devices).
- Device number, which is an incremental number based on the number of devices plugged-in, for all devices, including the system drive (which would like be device number 1).
- Device's DeviceGUID
which can be used for correlation with other events.
Other events, also generated upon errors and with similar information: 500
, 502
, 503
, 504
, 505
, 506
, and 510
.
These events, especially 507
, can be used to:
- Determine when a device was plugged using the device vendor and product names or serial number
.
- Retrieve (a version of) the device serial number
(!= registry serial number)
and its vendor and product names.
- Identify the device DeviceGUID
for correlation with other events.
Microsoft-Windows-Storage-ClassPnP%4Operational.evtx
EVTX
-
Microsoft-Windows-Kernel-PnP/Device Configuration
Devices and USB activity
Provider: Microsoft-Windows-Kernel-PnP
.
Contains information for all plug and play devices, not limited to USB storage devices.
Event 400
: Device <DEVICE> was configured
.
Event 401
: Device <DEVICE> failed configuration
.
Event 410
: Device <DEVICE> was started
.
Event 411
: Device <DEVICE> had a problem starting
.
Event 430
: Device <DEVICE> requires further installation
.
> The events above appear to be generated when a device is first plugged-in to the system.
Event 420
: Device <DEVICE> was deleted
.
The <DEVICE>
string is based on the event DeviceInstanceId
field, which contains the device's vendor ID (VID)
, product ID (PID)
and (registry) serial number
or location information.
These events can be used to:
- Determine when a device was first plugged.
- Identity the vendor ID (VID)
and product ID (PID)
of the device from its serial number
or location information (and vice versa).
Microsoft-Windows-Kernel-PnP%4Configuration.evtx
EVTX
-
Microsoft-Windows-Kernel-PnP/Device Management
Introduced in Windows 11.
Devices and USB activity
Provider: Microsoft-Windows-Kernel-PnP
.
Contains information for all plug and play devices, not limited to USB storage devices.
Event 1010
: Device <DEVICE> has been surprise removed as it is reported as missing on the bus
.
The event is reliably generated when a device is removed / unplugged without prior ejection. Additionally, subsequent immediate event(s) are generated for each of the device volume(s).
Relevant information:
- For USB storage device: vendor ID (VID)
, product ID (PID)
, (registry) serial number
or location information. Example: USB\VID_18A5&PID_0302\1601000001586259
.
- For volumes: the volume GUID
of the volume. Example: STORAGE\Volume\<GUID>
.
If a device has been removed without prior ejection, these events can be used to:
- Determine when a device was unplugged with out prior ejection, from the device (registry) serial number
or location information.
- Identity the vendor ID (VID)
and product ID (PID)
of the device from its serial number
or location information (and vice versa).
- Identify the volumes GUID
associated with the device.
Microsoft-Windows-Kernel-PnP%4Device Management.evtx
EVTX
-
Microsoft-Windows-Partition/Diagnostic
Devices and USB activity
Provider: Microsoft-Windows-Partition
.
Event 1006
.
The event is generated when a device is plugged and unplugged with or without prior ejection.
This event contains key relevant information, and notably information that are not available in other sources:
- Vendor and product names of the device.
- vendor ID (VID)
, product ID (PID)
, and (registry) serial number
or location of the device (in the ParentId
field).
- A volume id
for one of the device volume in the RegistryId
field.
- (A version of) the device serial number (!= registry serial number).
- The DeviceGUID
of the device in the DiskId
, for correlation with other events.
- The size in bytes of the device in the Capacity
field. The capacity is set to 0 if the event match a removal.
- Raw dumps of the partition table (field PartitionTable
), Master Boot Record (MBR)
(field Mbr
), and / or Volume Boot Record (VBR)
(field VbrX
) if available. The VBR
dump can be used to reconstruct the Volume Serial Number
of the device.
This event can be used to determine when a drive was plugged / unplugged and to retrieve the aforementioned information.
Microsoft-Windows-Partition%4Diagnostic.evtx
EVTX
-
Microsoft-Windows-Ntfs/Operational
Devices and USB activity
Provider: Microsoft-Windows-Ntfs
.
These events are only generated for devices that have a NTFS
volume.
Event 142
: Summary of disk space usage, since last event
.
> This event is generated with a limited delay following the plugin of the device, one occurrence for each volume(s) of the device.
Relevant information:
- The volume friendly name and associated drive letter.
- A volume id
for one of the device volume.
This event can thus be used to determine the volume friendly name(s) and drive letter(s) associated with a device, either using the volume GUIDs
of the volumes on the device or time correlation with other events.
Starting from Windows 11:
Event 4
: The NTFS volume has been successfully mounted
.
Event 9
: NTFS scanned entire volume bitmap
.
Event 10
: NTFS cached run statistics
.
Event 300
: The NTFS volume dismount has started
.
Event 303
: The NTFS volume has been successfully dismounted
.
> These events are reliably generated when a device is plugged and unplugged with or without prior ejection.
Relevant information:
- The volume friendly name and associated drive letter.
- Vendor and product names of the device.
- (A version of) the device serial number (!= registry serial number).
- DeviceGuid
(for correlation with other events).
- Whether the drive was ejected ("Reason: Explicit lock") or directly unplugged ("Reason: Surprise removal").
These events can thus be used to:
- Determine when a device was plugged / unplugged (and if it was with or without prior ejection) and its associated volumes mounted / dismounted
- Identity the volume friendly name(s) and drive letter(s) associated with a device.
Microsoft-Windows-Ntfs%4Operational.evtx
Anti-vius and Remote Administration/Access applications
The ruler-project
references numerous anti-virus products (20+) and remote administration/access applications (15+) artifacts.
Other third-party applications
The SANS institute "Windows Third-Party Apps Forensics" poster can be consulted for a list of artefacts from a number of popular Windows third-party applications (also including anti-vius and remote administration/access applications).
Azure
's PowerShell / CLI activity
Interaction with Azure though the Az
PowerShell module and az
CLI utility.
Folder telemetry
: may contain information on azurecli
commands (user Azure ID, raw command, etc.).
Folder commands
: similar to telemetry
folder, with less data on the executed azure cli
commands.
Folder ErrorRecords
: details on HTTP requests, and their associated response, that generated an error.
%SystemRoot%\Users\<USERNAME>\.azure\*
Defense evasion
EVTX
-
Security.evtx
-
Security event log clear
Defense evasion
Generated upon the deletion of events in the Security
logs.
The absence of event 1102
should however not be taken as a sign of integrity of the Security
events, as the generation of this event can be bypassed. For instance, the threads of the Event Log
service threads (hosted by svchost.exe
) can be suspended to prevent events generation while the threads are suspended (even though all events will be written upon resuming of the threads).
Event 1102
: The audit log was cleared
Security.evtx
EVTX
-
System.evtx
-
Security event log clear
Defense evasion
Generated upon the deletion of events from event logs files (other than Security.evtx
).
Event 104
: The <PROVIDER> log file was cleared
System.evtx
Others
Thumbs.db
Thumbcache
Thumbnail previews of files
The Thumbs.db
and Thumbcache
files contain cached thumbnail previews for files (pictures, some document and media file types) in folders that were interactively accessed with the Windows Explorer
. The thumbnail previews are stored in these databases as it takes less system resources (CPU time and memory) to retrieve an already generated thumbnail as opposed to generating it every time the directory is accessed.
For a Thumbs.db
file to be generated in a given folder, or for entries to be added to the central Thumbcache
files, the access must have been done with some sort of files' thumbnail / icon preview enabled.
The cached thumbnail previews persist even after deletion of the associated files. Some document types, such as PDF
files, will have their first page as their thumbnail preview.
The Thumbs.db
files are stored in their associated folders, with one individual Thumbs.db
file per folder (that was interactively accessed with files preview). However, since Windows Vista, Thumbs.db
files are only generated for access through UNC
paths (such as \\<HOST>\<SHARE_NAME>\<FOLDER>
or \\<HOST>\c$\<FOLDER>
) in the remote / share directory.
Each thumbnail created in a directory is represented in the Thumbs.db
file as a small JPEG
file, regardless of the file's original format. The images are resized to 96 × 96 pixels by default. As each Thumbs.db
file is associated with a given directory, the location of the cached thumbnails can be easily deduced.
Starting with Windows Vista, the Thumbcache
files centralize thumbnails in a central location. Each Thumbcache
file, labeled thumbcache_<RESOLUTION>.db
, contains thumbnails from all locations. The <RESOLUTION>
indicate the resolution of the thumbnail previews, such as the thumbcache_1280.db
file for thumbnails in 1280 x 720 pixels resolution.
The location of the file linked to a thumbnail is not stored in the Thumbcache
file. However, each thumbnail in the Thumbcache
file is associated with an unique identifier ThumbnailcacheID
. This identifier / hash can be used to retrieve the location of the associated file, mostly for non deleted files:
- By scanning and computing the identifier for every files on the volume. This requires the file to still be present on the volume.
- By searching the Windows Search
database (Windows.edb
) for the ThumbnailcacheID
, as a table of this database notably references the file original full path and size. As the Windows Search
database is updated in near real time and does not store information on deleted files, this also requires the original file to still be present.
Thumbs.db
: individual hidden files in their associated folders.
Thumbcache
:
%SystemDrive%:\Users\<USERNAME>\AppData\Local\Microsoft\Windows\Explorer\thumbcache_<RESOLUTION>.db
files.
Windows Push Notifications (WPN)
Introduced in Windows 10.
Windows Push Notifications
Per user database and Write-Ahead Logging (WAL)
files:
%SystemDrive%:\Users\<USERNAME>\AppData\Local\Microsoft\Windows\Notifications\wpndatabase.db
%SystemDrive%:\Users\<USERNAME>\AppData\Local\Microsoft\Windows\Notifications\wpndatabase.db-wal
System-wide database and Write-Ahead Logging (WAL)
files:
%SystemDrive%:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Windows\Notifications\wpndatabase.db
%SystemDrive%:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Windows\Notifications\wpndatabase.db-wal
EVTX
-
Microsoft-Windows-VHDMP-Operational.evtx
-
ISO
mounting events
Phishing / malware execution
ISO
image can be leveraged in phishing scenarios where the loader is packed in an ISO
file to avoid the Mark-of-the-Web
(on unpatched system).
Upon the mounting of an ISO
image, the following events, containing the full path to the ISO
and the responsible user, will be generated:
- Event 22
: Starting to create the handle for the file backing virtual disk <ISO_PATH>
- Event 23
: Handle for the file backing virtual disk <ISO_PATH> created successfully
- Event 12
: Handle for virtual disk <ISO_PATH> created successfully [...]
- Event 25
: Beginning to bring the <ISO_PATH> online (surface)
Microsoft-Windows-VHDMP-Operational.evtx
EVTX
-
Application.evtx
-
ESENT
events
AD post exploitation
Active Directory ntds.dit
dump with ntdsutil
.
Upon execution of the ntdsutil
command to dump the Active Directory ntds.dit
database, the following events (containing the ntds
keyword) will be generated:
- Event 325
: The database engine created a new database [...]
- Event 326
: The database engine attached a database [...]
- Event 327
: The database engine detached a database [...]
- Event 206
: A database location change was detected [...]
Application.evtx
EVTX
-
Security.evtx
-
DRSUAPI
replication
AD post exploitation
Active Directory ntds.dit
dump through DRSUAPI
replication functions (DCSync
).
Upon replication operations, such as the retrieval of Active Directory secrets (DCSync
attack), the following events will be generated if the operation was not conducted under a Domain Controller
identity:
- Event 4662
: An operation was performed on an object
with the Property
attribute equal to the 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2
or 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2
GUID
.
Security.evtx
TODO
IconCache.db
Hidden local account HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList
Bitsadmin
EVTX: Microsoft-Windows-Bits-Client%4Operational.evtx 59
Persistent files: %SystemRoot%\ProgramData\Microsoft\Network\Downloader\ https://www.sans.org/white-papers/39195/
Syscache hive
Small memory dumps: hiberfil.sys, pagefile.sys, swapfile.sys
Registry LOG Files
References
https://nasbench.medium.com/a-primer-on-event-tracing-for-windows-etw-997725c082bf
https://blog.1234n6.com/2018/10/available-artifacts-evidence-of.html
SANS posters Windows forensics - https://www.sans.org/posters/windows-forensic-analysis/
https://www.scitepress.org/papers/2017/64167/64167.pdf
http://windowsir.blogspot.com/2013/07/howto-determine-program-execution.html
https://www.sans.org/blog/opensavemru-and-lastvisitedmru/
https://andreafortuna.org/2018/05/23/forensic-artifacts-evidences-of-program-execution-on-windows-systems/
https://dfir.ru/2020/04/08/bam-internals/
https://cellebrite.com/en/analyzing-program-execution-windows-artifacts/
https://blog.1234n6.com/2018/10/available-artifacts-evidence-of.html
https://crucialsecurity.wordpress.com/2011/03/14/typedurls-part-1/
https://www.crowdstrike.com/blog/how-to-employ-featureusage-for-windows-10-taskbar-forensics/
https://www.hexacorn.com/blog/2013/01/19/beyond-good-ol-run-key-part-3/
https://learn.microsoft.com/en-us/windows/win32/shell/app-registration
https://thinkdfir.com/2020/10/23/when-did-recentapps-go/
https://df-stream.com/2017/10/recentapps/
https://github.com/volatilityfoundation/community/blob/master/ThomasChopitea/autoruns.py
https://www.istrosec.com/blog/windows-10-timeline/
https://kacos2000.github.io/WindowsTimeline/WindowsTimeline.pdf
https://bohops.com/2021/03/16/investigating-net-clr-usage-log-tampering-techniques-for-edr-evasion/
https://www.youtube.com/watch?v=rioVumJB0Fo
https://www.youtube.com/watch?v=qxPoKNmnuIQ
https://www.13cubed.com/downloads/windows_registry_cheat_sheet.pdf
https://www.hecfblog.com/2013/08/daily-blog-67-understanding-artifacts.html
https://learn.microsoft.com/en-us/windows-hardware/drivers/storage/supporting-mount-manager-requests-in-a-storage-class-driver
https://www.sans.org/blog/computer-forensic-guide-to-profiling-usb-device-thumbdrives-on-win7-vista-and-xp/
http://windowsir.blogspot.com/2013/04/plugin-emdmgmt.html
https://www.hecfblog.com/2013/08/daily-blog-66-understanding-artifacts.html
http://website.bcmsystem.com/orion/wp-content/uploads/2019/05/Microsoft-Windows-10-USB-Forensic-Artefacts.pdf
https://lifars.com/wp-content/uploads/2020/04/LIFARS-WhitePaper-Windows-ShellBags-Forensics-Investigative-Value-of-Windows-ShellBags.pdf
https://aboutdfir.com/new-windows-11-pro-22h2-evidence-of-execution-artifact/
https://www.youtube.com/watch?v=rV8aErDj06A
https://www.netsurion.com/articles/following-a-users-logon-tracks-throughout-the-windows-domain
https://threathunterplaybook.com/hunts/windows/190511-RemotePwshExecution/notebook.html
https://www.ntfs.com/
https://github.com/jschicht/Secure2Csv
https://www.forensicsmyanmar.com/2022/08/ntfs-index-attributes.html
https://dfir.ru/2021/01/10/standard_information-vs-file_name/
https://en.wikipedia.org/wiki/Windows_thumbnail_cache
https://thumbcacheviewer.github.io/
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2429795
https://www.13cubed.com/downloads/windows_browser_artifacts_cheat_sheet.pdf
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4776
https://mandiant.com/resources/blog/digging-up-the-past-windows-registry-forensics-revisited
https://www.mdpi.com/2673-6756/2/1/7
Last updated