Detecting Malicious Activity via Windows Named Pipe Telemetry

Adversaries frequently rely on Windows named pipes for inter-process communication (IPC). Whether passing commands between a stager and a beacon, executing lateral movement via remote management protocols, or performing token impersonation attacks (ImpersonateNamedPipeClient), named pipes leave distinct footprints.

Because many offensive frameworks rely on default or semi-predictable naming structures when creating pipes, monitoring named pipe events provides some of the highest-fidelity detection engineering opportunities available on Windows endpoints.

Telemetry Sources for Named Pipes

Native Windows Security Event Logging does not capture named pipe creation by default without complex Object Access auditing configurations that create significant performance overhead. To get actionable telemetry, you need dedicated endpoint logging:

1. Sysmon Event ID 17 (PipeCreated): Triggers whenever a process creates a new named pipe.
2. Sysmon Event ID 18 (PipeConnected): Triggers when a connection is established to an existing named pipe.
3. ETW (Microsoft-Windows-Kernel-File): Captures file system operations, including FileCreate events targeting the \Device\NamedPipe\ device object.

For detection engineering, focus first on Pipe Creation (Event ID 17). Pipe Connections (Event ID 18) generate significantly higher volume and are best reserved for targeted threat hunting or forensic triage.

High-Fidelity Detection Indicators

When analyzing named pipe creation logs, look for four main categories of anomalies:

1. Default C2 Framework Pipe Patterns

Offensive toolkits often use hardcoded or structured templates for named pipes. While sophisticated operators alter these configurations, many default profiles remain untouched in the wild:

• Cobalt Strike default patterns (\cobaltstrike-, \mojo.5688.8052., \postex_)
• Empire default patterns (\spacecom, \lsadump)
• PsExec default service pipe patterns (\psexec-)
• Metasploit meterpreter default GUID-like strings

2. Anomaly: Script Interpreters Creating Pipes

Legitimate named pipes are typically generated by compiled binaries running as system services (e.g., services.exe, lsass.exe, svchost.exe) or complex desktop software (browsers, IDEs).

A user-mode script engine—such as powershell.exe, wscript.exe, cscript.exe, or mshta.exe—creating a named pipe is almost always suspicious. It usually indicates an in-memory execution payload, reflective DLL loading, or a custom C2 channel attempting IPC.

3. Anomaly: Suspicious Image Path Locations

Pay close attention to the executable path (Image) initiating the pipe creation. If a binary residing in C:\Users\...\AppData\Local\Temp\, C:\ProgramData\, or C:\Windows\Tasks\ creates a named pipe, elevate the alert severity. Legitimate core Windows binaries creating pipes reside almost exclusively in C:\Windows\System32\ or C:\Program Files\.

Building the Detection Logic

Here is an abstract detection strategy targeting Sysmon Event ID 17:

Sysmon_Event_17
| where PipeName !startswith "\\Device\\NamedPipe\\"
| extend Executable = tolower(Image), Pipe = tolower(PipeName)
| where 
    Pipe matches regex @"\\(cobaltstrike|psexec|postex|status_[0-9a-f]{8})"
    or Executable endswith "\\powershell.exe"
    or Executable endswith "\\cmd.exe"
    or Executable endswith "\\rundll32.exe"
    or Executable endswith "\\regsvr32.exe"
    or (
        Executable matches regex @"\\(appdata|temp|programdata|public)\\" 
        and not (Pipe startswith "\\chrome." or Pipe startswith "\\edge.")
    )

Baseline and Suppression Tuning

Every enterprise environment has software quirks. Before deploying named pipe detection rules into production blocking or high-priority alerting states, expect to tune out legitimate edge cases:

• Chromium-based Browsers: Chrome and Edge generate dynamic named pipes (e.g., \mojo.5688.8052.1234) per process tree. Whitelist these by pairing the specific browser binary path (C:\Program Files\Google\Chrome\Application\chrome.exe) with its expected regex pattern (\\mojo\.\d+\.\d+\.\d+).
• Developer Tooling: Developer environments using local RPC services (such as Docker, VS Code extension hosts, or local Kubernetes clusters) regularly spawn named pipes from non-standard paths. Filter these out based on signed code signatures or parent-child process relationships rather than broad path exclusions.

Focus your detection efforts on the process-to-pipe relationship. An unusual process creating a standard pipe name is just as dangerous as a standard process creating an offensive pipe name.

Photo by Luke Chesser on Unsplash.