Mastering PowerShell Logging: Best Practices for Comprehensive Visibility & Control

PowerShell logging involves capturing detailed information about commands, scripts, and events executed within a PowerShell session. These logs record critical data such as user activities, command parameters, execution times, and error messages.

Mastering PowerShell Logging: Best Practices for Comprehensive Visibility & Control

By analyzing this information, administrators can gain a better understanding of system behavior, ensuring compliance with security protocols, and identifying potential vulnerabilities.

What is Windows PowerShell Logging?

PowerShell logging refers to the process of recording and capturing various activities, commands, and events that occur within a PowerShell environment. PowerShell is a powerful command-line shell and scripting language developed by Microsoft for automating administrative tasks and managing system configurations.

PowerShell Logging helps to track and monitor the execution of scripts, commands, and functions, providing valuable insights into system behavior, security events, errors, and potential issues. It allows administrators and developers to review the historical data, identify patterns, troubleshoot problems, and improve overall system performance and security.

By enabling proper PowerShell logging, administrators can ensure better compliance with security policies, detect and respond to potential security breaches, and gain a deeper understanding of the actions performed within the PowerShell environment.

Setting Up Logging Configuration

The following must be done to configure logging through Group Policy:

Windows PowerShell, Windows Components, and Administrative Templates

The three forms of logging that PowerShell Logging provides are transcription, script block logging, and module logging. The PowerShell operational log contains PowerShell events. Microsoft-Windows-PowerShell%4Operational.evtx.

Module Logging PowerShell script

PowerShell pipeline execution data, such as variable initialization and command invocations, are recorded during module logging. Module logging will capture script fragments, some de-obfuscated code, and some data that has been output-formatted. 
This logging will record some information that other PowerShell logging sources could have missed, but it might not consistently record the commands that were run. Since PowerShell 3.0, module logging has been an option.

Module logging produces a lot of events, however, these events also record valuable output that isn’t found in other sources.

Activating module logging

  • Enable “Turn on Module Logging” in the “Windows PowerShell” GPO settings.
  • Click the button to see Module Name in the “Options” window.
  • To record every module, type * in the Module Names window.
  • In the “Module Names” Window, click “OK”.
  • Alternatively, the same result can be obtained by altering the registry settings listed below:
    • HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging → EnableModuleLogging = 1
    • HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging \ModuleNames → =
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging → EnableModuleLogging = 1

Script Block Logging

Blocks of code are recorded by script block logging as the PowerShell engine executes them. It records all of the scripts and commands that were executed by the attacker’s code. 

Because of the way script block logging works, it also captures de-obfuscated code as it runs. The output of the executed code will not be recorded by script block PowerShell Logging. 

Script blocks that are longer than the allotted length for an event log message are split up into several entries. It is possible to reassemble broken blocks using a script that can interpret script block logs.

Enabling script block logging will record all activity, not only blocks that the PowerShell process deems suspicious. Investigators are now able to pinpoint the complete range of attacker activities. The non-suspicious blocks will likewise be recorded under EID 4104, but with “verbose” or “information” levels.

While producing fewer events than module logging, script block recording captures crucial signs for alerting in a SIEM or log monitoring platform.

“Log script block execution start/stop events” is another option available in Group Policy. By script block ID, this option logs the beginning and end of script blocks in EIDs 4105 and 4106. 

This option generates an unreasonably high volume of events and is not suggested for most environments, although it may provide additional forensic information in the case of a PowerShell script running for a lengthy time.

Activate script block logging as follows:

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1

Configure Transcription

Every PowerShell Logging session is recorded via transcription, including all input and output, exactly as it appears during the session. Text files containing transcripts that are segmented by user and session are written. 
For the purpose of assisting analysis, transcripts also include timestamps and metadata for each command. The contents of scripts that have been executed or output that has been written to other destinations, such as the file system, are not captured by transcription; instead, it only captures what is visible in the PowerShell terminal.

To avoid clashes, PowerShell transcripts are given names that start with “PowerShell_transcript” by default. Transcripts can be configured to be written to any location that can be accessed on the local system or the network, however, they are typically written to the user’s documents folder. 

  • Set “Turn on PowerShell Transcription” to enabled in the “Windows PowerShell” GPO settings.
  • The “Include invocation headers” checkbox must be selected if you want to save a timestamp for each command that is run.
  • A write-only, password-protected network share that only authorized security professionals can access this directory is ideal. The transcript files will be created in the user’s documents directory if no output path is specified.
  • Alternatively, enabling logging by changing the following registry values:
    • HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableTranscripting = 1
    • HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableInvocationHeader = 1
    • HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → OutputDirectory = “” (Enter path. Empty = default)