https://github.com/gabriel-sztejnworcel/pipe-intercept
The tool creates a pipe client/server proxy with a WebSocket client/server bridge. The WebSocket client connects to the WebSocket server through an HTTP proxy such as Burp.
SensePost | Pipetap – a windows named pipe proxy tool
https://github.com/sensepost/pipetap
Like I’ve mentioned, pipetap aims to be a proxy (which is really its primary feature), but it can do a lot more.
There is a support DLL injection helper. This DLL is key to the features of the GUI, so having an easy way to inject DLLs seemed necessary. The technique used is by no means stealthy, by design.
The GUI client lets you connect to multiple targets, meaning you can inject the support DLL into multiple targets too. This is quite handy when exploring multi process targets. I’ve seen some software that will juggle between 2/3 processes and various named pipes. This can be a lot to wrap your head around and one of the reasons pipetap works the way it does.
The proxy lets you export traffic in a JSON formatted document for further processing elsewhere if you need.
There is a pipelist feature that lets you enumerate available Windows named pipe servers (along with ACLs and more when enumerating in aggressive mode). Right-clicking entries lets you send parts to the appropriate tools.
It’s a pipe client in itself, meaning it can take an arbitrary named pipe name and try and connect to it. With a message composer that lets you build up string (utf8/utf16) or hex payloads, you can experiment with pipe servers. You can also import payloads generated elsewhere into the composer!
The pipe client also has a “remote client” feature. To understand this, you need to know that by default, if you connect the named pipe client, the source process making the named pipe connection will be the pipetap GUI. In the remote client case, connections come out of another process (i.e., not the GUI). To achieve this you need to start by injecting the support DLL into a remote process. Then you connect to your desired named pipe using the named pipe client by also specifying the PID of the injected process. In this configuration, the pipetap GUI will use the support DLL to initiate the named pipe connection instead of the GUI itself. This means that the named pipe server receiving the connection will think the other process initiated the client connection and not the pipetap GUI. This remote client feature has been particularly useful in cases where some hardened named pipe servers do what I’m just calling “calling PID validation”. That is, the server asks for the PID of the connecting process and does some security checks (i.e., code signature validation of the backing PE, etc.).
Speaking of named pipe clients, the support DLL also has a TCP to named pipe proxy. It is not always convenient to use a GUI to interrogate an unknown named pipe server. To that end, once injected, the support DLL will open a TCP port that can be used to programatically (and remotely) interface with a local named pipe. I added a small Python SDK to demonstrate how to connect to this server and use it here. You can get the ython client with pip install pipetap then import pipetap in your project. I’ve used this with some virtual machine snapshot restoring logic and a nasty bash script before to fuzz a named pipe. :)