I am testing some exploits over WAN with a port-forwarded server and am attempting to use a specific exploit module with the payload being a windows/meterpreter/reverse_tcp shell. This is all executed within the metasploit console and not by physically generating a payload using msfvenom.

Since I do not want to port-forward my own router to my computer's IP on the 'attacker' side, I have chosen to use ngrok's IP and port as LHOST and LPORT for my payload.

However, I am not able to run the exploit as the handler fails to bind to ngrok's IP. Is it possible to specify 2 different LHOSTS for the payload and the handler so that I am able to listen on my own correct IP while telling the payload to connect back to ngrok's forwarding IP?

  • How are you able to connect to the target to exploit? And why do you want to do all this from the console? Why not just start the listener separately? – schroeder Jul 13 '20 at 14:26
  • the target is a simple HTTP server I've port forwarded on WAN on a different public IP. When I run the exploit with the chosen payload it immediately tries to bind a handler on ngrok's IP and fails. I was thinking if there was a way to start the listener separately? – Cheese Lord Jul 13 '20 at 14:40
  • When I run netstat on the server I'm trying to run the exploit on, I am able to see a connection. However, the status is CLOSE_WAIT. – Cheese Lord Jul 13 '20 at 14:43
  • Ok, hold on. I think you've got some network troubleshooting to do on the target side. If your target can't connect to ngrok, then it's way too early to be thinking about the handler. Have you confirmed that the target can connect to ngrok? This is looking like a simple networking issue, not a security issue or even a metasploit issue. – schroeder Jul 13 '20 at 14:48
  • Yeah, we can both ping the specific ip and port ngrok has assigned to us, when we start the exploit, we are able to see a netstat session on both attacker and server side but for some reason a shell is not started and metasploit tells me that the handler failed to bind. – Cheese Lord Jul 13 '20 at 14:55

It turns out I had to use another metasploit session to run multi/handler on the correct port as the first session was trying to bind my listening port wrongly as the ngrok given port and my listening port was different. All I had to do was to use another handler to listen on my loopback address + local listening port.

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.