Event ID 4104: Creating Scriptblock text

Event ID 4104 comes from the Microsoft-Windows-PowerShell provider and lands in the Microsoft-Windows-PowerShell/Operational channel. It fires every time the PowerShell engine parses a script block: a function definition, a loop, a one-liner typed at the prompt, or a block built dynamically at runtime through Invoke-Expression or Add-Type.

Two independent mechanisms can put a 4104 in the log, and mixing them up is the single most common mistake analysts make when scoping a hunt.

The first mechanism is deliberate: Script Block Logging turned on through Group Policy under Administrative Templates, Windows Components, Windows PowerShell, Turn on PowerShell Script Block Logging, or through the equivalent registry value EnableScriptBlockLogging under HKLM\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging.

With this enabled, every script block PowerShell processes gets logged, at Verbose level, whether the session is interactive, remote, or a scheduled task. This is the setting that gives full-fidelity coverage, and it is also the setting most environments still leave off because of the log volume it generates on build servers and DevOps hosts that run PowerShell constantly.

The second mechanism runs regardless of that policy. PowerShell carries a built-in list of suspicious constructs, patterns tied to encoding, reflection, and known bypass techniques, and any script block that matches gets logged automatically at Warning level even on a host where Script Block Logging was never enabled. This is why an analyst can sometimes find a 4104 for a single malicious one-liner on a machine that otherwise has none of this logging turned on.

It is a safety net, not a substitute for the GPO: it only catches patterns Microsoft already knows about, and it says nothing about the benign 4104 traffic the analyst would otherwise use as a baseline. Filtering on LevelDisplayName equal to Warning is a legitimate, cheap first pass across a fleet where full logging is not deployed everywhere.

The event's payload carries the fields that make it useful. ScriptBlockText is the actual code, post-parse, which is the important part: PowerShell logs what the interpreter is about to run, not what the operator typed. ScriptBlockId is a GUID that ties related events together.

Path records the originating script file when the block came from a .ps1 on disk, and is empty for ad hoc or in-memory blocks, which is itself a signal worth tracking. MessageNumber and MessageTotal exist because the event payload has a size limit; PowerShell splits a large script block into multiple 4104 events sharing one ScriptBlockId, with MessageNumber marking each fragment's position and MessageTotal recording how many fragments to expect.

An analyst reconstructing a long or heavily obfuscated script has to group by ScriptBlockId, sort by MessageNumber, and concatenate ScriptBlockText across every fragment before reading it as one artifact. Skipping this step is how analysts miss the back half of a payload that only reveals its intent in the last few hundred characters.

In a typical SOC, 4104 shows up constantly from legitimate sources: PSReadLine tab completion, module autoloading, Exchange and Active Directory management scripts, configuration management tools like DSC, and vendor agents that shell out to PowerShell for routine tasks.

It also shows up from attackers at almost every stage past initial access: a downloader pulling a second-stage payload with IEX and a WebClient object, a reconnaissance script enumerating AD group membership, a credential-dumping module reflected into memory, or a ransomware precursor disabling shadow copies.

The neighboring events matter for context. Event 4103 (module logging) records the pipeline execution details, parameter binding and cmdlet invocation, of specific modules that have been opted into logging, giving a shallower but broader view than 4104's full text capture.

Event 4688 (process creation) shows that powershell.exe or pwsh.exe launched at all, with the command line as originally typed, before any decoding, which is why a heavily obfuscated -EncodedCommand argument in 4688 and its plaintext, decoded equivalent in 4104 are two views of the same execution, useful for confirming that what launched matches what actually ran.

The single biggest false-positive source for 4104 is legitimate administration. Domain controllers, Exchange servers, and CI/CD runners generate large volumes of 4104 from scheduled maintenance scripts, group policy processing scripts, and configuration drift remediation.

These blocks are almost always associated with a Path pointing to a known, version-controlled .ps1 file in a predictable location, run under a service account, at a predictable cadence. If ScriptBlockText matches a script an admin can produce on request and the Path, account, and timing all line up with change records, treat it as benign and use it to build the environment's PowerShell baseline rather than discarding it.

The pattern that should always get attention is a script block with no Path (built or pasted interactively, or assembled in memory) combined with content that has no legitimate business reason to exist: a WebClient object immediately followed by FromBase64String, an IEX wrapping a DownloadString call, or a -EncodedCommand argument that decodes into something unrelated to the process that launched it. These combinations are what commodity loaders and post-exploitation frameworks produce, because they need to pull and execute a second stage without writing it to disk first.

Known offensive tooling gives a much higher-confidence signal than obfuscation alone, because tool names rarely appear in production automation. ScriptBlockText containing Invoke-Mimikatz, Invoke-DCSync, PowerView cmdlets like Get-DomainUser or Find-DomainShare, or PowerSploit and Empire-style function names is close to definitive; the false-positive rate for these strings in a real production environment is close to zero outside of an authorized red team engagement, which is exactly why they should be pre-approved and whitelisted before an engagement starts.

The automatically Warning-tagged events deserve a slightly different read. Because PowerShell promotes them without any custom tuning, they are a low-effort triage queue: anything at Warning level that does not correspond to a known, approved administrative script or an authorized pentest is worth a look.

What separates a true from a false positive here is almost always the combination of account context and Path. A Warning-level 4104 fired by a help desk technician's interactive session, with no Path and content resembling a downloader, is a very different event from the same content firing under a batch job that has run identically every night for a year.

AMSI-triggering keywords, obfuscation layering (nested encoding, string concatenation designed to break signature matching), and the presence of a fragmented, multi-part script with an unusually high MessageTotal are all secondary signals that shift a borderline Warning event toward true positive, especially when two or more of them appear in the same script block.