Sysmon Event ID 18

What Sysmon Event ID 18 Captures in Windows

Sysmon Event ID 18 is one of the event types that turns named pipe activity into security telemetry. In practice, it gives analysts visibility into local inter-process communication that would otherwise be easy to miss, especially when malware uses pipes to pass commands, stage data, or coordinate across processes without obvious network traffic.

Because named pipes are a normal Windows feature, the event is most useful when interpreted in context. A single pipe event is rarely enough on its own, but repeated connections, unusual pipe names, or pipe usage that aligns with suspicious process ancestry can become strong evidence of abuse.

Why Named Pipe Telemetry Matters

Named pipes are a legitimate Windows IPC mechanism, but they are also attractive to attackers because they can provide a quiet communication channel between processes on the same host. That makes them useful for malware families that want to exchange commands, move data between components, or avoid simple network-based detections. The value of Event ID 18 is that it exposes that hidden coordination layer.

Pipe telemetry is especially helpful when paired with other endpoint logs, because the security meaning usually comes from the relationship between the pipe event and the surrounding process activity. Sysmon Guide is the best starting point for understanding how Event ID 18 fits into broader Sysmon configuration, filtering and detection use cases.

The event also sits naturally alongside broader endpoint collection strategy. Endpoint Telemetry Guide explains how Sysmon, Windows auditing and related sources combine to close visibility gaps that single logs cannot cover alone.

How Analysts Use Event ID 18

Analysts use Event ID 18 to build a chain of evidence around suspicious local communication. That can include spotting a process creating an unexpected pipe, identifying a client process connecting to a pipe it should not normally touch, or linking pipe use to a parent-child process sequence that resembles malware staging or command relay.

In investigations, this event is most powerful when it helps explain behaviour that would otherwise look benign at the process level. For example, a script host, loader or dropped binary may appear ordinary until pipe activity shows it is coordinating with another component. Fileless Malware Guide is relevant here because pipe-based coordination is one of the ways fileless and living-off-the-land activity can reduce obvious on-disk indicators.

Named pipe activity also complements other Windows event sources. When event logs, process creation data and pipe telemetry are correlated correctly, the analyst can separate normal IPC from suspicious tool chaining, helper-process orchestration or local command exchange.

Detection Value and Common Blind Spots

The main detection value of Event ID 18 is that it helps reveal communication that does not rely on files, network sockets or visible user interaction. That is useful against malware that tries to keep its control flow on the same host and avoid easy signatures.

The blind spot is that pipe telemetry can be noisy in legitimate software, especially on systems with complex service architectures. Some environments create many short-lived pipes, so defenders need sensible baselines and correlation rules rather than treating every event as hostile. For that reason, the event works best as part of a broader telemetry strategy, not as a standalone indicator.

When defenders need a deeper Windows logging reference point, Windows Event Log Guide provides the surrounding event-log context that helps analysts anchor Sysmon data to other host signals.

Practical Use in Monitoring and Investigation

Event ID 18 is most useful when defenders define what “normal” pipe behaviour looks like for the endpoints they operate. That usually means understanding which applications, services and management tools legitimately use named pipes, then focusing on unusual names, rare processes, odd timing and unexpected source-destination pairings.

It is also valuable during post-incident review. If an intrusion involved local staging, lateral tooling on the host, or a malware loader chain, pipe events may help reconstruct how the components interacted after initial execution. The investigative question is not simply whether a pipe existed, but whether the pipe relationship makes sense for the process, user and system state at that moment.

For defenders who want to connect pipe telemetry to attack paths and related Windows abuse patterns, Discovery and Reconnaissance Techniques Guide helps place suspicious local communication into a broader attacker workflow, where host activity often supports later discovery, staging or execution steps.

Related resources from NHI Mgmt Group

• When is Sysmon Event ID 10 logged?
• When is Sysmon Event ID 22 logged?
• Which attacks show up in Sysmon Event ID 10?
• Which attacks show up in Sysmon Event ID 22?