PowerShell script block logging: what it records and what to protect

Script block logging makes PowerShell record the content of the script blocks it processes, written as event ID 4104 in the event log. It is one of the most useful PowerShell controls for defenders, but the log can also capture credentials a script handles, so pair it with Protected Event Logging.

What it records

Microsoft's documentation describes script block logging as recording the processing of commands, script blocks, functions and scripts, whether they run interactively or through automation. Once it is enabled, any new PowerShell session logs this information.

For PowerShell 7, the events land in the PowerShellCore/Operational log with event ID 4104. Windows PowerShell 5.1 has its own documentation and its own log, so check which engine your machines actually run before you build alerts around a log name.

Module logging is a separate category. It records pipeline execution events for members of the modules you name, and it must be enabled for both the session and the specific modules. Script block logging is the broader of the two for most investigations, because it shows the code, not just the pipeline events.

How to turn it on

There are three routes in PowerShell 7 on Windows:

• Group Policy: the Turn on PowerShell Script Block Logging setting, under Administrative Templates and PowerShell Core.
• A registry value, EnableScriptBlockLogging set to 1 under the ScriptBlockLogging policy key.
• The powershell.config.json file, using the ScriptBlockLogging option.

Group Policy is the right route for a fleet, because it is applied and reported centrally. The registry route is handy for a quick test on one machine.

On Windows, the PowerShell event provider also has to be registered before events can be written. Microsoft's page gives the command to run from an elevated prompt, and notes that you must unregister and register again after updating PowerShell.

The sensitive data problem

This is the part teams skip. The Microsoft page warns that with script logging enabled, credentials or other sensitive data used by a script can be written to the event log. If a machine that has logged such data is compromised, the logs can hand an attacker what they need to extend their reach.

A few practical consequences:

• Do not pass secrets as literal strings in scripts. They will appear in the log. Read them from a secret store at run time.
• Treat the event log as sensitive data, with access controls and retention that match.
• Forward logs off the machine so that a local attacker cannot simply clear them.

Protected Event Logging

Windows 10 introduced Protected Event Logging, which lets participating applications encrypt sensitive data written to the event log using the Cryptographic Message Syntax standard. You deploy a public key to the machines that log, and keep the private key on a more secure central collector or SIEM.

The certificate needs Document Encryption as an enhanced key usage, plus either Data Encipherment or Key Encipherment. Microsoft's warning is blunt: do not deploy the private key to the machines that log events. Decryption is then done where the key lives, for example with Unprotect-CmsMessage over the 4104 events.

Microsoft recommends enabling Protected Event Logging when you use script block logging for anything beyond diagnostics, which covers most security uses.

A sensible rollout

1. Enable on a pilot group of developer and admin machines.
2. Measure log volume for a week. Developer machines are noisy.
3. Turn on Protected Event Logging before you forward logs anywhere.
4. Write one or two detections, such as encoded commands or download cradles, and test them.
5. Roll out in rings and keep the pilot group as your canary.

Quick check

Sources

• about_Logging_Windows, Microsoft Learn

Last reviewed: 19 October 2026.