
Microsoft Windows Endpoint Forensics Readiness Booster
This short blog post will run through a few ways the IT/Security teams can configure their existing Windows environment in order to improve forensics readiness using existing operating system capabilities. We will focus on critical forensics readiness artifacts and logs which incident response (IR) teams can utilize for quick triage and accurate remediation. The scope of this cheat sheet was narrowed down to avoid external utilities such as Endpoint Detection and Response and meant to serve as a reference for every organization, not just enterprises.
All the tips below are based on built-in Windows operating system capabilities and do not require additional overhead, however can drastically help your environment breach readiness level.
Introduction
Windows environment by default have many valuable forensics artifacts that can help an Incident Response team understand what activity was conducted on the endpoints, but not all of them are enabled by default.
Logs are critical during an investigation, they can give information on processes that were created, executed PowerShell snippets, network activity and scheduled tasks that were created, and more.
Having those logs can help build a more accurate story of what exactly happened, when it happened, and by whom, which can help an IR team to contain and solve the incident quicker and more efficiently.
Besides being helpful during an incident, those logs also mean a lot for regular behavior monitoring and threat hunting. Many behavioral rules (i.e., Sigma rules) depend first on those logs, and if the logs are not enabled in the first place, no rules would ever apply.
Follow along this short Readiness Booster blog that will guide you through enabling critical built-in logs and artifacts for your Windows endpoint environments.
The following actions would increase the amount of information for activities on your endpoints:
- We recommend to enlarge the maximum size on "Event Log" logs, as usually they are quickly getting overwritten with new data, making it impossible to gather information on breaches that occurred more than a few weeks ago.
- Use group policies to enable non-default logs: Group Policy is an infrastructure that allows you to specify managed configurations for users and computers through group policy settings and preferences. You can manage group policy settings and preferences in an Active Directory Domain Services (AD DS) environment through the Group Policy Management Console (GPMC).
The same can be done also by setting the equivalent registry keys.
Event Log Providers - Configuration Guide
Let's start with the easiest quick wins - enabling log providers that end up in Event Viewer.
Those log providers are usually disabled by default or do not exist in older operating system versions.
In the section below we explain what those logs are and how to manually enable them.
Scheduled Tasks
Provider: TaskScheduler
Added value:
Track the creation, deletion, modification, and execution of scheduled tasks.
It is common for malware to assure persistence through scheduled tasks. The scheduled task will make sure the malware will run itself again after a reboot, or once every couple of hours.
Knowing that a program created a scheduled task for itself helps identify potentially malicious software, and by finding the first event of the task registration it is possible to gain insight on when the endpoint potentially got infected.
Related event IDs:
- 106 (Task Registered)
- 107 (Task Triggered)
- 140 (Task Updated)
- 141 (Registration Deleted)
- Or, in the Security log:
- 4698 (Scheduled Task Created), 4699 (Scheduled Task Deleted), 4702 (Scheduled Task Updated)
How to enable?
- Via Registry:
- Or in Event Viewer:
- Event Viewer ➝ Applications and Services Logs ➝ Microsoft ➝ Windows ➝ "TaskScheduler/Operational"Right click and choose "Enable".
In the same place you should also increase the max log size to be at least 2GB.
PowerShell Logging
Provider: Windows PowerShell
Added value:
PowerShell logs details about PowerShell operations, such as starting and stopping the engine and providers, and executing PowerShell commands.
Script Block logging - Record the processing of commands, script blocks, functions, and scripts whether invoked interactively, or through automation. When you enable Script Block Logging, PowerShell records the content of all script blocks that it processes. Once enabled, any new PowerShell session logs this information.
Module logging provides detailed information on portions of scripts, variables initialization and executed commands.
Countless malware has been using PowerShell to perform a wide range of actions on endpoints. PowerShell is native to Windows, so no installation is required, making it easier for the attackers to use. Also, PowerShell is very easy to use to make complicated changes and execute a wide range of commands.
Having the ability to witness past executions of those commands or scripts can help incredibly to understand what the attackers were trying to do, gain possible exfiltration insights, contacted command and control servers and so on.

Related event IDs:
4103 (Executing Pipeline module logging, includes the cmdlet name and output), 4104 (Script block logging of command start, contains the contents of the script), 4105 (Command Started), 4106 (Command completed)
How to enable?
Via Group Policy:
- Computer Configuration ➝ Administrative Templates ➝ Windows Components ➝ Windows PowerShell ➝
- Turn on Module Logging
- Turn on PowerShell Script Block Logging

Provider: PowerShell Transcription Logging
Added value:
Captures the input and output of PowerShell commands that appear in the terminal. Enabling this policy captures transcripts both for PowerShell and for any other programs that use the PowerShell engine.
Log location:
The transcripts are logged by default into text-based transcripts log files inside each users' "My Documents" folder. It is possible to set a different folder for those logs, preferably a remote folder with limited access, so the logs could remain private and untouched or tampered.
How to enable?
Computer Configuration ➝ Administrative Templates ➝ Windows Components ➝ Windows PowerShell ➝
- Turn on PowerShell Transcription
Process Execution Evidence
Provider: Security - Process Created
Added value:
Process Created - Logs the details about a newly created process. This is highly important to know which processes were executed on the endpoint.
Having a timeline of executed processes can help identify infection times, infecting executables, and general attack flow.
Related event IDs:
4688 (A new process has been created)
How to enable?
Via Group Policy: Computer Configuration ➝ Policies ➝ Windows Settings ➝ Security Settings ➝ Advanced Audit Configuration ➝ Detailed Tracking ➝
- Audit Process Creation
- Check both Success and Failure.
Also, it is important to enable command line logging:Computer Configuration ➝ Administrative Templates ➝ System ➝ Audit Process Creation ➝ Include command line in process creation events ➝ Enable
Network Activity
Provider: Network Connection
Added value:
Contains information about source and destination IP addresses, including port, and program name which receives or sends the TCP\UDP traffic.
Enabling this log would create a lot of noise, we recommend enlarging the Security event log in any case.
Adding this provider can help identify programs that make network connections. By having this information, it is possible to inspect suspicious IP addresses or programs and create a timeline of those activities. This can help identify the threat actors, gain insights on exfiltration if there was any, build a list of infected endpoints, and isolate suspicious executables.

Related event IDs:
5156 (The Windows Filtering Platform has permitted a connection)
How to enable?
Computer Configuration ➝ Windows Settings ➝ Security Settings ➝ Advanced Audit Policy Configuration ➝ System Audit Policies - Local Group Policy Object ➝ Object Access ➝ Audit Filtering Platform Connection
- Check Success (Failure is also possible)
Server Prefetch Logging
A small note about servers and endpoints: servers have different features than endpoints, and there are differences between investigating an endpoint and investigating a server. We would not expand on all of them currently to maintain the focus on endpoints, but it is important to know that Servers don't have Prefetch logging enabled by default.
Added value:
Prefetch gives good forensics value because it holds information on all the executed programs on the host. It also logs the first and last execution times, as well as a counter to all executions. The folder is located at "C:\Windows\Prefetch".
How to enable?
To enable Prefetch logging on servers via Registry:
HKLM\CurrentControlSet\ControlSessionManager\MemoryManagement\PrefetchParamaters
Misc
Provider: WMI-Activity
Added value:
Only exists since Windows 10. We recommend changing the default max log size to be bigger than it is.
Many attackers are using WMI to execute commands, data reconnaissance or even as a persistence mechanism.
A lot can be achieved through WMI, so it is important to have this information in order to understand the attackers activity in depth.
How to enable?
Provider: PrintService
Added value:
To detect print spooler attacks such as PrintNightmare
How to enable?
Either by heading to Event Log ➝ Applications and Services Logs ➝ Microsoft ➝ Windows ➝ PrintService ➝ Operational ➝
- Right click and choose "Enable Log"
- Or by setting the following registry key:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-PrintService/Operational\EnabledSet value: REG_DWORD, 1

Log Size
Now that we covered the most important disabled-by-default logs on windows, we highly recommend changing the default values of the actual max log size, even for logs that are enabled by default.
Nowadays storage is much cheaper, allowing more space for our precious logs. We recommend enlarging each log file, just in case, so the time of the backward saved information would be maximized.
We recommend this as most of the default settings for max log sizes are very small and limited. When a log file reaches its maximum size, it just overrides old events with new ones, which in practice means that old logs are deleted and won't exist to supply forensics value.
To prevent that from happening, change the following (and more, if you can) default log size:
Provider: System and Security Log Files Size
Added value:
The default to those log files is set to 2MB. By increasing the size, the history of the logged information would increase significantly.
How to enable?
- Computer Configuration → Policies → Administrative Templates → Windows Components → Event Log Service -> Security → Specify the maximum log file size (KB) We recommend setting a value of at least 2000000KB (~2GB). The same thing can and should be done also for "System" event log:
- Computer Configuration → Policies → Administrative Templates → Windows Components → Event Log Service → System → Specify the maximum log file size (KB)
Provider: PowerShell max log size
Added value:
The default size of this log file is 15MB. We can do better. Especially since the events in this log file can get a bit larger due to the size of the scripts that are running on the machine.
How to enable?
In Registry Editor, set the following key: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Windows PowerShell Key: MaxSize Value: 2000000 (~2GB)
Provider: WMI-Activity max log size
Added value:
The default of this log file is only 1MB, so we recommend setting a value of at least 2000000KB.
How to enable?
Windows - More resources
While the below artifacts don't need to be enabled in advance, it is possible that your team is not aware that those artifacts exist. In case you want your team to collect them, here are some cool logs that are only available on Windows 10 and Windows 11:
Program Compatibility Assistant (PCA)
A feature intended for application compatibility; it is possible to extract process execution information from it. Only available since Windows 11 22H2. The file is located at: %SystemRoot%\AppCompat\pca\PcaAppLaunchDic.txt
Background Activity Monitor & Desktop Activity Moderator (BAM, DAM)
Another source which provides evidence of execution on an endpoint. Available from Windows 10 1709 onward. The evidence is written to the Windows Registry and includes the executable file path and timestamp of most recent execution. The information is located at:
Windows Apps
The Microsoft Store is also a relatively new creature that has lived on windows machines since windows 8. It is a unified distribution point for apps, console games, digital videos, Digital music, and E-books. It is also an increasing distribution point for malware.
Windows apps are applications that are installed either from the Microsoft store or are side-loaded using malicious actions. Logs for those installation exist on windows 10 and windows 11, and many security products fail at successfully monitoring and blocking those malicious installations. The installer is not much different than other installers - however, the way the malware is delivered to the endpoint is more sophisticated and bypasses outdated protections, resulting in execution of malicious programs or commands.
One place to find evidence of installation of those logs, is under the following Event Log entries:
- Microsoft-Windows-AppxDeploymentServer/Operational
- Another log can be found at AppxPackagingOM log in Event Viewer: Microsoft-Windows-AppxPackaging/Operational
- Another source that can tell us about deployed apps: Microsoft-Windows-AppLocker/Packaged app-Deployment
- To get a list of installed windows apps, it is possible either using a PowerShell script or by querying the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateChange\PackageList
Windows Search Index
The search indexer allows one to search for files and contents on the host. In Windows 11, the structure of the indexer was changed to provide faster searching. The default folders for indexing every file inside of them are:
- C:\ProgramData\Microsoft\Windows\Start Menu\Programs
- C:\Users\ - and every subfolder except AppData
- Those two are the default folders, but you can configure the settings and add more folders to be indexed.
How can it help you and why do it?
The indexer records each new file and folder that is created (or deleted) under those folders alongside with timestamp, user who created it, file type, and size. Another important role of the indexer is that it indexes partial file contents for specific file types with plaintext data inside. The file extensions list can also be customized - for example, to add all .ps1 files. This can be very helpful to gather script file contents, like JavaScript, cmd and bat scripts, vbs, txt, even Word and Excel, and more. In addition, the indexer records URLs that were accessed with Edge and other files or programs that were opened by the user. The service is not on by default on old Windows Server versions so it has to be enabled to provide this data.
The new database file of the Search Index is located at:
- C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.db, Windows-gather.db
To change the default setting, head to:
- Control Panel → Indexing Options → Modify → There you can choose more folders.
- To add file types to be indexed, click on: Advanced Options → File Types → Index Properties and File Contents → There you can type file extension under the box of "Add new extension to list"
- To enable the service on Windows servers: open Services.msc → find and click on Windows Search → Properties → Choose Startup type to be Automatic (Delayed Start).
To conclude
Logs play an important part in the readiness of an organization to a security incident. During routine operations, correct log collection is important for monitoring the network health and performing continuous threat hunting. During an incident, logs play an even bigger role in the investigation and mitigation. Applying the above recommendations can create a huge difference in the organization. At Profero, we are strong proponents of continuous assessment and readiness improvements - methodologically.
Please don't hesitate to approach us, as we will be happy to guide you through this journey.