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
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
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
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.
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.
Top comments (1)
This article was curated as a part of #80th Issue of Software Testing Notes Newsletter.