Forensic Visibility Enhancements¶
Windows lab telemetry
These optional Windows settings increase the telemetry available in the SUSA lab. Apply them only after creating a clean virtual-machine snapshot, and record each policy or log-size change so the resulting evidence can be interpreted in context.
Balance visibility, privacy and storage
Enhanced auditing and PowerShell logging can record sensitive command content and generate substantial event volume. Use these settings in an authorised lab, monitor available storage, protect collected logs, and follow organisational policy before applying equivalent settings outside the SUSA environment.
Configure forensic visibility¶
A repeatable change pattern
For every enhancement, record the baseline, apply one bounded change, verify the expected state, generate harmless test activity where required, and retain the result with the VM snapshot or build notes.
Enable Account and Group Enumeration Events in Group Policy (EIDs 4798 and 4799)¶
Enabling Event IDs (EIDs) 4798 and 4799 provides visibility into local group-membership enumeration. Event 4798 records enumeration of a user's local group membership; event 4799 records enumeration of members of a security-enabled local group.
These events can support investigations into account or group discovery, but administrative tools and ordinary system activity can generate them as well. Treat them as leads and review the requesting account, process and surrounding activity.
To enable these events, open the Local Group Policy Editor and navigate to Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > System Audit Policies - Local Group Policy Object > Account Management. Enable both Audit Security Group Management and Audit User Account Management. Select Configure the following audit events, then enable both Success and Failure.
Enable Object Access Auditing (EIDs 5140 and 5145)¶
Enabling the file-share audit subcategories can generate Event IDs 5140 and 5145. Event 5140 records the first access to a network share in a session; event 5145 records a detailed check for access to an object within a share.
These events help investigators assess which account and source address accessed a share and, with event 5145, the relative target and requested access. They do not by themselves prove data staging or exfiltration. Correlate them with file-system, authentication, endpoint and network evidence.
To enable these events, open the Local Group Policy Editor and navigate to Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > System Audit Policies - Local Group Policy Object > Object Access. Enable both Audit File Share and Audit Detailed File Share. Select Configure the following audit events, then enable both Success and Failure.
Note: Audit Detailed File Share can generate a high volume of events. Enable this policy only when required and primarily on high-value or sensitive systems.
Enable Task Scheduler Operational Log¶
Enabling the Task Scheduler Operational log provides visibility into the creation, modification, and execution of scheduled tasks.
This is important because attackers commonly abuse scheduled tasks to establish persistence and automate the execution of malicious code. These logs help identify suspicious task activity during threat hunting and incident response.
Open PowerShell as an administrator and run the following command:
To verify that the Task Scheduler Operational log has been enabled, run the following command:
If the output shows enabled: true, the Task Scheduler Operational log has been successfully enabled.
Enable Process Tracking and Command-Line Auditing (EIDs 4688 and 4689)¶
Event IDs 4688 and 4689 provide visibility into process creation and termination on Windows systems. Enabling command-line auditing extends EID 4688 to capture the full command line used to launch a process, including any arguments supplied.
This information is valuable during DFIR investigations because it helps identify potential malware execution, understand how processes were launched, reconstruct attacker activity, establish parent-child process relationships, and build accurate timelines of events.
To enable these settings:
Open the Local Group Policy Editor and navigate to Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Detailed Tracking. Enable Audit Process Creation.
In the Local Group Policy Editor, navigate to Computer Configuration > Administrative Templates > System > Audit Process Creation. Enable Include command line in process creation events.
Disable PowerShell Version 2¶
PowerShell Version 2 should be disabled to prevent PowerShell downgrade attacks, where an attacker intentionally launches the legacy PowerShell engine to bypass modern security features and logging capabilities. PowerShell v2 lacks important security controls such as Script Block Logging, Module Logging, Antimalware Scan Interface (AMSI) integration, and enhanced auditing available in later versions. Disabling PowerShell v2 helps ensure that malicious PowerShell activity is captured in logs, improving visibility during incident response and forensic investigations.
To determine whether PowerShell Version 2 is installed or enabled, run the following command in administrator PowerShell prompt:
If PowerShell Version 2 is installed or enabled, output similar to the following will be displayed:
If no output is returned, PowerShell Version 2 is likely not installed or enabled.
To verify this, attempt to start PowerShell Version 2 by running:
The following or similar output should be displayed:
Disable and remove PowerShell Version 2 by running the following command:
Disable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root -Remove -NoRestart
Restart the computer to apply the changes:
After the restart, verify that PowerShell Version 2 has been removed by running:
Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root
powershell.exe -Version 2
The output should indicate that the feature is disabled and that the PowerShell Version 2 engine is no longer installed:
Enable PowerShell-Specific Logging (EID 4103 & 4104)¶
PowerShell is frequently used by attackers and administrators alike. Enabling PowerShell logging provides visibility into executed commands, script contents, module activity, and interactive PowerShell sessions.
This configuration enables:
- Module Logging (EID 4103): Records PowerShell pipeline and module activity.
- Script Block Logging (EID 4104): Records PowerShell scripts and commands executed.
- PowerShell Transcription: Records interactive PowerShell sessions, including commands and console output.
Enable Module Logging (EID 4103)
Open an administrator PowerShell prompt, and run:
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging" -Force | Out-Null
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames" -Force | Out-Null
Set-ItemProperty `
-Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging" `
-Name EnableModuleLogging `
-Type DWord `
-Value 1
Log All Modules (Recommended)
New-ItemProperty `
-Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames" `
-Name "*" `
-Value "*" `
-PropertyType String `
-Force | Out-Null
Enable Script Block Logging (EID 4104)
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Force | Out-Null
Set-ItemProperty `
-Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" `
-Name EnableScriptBlockLogging `
-Type DWord `
-Value 1
Enable PowerShell Transcription
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription" -Force | Out-Null
Set-ItemProperty `
-Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription" `
-Name EnableTranscripting `
-Type DWord `
-Value 1
Set-ItemProperty `
-Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription" `
-Name EnableInvocationHeader `
-Type DWord `
-Value 1
Verify logging is active
Close the current administrator PowerShell prompt, open a new one then run the following command:
Look for:
| Event ID | Description |
|---|---|
| 4103 | Module Logging |
| 4104 | Script Block Logging |
4103 events are generated by Module Logging, but they don't necessarily appear immediately just because you enabled the setting. You need to execute some PowerShell commands that invoke modules after enabling logging.
Try:
Then run:
Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" |
Where-Object {$_.Id -eq 4103} |
Select-Object -First 10 TimeCreated, Id, Message
Increase PowerShell Operational Log Size¶
The default size of the Microsoft-Windows-PowerShell/Operational event log is typically 15 MB, which may result in rapid log rollover when PowerShell logging is enabled. Increase the log size to 1 GB to improve retention of PowerShell forensic artefacts and reduce the likelihood of losing historical events during investigations.
View the current log size
Get-WinEvent -ListLog "Microsoft-Windows-PowerShell/Operational" |
Select-Object LogName, MaximumSizeInBytes
My current log size shows as 15 MB.
Run the following command to set the log size to 1 GB:
Verify:
Alternatively, you can run the following commands to achieve the same result:
$log = Get-WinEvent -ListLog "Microsoft-Windows-PowerShell/Operational"
$log.MaximumSizeInBytes = 1GB
$log.SaveChanges()
Verify the change
Get-WinEvent -ListLog "Microsoft-Windows-PowerShell/Operational" | Select-Object LogName,@{Name="MaxSizeGB";Expression={$_.MaximumSizeInBytes/1GB}}
