Pivoting with Metasploit
The ability to pivot to another target or network
is a vital skill for every penetration tester.
In Port Redirection and Pivoting,
we learned various techniques to perform pivoting.
Instead of using these techniques manually,
we can also use Metasploit to perform them.
As in the previous sections, we’ll start a multi/handler listener,
and then connect to the bind shell on port 4444 on the machine ITWK01.
Let’s assume we are currently gathering information on the target.
In this step, we’ll identify a second network interface.
The output shows that the second interface has the assigned IP address.
We can try to identify other live hosts on this second network
by leveraging methods from active information gathering.
Before we do so, let’s start a Meterpreter shell on our compromised target
by downloading and executing met.exe as we did before.
Now that we have a working session on the compromised system, we can background it.
To add a route to a network reachable through a compromised host,
we can use route add with the network information
and session ID that the route applies to.
After adding the route, we can display the current routes with route print.
With a path created to the internal network, we can enumerate this subnet.
Now we could scan the whole network for live hosts
with a port scan auxiliary module.
Since this scan would take quite some time to complete,
let’s shorten this step by only scanning the other live host in the second network.
Therefore, instead of setting the value of RHOSTS to our target network_
as we normally would do, we set it to one IP address.
For now, we only want to scan ports 445 and 3389.
The output shows that the IP address has ports 445 and 3389 open.
Let’s use two modules for SMB and RDP
using our pivot host ITWK01 to perform operations on the target.
First, we’ll attempt to use the psexec module
to get access on the second target as user luiza.
In the previous section, we retrieved the NTLM hash via Kiwi.
Let’s assume we could successfully crack the NTLM hash to find the password.
For psexec to succeed, luiza has to be a local administrator on the second machine.
For this example,
let’s also assume that we confirmed this through information gathering techniques.
Let’s use the psexec exploit,
and set SMBUser to luiza,
SMBPass to her password,
and RHOSTS.
It’s important to note that the added route
will only work with established connections.
Because of this, the new shell on the target must be a bind shell
such as meterpreter bind_tcp_,
thus allowing us to use the set route to connect to it.
A reverse shell payload would not be able to find its way back to our attacking
system in most situations
because the target does not have a route defined for our network.
Now that all options are set, we can launch the module.
The output shows that we successfully used the psexec exploit module
to obtain a Meterpreter shell on the second target via the compromised machine.
As an alternative to adding routes manually,
we can use the autoroute post-exploitation module to set up pivot routes
through an existing Meterpreter session automatically.
To demonstrate the usage of this module,
we first need to remove the route we set manually.
Let’s terminate the Meterpreter session created through the psexec module,
and remove all routes with route flush.
Now the only session left is the Meterpreter session
created by executing met.exe as user luiza.
In addition, the result of route print states that there are no routes defined.
Next, let’s activate the module multi/manage/autoroute
in which we have to set the session ID as value for the option SESSION.
Then, let’s enter run to launch the module.
The output shows that autoroute added the target network to the routing table.
We could now use the psexec module as we did before,
but we can also combine routes with the server/socks_proxy auxiliary module
to configure a SOCKS proxy.
This allows applications outside of the Metasploit Framework
to tunnel through the pivot on port 1080 by default.
We set the option SRVHOST to local host,
and VERSION to 5 in order to use SOCKS version 5.
We can now update our Proxychains configuration file
to take advantage of the SOCKS proxy.
Finally, we can use proxychains to run xfreerdp to obtain GUI access
from our Kali Linux system to the target machine on the internal network.
The xfreerdp client opens a new window providing us access to the GUI of ITWK02
in the internal network via RDP.
Nice!
The output shows that we successfully connected to the second target
via RDP by pivoting.
We can also use a similar technique for port forwarding using the portfwd command
from inside a Meterpreter session,
which will forward a specific port to the internal network.
We’ll again interact with a session.
We can create a port forward with the add option,
listen from localhost on port 3389,
and forward to port 3389 on the target host.
Let’s test this by connecting to localhost and port 3389
with xfreerdp to access the compromised host in the internal network.
Using this technique, we are able to gain a remote desktop session on a host
we were otherwise not able to reach from our Kali system.
Likewise, if the second target machine was connected to an additional network,
we could create a chain of pivots to reach further hosts.