PHP2Shell、LiteLLM、Node.js：Exaforceが顧客環境で実施した脅威ハンティングの実例

通常の週の5倍を超えるハンティング量、評価した指標は130万件以上。そして、あるLiteLLMの事例では、検知から統合された修復計画の提示まで1時間39分でした。Exaforceが自動ハンティングとMDRによる調査を組み合わせ、急速に展開する3つの脅威に対して顧客ごとの対応につなげた方法を紹介します。

はじめに

同じ週に、PHP2Shell、LiteLLMのサプライチェーンに仕込まれたバックドア、Node.jsの大規模なセキュリティ更新という3つの脅威が相次ぎました。防御側に求められたのは、脆弱な状態が悪用につながる前に、顧客環境全体で影響を把握し、不審なアクティビティを調査して、対応の優先順位を決めることでした。

2026年10月18日からの週、ExaforceのMDRチームは、直前3か月の週平均と比べて5倍を超えるハンティングを実施し、中以上に分類された侵害指標（IOC）を130万件以上評価しました。Exaforce AI SOCプラットフォームが広範なハンティングを担い、MDRアナリストが判断を加えました。検出結果とエンドポイントの証拠を関連付け、環境ごとの修復計画へと落とし込んだのです。

3つのハンティングすべてで重視したのは、新しい脅威インテリジェンスを顧客ごとの具体的な対応に素早くつなげることでした。PHP2Shellでは、CVEがフィードに入ると自動ハンティングが始まり、その日の夕方までに影響のある顧客へテナント別の評価とパッチ適用の優先順位を提示しました。LiteLLMでは、MDRチームがハンティング結果とEDRの証拠を統合し、検知から1時間39分でケースと修復計画を提供しました。この調査では12台のホストにまたがる不審なアクティビティを特定しました。Node.jsでは、コードを対象とするハンティングにより、5つのリポジトリにある脆弱なコンポーネント、メジャーバージョンの更新が必要なサービス、確認が必要なパッチレベルの不明点を洗い出しました。

この記事では、実際の顧客事例を通じて、ExaforceプラットフォームとMDRチームがどのように連携し、新たな脅威への対応を支援したかを解説します。

脅威1：PHP2Shell — 緊急パッチから数時間でテナント別の評価へ

2026年10月21日、PHPはCVE-2026-109618とCVE-2026-109619に対応する緊急リリース（8.5.12、8.4.27、8.3.36、8.2.35）を公開しました。いずれもCVSSスコア9.2のメモリ安全性に関する脆弱性で、mod_php、PHP-FPMなどのリクエストハンドラーを通じて、認証なしでコードが実行される可能性があります。場合によっては、アプリケーションコードの実行前に攻撃が成立します。影響するコードパスはPHP 5.4までさかのぼります。Amazon Threat Intelligenceはその後、公開の4日前にあたる10月17日に、MadPotハニーポットで悪用の試みを観測していたと報告しました。

読者向けの追記：PHPが10月23日に公開した追加勧告では、セッションのアップロード進捗処理に残る例外的なケースへの対策として、次の通常のバグ修正リリースまでsession.upload_progress.enabled=0を維持することも推奨しています。パッチ適用時は、PHPおよび利用しているディストリビューションの最新の案内に従ってください。

Exaforceプラットフォームが実施したこと

CVEが脅威インテリジェンスのフィードに入ると、Exabotエージェントはすべての顧客テナントで侵害の有無を調べるハンティングを自動実行しました。各ハンティングは、そのテナント自身のテレメトリからPHPワークロードと悪用の兆候を探し、単一のハンティング検出結果から参照できる形で、Exaforce Threat Centerに結果を記録しました。

顧客に伝えたこと

その日の夕方までに、影響のある顧客へ、希望する連絡手段を通じてThreat Hunt Noticeを届けました。連絡手段はExaGoモバイルアプリ、Slack、Teams、メール、MDRのオンコール担当者からの連絡などです。通知では、次の点を簡潔に伝えました。

• 顧客に影響があったかどうか。
• 何を対象にハンティングし、何が見つかったか。
• 推奨する対応：WordPress環境を含め、インターネットに公開されたPHPを優先して修正し、PHP-FPMが実際に再起動したことを確認する。
• 継続する対応：新しいIOCが届くたびにハンティングを再実行する。

ハンティングの先へ

テレメトリから攻撃の兆候を見つけることはできますが、環境が攻撃にさらされているかどうかを常に判断できるとは限りません。そこで、リサーチチームは無料スキャナーExaPHP2Shellを開発し、翌朝には詳細な技術分析を公開しました。

PHP2Shellハンティングのタイムライン例

脅威2：LiteLLM — 認証情報を盗むサプライチェーン攻撃を調査

2026年10月21日、攻撃者は盗んだGitHubの認証情報を使い、トロイの木馬化したLiteLLM 1.107.0をPyPIと、公式のDocker HubおよびGHCRイメージに公開しました。このパッケージは、UTCの11時39分から13時20分までPyPIで入手可能でした。ペイロードは、LiteLLMをインポートしなくてもPythonの起動時に動作し、クラウドなどの認証情報を盗んでlitellm[.]devへ送信し、1時間ごとに動作するバックドアのループを設置するよう設計されていました。Wizはその後、認証情報の流出から約4時間半後に、盗まれたAWSの認証情報が使われる様子を観測しました。

この時間差は重要です。サプライチェーン攻撃では、インストールから認証情報の悪用までの時間が対応を左右します。

顧客事例：複数ホストにまたがる影響

ある顧客では、不正リリースの公開から4分後に、本番ホストで不審なアクティビティが現れました。公表後の8時間に5回の自動ハンティングを実行し、最後のハンティングで、そのアクティビティと攻撃との関連を特定しました。MDRアナリストはハンティング結果と顧客のEDRデータを統合し、その夜、検知から1時間39分で、修復計画を添えた単一のケースを送りました。調査結果は次のとおりです。

• 12台のホストで、Python配下のopensslを使ってファイルを隠しフォルダーにまとめる動作が見つかった。このパターンは、それまで当該テナントでは観測されていなかった。
• 4台のホスト（VM 1台とGKEノード3台）から、攻撃者のドメイン、クラウドメタデータのエンドポイント、GitHubへの通信があった。
• 追加のハンティングで4台のGKEノード上の悪意あるファイルを確認し、翌朝に隔離した。この顧客環境でのペイロードの実行とデータ流出は立証されていなかった。
• 確認すべき送信元の外向きIPアドレス、探すべきドロップファイル、ローテーションが必要なアカウント、ID、APIキーを具体的に案内した。
• 感染したホストでpip installを実行しない。Pythonの起動によってペイロードが再実行される可能性があるためだ。影響のあるノードを置き換え、VMを隔離し、フォレンジックの完了を待たずに認証情報をローテーションする。この事案では、安全と確認されたlitellm==1.106.2に固定して再構築するよう案内した。

脅威3：Node.js — コードから「どこで動かしているか」を明らかにする

同じ日、Node.jsは、重要度「高」の4件を含む10件の脆弱性を修正しました。その中には、コード実行につながる可能性があるBrotli展開処理の脆弱性CVE-2026-111497のほか、TLSホスト名検証やDNS処理の問題が含まれていました。修正版は26.12.1、24.22.1、22.23.4です。また、eMudhra中間認証局の侵害を受け、証明書の信頼情報も更新されました。設定上のランタイムバージョンを変更するだけでは不十分です。コンテナーイメージを再構築して再デプロイし、Next.jsを含むセルフホスト型アプリケーションが使うNode.jsランタイムも更新する必要があります。

ランタイムの脆弱性では、バックドアとは異なるハンティングが必要です。悪用に伴う通信が、まだ存在しない場合もあります。そこで重要になるのがインベントリです。どのサービスがどのNode.jsバージョンを使い、どのサービスが現在のリリース系列では修正できないのかを把握します。

GitHubを接続している顧客について、Exaforceはソフトウェア部品表（SBOM）とリポジトリのロックファイルを使ってこの問いに答えました。ある顧客へのハンティングレポートでは、次の点を特定しました。

• 5つのリポジトリにまたがる複数の脆弱なコンポーネント。
• 修正が提供されないサポート終了済みのNode.js 20.xを使うサービス1件。メジャーバージョンの更新が必要だった。
• Node.jsのメジャーバージョンしか固定していない複数のリポジトリ。コードからパッチレベルを確定できず、手動確認が必要だった。
• 証明書の問題に関連するエンドポイント側の対策漏れ。対象のルート証明書を引き続き信頼するcurlなどのCLIツール、古いFirefoxのインストール1件、更新が提供されないサポート終了済みのMicrosoft Windows端末が複数見つかった。

レポートでは、侵害された証明書を引き続き信頼しているエンドポイントを調べるために、MDMまたはEDR経由で配布できる1行のテストも提供しました。これにより、広範な勧告を、担当者が明確な端末一覧へと変えることができました。

仕組み：エージェントによるハンティングと人間の判断

認証前のRCE、不正なパッケージ、ランタイムのセキュリティ更新という3つの脅威は、それぞれ性質が大きく異なります。それでも、対応は毎回同じサイクルに沿って進みました。

1. インテリジェンスを自動更新する。 新しいCVE、勧告、IOCが、独自の調査結果とともにExaforceの脅威インテリジェンスフィードに入り、新しい情報に応じて継続的に更新される。
2. すべてのテナントで自動ハンティングする。 Exabotが各テナントのID、クラウド、エンドポイント、コード、SaaSデータを対象に、侵害の有無を調べるハンティングを開始する。チケットの起票やアナリストの待ち行列は不要。
3. 大量のアラートではなく、検出結果を届ける。 証拠を添え、テナントごとに1つのハンティング検出結果としてThreat Centerに記録する。
4. 人間が判断する。 MDRアナリストがヒットを確認し、関連するシグナルを1つのケースに統合する。そのうえで、どのホスト、アカウント、キーへの対応が必要か、環境に即した案内を作成する。
5. 必要な場面で顧客に対応を依頼する。 チームがノイズをトリアージし、顧客には自身の対応が必要な手順を届ける。
6. インテリジェンスの変化に応じて再実行する。 新しいIOCが公開されるたびにハンティングを再実行し、脅威の状況に応じて影響を再評価する。

この仕組みを支える要素は2つあります。まず、顧客がすでに送信しているデータを使ってハンティングするため、ゼロデイが明らかになった時点で新たに導入するものはありません。次に、調査範囲を明示することです。ある可能性を否定するためのテレメトリがテナントに不足している場合は、その点と、顧客が具体的に何を確認すべきかを通知に記載します。

まとめ

この1週間は、脆弱な状態がどれほど素早く緊急事態につながり得るかを示しました。公表前に悪用が始まることもあれば、数分で本番環境に不審なアクティビティが現れることもあります。新しい指標やセキュリティ更新が届くたびに、チームは一度きりの確認に頼らず、以前の検出結果を見直す必要があります。

Exaforceは、まさにこうした状況に対応するために設計されています。新しいインテリジェンスが届くと自動ハンティングが顧客環境を評価し、MDRチームが検出結果を調査して証拠を確認し、明確な修復手順を案内します。自動化と人間の判断を組み合わせることで、変化する脅威への対応を支援します。プラットフォームが影響を能動的に調べ、チームが検出結果の意味と次に取るべき対応を説明します。

デモでExaforceの脅威ハンティングをご覧ください。