0

I have a problem with exploiting machine outside my LAN network. I tried answers from StackExchange but they didn't work for me.

My setup of exploit: ms17_010_eternalblue

RHOST = target ip and RPORT = target port

I set the payload windows/meterpreter/reverse_tcp

LHOST = my PUBLIC ip and LPORT = my forwarded port on router.

I check the port and my external ip on canyouseeme.org and it shows that port is open.

When exploit starts it says:

[-] Handler failed to bind to XXX.XXX.XXX.XXX:4444:-  -my external ip

On other sites it says that i must set payload lhost to external ip but then this error shows. Please provide command by command answer because I don't have any ideas what to do. I know that handler must be set to my internal ip because it is listening for connections, but on the other side, the target must have my external ip to connect back to me.

  • 1
    Your handler needs to be started on your internal IP. The handler has no connection to your external IP – schroeder Nov 30 '17 at 11:10
  • then that's the problem - you need to start the handler on your internal IP - your metasploit machine has no idea what your external IP is and is failing because you configured it to look for an interface with that IP – schroeder Nov 30 '17 at 11:12
  • Ok, but handler is started automaticly when exploit start. I only type my external ip in payload lhost. If i type internal ip there, then how the target will now how to connect back to me – remix30303 Nov 30 '17 at 11:13
2

You need the LHOST for the meterpreter to be your external IP and the LHOST for the handler to be the local IP. You can easily configure this when using multi_handler with the appropriate meterpreter payload (so that staging works).

Set the LHOST for multi_handler to be your external IP, run -j it in the background and then use whatever exploit you are using, setting the LHOST to your external IP and the correct meterpreter payload.

Setting the LHOST to the external IP will fail and instead, the handler will bind to 0.0.0.0.

Then run -j the exploit in the background and wait for the session to connect, then resume the session from the background.

(sessions -i sessionnumber where the session number comes from sessions -l)

Alternatively, you could use two consoles and not use background tasks.

Obiter dictum:

These additional loopholes you have to jump through are the reason why pentesting should be done without a NAT in the way.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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