21.05.2026 19:45
🧵 pipetap: Burp Suite, но для Windows Named Pipes Named Pipes в Windows — частый механизм IPC: один процесс поднимает pipe-сервер, другой подключается…
🧵 pipetap: Burp Suite, но для Windows Named Pipes
Named Pipes в Windows — частый механизм IPC: один процесс поднимает pipe-сервер, другой подключается как клиент. В security research это особенно интересно, когда привилегированный процесс принимает команды или данные через named pipe.
SensePost выпустили pipetap — инструмент для наблюдения, перехвата, редактирования и replay трафика Windows Named Pipes. По сути, это прокси и multi-tool для reverse engineering pipe-коммуникаций.
Что умеет:
🔹 перехватывать трафик через хуки Windows API
🔹 показывать payload в hex/text, включая UTF-8 и UTF-16
🔹 редактировать request/response “на лету”, в стиле Burp
🔹 replay’ить сообщения в named pipe
🔹 перечислять pipe-серверы и связанные процессы
🔹 работать с несколькими PID в одной GUI-сессии
🔹 использовать “remote client”, когда соединение с pipe инициируется не GUI, а целевым процессом
Архитектура простая: в целевой процесс инжектится support DLL, которая хукает API named pipes и передаёт события в GUI. Для хуков автор выбрал Microsoft Detours, а интерфейс сделан на ImGUI.
Особенно интересная фича — remote client. Она полезна, когда pipe-сервер проверяет, какой процесс подключается: например, валидирует PID, подпись бинаря или другие свойства клиента. В таком сценарии pipetap может инициировать подключение “изнутри” уже инжектнутого процесса, а не напрямую из GUI.
Есть и Python SDK: после инжекта DLL поднимает TCP-to-Named-Pipe proxy, к которому можно подключаться программно. Это удобно для автоматизации, fuzzing’а и сложной обработки payload’ов.
⚠️ Но есть нюанс: работа с named pipes может ломать тайминги, вызывать подвисания и deadlock’и, потому что многие приложения не рассчитаны на задержки и вмешательство в IPC. Асинхронные pipe-коммуникации в pipetap тоже пока поддержаны не полностью.
https://github.com/sensepost/pipetap
👉 @thehaking
Named Pipes в Windows — частый механизм IPC: один процесс поднимает pipe-сервер, другой подключается как клиент. В security research это особенно интересно, когда привилегированный процесс принимает команды или данные через named pipe.
SensePost выпустили pipetap — инструмент для наблюдения, перехвата, редактирования и replay трафика Windows Named Pipes. По сути, это прокси и multi-tool для reverse engineering pipe-коммуникаций.
Что умеет:
🔹 перехватывать трафик через хуки Windows API
🔹 показывать payload в hex/text, включая UTF-8 и UTF-16
🔹 редактировать request/response “на лету”, в стиле Burp
🔹 replay’ить сообщения в named pipe
🔹 перечислять pipe-серверы и связанные процессы
🔹 работать с несколькими PID в одной GUI-сессии
🔹 использовать “remote client”, когда соединение с pipe инициируется не GUI, а целевым процессом
Архитектура простая: в целевой процесс инжектится support DLL, которая хукает API named pipes и передаёт события в GUI. Для хуков автор выбрал Microsoft Detours, а интерфейс сделан на ImGUI.
Особенно интересная фича — remote client. Она полезна, когда pipe-сервер проверяет, какой процесс подключается: например, валидирует PID, подпись бинаря или другие свойства клиента. В таком сценарии pipetap может инициировать подключение “изнутри” уже инжектнутого процесса, а не напрямую из GUI.
Есть и Python SDK: после инжекта DLL поднимает TCP-to-Named-Pipe proxy, к которому можно подключаться программно. Это удобно для автоматизации, fuzzing’а и сложной обработки payload’ов.
⚠️ Но есть нюанс: работа с named pipes может ломать тайминги, вызывать подвисания и deadlock’и, потому что многие приложения не рассчитаны на задержки и вмешательство в IPC. Асинхронные pipe-коммуникации в pipetap тоже пока поддержаны не полностью.
https://github.com/sensepost/pipetap
👉 @thehaking