Your Windows PC is constantly running dozens — sometimes hundreds — of processes.

One program needs to talk to another.

A service needs to communicate with an application.

A privileged process needs to exchange information with a user-mode process.

Windows needs a way to make all of this happen.

One of the mechanisms it uses is called Named Pipes.

And most Windows users have probably never heard of them.

That makes them particularly interesting from a cybersecurity perspective.

Named Pipes are legitimate Windows technology used for inter-process communication (IPC). But like many powerful operating-system features, they can also appear in malware, security research, lateral-movement techniques, and other attack chains.

Microsoft describes a named pipe as a named, one-way or duplex communication channel between a pipe server and one or more clients. Named pipes can operate locally or, under the right conditions, across a network.

In other words:

A Named Pipe is essentially a private communication channel that Windows processes can use to talk to each other.

The interesting part?

That communication channel has a name, permissions, processes, connections, and security boundaries.

Which means defenders can investigate it.

And attackers can sometimes abuse it.

What Exactly Is a Windows Named Pipe?

Let’s start with the simplest possible explanation.

Imagine two applications:

Application A
     |
     |  "Send this data"
     v
  Named Pipe
     |
     |  "Received"
     v
Application B

Application A writes information into the pipe.

Application B reads it.

Neither application necessarily needs to communicate through a normal file.

Instead, Windows provides an IPC mechanism specifically designed for this kind of communication.

Microsoft supports named pipes through APIs such as:

CreateNamedPipe()
ConnectNamedPipe()
CreateFile()
CallNamedPipe()

The application creating the pipe is generally called the:

Pipe Server

The application connecting to it is generally called the:

Pipe Client

A process can also act as both.

Why Are Named Pipes Needed?

Modern operating systems constantly have processes communicating with one another.

For example:

Browser
   ↓
Windows Service
   ↓
System Component
   ↓
Another Process

Applications might need to exchange:

• Commands
• Status information
• Data
• Authentication information
• Results
• Notifications
• Synchronization messages

Named Pipes provide a convenient mechanism for this.

They can also support communication between processes that aren’t related as parent and child.

Microsoft distinguishes this from anonymous pipes, which are commonly used for communication between related processes such as a parent and child. Named pipes can communicate between unrelated processes and can also support communication across computers.

What Does a Named Pipe Look Like?

On Windows, named pipes commonly appear under:

\\.\pipe\

For example:

\\.\pipe\example

The . means the local computer.

A remote named-pipe path can use:

\\ComputerName\pipe\PipeName

Microsoft documents this naming format for named pipes.

So conceptually:

\\.\pipe\MyApplication

means:

Local computer
      ↓
Named pipe namespace
      ↓
MyApplication

Named Pipes Are Not Files

This is an important distinction.

A path such as:

C:\Users\User\file.txt

refers to a file stored on disk.

But:

\\.\pipe\MyPipe

doesn’t represent an ordinary file sitting inside a folder.

It’s an operating-system communication endpoint.

Think of it more like:

Socket

than:

Text file

although Windows implements and manages it differently.

Named Pipes Can Be One-Way or Two-Way

Named pipes can operate in different modes.

One-way communication

Process A
   |
   v
Named Pipe
   |
   v
Process B

Process A sends information.

Process B receives it.

Duplex communication

Both sides can communicate.

        ┌───────────────┐
        │  Named Pipe   │
        └───────────────┘
          ↑           ↓
       Process A ↔ Process B

This makes named pipes useful for applications that need continuous communication.

Why Should Cybersecurity Researchers Care?

Because IPC is part of the security boundary of an operating system.

A normal application may use a named pipe for completely legitimate reasons.

But security researchers may ask:

Which process created this pipe?

Who can connect to it?

What privileges does the server have?

Is the pipe local or remotely accessible?

Is an unexpected process communicating through it?

Is the pipe associated with suspicious process behavior?

That turns a seemingly obscure Windows feature into a valuable investigation source.

The Security Problem: Permissions

Here’s where things become interesting.

Named pipes have security descriptors and access controls.

Microsoft documents that access to named pipes can be controlled using security descriptors and ACLs. Windows performs access checks when processes attempt to connect or obtain handles to pipes.

Conceptually:

Process
   |
   | Request access
   v
Named Pipe
   |
   v
Security Descriptor
   |
   ├── Allowed
   │
   └── Denied

This matters because a poorly secured IPC channel can potentially expose sensitive functionality to processes that shouldn’t have access.

A Simple Security Scenario

Imagine a privileged Windows service.

Suppose:

Service
  |
  | Runs with elevated privileges
  |
  └── Named Pipe

And suppose an ordinary user process can communicate with that pipe.

The security question becomes:

What does the service do with messages received through the pipe?

If the service blindly trusts requests from unauthorized clients, the IPC boundary can become dangerous.

For example, an insecure design might conceptually look like:

Low-privileged process
        |
        | "Perform operation X"
        ↓
Privileged service
        |
        ↓
Operation performed

The underlying vulnerability isn’t necessarily “named pipes are insecure.”

The problem is:

The application trusted an IPC client that it shouldn’t have trusted.

Named Pipe Impersonation

One particularly important Windows capability is impersonation.

A named-pipe server can potentially impersonate the client under certain conditions.

Microsoft documents the ImpersonateNamedPipeClient functionality, which allows a server thread to assume the security context of a connected client, subject to Windows impersonation rules.

Conceptually:

Client
   |
   | Connects
   ↓
Named Pipe Server
   |
   | Impersonates client
   ↓
Client security context

Why does this matter?

Because Windows security is heavily based on security tokens and identities.

If a program handles impersonation incorrectly, security boundaries can become complicated very quickly.

This is one reason named-pipe security deserves attention during Windows security research.

Named Pipes and Privilege Escalation

Named pipes have appeared in various Windows privilege-escalation research scenarios.

The important concept isn’t:

“Named pipes automatically give administrator privileges.”

They don’t.

Instead, researchers look for situations where:

Low Privilege
      ↓
Accessible IPC Endpoint
      ↓
Privileged Service
      ↓
Unsafe Trust / Impersonation / Validation
      ↓
Security Boundary Violation

The vulnerability usually comes from the application’s implementation and its security assumptions.

The pipe itself is simply the communication mechanism.

Named Pipes and Malware

Malware can also use named pipes.

Why?

Because malware often needs communication between its own components.

For example:

Malware Process A
        |
        ↓
   Named Pipe
        |
        ↓
Malware Process B

This allows separate components to exchange information.

MITRE ATT&CK documents real-world malware and intrusion activity involving pipes and IPC mechanisms, including examples where malware used Windows named pipes for communication between components.

That doesn’t mean:

Named Pipe = Malware

Absolutely not.

Windows itself and legitimate applications use named pipes extensively.

The useful security question is:

Is this pipe expected for this process and this environment?

The 3CX Supply-Chain Example

MITRE ATT&CK documents the 3CX supply-chain attack as an example involving Windows named pipes.

The malware associated with the incident created and listened on a Windows named pipe to exchange messages between components.

This illustrates an important defensive principle:

IPC activity can become part of a malware behavior chain.

A defender shouldn’t investigate only:

.exe files

They should also understand:

Process
 ↓
Parent Process
 ↓
Network
 ↓
Files
 ↓
Registry
 ↓
IPC
 ↓
Named Pipes

How Attackers Can Hide in Normal Windows Functionality

This is a recurring theme in Windows security.

Attackers don’t always need to invent a completely new technology.

They can abuse:

• PowerShell
• WMI
• COM
• Scheduled Tasks
• Services
• DLL loading
• Named Pipes
• Windows APIs

The underlying technology can be completely legitimate.

The suspicious part is often the context.

For example:

Normal:
Trusted Service
     ↓
Expected Named Pipe
     ↓
Expected Client

versus:

Suspicious:
Unknown Process
     ↓
Unexpected Named Pipe
     ↓
Privileged Process

Context is everything.

How to List Named Pipes on Windows

One of the easiest ways to investigate named pipes is through PowerShell.

Open PowerShell and try:

Get-ChildItem \\.\pipe\

You may see output containing pipe names.

Depending on the system, there can be many entries.

For example:

\\.\pipe\InitShutdown
\\.\pipe\lsass
\\.\pipe\spoolss
\\.\pipe\...

Don’t immediately assume an unfamiliar pipe is malicious.

Windows and installed software can create many legitimate pipes.

The goal is investigation, not blindly deleting things.

Search for a Specific Pipe

You can filter the list.

For example:

Get-ChildItem \\.\pipe\ | Where-Object {
    $_.Name -match "test"
}

Or simply:

Get-ChildItem \\.\pipe\ | Select-Object Name

This is useful when investigating a specific application.

A Safer Lab: Create Your Own Named Pipe

You don’t need malware to understand how named pipes work.

We can create a completely harmless lab.

Python can access Windows named pipes through the Windows API.

Here’s a simple educational server example:

import ctypes
from ctypes import wintypes
kernel32 = ctypes.WinDLL("kernel32", use_last_error=True)
PIPE_ACCESS_DUPLEX = 0x00000003
PIPE_TYPE_MESSAGE = 0x00000004
PIPE_READMODE_MESSAGE = 0x00000002
PIPE_WAIT = 0x00000000
CreateNamedPipe = kernel32.CreateNamedPipeW
CreateNamedPipe.argtypes = [
    wintypes.LPCWSTR,
    wintypes.DWORD,
    wintypes.DWORD,
    wintypes.DWORD,
    wintypes.DWORD,
    wintypes.DWORD,
    wintypes.DWORD,
    wintypes.LPVOID
]
CreateNamedPipe.restype = wintypes.HANDLE
pipe_name = r"\\.\pipe\SpyboySecurityLab"
pipe = CreateNamedPipe(
    pipe_name,
    PIPE_ACCESS_DUPLEX,
    PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT,
    1,
    1024,
    1024,
    0,
    None
)
if pipe == wintypes.HANDLE(-1).value:
    raise ctypes.WinError(ctypes.get_last_error())
print("Named pipe created:")
print(pipe_name)
print("PID:", __import__("os").getpid())
print("Press Ctrl+C to exit.")
try:
    while True:
        pass
except KeyboardInterrupt:
    kernel32.CloseHandle(pipe)

This is simply a learning exercise demonstrating the Windows API.

It doesn’t exploit another process.

It doesn’t steal credentials.

It doesn’t bypass security.

It simply creates a named pipe.

⚠️ Important: Use This Only on Your Own Lab

When researching Windows IPC:

Do not experiment against machines you don’t own or administer.

Build a small test environment instead.

For example:

Windows 11 VM
     |
     ├── Python
     ├── Sysmon
     ├── Process Explorer
     └── Wireshark

Then create your own benign processes and observe their behavior.

That’s enough to learn a huge amount.

Monitor Named Pipes With Sysmon

This is where things become much more interesting for defenders.

Sysmon provides telemetry for named-pipe activity.

MITRE documents:

Sysmon Event ID 17

for named-pipe creation and:

Sysmon Event ID 18

for named-pipe connection activity.

That gives defenders something extremely useful:

Process
   ↓
Creates Named Pipe
   ↓
Sysmon records event
   ↓
SOC investigates process

Why Event ID 17 Matters

Suppose you suddenly see:

Event ID: 17
Image:
C:\Users\User\AppData\Local\Temp\unknown.exe
Pipe:
\\.\pipe\RandomPipe123

That doesn’t automatically mean malware.

But it gives you something to investigate.

Ask:

1. What process created it?

unknown.exe

2. Where is the executable located?

AppData\Local\Temp

3. Is it signed?

4. What launched it?

5. What other processes did it contact?

6. Did it make network connections?

7. Did it create additional files?

8. Does the pipe name match known application behavior?

This is how security analysts turn one event into an investigation.

Named Pipe Detection Should Be Behavioral

A bad detection rule might be:

IF named pipe exists
THEN malware

That’s useless.

There are many legitimate named pipes.

A better detection approach combines multiple signals:

Suspicious Process
      +
Unusual Named Pipe
      +
Unexpected Parent Process
      +
Privilege Anomaly
      +
Network Activity
      +
Persistence

Now the signal becomes much stronger.

MITRE’s detection guidance similarly emphasizes correlating named-pipe activity with unusual process relationships and other suspicious execution behavior rather than treating IPC activity alone as malicious.

Example Detection Logic

Imagine this:

WINWORD.EXE
    ↓
powershell.exe
    ↓
unknown.exe
    ↓
Named Pipe
    ↓
External Network Connection

Each event alone might have an explanation.

Together?

That’s worth investigating.

A SOC analyst could correlate:

Process Creation
+
Named Pipe Creation
+
Network Connection
+
Persistence

to create a behavioral detection.

What About Remote Named Pipes?

This is another important detail.

Named pipes aren’t necessarily restricted to the local machine.

Windows supports named-pipe communication between computers.

A path can look conceptually like:

\\SERVER01\pipe\Example

Microsoft notes that when the Windows Server service is running, named pipes can be accessible remotely, depending on configuration and permissions.

That means defenders should consider:

Local IPC

and:

Remote IPC

as separate investigation scenarios.

The IPC$ Connection

Windows networking also has a special administrative share associated with IPC:

IPC$

Conceptually:

Client
   |
   ↓
SMB
   |
   ↓
IPC$
   |
   ↓
Named Pipe

This mechanism is part of Windows network communication and administration.

But it also means remote IPC deserves careful monitoring in enterprise environments.

Unexpected remote access involving privileged services should be investigated according to the environment’s baseline.

Why Named Pipes Can Be Difficult to Investigate

There’s a simple reason:

There can be a lot of legitimate activity.

A Windows system may have:

Dozens
or
Hundreds

of normal IPC interactions depending on the installed software and workload.

Therefore:

Unknown ≠ malicious

This is one of the most important rules in security analysis.

Don’t Delete Random Pipes

If you’re investigating a suspicious system, don’t do this:

"That pipe looks strange."
↓
Delete/kill everything related to it.

You can accidentally break:

• Windows services
• Applications
• Authentication components
• Printing
• Security software
• Enterprise software
• Remote-management tools

Instead:

Observe
 ↓
Identify owner
 ↓
Identify process
 ↓
Understand communication
 ↓
Correlate telemetry
 ↓
Contain if necessary

Named Pipes vs Sockets

Here’s a simplified comparison:

The important lesson is:

The communication mechanism isn’t the threat.

The behavior using it can be.

Named Pipes vs Anonymous Pipes

Microsoft describes anonymous pipes as commonly being used for parent/child process communication, while named pipes support communication between unrelated processes and computers.

How Security Researchers Investigate Named Pipes

A useful investigation workflow is:

1. Enumerate pipes
        ↓
2. Identify suspicious names
        ↓
3. Identify creating process
        ↓
4. Inspect parent process
        ↓
5. Check process privileges
        ↓
6. Inspect network connections
        ↓
7. Review Sysmon telemetry
        ↓
8. Check persistence
        ↓
9. Determine whether behavior is expected

This is far more reliable than simply searching for “malicious pipe names.”

Tools You Can Use

1. PowerShell

Good for quick enumeration.

Get-ChildItem \\.\pipe\

2. Sysmon

Excellent for collecting named-pipe telemetry.

Important events include:

Event ID 17
Event ID 18

MITRE specifically identifies Sysmon Event IDs 17 and 18 as useful named-pipe telemetry sources.

3. Process Explorer

Useful for investigating:

Process
PID
Parent process
Handles
Loaded components

4. Process Monitor

Procmon is particularly useful when you need to observe what a process is doing in real time.

You can investigate activity around:

Process
File system
Registry
Network

and correlate that with your named-pipe investigation.

5. EDR

Enterprise EDR products can correlate:

Process tree
+
IPC
+
Network
+
Authentication
+
Persistence

This is much more powerful than looking at one artifact independently.

A Practical Windows Security Lab

If you’re learning Windows security, build this:

Windows 11 VM
       |
       ├── Sysmon
       ├── Process Explorer
       ├── Process Monitor
       ├── PowerShell
       └── Python

Then:

Step 1

Create your own named pipe.

Step 2

List pipes:

Get-ChildItem \\.\pipe\

Step 3

Identify your test pipe.

Step 4

Generate Sysmon telemetry.

Step 5

Find the creating process.

Step 6

Study the process tree.

Step 7

Compare your controlled activity with normal Windows behavior.

This gives you practical experience without needing malware.

What Defenders Should Monitor

Organizations should consider monitoring for:

Unexpected named-pipe creation

Unknown executable
       ↓
Creates pipe

Suspicious process relationships

Office application
       ↓
Script interpreter
       ↓
Unknown process
       ↓
Named pipe

Privileged services communicating with unexpected clients

Especially when:

Privilege level
        +
IPC
        +
Unexpected process

appear together.

Remote IPC

Investigate unusual remote named-pipe communication, particularly when it involves privileged systems or accounts.

Pipe names that don’t match the application

Random-looking names aren’t automatically malicious, but they can be a useful signal when combined with other evidence.

Common Mistakes

Mistake #1: Assuming Every Named Pipe Is Malicious

Wrong.

Named pipes are a normal Windows feature.

Mistake #2: Hunting Only by Pipe Name

Attackers can change names.

A better detection strategy focuses on:

Process
Behavior
Privilege
Parent/child relationship
Network activity
Persistence

Mistake #3: Ignoring Permissions

The most important question isn’t always:

“What is this pipe called?”

It can be:

“Who is allowed to interact with it?”

Microsoft’s documentation emphasizes that named-pipe access is controlled through security descriptors and ACLs.

Mistake #4: Looking at IPC Without Process Context

A pipe by itself tells you very little.

A pipe plus:

Unknown executable
+
Suspicious parent
+
Unexpected privilege
+
Network connection

tells you much more.

Can Named Pipes Be Used for Lateral Movement?

Potentially, yes.

Because Windows supports named-pipe communication across computers, remote IPC can appear in legitimate administration as well as adversarial activity.

This is why network defenders shouldn’t treat:

SMB
IPC$
Named Pipes

as isolated technologies.

They can form part of a broader Windows communication and authentication chain.

The Bigger Lesson

Named Pipes teach one of the most important concepts in cybersecurity:

Legitimate functionality can become an attack surface.

Windows doesn’t need to have a vulnerability for this to happen.

A developer might create:

Privileged Service
       ↓
Named Pipe
       ↓
User Application

and accidentally trust the wrong client.

A security engineer might discover:

Weak ACL

A malware author might use:

Named Pipe

to allow two components to communicate.

A SOC analyst might detect:

Unexpected pipe
+
Suspicious process
+
Abnormal network behavior

Same technology.

Completely different context.

Windows Named Pipes Security Checklist

If you’re auditing a Windows environment, check:

IPC

• What named pipes are active?
• Which processes create them?
• Which processes connect to them?
• Are any accessible remotely?
• Are privileged services involved?

Permissions

• Are ACLs appropriately restrictive?
• Can unintended users access the pipe?
• Are anonymous or broad permissions necessary?
• Are service boundaries clearly defined?

Monitoring

• Is Sysmon deployed?
• Are Event IDs 17/18 collected?
• Are suspicious process relationships detected?
• Is remote IPC monitored?
• Are unusual privileged interactions investigated?

Application Security

• Does the server authenticate clients appropriately?
• Does it validate input?
• Does it safely handle impersonation?
• Does it expose privileged operations unnecessarily?
• Does it fail securely?

Frequently Asked Questions

What is a Windows Named Pipe?

A Windows Named Pipe is an inter-process communication mechanism that allows applications and services to exchange data. Named pipes can support local communication and, under appropriate configurations, communication between computers.

Are Named Pipes dangerous?

Not inherently.

They are a legitimate Windows technology.

The security risk depends on how applications configure permissions, authenticate clients, process input, and use the communication channel.

Can malware use Named Pipes?

Yes.

MITRE ATT&CK documents multiple malware examples involving pipes and IPC.

But finding a named pipe does not mean you’ve found malware.

How do I view Named Pipes?

On Windows, PowerShell can enumerate the local pipe namespace:

Get-ChildItem \\.\pipe\

What Sysmon event detects Named Pipes?

Sysmon Event ID 17 records named-pipe creation and Event ID 18 records named-pipe connection activity.

Can Named Pipes be accessed remotely?

Yes. Windows supports remote named-pipe communication, subject to configuration, services, networking, and access controls.

Can Named Pipes be used for privilege escalation?

They can become part of privilege-escalation vulnerabilities when a privileged service exposes an IPC interface with unsafe permissions, authentication, impersonation, or request handling.

The named pipe itself does not magically grant privileges.

Final Thoughts

Windows is full of technologies most users never see.

Named Pipes are one of them.

They’re invisible to the average user.

You won’t normally find a giant:

NAMED PIPE ACTIVE

notification on your desktop.

But behind the scenes, Windows applications and services can use these communication channels constantly.

And from a security perspective, they can provide valuable clues.

A suspicious pipe doesn’t automatically mean compromise.

A strange process doesn’t automatically mean malware.

But when you connect the dots:

Unknown Process
       ↓
Unexpected Named Pipe
       ↓
Suspicious Parent
       ↓
Unexpected Privileges
       ↓
Network Activity
       ↓
Persistence

you can start seeing the bigger picture.

That’s the real skill in cybersecurity.

Not memorizing a list of “hacker tricks.”

Not assuming every unusual artifact is malicious.

It’s learning how normal systems work well enough that abnormal behavior becomes visible.

Windows Named Pipes are a perfect example.

Understand the mechanism.

Understand the permissions.

Understand the processes.

Understand the telemetry.

Then investigate the behavior.

Think Like an Attacker. Investigate Like a Defender. Secure Like a Pro.