Nessus And Metasploit: Scan Networks In Pivoting

One of the best features that Metasploit offers is the ability of “pivoting”.  With this technique, an attacker can use a compromised machine as a “pivot” to attack other machines in the same or in other networks that the compromised host can reach. Most of the time the attacker uses this technique to infiltrate multiple computers and subnets in order to reach his ultimate goal (dumping a database, accessing isolated information…). Pivoting can be done in Metasploit, it works very well and it’s quite simple to do.

What we want to discuss today, is not exploiting machines through pivoting (that we cover in depth in our course), but how pivoting can be used, during the Post-exploitation process, to scan internal networks, not directly accessible to us.  In this post we will use Nessus as a vulnerability scanner.

DigiNinja has discussed this topic in depth before. You can find his article here:http://www.digininja.org/blog/nessus_over_sock4a_over_msf.php

During our tests we have found limitations and issues to this technique. We will show you how to configure Nessus and Metasploit and then discuss these issues.

Let’s first define the scenario and then we will go through the configuration steps.

• 199.16.45.52: is the attacker machine
• 192.168.78.5: is the compromised machine that the attacker will use for pivoting
• 192.168.78.25: is the target machine, the one the attacker wants to scan. This host is not accessible from Internet,
  hence we need to “pivot”.

Since the machines are on different networks, the attacker cannot directly communicate with the target.

Let’s start configuring the environment. The steps to get pivoting to work are the following:

1. Add a route to the target network ( within meterpreter )
2. Start a proxy on the exploited machine ( this will be used by Nessus )
3. Run Nessus service within the proxy ( tools like proxychains and tsocks work fine )

The following screenshot shows the meterpreter session on the exploited machine (192.168.75.5):

 

As we can see from the ipconfig the target network is 192.16.78.0/24. We can now add the route to the network by running the command route add as follows:

 

Let’s suppose we don’t know the what other hosts are present in the same network of our compromised machine. We can easily scan the target network using the route just added. To do this let’s run the command run arp_scanner:

 

As you can see, by adding the previous route, we are able to communicate with the target network (within meterpreter).
To be sure we can run the module auxiliary/scanner/portcscan/tcp on the target:

 

Here the traffic goes from the attacker machine (199.16.45.52), through the meterpreter session on the exploited machine (192.168.78.5) , and then from the exploited machine to the target ( 192.168.78.25). Indeed by sniffing the traffic on the attacker and the exploited machine we can confirm this:

 

The attacker communicates through meterpreter (see port 4444) with the exploited machine.

The exploited machine (192.168.78.5) performs the actual scan to the victim (192.168.78.25) and then communicates back the results to the attacker.

As per our assumption, this of course is impossible to do outside the meterpreter session. If we try to ping the target directly we get no response:

Now that we have our route to the target, we need to start a proxy server on the exploited machine and then run Nessus through it. Metasploit already comes with a module that allows us to run the proxy. This is the moduleauxiliary/server/socks4a. So let’s run it and configure it as follow:

 

This configuration will start a proxy on the localhost (0.0.0.0:1080). Now we have to configure the tool that will proxy all the traffic. We are going to use proxychains. So let’s open /ect/proxychains.conf and edit the last line with the metasploit socks4a server configuration (localhost and port 1080):

 

Now we can proxify any program. To check if it is working fine, we can run a Nmap scan to the target machine. Note thatproxychains allows only TCP tunneling, so we can’t use UDP communications . We can simply force Nmap not to perform ping scans with the option –PN. Let’s then run the following command and see if we are able to scan the target:

_____________________________________________
>>proxychains nmap –sTV –n –PN 192.168.78.25
_____________________________________________

Here is the result of the scan:

As you can see here, we are correctly performing the port scan with Nmap by tunneling all the traffic through the proxy server on the exploited machine.
Indeed we can confirm this by sniffing the traffic on both attacker and victim:

The Nmap scan goes through the proxy on the meterpreter session

The victim (192.168.78.5) performs the real scan on the target machine (192.168.78.25)

So, now that we know that the tunnel works, we can start Nessus the same way we did for Nmap. So let’s type the following command to start the service:

____________________________________>> proxychains nessus-service –D____________________________________

 

Now we can access the Nessus GUI from the browser as usual (https://localhost:8834). Once we are logged we can start our scan. Remember that since the proxy does not tunnel protocols other than TCP, the first thing to do before running the scan, is to disable the ping scan option in the policy configuration. If this option is enabled, the scan in pivoting will not work at all. 

At this point, we can simply run the Nessus scan as usual. Here again if we sniff the traffic on the attacker machine we will see that the scan runs through the meterpreter session ( 192.168.78.5:444):

The scan is slower than usual but, as we can see in the previous screenshot, after few minutes Nessus has found 10 vulnerabilities.

So, it seems it is working…but there are two problems:

1. We lose all vulnerability checks performed through UDP
2. (too) Many plugins will fail. Indeed if we look at wireshark, we will see that there are many packets bypassing the tunnel:

This happens because many plugins use packet forgery (raw sockets) bypassing the tunnel. So keep this in mind when you perform such scan.

Let’s see the difference between a scan performed through pivoting and one that runs without

 

Here is another screenshot of the scan results performed with the same technique, but on a different target:

In conclusion, this is a very useful advanced technique! Any Penetration tester should be able to mount a Vulnerability scan in pivoting using Nmap and Metasploit, keeping in mind the limits of the technique.