web-dev-qa-db-ja.com

接続が確立された直後にリバースシェルが壊れる

現在、OSCPの準備をしています。リバースシェルに取り組んでいることはわかっています。 msfconsoleを使用してmeterpreter-sessionを取得することは問題ありませんが、試験中にmeterpreterは許可されていないため、「手動」の方法を使用します。

Msfvenomを使用して、被害者のWindows 7マシンのペイロードを作成し、正しいポートでnetcatリスナーを開き、被害者のマシンから悪質なexeファイルをダウンロードして実行すると、接続が確立されます。しかし、コマンドを入力すると、接続が閉じます。スクリーンショットでは、私が話していることがわかります。

enter image description here

何が悪いのですか？私が言ったように、まったく同じmsfvenomコマンド（windows/Shell/reverse_tcpの代わりにwindows/meterpreter/reverse_tcpを使用）とmsfconsoleのマルチハンドラーを使用すると、すべて正常に動作します。したがって、クライアントポート（ファイアウォールルールなど）の問題を排除できます。多分私は間違ったペイロードを使用しています...？

msfvenomnetcat
1
Alex

[〜＃〜] tldr [〜＃〜]：netcatリスナーでキャッチするには、windows/Shell/reverse_tcpではなく、windows/Shell_reverse_tcpを使用する必要があります。それ以外の場合は、マルチハンドラーを使用する必要があります。

Msfvenomの次の2つのペイロードを見てください。

payload/windows/Shell/reverse_tcp
Windows Command Shell, Reverse TCP Stager
Spawn a piped command Shell (staged). Connect back to the attacker
Total size: 283

Versus

payload/windows/Shell_reverse_tcp
Windows Command Shell, Reverse TCP Inline
Connect back to attacker and spawn a command Shell
Total size: 324

最初の方が小さいが、ステージングされていることも示されていることに注意してください。つまり、必要なすべてのコードをペイロード自体に詰め込むのではなく、互換性のあるリスナーに接続して残りのコードを受信するために最低限必要なものが含まれるだけなので、サイズを小さくすることができます。これはmsfconsoleのマルチハンドラーによって行われますが、netcatでは行われません。

マルチハンドラーを起動することに煩わされたくない場合は、少し大きいものの、ステージレスバージョンを使用できます。ペイロードをリストするときは、何かがステージングされていると記述されているかどうかに注意してください。また、最初のリストからステージングされたペイロードをフィルタリングすることもできます：msfvenom --list-payloads | grep -v stage[rd]

5
Yaakov Saxon