When is Event ID 4104 logged?

What Event ID 4104 Actually Tells You

Event ID 4104 is not just a generic PowerShell notice, it is the record that PowerShell created a script block and wrote its content to the PowerShell Operational log. That makes it especially useful for seeing what code was actually executed, including commands that may have been obscured at the command line or assembled at runtime.

For defenders, the value is in the content itself. A 4104 event can expose encoded command usage, string concatenation meant to hide intent, and script content that never appears clearly in process creation telemetry. It is most useful when you are looking for abuse that relies on PowerShell as an execution layer rather than on a standalone executable.

Because it depends on Script Block Logging, 4104 is a visibility control as much as a detection source. If logging is not enabled, you lose this layer of detail even though PowerShell may still be active on the host.

When It Appears in the PowerShell Lifecycle

4104 is logged when PowerShell processes script blocks in new sessions and the host policy allows that content to be captured. In practice, that means the event is tied to runtime execution, not merely to the presence of a script file on disk.

The event can appear for both administrative and non-administrative activity, which is why context matters. A legitimate automation task can generate it, but so can a hands-on operator, a maintenance script, or an attacker using PowerShell for staging, download, deobfuscation, or lateral movement.

That timing makes 4104 useful for correlation. Pair it with process creation, logon activity, PowerShell module logging, and parent-child process relationships so you can tell whether the script block belongs to expected management activity or an unusual interactive session.

What Good Detection and Coverage Look Like

Good coverage starts with enabling the policy or registry setting wherever PowerShell use matters, then confirming that the event is actually flowing into your central logging platform. The event is only useful if it is retained, searchable, and tied to the host and user context needed for triage.

Once it is available, focus on patterns that indicate concealment or abuse. Repeated deobfuscation, encoded commands, reflective loading patterns, unusual download-and-execute behavior, and script blocks that introduce administrative capability outside normal change windows deserve closer review.

PowerShell Security Guide covers script block logging, common abuse patterns, and the broader PowerShell controls that make 4104 more actionable.

Windows Event Log Guide helps you place 4104 alongside the other Windows event IDs needed for reliable investigation and correlation.

Risk and Threat Considerations

When 4104 is absent or disabled, attackers who rely on PowerShell can leave far less visible evidence behind. That weakens your ability to spot obfuscated command use, script-based staging, and post-compromise administrative activity that never shows up cleanly in a process tree alone.

Failure mechanism: Script Block Logging is not enabled, not retained long enough, or not forwarded reliably, so the host executes PowerShell content without preserving the script body that investigators need for detection and reconstruction.

Impact: You lose visibility into what PowerShell actually ran, which raises the chance that malicious commands, deobfuscation chains, and hands-on-keyboard activity will be missed or diagnosed late.

Practitioner Guidance

What to verify: Confirm that Script Block Logging is enabled where PowerShell is allowed, and verify that 4104 events arrive in your SIEM with enough host, user, and timestamp context to support investigation.

Common mistake: Treating 4104 as a standalone alert source instead of a content-rich telemetry stream. It is most effective when you correlate it with process creation, logon activity, and administrative change signals.

What practitioners underestimate: Normal administration can generate the same event ID, so the real decision point is not whether 4104 exists, but whether the script content matches the system’s expected operational patterns.

Practitioner takeaway: 4104 is most valuable when you use it to recover PowerShell intent, not just to confirm execution, so coverage and retention matter as much as the alert itself.

Related resources from NHI Mgmt Group

• When is Event ID 4624 logged?
• When is Event ID 4648 logged?
• When is Event ID 4625 logged?
• When is Event ID 4663 logged?