How to use Burp Suite through a socks5 proxy with proxychains and chisel

Disclaimer: For this example I used HTB's Dante Pro Labs. I don't show any exploits or attack vectors, but if you're working through the labs on your own and don't want to see anything that could even remotely be considered a spoiler, you've been warned.

Recently, I've been prepping for the OSCP and one of the major focus areas of the Penetration Testing with Kali course materials is understanding how to effectively pivot into internal subnets.

My go-to method for pivoting is through a chisel socks5 proxy. I won't go into detail here about how to set that up, but if you want a walkthrough, Ap3x Security's writeup on chisel is a fantastic resource. For the rest of this article, I'm assuming you've used the setup and configuration options from that guide.

In the lab environment I'll be working in, I've already setup my pivot, which included transfering a copy of the chisel binary onto the victim. The image below shows the victim host making a connect back to our reverse proxy, and the chisel server output confirms that connection.

With that pivot in place, we can now access the private network in the 172.16.1.0/24 range. We're going to skip the internal network enumeration step, and assume that we've found an internal host with HTTP open on port 80.

One way to access that web service is to configure FoxyProxy to route through our socks5 proxy on localhost:1080. In my FoxyProxy setup, I have 2 proxies configured, one is the default setup for Burp Suite, the other is for proxychains. Take note that the Burp Suite proxy uses HTTP, for the Proxy Type field and proxychains uses SOCKS5.

Without FoxyProxy, we can't access the internal host:

Using FoxyProxy to route traffic through our localhost:1080 proxy, we can access the internal webserver: (note that the FoxyProxy icon is green indicating the proxy is active)

While this approach does allow us to interact with the internal webserver in our browser, the major drawback to this approach is that we're unable to use Burp Suite through the pivot.

Fortunately, the solution is fairly simple. Burp Suite has a feature called Upstream Proxies, which allows us to both proxy traffic through both Burp Suite and our socks5 tunnel.

To use an upstream proxy, we'll first start by switching our FoxyProxy back to using the default Burp Suite setup.

Next, you'll need to open up the "Settings" window inside Burp Suite. You can find the button to open that in the upper right-hand corner of the application.

After the settings window opens up, with the "All" tab / button highlighted, select the "Network" option from the left sidebar dropdown, and in the main window scroll to the bottom of the page until you see the SOCKS Proxy header.

Once you've reached the SOCKS Proxy section, we can now configure Burp to work with our chisel tunnel. Before doing so, I recommend selecting the option Override options for this project only. That way if you quit Burp Suite, and open up a new project later, you avoid the headache of forgetting that the socks proxy is on and not being able to connect to any websites.

Toggling the Override options for this project only, will clear out the host and port fields, which is the reason I reccommend selecting that option before entering your proxy config.

The actual settings to configure are fairly straight forward. Type in 127.0.0.1 for the host and 1080 for the port (if you followed the chisel setup from Ap3x). Finally check the Use SOCKS proxy box, and our setup is all configured.

With that setup out of the way, we can return to our browser, and try accessing the webserver on the internal host again. If everything is setup correctly, you should be able to access the website in your browser, but this time around you should also be able to see the request in Burp Suite's proxy window too.

note that foxyproxy option is set to Burp suite this time

Back in Burp Suite we can see that the request is being logged.

Now that we have our upstream proxy setup, we can use Burp Suite against any HTTP webservers in the internal network, just like we would against ones in a public subnet.