Tips & Tricks

Pivoting to Attack Remote Networks Through Meterpreter Sessions and Proxychains

How to configure the tools

Once you have a Meterpreter session for a compromised machine, you can utilize Metasploit to start leveraging that machine as a proxy. This is very useful, as you will be able to run tools from your attacker system, outside the network, against systems that are local to the network you’ve compromised a single host on.

Configuring the route in Metasploit

To begin, we’re going to assume you already have an active Meterpreter session. We’ll start by backgrounding your Meterpreter session, and using the following module.
use post/multi/manage/autoroute

There will be an option where you can select the victim session.

And configure the victim’s subnet. Any traffic issued by Metasploit to an address within this subnet will be routed through the previously selected session.

You can run the following command to confirm your route has been successfully created.
route print

Configuring the Socks4 Proxy

Now that we have the route configured, we’ll switch to a different module.
use auxiliary/server/socks_proxy
set VERSION 4a

Once running, this module will forward any traffic issue to its SRVHOST and SRVPORT through the Metasploit routing table. Since we just added an entry in our routing table to send traffic through Meterpreter session 1, this should allow us the ability to utilize tools on our local attacking system. If the default port of 1080 works for you, leave the default and run the module.

Now, let’s head over to our attacker system and adjust our Proxychains configuration file.
sudo vi /etc/proxychains.conf

Adjust the last line of the file to route traffic through the Socks4 proxy listening at on port 1080 (this is the configuration of our socks4a module in Metasploit).
socks4 1080

Running tools through the proxy

Finally, we can now utilize tools on our local filesystem to interact with hosts on the remote network.
proxychains ssh root@<remoteHost>

To utilize Nmap, you’ll need additional flags. Your scan will also take longer than it would without the pivot.
sudo proxychains nmap -sT -Pn -n <targetIP> --top-ports 50

To open a web browser that routes through the proxy, you can use:
proxychains firefox

Alternatively, you could also configure your browser to route through the proxy in the advanced settings, or you could leverage a add-in, such as FoxyProxy.

Keep in mind that since we’re routing traffic through the Meterpreter session, this session needs to stay active in order for us to reach hosts on the remote subnet. Also note that some tools, such as the default Nmap scan, may not work as they would if you were scanning a target directly.

Exploitation via pivoting

Once a route has been set up in Metasploit, you can now communicate to any host that the compromised host can communicate to. Assuming you know valid user credentials (or a NTLM hash), we can leverage PSExec to gain a shell on the remote system.
use exploit/windows/smb/psexec

Before running the above mentioned module, make sure you’ve already configured a route in Metasploit that will forward traffic destined to the remote machine through your active Meterpreter session.

In the event that the remote machine you wish to target does not have access to the internet, you can add a 2nd route in Metasploit so that traffic destined to address of your existing compromised connection will route through the Metasploit routing table. This would allow you to configure the LHOST of your Meterpreter payload to the local IP address on the host of your existing Meterpreter session.

Cleaning Up

It’s always important to clean up once you’re finished. From within Metasploit, we can stop the Socks4 proxy by running the following command to kill all jobs.
jobs -K

Then you can flush the routing table entry you configured.
route flush

Hacking Tutorial

How To Route Tools (Gobuster) Through a BurpSuite Proxy

There are times where you will need to troubleshoot or route your tools through a proxy in order to get the result you need. This post will serve as a general guide for configuring BurpSuite as a proxy so you can route tools through it easily, and troubleshoot things as needed.

In this specific example, we showcase how to route Gobuster through Burpsuite so we can analyze traffic.

Table of Contents:

  • Identifying the Problem
  • Configuring Proxy in BurpSuite
  • Testing the Proxy

Identifying the Problem

On HackTheBox, there is a box called Node where you can’t use Gobuster for enumeration. When you’re able to analyze requests through a tool like Burpsuite, you can identify this early on and save a ton of time by dodging a rabbit hole.

Note: This is NOT a write-up on Node. We will not be resolving the problem of enumerating Node using Gobuster, but instead will simply use Node as an example for this blog post.

Node lives at, and has a webserver listening on port 3000. Let’s start by browsing to that webpage to see what we get once we’re connected to the HackTheBox VPN.

Anytime I see a webpage, I always like to start Gobuster to try and enumerate any directories that may be living under the hood. Let’s give that a shot.

gobuster dir -u -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt

Very quickly we get a response back that states “Error: the server returns a status code that matches the provided options for non existing urls., specify the ‘–wildcard’ switch

Specifying the --wildcard switch as it suggests in this case will just cause every page to report back with a 200 status code. Not very helpful.

gobuster dir -u -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt --wildcard

Configuring Proxy in BurpSuite

Let’s spin up BurpSuite and navigate to the Proxy tab. Let’s then go into Options, and Add a new proxy listener.

In the Binding tab, enter a Port that you’d like to use. In this case, I’ll just use 8081.

Click on the Request Handling tab. Fill out as needed.

Redirect to host: Enter the host that you wish to send traffic to. I’ll be sending my traffic to
Redirect to port: Enter the port that the host is listening on. In my case, it will be 3000.
Force use of TLS: That is not necessary in my example, but it may be a requirement for you depending on your use-case.
Support Invisible Proxying: N/A

Click OK.

The add listener screen should close, and you should be taken to the Proxy Listeners table with a new entry shown. Make sure that your new listener is Running.

Testing the Proxy

Now, let’s open a browser and see what happens when we browse to localhost on the port we specified earlier.


Great! We know our proxy is working and we’re able to route traffic through BurpSuite. Let’s do the same, but with Gobuster this time.

gobuster dir -u http://localhost:8081 -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt

We notice that we are still getting the same error message. Let’s see if we can analyze this traffic within BurpSuite and identify why. Let’s head back into Burp and select the Proxy tab. Turn Intercept On.

Let’s run the same Gobuster command again. You’ll notice the tool will spin up, but then appear to hang.

gobuster dir -u http://localhost:8081 -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt

Heading back to Burp, we have a chance to modify the request if we desire. I will go ahead and click Forward. You may need to click it a few times if multiple requests are being sent.

Gobuster still reports the same error as before, but now we have a chance to go into the HTTP History within Burp. From here, we can review the Response received from the webserver and have a chance to troubleshoot.

This proves that we are routing fully through Burp, and now have a chance to utilize some of its features while running our tools.

That’s it for this post! Again, the goal was to learn how to route tools through BurpSuite so that you can leverage all of its features. Let me know if this is at all helpful, or if there is more that you’d like me to add.