Metasploit Fundamentals (3 of 5) – Pivoting with Metasploit

This is the third in a five part series on the fundamentals of Metasploit that I wrote back in 2014.  While some of the specifics have changed over time, the series still provides a good overview for the new user of Metasploit.

Links to all of the articles are listed below:

Overview

If you’ve been following along so far with these articles you have learned about the tools and features that are included with the Metasploit Framework, and possibly even compromised a test system and opened a Meterpreter session.  This article will discuss a common next step after the initial compromise: pivoting to an internal network.

What is Pivoting

Pivoting is a term used broadly in the information security community to refer to the process of achieving one objective and then using that as the basis for achieving another objective.  That’s a pretty broad statement, so let’s examine it from the perspective of exploiting networks.  Say for the sake of argument that we have a general office that we have been asked to perform a penetration test on.  The office has two networks, one of which is used to provide guest Internet services and access and the other which is used for the office machines and servers only.

The only thing that connects the two networks is a single system named “WEAKFOOL” which is used by their IT support person to monitor both systems.  There is a router for guests which assigns addresses in the 10.10.10.0/24 range, and “WEAKFOOL” has an address of 10.10.10.20.  For the internal systems a completely separate network of 192.168.100.0/24 has been configured, and “WEAKFOOL” has a connection to that as well on a second network card.  Aside from the “WEAKFOOL” system, no other computers can see both networks, and their routers are configured to not communicate either.

In short, the only way we can get to systems in the 192.168.100.0/24 address space is through “WEAKFOOL”. This is the quintessential pivoting situation.  Our objective is to compromise “WEAKFOOL” and use that to pivot into the internal network.  We will exploit a weakness in that system and then use it to route all of the communciations we want to have with the internal systems through “WEAKFOOL”. It will become our own private router. Let’s get started.

First Steps

If you haven’t read the previous article that talks about using the Metasploit Console now would be a fantastic time to do so.  This article assumes that you have a setup similar to the one described in that article, and we’ll be referencing the same hypothetical system for this explanation.

Your first step is to compromise the target system, and establish a Meterpreter session.  You will recall that previously we walked through how to configure and exploit the EasyFTP server on a Windows XP system to establish a Meterpreter session.  Once we have that open, we are ready to start.

Identifying Internal Networks

Once we have opened that session, it’s time to determine what networks the system is capable of communicating on.  To do this, we can use two common *nix commands: “route” and “ifconfig”.  Just execute each and look to determine what networks are available.  In our example, we will assume that the output showed us that the first LAN interface has an address of 10.10.10.20 with a netmask of 255.255.255.0 and that the second LAN interface has an address of 192.168.100.55 with a netmask of 255.255.255.0.  Perfect.

Of course, we also need to know what systems are found in that internal range.  There are plenty of ways to do this, but we’ll just use a basic ARP scan for the purposes of this example.

meterpreter > run arp_scanner -r 192.168.100.1/24

[*] ARP Scanning 192.168.100.1/24
[*] IP: 192.168.100.38 MAC de:ad:be:ef:00:69
[*] IP: 192.168.100.20 MAC be:d1:5c:0l:d0:00

{etc}

Looks great.  We’ve found a few hosts that we can take a look at.  Let’s head back to our main Metasploit Console and configure a scan to take a look at them.

meterpreter > background

[*] Backgrounding session 1…

Note the session number that is reported, as we’ll need it shortly.  Of course, you can always look it up again in the future using this command:

sessions -l

Setup New Routes

As it stands right now, your Metasploit Console (and system as a whole) have no way to communicate with the 192.168.100.0/24 address range, but they DO have a connection to 10.10.10.20, which knows how to communicate in that IP address space.  Let’s tell Metasploit that it can use that system to reach that range.

We do this by adding a new route to Metasploit’s internal table.  The general syntax for this command is as follows:

msf > route add {pivot_system_internal_ip_address} {netmask} {session_id}

In our case, that would look like this:

msf > route add 192.168.100.55 255.255.255.0 1

We’ve just told Metasploit that if we are communicating to something in the 192.168.100.0/24 range it should route that through session 1.  That’s it.

The Meterpreter will handle everything else.

Scan Through Meterpreter

Now that we have our basic pivot stood up, let’s gather some more information on that internal network. A simple TCP connect scan seems like a good first step, so we’ll start with that.  You can search for a scanner of your choice, but I like the TCP port scanner as a starting point.

msf > use auxiliary/scanner/portscan/tcp
msf auxiliary(tcp) > set RHOSTS 192.168.100.55
RHOSTS => 192.168.100.55
msf auxiliary(tcp) > exploit
[*] 192.168.100.38:80 - TCP OPEN
{etc}

Okay, so we’ve found an open TCP port 80 (standard HTTP).  Let’s take a look at what it might have running on that.

Exposing Routes to the Host OS

It’s quite likely that you will find something on an internal network that you will want to use tools outside of Metasploit for.  In those cases, you need to be able to create a route to that internal system through Metasploit and the Meterpreter that your host operating system can use.  Let’s set one up now.

We found what is potentially a web server on 192.168.100.38 port 80 (TCP). Maybe we’d like to browse that in our web browser to quickly explore  whatever content they are hosting.  To do so, we’ll need to establish a route that our browser can use.  We do this by establishing a local port and forwarding all traffic from that to a remote IP address and port.

We do all this by configuring the Meterpreter, which automatically handles making the local port available through the Metasploit Console (this is one of hundreds of ways the Metasploit Framework makes tasks like this automatic and easy).  To do so, we will first resume the session:

msf > sessions -i 1
meterpreter >

Next, we’ll add a port forwarding from a local port to the remote address and port.  The syntax for this command is:

meterpreter > portfwd add -l {local_port} -p {target_port} -r {target_IP}

In our instance, that works out to this:

meterpreter > portfwd add -l 31337 -p 80 -r 192.168.100.37

That’s all there is to it.  Now from our local system we can set our browser to visit the following address:

http://127.0.0.1:31337

Metasploit has already opened a listener on the 31337 port as part of the portfwd command, so when we browse there our request is sent to Metsaploit. When it receives traffic, Metasploit automatically routes it to the specified Meterpreter session ID (1 in our case), and once the Meterpreter session receives that data it is capable of routing it to the specified destination and port.  All responses are then brought back through Meterpreter and Metasploit back to the requesting application on the local machine (in this case, our browser).  Pivot achieved!

Summary

At this point you should be comfortable using Meterpreter sessions to allow both Metasploit and the host operating system to pivot through a compromised system and gain access to internal networks.  This is a critical skill for getting the maximum utility out of Metasploit, and one that you will find yourself using time and again.  In the next article we’re going to take our first venture outside of the Metasploit Console to build custom shellcode.

When we do that, we’ll be able to upload a file, exploit a vulnerability, and establish sessions without relying on the Metasploit Console (or the command line, for those that have been reading ahead).  Let’s keep going!

Comments are closed.

Create a website or blog at WordPress.com

Up ↑

%d bloggers like this: