What is pwncat#
pwncat is a post-exploitation framework built around reverse and bind shells, but it goes far beyond being a shell wrapper. It intercepts the raw shell stream, stabilizes the session, and then helps you enumerate the target, stage implants, and pivot into privilege-escalation workflows from your attacker machine.
For operators who care about speed and repeatability, that matters. Instead of manually fixing terminal settings, hunting for binaries, and retyping the same local-check steps on every foothold, pwncat automates the repetitive parts and gives you a module-driven workflow. It is especially useful when you want a practical handler for Linux shells and a growing set of Windows-target capabilities.
The project is written in Python and is designed to run on Linux with Python 3.9+. Windows support exists on the target side, but the operator machine is still expected to be a Linux environment.
Installation#
The recommended install path is a virtual environment on a Linux system. That keeps dependencies isolated and avoids polluting your system Python.
python3 -m venv pwncat-env
source pwncat-env/bin/activate
pip install pwncat-cs
If you prefer Poetry for a development or repeatable lab setup, clone the repository and install from source:
git clone git@github.com:calebstewart/pwncat.git
cd pwncat
poetry install
poetry shell
On BlackArch, the packaged build is straightforward:
pacman -Syu pwncat-caleb
A few installation notes are worth keeping in mind:
python3 --version
pwncat-cs --help
# If you are preparing for Windows-target work, pre-stage the built-in plugins
pwncat-cs --download-plugins
pwncat stores plugins in ~/.local/share/pwncat by default. If you are working offline or in an air-gapped lab, download the release bundle and extract it to the plugin directory before launching sessions.
macOS is not the right host platform for this workflow. If your primary workstation is a Mac, use a Linux VM or dedicated jump box for the operator side.
Basic Configuration#
At minimum, you need a listener on the attacker side and a shell connection from the target. pwncat accepts common netcat-like syntax, so the typical workflow is to bring up a handler, then point your payload at it.
A simple reverse-shell handler session usually looks like this:
pwncat-cs -lp 4444
If your build prefers explicit host/port syntax, keep the same port and bind to the interface you want to receive on:
pwncat-cs 0.0.0.0 4444
When the target connects, pwncat will try to normalize the session automatically. That usually includes:
export TERM=xterm-256color
stty rows 48 cols 160
For Windows targets, the connection should come from cmd.exe or powershell.exe, and pwncat will load its C2 components automatically when the plugins are available:
pwncat-cs --download-plugins
pwncat-cs -lp 4444
If you are operating in a restricted environment without internet access, stage the plugin set before the engagement and make sure your plugin_path points at the extracted bundle.
A minimal session workflow after connection is:
info
search enum
search privesc
run
If you are using modules interactively, you can enter a module context, inspect its options, and then execute it once the target state is clear:
use <module-name>
info
run
Common Use Cases#
1) Stabilizing a raw reverse shell#
The most common reason to reach for pwncat is to turn an unreliable shell into something you can actually work with. After the connection lands, pwncat will try to disable shell history, normalize the prompt, locate useful tools, and spawn a PTY if possible.
That helps with interactive binaries like vim, nano, top, and long-running commands that are painful in a plain TCP shell.
pwncat-cs -lp 4444
From there, use the session to verify the environment and upgrade the shell if needed:
info
search pty
run
If the PTY upgrade is successful, your terminal behaves much more like an ssh session than a raw socket.
2) Enumeration after initial access#
Once you have a foothold, pwncat’s module model is useful for quick triage. You can search for enumeration modules, inspect what they do, and run them in a repeatable way instead of manually typing ad hoc checks.
A typical flow is:
search enum
use <enumeration-module>
info
run
In practice, you want to look for modules that confirm:
hostname
kernel version
current user
sudo rules
PATH contents
interesting binaries
That information helps you decide whether the host is a good candidate for local privilege escalation, credential harvesting, or lateral movement prep.
If you are on a Linux target, make sure the shell has a sane terminal and that the session can execute common commands without line-editing issues:
export TERM=xterm-256color
stty rows 40 cols 120
3) Windows-target post-exploitation#
Windows support is newer and should be treated as alpha, but it is useful when you want a single operator workflow across both Linux and Windows footholds. The target should connect with cmd.exe or powershell.exe, and pwncat will handle the rest through its C2 plugins.
For connected or semi-connected environments, download the plugins ahead of time:
pwncat-cs --download-plugins
Then make sure the plugin bundle is present in the expected directory:
ls ~/.local/share/pwncat
If you are running in a lab with no external network, pre-stage the DLLs and verify your extraction path before the first callback. That avoids a failed session where the handler is up but the Windows side cannot fetch what it needs.
Tips and Gotchas#
pwncat is powerful, but a few operational details matter if you want reliable results.
python3 --version
- Use a Linux operator machine with Python 3.9 or newer; mismatched interpreter versions are a common source of install pain.
- Prefer a virtual environment or Poetry; it keeps dependency issues out of your system Python.
- If you are working with long-lived sessions, keep terminal settings under control. A broken
TERM, wrong window size, or missing PTY can make otherwise functional shells miserable. - If a module does not behave as expected, inspect it before running it blindly.
info
search <keyword>
use <module-name>
info
- The Windows plugin path matters. If the DLLs are not where pwncat expects them, the handler may connect but the higher-level features will not load.
- For air-gapped ops, pre-download plugins and verify the release bundle before deployment.
- The project renamed the PyPI package to
pwncat-cs, so older notes that reference the old command names may no longer match current usage. - Do not assume every target will support every automation path. pwncat tries multiple methods for PTY creation and session cleanup, but hardened hosts, stripped environments, and minimal containers can still block upgrades.
If you are building a repeatable operator workflow, test your listener command, your plugin cache, and one known-good Linux target before relying on it in a live engagement.
See Also#
Conclusion#
pwncat is a strong choice when you want more than a shell listener: it gives you session stabilization, module-based enumeration, and a path toward privilege escalation from a single interface. Advanced users who work regularly with Linux footholds and want emerging Windows support will get the most value from it.