Named Pipes

Author: Roger C.B. Johnsen

Named pipes are Windows interprocess communication endpoints. They support normal operating-system, application, RPC, and management activity, but also appear in discovery, credential access, lateral movement, and command-and-control workflows. A pipe name is context, not a verdict.

Path context

Pipes worth recognizing

The presence of samr, lsarpc, or svcctl does not prove malicious use. Windows components and administration tools use the same RPC interfaces.

High-value patterns

• One workstation accessing the same RPC pipe across many servers.
• Many identity-related pipes against a domain controller in a short window.
• ADMIN$ file transfer followed by svcctl, service installation, and SYSTEM process creation.
• Pipe activity immediately after an unusual network logon.
• A rare local pipe created by an unsigned process in a user-writable path.
• A common pipe name used by an unexpected process or account.
• Snapshot or directory enumeration followed by samr, srvsvc, and broad SMB access.
• Short-lived service and pipe activity followed by payload and service deletion.

Speed and breadth are useful features. Build separate baselines for endpoint management, backup, monitoring, vulnerability scanning, identity administration, and software deployment.

Sysmon telemetry

Sysmon coverage depends on configuration. Event 17 and 18 identify local process participation; enrich with process creation, logon, SMB, service, and network telemetry before inferring a remote action.

Defender XDR telemetry

Some tenants expose named-pipe activity through DeviceEvents with ActionType == "NamedPipeEvent" and pipe-specific values in AdditionalFields. The shape and availability can vary, so inspect the schema and sample records first:

DeviceEvents
| where Timestamp > ago(24h)
| where ActionType == "NamedPipeEvent"
| take 20
| project Timestamp, DeviceId, DeviceName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          InitiatingProcessAccountUpn,
          AdditionalFields

After confirming the local field names:

let TargetName = "TARGET-DEVICE.contoso.invalid";
DeviceEvents
| where Timestamp > ago(7d)
| where DeviceName =~ TargetName
| where ActionType == "NamedPipeEvent"
| extend Fields=todynamic(AdditionalFields)
| extend PipeName=tostring(Fields.PipeName),
         FileOperation=tostring(Fields.FileOperation),
         NamedPipeEnd=tostring(Fields.NamedPipeEnd)
| project Timestamp, DeviceName, PipeName,
          FileOperation, NamedPipeEnd,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          InitiatingProcessAccountUpn
| order by Timestamp asc

Filter remote MUP paths only after verifying how the tenant formats PipeName:

DeviceEvents
| where Timestamp > ago(7d)
| where ActionType == "NamedPipeEvent"
| extend Fields=todynamic(AdditionalFields)
| extend PipeName=tostring(Fields.PipeName)
| where PipeName startswith @"\Device\Mup\"
| summarize Events=count(),
            Pipes=dcount(PipeName),
            SamplePipes=make_set(PipeName, 10)
    by DeviceId, DeviceName,
       InitiatingProcessFileName,
       InitiatingProcessAccountUpn,
       bin(Timestamp, 5m)
| order by Events desc

Remote execution correlation

A useful sequence is:

network logon
  -> IPC$ or ADMIN$ access
  -> payload transfer
  -> svcctl or tool-specific pipe
  -> service installation
  -> child process on target
  -> service and payload cleanup

Correlate Security Events 4624, 4648, 4697, 5140, and 5145; System Event 7045; Sysmon Events 1, 3, 11, 17, and 18; and Defender device, file, network, and logon tables. Not every step is present in every telemetry source.

Triage workflow

1. Normalize the pipe path and decide whether it is local or remote.
2. Identify creator and connector processes using stable process identifiers.
3. Resolve account, integrity, logon session, source, and target.
4. Check pipe prevalence by process, device role, and peer group.
5. Correlate nearby SMB, RPC, service, task, file, and process activity.
6. Determine whether the behavior is interactive, automated, or fleet-wide.
7. Validate management tooling and change records.
8. Expand on pipe name, process hash, source account, and target set.

ATT&CK references

• T1559: Inter-Process Communication
• T1021.002: SMB/Windows Admin Shares
• T1569.002: Service Execution
• T1135: Network Share Discovery

References

• Sysmon documentation
• Defender XDR DeviceEvents schema

Revision