Event ID 4104 records PowerShell script blocks when Script Block Logging is enabled. It gives defenders visibility into the commands PowerShell actually processes, including obfuscated or dynamically built content. Enable it through policy or the registry setting, then monitor the content alongside process lineage and host context. The event appears in the PowerShell Operational log.
What Event ID 4104 tells defenders that simpler logging can miss
Event ID 4104 matters because it captures the script block PowerShell actually executes, not just the command line that launched it. That closes a common visibility gap: attackers often hide intent through encoded, concatenated, or dynamically generated PowerShell. With 4104, security teams can inspect the content that reaches the engine and build detections around behavior, not just syntax.
That makes the event especially useful when process creation logs show only a benign launcher or a short encoded command. It gives analysts a higher-fidelity view of what ran in memory, which is why it is valuable for triage, hunting, and post-compromise review.
Why 4104 improves investigation quality and detection coverage
PowerShell is frequently used for administration, automation, and adversary tradecraft, so the event is most useful when paired with process lineage, parent-child relationships, and host context. The log entry can help separate routine automation from suspicious script content, especially when the same host also shows unusual logon behavior, remote execution, or privileged activity.
It also helps detection engineering. Teams can search for recognizable abuse patterns such as download-and-execute behavior, suspicious reflection or deobfuscation, in-memory loaders, and script fragments that never appear in a saved .ps1 file. In other words, 4104 is not just a forensic artifact, it is a content source for better alerts and hunts.
For teams building Windows telemetry, the event belongs in the same collection strategy as other host-level sources that explain how activity unfolded. A broader logging baseline can be easier to operationalise when you align it with a Windows event log guide for security teams and then use PowerShell-specific telemetry to fill in the execution detail.
How to enable, validate, and use it without creating blind spots
4104 only appears when Script Block Logging is enabled, so the first practical question is whether the setting is actually deployed everywhere you think it is. Security teams should verify policy inheritance, local overrides, and whether the relevant PowerShell versions on the fleet are covered consistently. If the setting is partial, the resulting visibility gap is often worse than no logging at all because it creates a false sense of coverage.
Once enabled, the event should be monitored in context. The content alone is useful, but the real value comes from correlating it with the process that spawned PowerShell, the account in use, the network or file activity that followed, and whether the host later showed signs of tampering. That is why a dedicated PowerShell Security Guide is the natural companion: it ties 4104 to script block logging, common abuse patterns, and the surrounding defensive controls.
Teams that already operate a SIEM should forward these events with enough fidelity to preserve the script text, timestamps, and host metadata. A SIEM Guide is useful here because 4104 is only actionable when ingestion, parsing, and alert tuning let analysts search the script content quickly and with tolerable noise.
Risk and Threat Considerations
Attackers value Event ID 4104 because it can expose the exact malicious logic they are trying to conceal. If defenders are not collecting it, obfuscated PowerShell can look like generic administrative activity, delaying detection and making it harder to reconstruct what was executed on the host.
Failure mechanism: Script Block Logging is disabled, only partially deployed, or not forwarded with enough context, so analysts lose visibility into the actual script content and miss malicious or dual-use PowerShell activity.
Impact: Security teams may fail to detect living-off-the-land execution, miss the sequence of commands used during compromise, and lose the evidence needed to scope lateral movement, persistence, or follow-on payloads.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | PowerShell script block logging helps detect command-and-script execution abuse. |
| Recommendation — Map suspicious script blocks to T1059 and hunt for execution patterns that indicate malicious scripting. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | 4104 is a host audit event that must be collected, retained, and reviewed for detection value. |
| Recommendation — Centralise 4104 collection and review it as part of your audit log management process. | ||
| NIST CSF 2.0 | DE.CM-01 — Continuous Monitoring | 4104 supports continuous monitoring of endpoint activity and script execution behavior. |
| Recommendation — Include PowerShell logging in continuous monitoring for host execution and abuse signals. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | 4104 depends on generating audit records for PowerShell script blocks to preserve forensic visibility. |
| AU-6 — Audit Record Review, Analysis, and Reporting | 4104 is only useful when analysts review the events for malicious or abnormal script content. | |
| Recommendation — Enable script block audit generation and ensure records are forwarded intact for analysis. Review 4104 events for suspicious content and correlate them with host and process context. | ||
Practitioner Guidance
What to verify: Confirm that Script Block Logging is enabled by policy, not just on a few pilot systems, and that 4104 events arrive in your central platform with the script text intact. If the content is truncated or missing host context, treat the deployment as incomplete rather than “working enough.”
Decision rule: If 4104 shows a script block that is encoded, obfuscated, dynamically assembled, or paired with unusual parent processes, treat it as a hunting lead first and an incident indicator second. The event is most valuable when it changes your investigation priority, not when it is merely archived.
Practitioner takeaway: Event ID 4104 is valuable because it reveals PowerShell execution at the content layer, so teams should treat it as a visibility control that only works when collection, correlation, and review are all in place.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org