How do I enable PowerShell Script Block Logging (Event ID 4104)?

Via Group Policy: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on Script Block Logging. Set to Enabled. This applies to all PowerShell sessions on the machine — you will start seeing 4104 events in the Microsoft-Windows-PowerShell/Operational log immediately after the policy is applied. Also enable Module Logging (Event 4103) for complementary pipeline-level visibility. Without Script Block Logging, encoded PowerShell and in-memory attacks are nearly invisible from the Windows log perspective alone.

Is Event ID 4104 always malicious?

No — 4104 fires for all PowerShell script blocks, including legitimate automation, system management, and monitoring scripts. The Warning level only triggers when PowerShell's internal suspicious keyword heuristic fires (keywords like IEX, DownloadString, or known offensive module names). Start by filtering on level=Warning, then look for: IEX or Invoke-Expression combined with a download, FromBase64String (especially nested multiple times), known offensive tool names (Invoke-Mimikatz, Invoke-ReflectivePEInjection), and AMSI bypass patterns (AmsiUtils, amsiContext). Legitimate scripts in 4104 are readable, have known paths, and run from expected parent processes.

Does Event ID 4104 capture obfuscated or encoded PowerShell?

Yes — this is its primary security value. PowerShell de-obfuscates and decodes script content before executing it, and Script Block Logging captures the content after de-obfuscation. This means even heavily obfuscated payloads — multiple layers of Base64, string concatenation, char-code assembly, Invoke-Obfuscation output — appear as readable code in the 4104 script block content. The only exceptions are the PowerShell v2 downgrade attack (which bypasses 4104 entirely since PSv2 lacks Script Block Logging) and ETW-based AMSI patching that targets the logging provider itself.

Why am I suddenly seeing Event ID 4104 events I didn't see before?

Either Script Block Logging was just enabled on that host (check when the GPO was applied), or PowerShell activity genuinely increased. If logging was already enabled, look at what process is spawning PowerShell — check Event 4688 for the PowerShell process creation and note the Creator Process Name. New 4104 events from a host with no recent policy change often mean a new scheduled task, service, or remote command is now executing PowerShell. Correlate the 4104 timing with 4698 (scheduled task created) or 7045 (service installed) to find what changed.

Scan your Security and Sysmon logs·Detection guides

Event ID 4104WarningMicrosoft-Windows-PowerShell/OperationalT1059.001

Windows Event ID 4104 — PowerShell Script Block Logging

Logged when PowerShell executes a script block — captures the actual code being run, even if it was de-obfuscated at runtime. One of the most valuable PowerShell forensic data sources.

MITRE ATT&CK

Technique

T1059.001 · PowerShell

Tactic

Execution

View on attack.mitre.org →

Why It Matters

Attackers heavily obfuscate PowerShell to evade detection. Script Block Logging captures the de-obfuscated code after PowerShell processes it, exposing encoded payloads, in-memory attacks, and download cradles.

Key Fields

Script Block TextThe actual PowerShell code — look for IEX (Invoke-Expression), DownloadString, encoded commands, and known offensive tool signatures

Script Block IDLinks multi-part script blocks together

PathFile path if a script file was used; empty for memory-only execution

Investigation Tips

1.Search for IEX, Invoke-Expression, [System.Convert]::FromBase64String — common obfuscation techniques.
2.Look for download cradles: (New-Object Net.WebClient).DownloadString or Invoke-WebRequest.
3.Enable via GPO: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on Script Block Logging.

Seeing Event ID 4104 in your own logs? Upload an .evtx file — EventPeeker flags powershell script block logging automatically, maps it to MITRE ATT&CK, and writes the triage report. No account, files auto-deleted.

Analyze my logs →

Related Event IDs

4103PowerShell module logging — less detailed but complementary

4688Process creation for the PowerShell process

Frequently Asked Questions

How do I enable PowerShell Script Block Logging (Event ID 4104)?: Via Group Policy: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on Script Block Logging. Set to Enabled. This applies to all PowerShell sessions on the machine — you will start seeing 4104 events in the Microsoft-Windows-PowerShell/Operational log immediately after the policy is applied. Also enable Module Logging (Event 4103) for complementary pipeline-level visibility. Without Script Block Logging, encoded PowerShell and in-memory attacks are nearly invisible from the Windows log perspective alone.
Is Event ID 4104 always malicious?: No — 4104 fires for all PowerShell script blocks, including legitimate automation, system management, and monitoring scripts. The Warning level only triggers when PowerShell's internal suspicious keyword heuristic fires (keywords like IEX, DownloadString, or known offensive module names). Start by filtering on level=Warning, then look for: IEX or Invoke-Expression combined with a download, FromBase64String (especially nested multiple times), known offensive tool names (Invoke-Mimikatz, Invoke-ReflectivePEInjection), and AMSI bypass patterns (AmsiUtils, amsiContext). Legitimate scripts in 4104 are readable, have known paths, and run from expected parent processes.
Does Event ID 4104 capture obfuscated or encoded PowerShell?: Yes — this is its primary security value. PowerShell de-obfuscates and decodes script content before executing it, and Script Block Logging captures the content after de-obfuscation. This means even heavily obfuscated payloads — multiple layers of Base64, string concatenation, char-code assembly, Invoke-Obfuscation output — appear as readable code in the 4104 script block content. The only exceptions are the PowerShell v2 downgrade attack (which bypasses 4104 entirely since PSv2 lacks Script Block Logging) and ETW-based AMSI patching that targets the logging provider itself.
Why am I suddenly seeing Event ID 4104 events I didn't see before?: Either Script Block Logging was just enabled on that host (check when the GPO was applied), or PowerShell activity genuinely increased. If logging was already enabled, look at what process is spawning PowerShell — check Event 4688 for the PowerShell process creation and note the Creator Process Name. New 4104 events from a host with no recent policy change often mean a new scheduled task, service, or remote command is now executing PowerShell. Correlate the 4104 timing with 4698 (scheduled task created) or 7045 (service installed) to find what changed.

Go deeper: the full Event ID 4104 — PowerShell Script Block Logging guide

Builds on this page with the attack chain, step-by-step investigation, immediate containment actions, KQL/Sigma detection queries, and an annotated example log.

Read the Event ID 4104 — PowerShell Script Block Logging guide →

See Event ID 4104 in your logs

Upload a Windows Event Log (.evtx) file — EventPeeker automatically detects powershell script block logging patterns, maps findings to MITRE ATT&CK, and generates an AI triage report.

Analyze EVTX Logs Free →

← All detection guides·Analyze EVTX Logs Free →