Whispers in the Code: Inter Process Communication (IPC) and Named Pipes For Covert C2

Inter-Process Communication (IPC) refers to mechanisms that allow processes to communicate with each other within an operating system (OS). These processes can share data, coordinate actions, and synchronize their execution. IPC is crucial because processes generally run in their own isolated memory spaces, and communication between them needs to be facilitated by the OS or external mechanisms.

Why is IPC Required? What Purpose Does It Serve?

IPC is essential for building complex applications where different processes need to work together. Its primary purposes include:

• Data Sharing: Processes might need to share data to collaborate, such as a web server and its worker threads sharing network requests.
• Synchronization: IPC mechanisms help synchronize the execution of processes. For example, when multiple processes access shared resources, IPC ensures no conflicts occur, like file locks or semaphores preventing data races.
• Resource Sharing: IPC allows multiple processes to share resources like memory and files.
• Modular Design: Applications can be split into smaller, independently running components (e.g., microservices) that communicate using IPC, improving scalability and maintainability.

How Windows OS Handles IPC

Windows provides several IPC mechanisms, each with varying performance characteristics and complexity:

IPC Mechanisms in Windows:

Pipes:

• Anonymous Pipes: Used for communication between processes that have a parent-child relationship. It allows unidirectional data flow.
• Named Pipes: More flexible, used for communication between unrelated processes, and can work across networks.
• API Example: CreatePipe(), CreateNamedPipe(), ReadFile(), WriteFile().

Shared Memory (File Mapping):

• Allows processes to map a section of memory into their address space to share data.
• API Example: CreateFileMapping(), MapViewOfFile(), UnmapViewOfFile().

Message Queues:

• Allows asynchronous communication by sending and receiving messages.
• API Example: PostMessage(), GetMessage(), DispatchMessage().

Sockets:

• Typically used for communication between processes over a network but can also be used locally.
• API Example: socket(), send(), recv().

Clipboard:

• The Windows clipboard allows data to be transferred between processes using copy/paste operations.
• API Example: OpenClipboard(), GetClipboardData(), SetClipboardData().

Remote Procedure Call (RPC):

• A powerful mechanism where one process can invoke procedures or functions in another process, either locally or on a networked machine.
• API Example: RpcServerUseProtseqEp(), RpcBindingFromStringBinding(), RpcBindingFree().

Relevant Process Parameters, Syscalls, APIs:

Let’s look at how Windows handles IPC using a specific mechanism, such as Named Pipes.

Named Pipe Creation:

• A process creates a named pipe using the CreateNamedPipe() API.
• Syscall Involved: When CreateNamedPipe() is invoked, the syscall NtCreateNamedPipeFile is used internally to interact with the kernel.

HANDLE hPipe = CreateNamedPipe(
    L"\\\\.\\pipe\\PipeName",     // pipe name
    PIPE_ACCESS_DUPLEX,           // read/write access
    PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT,
    PIPE_UNLIMITED_INSTANCES,     // max instances
    512,                          // output buffer size
    512,                          // input buffer size
    0,                            // default timeout
    NULL                          // security attributes
);

Client Connection:

• Another process can connect to the pipe using CreateFile() or CallNamedPipe(). Internally, the Windows kernel handles the synchronization and locking needed to prevent data races.
• Syscall Involved: The NtOpenFile syscall is used to open the pipe.

Reading/Writing Data:

• Once the connection is established, processes use ReadFile() and WriteFile() to exchange data via the pipe.
• Syscall Involved: The NtReadFile and NtWriteFile syscalls are invoked by these APIs to handle data exchange.

Synchronization and Cleanup:

• Windows manages the lifecycle of the pipe (connection/disconnection) via the DisconnectNamedPipe() API, and the CloseHandle() API releases the resources.
• Internally, the kernel manages synchronization with events and semaphores.

Out Of all IPC Mechanisms we discussed above, a process can use any of it depending on its specific requirements. Processes will typically select one or more of the following IPC mechanisms based on factors such as:

• Data transfer requirements (e.g., large datasets or small control messages).
• Synchronization needs (e.g., sequential execution or parallel tasks).
• Security (e.g., communication within a system or across a network).
• Efficiency (e.g., speed, latency, and resource consumption).

Selection Criteria: Which One Should a Process Use?

Performance and Latency:

• Shared Memory (File Mapping) is the fastest because data doesn’t have to be serialized and transferred through OS buffers; instead, it’s directly available to the processes.
• Pipes are useful for stream-like communication with moderate performance overhead.
• Sockets tend to have more overhead, especially if used for local communication instead of over a network.

Asynchronous vs. Synchronous Communication:

• Message Queues and Pipes allow for asynchronous communication where processes do not need to wait for the other process to be ready.
• RPC provides a way to perform synchronous function calls across processes but also supports asynchronous execution.

Data Size:

• Shared Memory is ideal for large data exchanges since processes directly access the same memory region, avoiding multiple copies of the data.
• Pipes or Message Queues are typically used for small to moderate-sized messages or streams of data.

Security Considerations:

• Named Pipes and RPC support advanced security models like Access Control Lists (ACLs), which can limit which processes are allowed to communicate.
• IPC methods like Shared Memory require careful management of permissions to ensure that no unauthorized process can access the shared region.

Cross-Network Communication:

• Sockets and RPC are designed to facilitate communication between processes over a network. If the processes are on different machines, these are typically the go-to mechanisms.
• Named Pipes can also be extended across a network but are less common for that purpose than sockets.

Application Type:

• User Applications: Most commonly use Pipes, Message Queues, or Shared Memory for IPC.
• System Services: Often use RPC, as it provides a more structured and secure way for services to communicate with other parts of the system.
• Networked Applications: Use Sockets for communicating with remote machines.

Example Scenarios for Choosing IPC Mechanisms:

• A Web Server with Worker Processes: Might use Shared Memory for fast access to session data, and Named Pipes for communication between worker processes and the parent server process.
• A GUI Application: Could use Message Queues to communicate between the GUI thread and background worker threads without blocking the interface.
• Client-Server Communication: A distributed application might use Sockets or RPC for communication between a client and server over the network.

General Usage of IPC Mechanisms by core Windows Processes

1. Pipes (Anonymous & Named Pipes):

• Usage: Pipes are often used when a parent process needs to communicate with its child processes, or when unrelated processes need to exchange data in a stream or message-based fashion.
• Example Process: svchost.exe
• How It Uses IPC: svchost.exe is a system process that hosts multiple Windows services. Named pipes are often used for communication between different service host instances and client processes. For example, the Windows Remote Procedure Call (RPC) service uses named pipes to allow inter-process communication between services hosted by svchost.exe and other processes.
• IPC Mechanism: CreateNamedPipe() and ReadFile()/WriteFile() for communication between services.

Code Example

HANDLE hPipe = CreateNamedPipe(
    L"\\\\.\\pipe\\examplepipe", 
    PIPE_ACCESS_DUPLEX, 
    PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT,
    PIPE_UNLIMITED_INSTANCES,
    512, 512, 0, NULL);

2. Shared Memory (File Mapping):

• Usage: Shared memory is used for processes that need to share large datasets without the overhead of copying data back and forth between process memory spaces.
• Example Process: csrss.exe (Client-Server Runtime Subsystem)
• How It Uses IPC: csrss.exe handles the graphical user interface and some kernel-related functions in older versions of Windows. It uses shared memory for communicating large data between user applications and the kernel subsystems (such as drawing windows or managing text). Shared memory ensures efficient transfer of large amounts of data, like graphical data, without slowing down the system.
• IPC Mechanism: CreateFileMapping() and MapViewOfFile() are used for mapping shared memory.

Code Example

HANDLE hMapFile = CreateFileMapping(
    INVALID_HANDLE_VALUE,    // use paging file
    NULL,                    // default security
    PAGE_READWRITE,          // read/write access
    0,                       // maximum object size (high-order DWORD)
    256,                     // maximum object size (low-order DWORD)
    L"SharedMemoryExample"); // name of mapping object

3. Message Queues:

• Usage: Processes that require asynchronous communication where one process sends messages to another that are handled at a later time, often found in GUI-based applications.
• Example Process: explorer.exe
• How It Uses IPC: explorer.exe is the Windows shell responsible for managing the desktop, taskbar, and file explorer. It uses message queues to communicate with various system components, handle GUI events, and process user input. For example, user input events like mouse clicks are passed through message queues (PostMessage(), GetMessage()) to ensure asynchronous communication between the GUI thread and other components.
• IPC Mechanism: PostMessage() and DispatchMessage() for asynchronous message-based communication.

Code Example

PostMessage(hWnd, WM_COMMAND, (WPARAM)wParam, (LPARAM)lParam);

4. Sockets:

• Usage: Sockets are used for network communication between processes, both locally (localhost) and remotely, for example, between a client and a server.
• Example Process: lsass.exe (Local Security Authority Subsystem Service)
• How It Uses IPC: lsass.exe handles security tokens and user logins. When a client on the network requests authentication (e.g., logging into a machine remotely), lsass.exe uses sockets to communicate with network clients and authenticate them.
• IPC Mechanism: socket(), send(), and recv() for network communication between client and server processes.

Code Example:

SOCKET ConnectSocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);

5. Clipboard:

• Usage: The clipboard is used for inter-process data sharing through user interactions, such as copy-pasting content between two applications.
• Example Process: dwm.exe (Desktop Window Manager)
• How It Uses IPC: dwm.exe manages the graphical effects in Windows. While it doesn't directly manage the clipboard, applications that interact with dwm.exe (like Explorer or Office applications) often use the clipboard to transfer data between different user processes. The clipboard acts as shared memory that any process can access through well-defined APIs.
• IPC Mechanism: OpenClipboard(), GetClipboardData(), and SetClipboardData() for transferring data between applications via the clipboard.

Code Example:

OpenClipboard(NULL);
HANDLE hData = GetClipboardData(CF_TEXT);
CloseClipboard();

6. Remote Procedure Call (RPC):

• Usage: RPC is used when one process needs to invoke a function or method in another process, either locally or remotely. It abstracts the process of communication so that a process can call a remote function as if it were local.
• Example Process: winlogon.exe
• How It Uses IPC: winlogon.exe manages user logins and Windows sessions. It uses RPC to communicate with other core processes like lsass.exe (Local Security Authority Subsystem Service) to validate user credentials and manage user sessions. The RPC mechanism allows these processes to coordinate login activities securely.
• IPC Mechanism: RpcServerUseProtseqEp(), RpcBindingFromStringBinding(), and RpcBindingFree() for invoking remote functions between core system services.

Code Example:

RpcServerUseProtseqEp(
    (unsigned char *)"ncacn_ip_tcp", 
    RPC_C_PROTSEQ_MAX_REQS_DEFAULT, 
    (unsigned char *)"4747", 
    NULL);

Below is a summary of Example Processes and their IPC mechanisms:

IPC via Pipe Mechanism

Let’s break down the task of establishing IPC using Pipes into a detailed step-by-step approach, using one Windows core process and two external processes.

Step 1: Choosing the Processes

For this demonstration, we’ll use the following three processes:

1. Windows Core Process: svchost.exe (Service Host Process)
2. External Process 1: A custom user-created client process (we’ll simulate this using a C program).
3. External Process 2: A custom user-created server process (again, a C program or PowerShell script).

We’ll use Named Pipes for communication between svchost.exe and the two external processes and Anonymous Pipes for internal communication between the external processes.

Step 2: Understanding the Need and Practical Use of Pipes

Anonymous Pipes:

• Purpose: Used for one-way communication between a parent and child process, typically on the same machine.
• Scenario: We’ll simulate IPC between two custom user processes (external process 1 and external process 2) that interact through anonymous pipes.

Named Pipes:

• Purpose: Used for two-way communication between two unrelated processes, even across networks.
• Scenario: We’ll use named pipes to allow communication between svchost.exe (the core process) and one or both of the external processes.

Step 3: Creating and Establishing IPC with Pipes

1. Named Pipes (PowerShell)

• Server Process (svchost.exe Equivalent): Named Pipe Server

# Named Pipe Server Script (acts as svchost.exe)
$pipeName = "\\.\pipe\namedPipeExample"
$pipeServer = New-Object System.IO.Pipes.NamedPipeServerStream $pipeName

# Waiting for client connection
Write-Host "Waiting for a client to connect..."
$pipeServer.WaitForConnection()

# Reading data from the client
$reader = New-Object System.IO.StreamReader $pipeServer
$dataReceived = $reader.ReadLine()

Write-Host "Data received from client: $dataReceived"

# Clean up
$reader.Close()
$pipeServer.Dispose()

External Process 1 (Client_Reader): Named Pipe Client (Reader)

# Named Pipe Client Reader Script
$pipeName = "\\.\pipe\namedPipeExample"
$pipeClient = New-Object System.IO.Pipes.NamedPipeClientStream ".", $pipeName, [System.IO.Pipes.PipeDirection]::In

$pipeClient.Connect()

# Reading data from the pipe
$reader = New-Object System.IO.StreamReader $pipeClient
$dataReceived = $reader.ReadLine()

Write-Host "Data read from pipe: $dataReceived"

# Clean up
$reader.Close()
$pipeClient.Dispose()

External Process 2 (Client_Writer): Named Pipe Client (Writer)

# Named Pipe Client Writer Script
$pipeName = "\\.\pipe\namedPipeExample"
$pipeClient = New-Object System.IO.Pipes.NamedPipeClientStream ".", $pipeName, [System.IO.Pipes.PipeDirection]::Out

$pipeClient.Connect()

# Writing data to the pipe
$writer = New-Object System.IO.StreamWriter $pipeClient
$writer.WriteLine("Hello from the writer!")
$writer.Flush()

Write-Host "Data sent to the pipe."

# Clean up
$writer.Close()
$pipeClient.Dispose()

2. Anonymous Pipes (PowerShell)

Anonymous pipes are more commonly used for local, parent-child process communication. We will simulate it with PowerShell, where a parent process creates the pipe and two child processes communicate using it.

• Parent Process (svchost.exe Equivalent): Anonymous Pipe Server

# Anonymous Pipe Server (Parent Process)
$pipeServerRead, $pipeServerWrite = [System.IO.Pipes.AnonymousPipeServerStream]::CreatePipePair()

# Passing pipe handles to the client processes
$readerHandle = $pipeServerRead.GetClientHandleAsString()
$writerHandle = $pipeServerWrite.GetClientHandleAsString()

# Launching Client Processes
Start-Process powershell -ArgumentList "-NoExit", "-Command", "& { Start-Process powershell -ArgumentList `'$readerHandle`' -NoNewWindow -Wait; }"
Start-Process powershell -ArgumentList "-NoExit", "-Command", "& { Start-Process powershell -ArgumentList `'$writerHandle`' -NoNewWindow -Wait; }"

Write-Host "Anonymous pipes created. Waiting for data..."

# Server now reads from the pipe
$reader = New-Object System.IO.StreamReader $pipeServerRead
$dataReceived = $reader.ReadLine()

Write-Host "Data received from client: $dataReceived"

# Clean up
$reader.Close()
$pipeServerRead.Dispose()

External Process 1 (Client_Reader): Anonymous Pipe Reader

param($readerHandle)

# Anonymous Pipe Client Reader
$pipeClientReader = New-Object System.IO.Pipes.AnonymousPipeClientStream 'In', $readerHandle

$reader = New-Object System.IO.StreamReader $pipeClientReader
$dataReceived = $reader.ReadLine()

Write-Host "Data read from anonymous pipe: $dataReceived"

# Clean up
$reader.Close()
$pipeClientReader.Dispose()

External Process 2 (Client_Writer): Anonymous Pipe Writer

param($writerHandle)

# Anonymous Pipe Client Writer
$pipeClientWriter = New-Object System.IO.Pipes.AnonymousPipeClientStream 'Out', $writerHandle

$writer = New-Object System.IO.StreamWriter $pipeClientWriter
$writer.WriteLine("Hello from anonymous writer!")
$writer.Flush()

Write-Host "Data sent to anonymous pipe."

# Clean up
$writer.Close()
$pipeClientWriter.Dispose()

Understanding the Flow and Output

Named Pipes:

• The ‘server process’ creates a named pipe (\\.\pipe\namedPipeExample) and waits for the client processes to connect.
• The ‘writer process’ connects first and writes data (“Hello from the writer!”).
• The ‘reader process’ connects to the same pipe and reads the data written by the writer.
• The server displays the message sent from the writer.

Anonymous Pipes:

• The ‘parent process’ (in this case, acting as svchost.exe) creates an anonymous pipe and passes the handles to two child processes.
• The ‘writer process’ writes data to the pipe, and the ‘reader process’ reads it.
• The ‘parent process’ (the server) displays the data passed between the two clients.

Let’s break down the decision-making process behind naming processes as Client and Server and how this distinction applies to both Named and Anonymous pipes in Windows IPC.

Client vs. Server in IPC (General Concept)

In any Inter-Process Communication (IPC) mechanism:

• Server: The process that creates the communication channel (like a pipe) and waits for another process to connect to it.
• Client: The process that connects to an already existing communication channel created by the server and initiates the data exchange.

This distinction is important for understanding how IPC works because:

• The server controls the communication channel (e.g., a named pipe).
• The client leverages the server’s channel to send/receive data.

Comparison Between Named and Anonymous Pipes

Important Points

• Named Pipes are created and managed by the processes themselves (the server side), while the OS facilitates resource management and communication.
• svchost.exe (or any core process) can act as the server, creating named pipes as needed. External client processes can then communicate with svchost.exe through these pipes.
• In both cases, processes themselves are responsible for initiating pipe creation, with the OS playing a supporting role in managing the underlying infrastructure.

Simulating and Detecting Covert C2 Communication Via Pipes

Let’s simulate C2 (Command and Control) communication using Pipes (both Named and Anonymous) and explore how an attacker might use these for covert communication. For this simulation, we’ll combine Named Pipes with covert C2 techniques to create and detect such communication in a controlled scenario.

Overview of Simulation

1. Named Pipes will be used for IPC to simulate local C2 communication.
2. Covert C2 Mechanism: We’ll simulate covert communication using Named Pipes, where an attacker could use pipes to communicate stealthily between local processes without raising alarms. This could simulate a situation where a legitimate process (or even a Windows service) is compromised to communicate with a malicious payload.
3. We’ll simulate how defenders can detect suspicious communication through pipes (e.g., by analyzing pipe creation or inspecting suspicious named pipe activity).

Step 1: Define the Covert C2 Communication

C2 Mechanism: Named Pipes with Covert Channel

• Attackers might use Named Pipes for C2 communication by hiding malicious payloads and commands within legitimate process interactions.

In this case, named pipes are exploited as a local C2 channel where:

• The server process is a compromised or attacker-controlled process.
• The client processes are used to send and receive malicious commands.

Possible Techniques for Concealing C2 Communication:

• Covert Channel: The attacker can disguise C2 traffic as legitimate communication between local processes, making it difficult for detection tools to identify the threat.
• Obfuscation: Data sent over pipes can be encoded/encrypted to avoid detection.

Step 2: Create a Simulation of C2 Communication Using Named Pipes

1. C2 Server Process (Malicious Server using Named Pipe)

This server will simulate a C2 server running on the compromised machine.

# C2 Named Pipe Server (Malicious Server)
$pipeName = "\\.\pipe\CovertC2Pipe"
$pipeServer = New-Object System.IO.Pipes.NamedPipeServerStream $pipeName

# Wait for a client to connect (C2 Client)
Write-Host "C2 Server waiting for client to connect..."
$pipeServer.WaitForConnection()

# Read command sent by the attacker
$reader = New-Object System.IO.StreamReader $pipeServer
$commandReceived = $reader.ReadLine()

Write-Host "Command received from C2 Client: $commandReceived"

# Process command (Here we're simulating it by outputting to console)
Write-Host "Executing malicious command: $commandReceived"

# Clean up
$reader.Close()
$pipeServer.Dispose()

This process acts as the C2 server, which could be a legitimate system process like svchost.exe that has been compromised to accept malicious commands through the named pipe.

2. C2 Client Process (Malicious Client sending commands)

This client will simulate the C2 client sending commands to the server.

# C2 Named Pipe Client (Malicious Client)
$pipeName = "\\.\pipe\CovertC2Pipe"
$pipeClient = New-Object System.IO.Pipes.NamedPipeClientStream ".", $pipeName, [System.IO.Pipes.PipeDirection]::Out

$pipeClient.Connect()

# Send covert command to the C2 server
$writer = New-Object System.IO.StreamWriter $pipeClient
$commandToSend = "run_malware.exe" # This is the simulated malicious command
$writer.WriteLine($commandToSend)
$writer.Flush()

Write-Host "C2 command sent to server: $commandToSend"

# Clean up
$writer.Close()
$pipeClient.Dispose()

This C2 client sends a covert command (e.g., run_malware.exe) to the C2 server using the named pipe. In a real scenario, this could be a malicious implant on the system, issuing commands to execute payloads or gather information.

Step 3: Simulating C2 Detection via Named Pipe Activity

Detecting C2 activity through named pipes is challenging because attackers may use legitimate system processes or inject themselves into trusted applications. However, monitoring pipe creation and anomalous named pipe activity can be effective.

Here’s how defenders can detect such communication:

1. Detecting Named Pipe Creation (Using Sysmon or PowerShell)

Sysmon (System Monitor) can be configured to detect pipe creation events. However, for simplicity, let’s use PowerShell to monitor for suspicious named pipe activity.

# PowerShell script to monitor Named Pipe creation
$pipeName = "\\.\pipe\CovertC2Pipe"
$pipePath = "\\Device\NamedPipe\CovertC2Pipe"

Write-Host "Monitoring for suspicious Named Pipe activity..."

# This will continuously check for the existence of the named pipe
while ($true) {
    if (Test-Path $pipePath) {
        Write-Host "Suspicious Named Pipe detected: $pipeName"
        break
    }
    Start-Sleep -Seconds 1
}

This script continuously monitors for the creation of the specific named pipe CovertC2Pipe that attackers might use. When the pipe is created, it raises an alert.

2. Detecting Suspicious Pipe Usage (Sysmon Event Logs)

If you have Sysmon configured, you can monitor event ID 17 (Pipe Creation) to capture details on which processes are creating named pipes. This would help detect pipes that are used for malicious purposes.

Step 4: Implementing a Covert C2 Channel (Stealth and Encryption)

In a real-world C2 scenario, attackers would likely use encryption or obfuscation to conceal the data being sent over the pipe. For simplicity, here’s an example where we Base64 encode the C2 command to make it less obvious:

C2 Client (With Base64 Encoding):

# C2 Named Pipe Client with Base64-encoded command
$pipeName = "\\.\pipe\CovertC2Pipe"
$pipeClient = New-Object System.IO.Pipes.NamedPipeClientStream ".", $pipeName, [System.IO.Pipes.PipeDirection]::Out

$pipeClient.Connect()

# Encode command in Base64 for obfuscation
$commandToSend = "run_malware.exe"
$encodedCommand = [Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($commandToSend))

$writer = New-Object System.IO.StreamWriter $pipeClient
$writer.WriteLine($encodedCommand)
$writer.Flush()

Write-Host "C2 command (Base64) sent to server: $encodedCommand"

# Clean up
$writer.Close()
$pipeClient.Dispose()

C2 Server (With Base64 Decoding):

# C2 Named Pipe Server with Base64 decoding
$pipeName = "\\.\pipe\CovertC2Pipe"
$pipeServer = New-Object System.IO.Pipes.NamedPipeServerStream $pipeName

Write-Host "C2 Server waiting for client to connect..."
$pipeServer.WaitForConnection()

# Read command sent by the attacker
$reader = New-Object System.IO.StreamReader $pipeServer
$encodedCommandReceived = $reader.ReadLine()

# Decode Base64 command
$commandReceived = [System.Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($encodedCommandReceived))

Write-Host "Decoded Command received from C2 Client: $commandReceived"

# Process command (Here we're simulating it by outputting to console)
Write-Host "Executing malicious command: $commandReceived"

# Clean up
$reader.Close()
$pipeServer.Dispose()

Step 5: Summary of the C2 Communication Mechanism

1. Named Pipes were used as the C2 communication channel between the C2 server (a compromised or attacker-controlled process) and the C2 client (a malicious client sending commands).
2. The covert C2 mechanism hides the malicious intent by using legitimate system processes to create pipes, making detection difficult unless pipe activity is closely monitored.
3. Detection of named pipe-based C2 can be done through:

• Sysmon Event Logs (e.g., Event ID 17 for pipe creation).
• Monitoring suspicious pipe names or analyzing suspicious activity within trusted processes using PowerShell or other monitoring tools.

In a real-world scenario, defenders would need to monitor for signs of anomalous pipe usage and suspicious named pipe activity to detect covert C2 communication.