Which attacks show up in Event ID 4103?

What Event ID 4103 tells you about attacker activity

event id 4103 is not an attack indicator by itself, it is a visibility point. The useful question is whether the logged module activity looks like normal administration or like a path an adversary would use for discovery, staging, or download behavior. That distinction depends on what was invoked, how often, from where, and alongside what other telemetry.

When you are trying to interpret module logging, the best first filter is context, not signature matching. Compare the module names, command patterns, parameters, user context, host role, and timing against the system’s normal PowerShell use. A single module load can be benign, but unusual parent processes, rare modules, encoded content, or unexpected remote administration patterns make the event more suspicious.

Event ID 4103 becomes more actionable when paired with other PowerShell and endpoint telemetry. PowerShell Security Guide is the most direct reference for how module logging fits with script block logging, transcription, AMSI, and common abuse patterns, while Sysmon Guide helps you correlate module activity with process creation, network connections, and image loads.

Which attack behaviors tend to surface in 4103?

The event most often exposes reconnaissance and execution support activity rather than the full attack chain. That includes enumeration of local environment details, inspection of installed modules, use of administrative or download-capable cmdlets, and execution patterns that support follow-on actions such as payload retrieval or lateral movement preparation. In practice, 4103 is often a “what ran” record that helps explain suspicious intent after another alert has already fired.

It is especially useful when an attacker tries to blend in through legitimate tooling. PowerShell module logging can surface abuse of administrative modules, command patterns that are uncommon on a given host, or repeated module imports that indicate experimentation, automation, or staged execution. Correlating this with process ancestry and network activity usually reveals whether the module use was routine maintenance or part of a broader intrusion path.

Benign administration can look similar to attack tradecraft, so the event should be interpreted against role, change window, and asset sensitivity. A jump host, deployment server, or admin workstation will naturally generate more module activity than a standard user desktop. The same event on a finance workstation, domain controller, or server with no clear administrative purpose deserves a much closer look.

How defenders should use 4103 without over-reading it

Use 4103 as a correlation anchor, not a standalone verdict. The most reliable workflow is to pair it with script block logging, process creation telemetry, and a known-good baseline of administrative module use. That combination helps separate normal automation from suspicious discovery, download, or staging behavior without assuming every unusual module load is malicious.

When a suspicious event appears, start by reconstructing the surrounding sequence: which process launched PowerShell, which user context was active, whether the host normally uses that module, and whether the commands align with a maintenance task. Windows Event Log Guide is useful for building that timeline from native Windows telemetry, especially when you need to combine PowerShell evidence with logon, service, and process events.

If you rely on 4103 operationally, make sure the logging configuration is actually enabled everywhere that matters and that log forwarding preserves the fields you need for triage. Missing module logging, weak retention, or inconsistent baselines will make suspicious activity look ordinary or make ordinary activity look suspicious.

Risk and Threat Considerations

PowerShell module logging improves visibility, but it does not prevent abuse. Attackers can use the same built-in tooling administrators use, which means the real risk is false normalisation: the more common PowerShell is in your environment, the easier it is for malicious module use to hide inside routine administration.

Failure mechanism: A hostile actor uses legitimate PowerShell modules, parameters, and administrative context to perform discovery or download activity that blends into expected operations, while defenders miss it because they are looking for a clearer malware signature.

Impact: Suspicious module activity can become an early signal of hands-on-keyboard intrusion, but only if it is correlated with process creation, script block data, and host-specific baselines; otherwise the event is easy to underuse or misclassify.

Practitioner Guidance

What to verify: Confirm that 4103 is enabled on the hosts where you expect meaningful PowerShell use, and verify that your SIEM can retain the command, module, and user context needed for correlation. If the environment cannot support that level of detail, the event will be much less useful for triage.

Decision rule: Treat 4103 as suspicious when the module or command is rare for that host, appears outside an expected change window, or is paired with abnormal parent processes or outbound network activity. Treat it as lower priority when it matches known automation and the surrounding telemetry is consistent with approved administration.

Practitioner takeaway: Event ID 4103 is most valuable when it narrows the question from “was PowerShell used?” to “was PowerShell used in a way that fits this host and this role?”

Related resources from NHI Mgmt Group

• Which attacks show up in Event ID 4624?
• Which attacks show up in Event ID 4648?
• Which attacks show up in Event ID 4625?
• Which attacks show up in Event ID 4719?