Named pipes as a C2 channel: hunting the pivot with Sysmon EID 17 and 18

A named pipe is just an inter-process communication channel with a name, and Windows uses thousands of them for entirely mundane things: RPC, printing, service control, the stuff that makes the OS work. That ubiquity is exactly why offensive tooling likes them. A beacon that links to another beacon over SMB, or a PsExec-style tool that shuttles command output back to the operator, can do it over a named pipe and blend into a category of activity that is both enormous in volume and invisible to anything watching the network, because the traffic never leaves the SMB session or, for a local link, never touches the wire at all.

So the network sensor is out. The catch lives on the host, in two Sysmon events most people leave off because of the volume.

What EID 17 and 18 give you

Sysmon Event ID 17 fires on pipe creation and Event ID 18 on pipe connection, and both record the pipe name and the process that owns the operation. That pairing, name plus owning image, is the raw material. The reason people disable these events is the same reason they disable image-load logging: unscoped, they are among the loudest things Sysmon emits. The reason to keep them, scoped, is that named-pipe C2 has nowhere else to hide.

You are hunting two things in that stream: pipe names that shouldn’t exist, and ordinary-looking pipes owned by processes that have no business creating them.

Signal one: the pipe name

A lot of commodity tooling ships with default pipe-name patterns, and for years the fastest wins came from a deny-list of those defaults. That still catches the lazy end of the field, but I would not build the whole detection on it, because the name is a string in a config file and any operator who reads their own documentation changes it. Treat a match on a known default as high-confidence when it happens, and do not assume its absence means clean.

The more durable version is anomaly rather than signature. In a given environment the set of pipe names is large but not infinite, and it is stable. Baseline the pipe names your fleet legitimately produces over a couple of weeks, then alert on names that fall outside it, especially short random-looking or hex-like names that no product in your inventory generates. This is more work to stand up and it ages far better than any default list.

Signal two: the process that owns the pipe

The stronger half, in my experience, is the owning image. Named pipes for SMB-based lateral movement and for post-exploitation output tend to be created or connected by processes that have no ordinary reason to be doing pipe work: an injected rundll32, a spoolsv or service host behaving unlike itself, a random user-land process suddenly acting as a pipe server. Join EID 17 and 18 to the process context you already collect and the question becomes “is this owning image one that legitimately does IPC,” which is a much shorter and more stable list to reason about than the pipe names themselves.

The best catch is the correlation of the two halves with a lateral-movement context. A named pipe with an unfamiliar name, created by an unexpected process, on a host that just took a network logon it can’t explain, is the SMB-beacon pivot. That last clause ties it to the same logon-context idea I used for DCOM lateral movement, because the tooling that pivots over named pipes is frequently the same tooling that moves over DCOM and SMB.

The false positives, honestly

These events are noisy and I will not pretend otherwise. Backup agents, management software, and Windows itself create and connect pipes constantly, and some of them do it from processes that look odd until you learn them. The path through it is the boring one: baseline first, deny-list the known-good owners and names, and alert on the residue. Expect to spend a week tuning before the rule is quiet, the same tax you pay for image-load logging, and for the same reason, because you are collecting a high-volume event to catch a technique that produces no other signal.

The ATT&CK anchor is application-layer C2 over an internal channel, in the neighbourhood of Protocol Tunneling (T1572) and internal proxying, and the Sysmon side of the collection question is the same one I worked through in the Sysmon baseline. Turn EID 17 and 18 on, scope them hard, and accept that named-pipe C2 is one of the few techniques where the loud, expensive event is the only one that sees it.