Event ID 4104 records PowerShell script block content when Script Block Logging is enabled. It can expose malicious commands, obfuscation, downloaders and post-exploitation activity. Enable logging through policy or the registry setting, then monitor the recorded script content for suspicious encoded text, unusual cmdlets and commands executed in new sessions.
What Event ID 4104 actually tells you about attacker activity
Event ID 4104 is useful because it preserves the PowerShell script block itself, not just the fact that PowerShell ran. That makes it valuable for seeing malicious intent after obfuscation, especially when attackers use encoded commands, downloaders, in-memory execution, or layered post-exploitation steps that would otherwise be hard to reconstruct.
In practice, the event often shows the difference between benign administration and abuse. A normal administrative session usually contains familiar cmdlets and routine automation patterns, while suspicious activity tends to stand out through unusual parameters, hidden content, script deobfuscation artifacts, or command chains that fetch, decode, or execute additional payloads.
The event is also strongest when you interpret it with surrounding telemetry. Pairing the script block with process creation, logon context, and session timing helps you decide whether the script was part of an expected admin workflow or a foothold-to-lateral-movement sequence.
Which attack patterns are most often visible in script block logging
Event ID 4104 commonly exposes the kinds of PowerShell tradecraft that defenders expect to see during intrusion, including encoded or compressed commands, obfuscated variable names, download-and-execute behavior, credential access helpers, and post-exploitation modules. It can also reveal living-off-the-land activity where PowerShell is used to avoid dropping obvious binaries.
When you review these events, focus on whether the script is doing something that changes host state, stage-delivers content, or reaches out to external infrastructure. Those patterns are more meaningful than a simple count of cmdlets, because attackers often rely on short, nested, or heavily obscured command fragments to hide the real action.
For security teams that want a deeper PowerShell-specific reference point, the PowerShell Security Guide is the most direct companion to Event ID 4104 because it covers script block logging, obfuscation, Constrained Language Mode, AMSI, and common abuse patterns.
How to use 4104 without drowning in benign administrative noise
Script Block Logging produces useful detail, but it can be noisy if you treat every PowerShell invocation as suspicious. The better approach is to separate ordinary automation from scripts that contain encoded payloads, remote retrieval, suspicious reflection, unusual parent processes, or commands executed in a session that has no normal administrative history.
Good filtering starts with baseline awareness. If your environment has standard management scripts, scheduled tasks, or software deployment tooling, learn what those look like first. That baseline makes it much easier to spot deviations such as a one-off encoded command, a new download cradle, or a script block that appears only after an unexpected logon.
For the broader event context around PowerShell, logons, and host activity, the Windows Event Log Guide helps place 4104 alongside the event IDs that show who logged on, what process started, and whether the host also recorded log clearing or other suspicious changes.
Risk and Threat Considerations
Event ID 4104 matters because it often captures the attacker’s working material after obfuscation but before the broader impact becomes obvious. If Script Block Logging is disabled, incomplete, or not centrally collected, you can lose the most readable record of how an intrusion was staged, which makes detection, triage, and scoping much harder.
Failure mechanism: Attackers abuse PowerShell because it is trusted, flexible, and often allowed in admin workflows. They hide intent through encoding, string concatenation, nested invocation, or in-memory execution, then rely on weak logging coverage or poor alert tuning so the script content is not reviewed in time.
Impact: Missing or ignored 4104 data can delay discovery of downloader activity, credential-related tooling, lateral movement preparation, and persistence steps. That increases the chance that a short-lived foothold becomes a wider compromise before defenders reconstruct the execution chain.
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 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.001 — PowerShell | PowerShell script block content maps directly to attacker use of PowerShell for execution. |
| Recommendation — Map suspicious 4104 content to PowerShell execution activity and correlate it with related ATT&CK techniques. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Event ID 4104 is a logging artifact that depends on centralized audit collection and review. |
| Recommendation — Enable, centralize, and review PowerShell script block logs as part of audit log management. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | 4104 depends on generating detailed audit records for PowerShell script blocks. |
| AU-6 — Audit Record Review, Analysis, and Reporting | The event is only useful when analysts review script content for suspicious execution patterns. | |
| SI-4 — System Monitoring | 4104 supports monitoring for malicious PowerShell behavior on hosts. | |
| Recommendation — Generate and retain PowerShell script block audit records for security monitoring and incident analysis. Review PowerShell audit records for encoded commands, obfuscation, and post-exploitation activity. Use host monitoring to detect suspicious PowerShell script behavior and escalation paths. | ||
Practitioner Guidance
What to verify: Confirm that Script Block Logging is enabled on the systems where PowerShell is a meaningful administrative tool, and verify that the events are actually landing in your SIEM or log store. A configuration that exists only on paper is not useful when an incident starts.
Decision rule: Treat 4104 entries with encoded text, obvious obfuscation, or download-and-execute behavior as higher priority than ordinary automation. If the script is tied to a new session, unusual parent process, or an account that does not normally run PowerShell, escalate the review even if the commands are short.
What practitioners underestimate: The value of 4104 is not just detection, it is reconstruction. In a real incident, the script block often becomes the fastest way to understand what the attacker tried next, which means preservation, searchability, and correlation matter as much as the alert itself.
Practitioner takeaway: Use Event ID 4104 as a content source, not a standalone verdict, because the most useful signal appears when suspicious script text is correlated with session context and adjacent Windows telemetry.