Did You Know: PowerShell 7 Writes Script Block Logs to Its Own Event Log, Not the One Windows PowerShell Uses

LONDON - A SOC that hunts PowerShell activity in one Windows event log may be looking in the wrong place. Microsoft's documentation for PowerShell 7 says that when script block logging is enabled, PowerShell records the content of all script blocks it processes and writes event 4104 to the PowerShellCore/Operational log, found in Event Viewer under Application and Services Logs. Microsoft's page for the older Windows PowerShell 5.1 lists the same event ID, 4104, but in a different log, Microsoft-Windows-PowerShell/Operational, under a different ETW provider. A detection or saved search pointed only at the 5.1 channel will not see the script blocks that PowerShell 7 writes to its own log.

The settings that turn logging on are separate as well. Microsoft says PowerShell 7 script block logging can be enabled through Group Policy under Administrative Templates, PowerShell Core, through the registry key HKLM:\Software\Policies\Microsoft\PowerShellCore\ScriptBlockLogging, or through the ScriptBlockLogging option in the powershell.config.json file. Windows PowerShell 5.1 uses Administrative Templates, Windows Components, Windows PowerShell, and the key HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging. Microsoft's Group Policy reference says PowerShell 7 ships its own administrative templates and an InstallPSCorePolicyDefinitions.ps1 script in its install folder, that those templates do not include settings for Windows PowerShell, and that each PowerShell 7 setting has a Use Windows PowerShell Policy setting option that takes its value from the matching Windows PowerShell policy.

PowerShell 7 on Windows also has a setup step that Microsoft's Windows PowerShell 5.1 page does not list. Microsoft says that, unlike Linux or macOS, Windows requires the PowerShell 7 event provider to be registered before events can be written to the event log, by running RegisterManifest.ps1 from the PowerShell install folder in an elevated prompt. It also says to run the script again after updating PowerShell, so the updated provider is registered. Microsoft recommends turning on Protected Event Logging whenever script block logging is used for anything other than diagnostics, because logged scripts can contain credentials and other sensitive data. That feature encrypts the logged content with a public key, and Microsoft says the private key should be kept off the logging machines, at a central collector where the events are decrypted.

Several behaviors that shape what analysts find were spelled out by the PowerShell team in a June 2015 post introducing these features in PowerShell version 5. By default, PowerShell logs a script block only the first time it is used; logging every start and stop is a separate option that the team warned can generate an extremely high volume of events. When a script block is longer than a single ETW event can hold, PowerShell splits it into multiple parts, and each event carries a part count and a ScriptBlock ID, a GUID retained for the life of the script block, which analysts can use to group the pieces. The post also says PowerShell automatically logs script blocks whose content is often used by malicious scripts, as a record of last resort, and that setting the script block logging policy to Disabled turns that automatic logging off.

For a detection team, the practical checks are short. Find out which PowerShell versions are installed on each host class, and forward both the Microsoft-Windows-PowerShell/Operational and PowerShellCore/Operational channels to the SIEM. Confirm the policy is set in both places, or that the PowerShell 7 policy is set to follow the Windows PowerShell value, and that the PowerShell 7 provider was registered again after upgrades. Treat a policy explicitly set to Disabled as a gap, not a neutral default. Microsoft's own pages do not fully agree on the channel name: the PowerShell 7 Group Policy reference still describes script block logging as writing to Microsoft-Windows-PowerShell/Operational. Test on a real host by running a harmless script block and checking which log it lands in before trusting an empty search.