Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Ok first of all this is legal and I have it in writing my friend and I are attacking eachother to get better and not break the law.

Setup I have a VMWare image running BT5R3. It uses VMWare's NAT then my network is behind a router using NAT. From there I am VPN tunneled into work which also uses NAT (I believe). I've come to realize that I have only ever run metasploit from the inside or in a lab but never over the internet.

I'm pretty sure with this scenario a reverse payload wouldn't be possible since it requires the machine to connect back to me. Will this work with any payload at all?

share|improve this question
up vote 3 down vote accepted

This won't work with reverse payloads unless you can do portforwarding on the system which is NATing your traffic. Hence it's better to generate a payload which allows you to connect to it rather than a payload which connects back (but if your target is also using NAT, then this becomes obsolete as well). For instance:


This does give problems if there is a firewall between you and the target. Best thing to do is take away the NAT completely if possible. In your case this seems quite difficult...

share|improve this answer
Bind shells don't help much if there is also NAT on the target side. – buherator Jul 16 '13 at 13:19
Yea, you are a bit out of options then. – Lucas Kauffman Jul 16 '13 at 13:21
Our victim servers are honeypots connected directly to the internet so there's no NAT there just from my side. So in this scenario you're saying bind_tcp will work but reverse will not unless I can do port forwarding which is exactly what I was thinking. Thanks Lucas! – Four_0h_Three Jul 16 '13 at 13:24
I usually give it about a day before I mark as answer to allow others to chime in. – Four_0h_Three Jul 16 '13 at 13:26

You can use meterpreter/reverse_https and set LHOST to your public ip. Make sure you forward port 443 to the machine hosting metasploit.

set payload windows/meterpreter/reverse_https
set LPORT 443

"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 (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 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."


share|improve this answer
There is no public IP in this scenario. – schroeder Aug 15 '15 at 2:47
I misunderstood the question, deleting in 20'. – Pedro Lobito Aug 15 '15 at 2:53

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.