Event ID 4103: Executing Pipeline (Module Logging)

Event 4103 is not a Security-log event at all, and that distinction matters before anything else about its content: it lives in the Microsoft-Windows-PowerShell/Operational channel, generated by the PowerShell engine itself rather than the Windows security-auditing subsystem. If your SIEM ingestion is scoped to the Security channel only, as many default configurations are, you are not collecting this event regardless of how your audit policy is configured, a gap worth checking before assuming PowerShell activity is covered.

The event comes from PowerShell's Module Logging feature, and it fires once per pipeline execution, each time a cmdlet, function, script, or external script actually runs. ContextInfo_CommandName records what was invoked, ContextInfo_CommandType records whether that resolved to a Cmdlet, Function, Script, or ExternalScript, and ContextInfo_User records the account under whose session it ran. ContextInfo_HostApplication carries the full command line that launched the PowerShell host process itself, useful context for distinguishing an interactive console session from a script launched by a scheduled task or a remote-execution framework.

Payload is the field that actually carries operational weight: it records the parameter bindings and execution details for the invoked command, which means the argument values passed to whatever ran, not just the command's name. A generic-looking Invoke-WebRequest tells you almost nothing by itself; the same event with a Payload showing a download target and a destination path tells you exactly what happened.

Module Logging's specific value, and the reason this event deserves its own coverage rather than folding into a general PowerShell writeup, is that it operates independently of Script Block Logging, event 4104. A host can have Module Logging enabled and Script Block Logging disabled, in which case 4103 is the only PowerShell telemetry available at all on that host, still naming every cmdlet invoked and every parameter passed, just without the full deobfuscated script text 4104 would otherwise capture. Environments with incomplete PowerShell-logging rollouts, which describes most large environments at some point in their maturity, frequently have exactly this gap: 4103 turned on everywhere, 4104 turned on only in pockets.

That asymmetry cuts the other way too, and it is worth checking explicitly: a host generating 4103 events with no corresponding 4104 for the same session is a visibility gap, not necessarily an attack, but one worth closing, since it means you are seeing command names and arguments without the full script context that would let you distinguish a benign automation script from an obfuscated one using the same handful of cmdlets.

Certain cmdlet and API patterns showing up in the Payload field are worth dedicated matching regardless of everything else: credential-dumping tools invoked from PowerShell, Invoke-WebRequest or .NET download methods fetching remote content, Invoke-Expression executing a string as code, and reflection-based techniques, Add-Type, System.Reflection.Assembly, used to load compiled code directly into the PowerShell process, a common way to bypass Constrained Language Mode restrictions that would otherwise block direct .NET method calls.

PowerShell is one of the most heavily used administrative tools in any Windows environment, and the honest starting point is that most 4103 volume reflects entirely legitimate automation: scheduled maintenance scripts, configuration-management tooling, and administrators doing routine work from an interactive console. Alerting on the event's existence, or even on common cmdlet names in isolation, produces far more noise than signal.

The Payload field's content is where true positives actually separate from the baseline. Matching against a known-offensive cmdlet or pattern list, credential-access tooling, remote-download-and-execute chains, in-memory reflective loading, catches a meaningful share of real activity with a manageable false-positive rate, because these specific patterns have limited legitimate use in routine administration outside of a small, identifiable set of management and deployment tools that should already be allowlisted by host and script path.

The visibility-gap check, hosts emitting 4103 with no matching 4104, is not itself a detection of malicious activity; it is an instrumentation-coverage finding that directly affects how much you should trust the absence of alerts from those hosts. Treat it as an operational finding to remediate, enable Script Block Logging everywhere Module Logging already runs, rather than a security incident, but prioritize remediating it on any host where 4103 has already shown suspicious cmdlet activity, since that is exactly where the missing full-script context would matter most.

Constrained Language Mode bypass attempts, Add-Type and direct assembly-reflection calls, deserve elevated scrutiny specifically on hosts where Constrained Language Mode is supposed to be enforced, typically non-administrative workstations in a locked-down environment. The same calls from an unrestricted administrative workstation, where Full Language Mode is expected and reflection-based scripting is routine for legitimate management tooling, carry much lower signal, which is why this specific check should always be scoped against your actual language-mode deployment rather than applied uniformly.

Context from the surrounding session matters as much as the Payload content itself. A suspicious cmdlet invocation immediately following an unusual logon, arriving via a remote-execution channel, WinRM, a scheduled task created moments earlier, a service freshly installed, or paired with other host-based indicators from the same timeframe should be escalated regardless of how common that specific cmdlet is in isolation. Conversely, the same cmdlet running on a schedule, from a known script path, under a known service account, at the same time every day, is the signature of legitimate automation and a strong candidate for an explicit allowlist entry rather than a recurring alert.