PHP悪用後にMFAの秘密情報へ到達｜Unit 42の報告で広がる侵害調査

PHPの重大脆弱性を修正した後も、アプリの認証情報と、その先の認証基盤を調べる必要があります。Palo Alto NetworksのUnit 42は、PHPの悪用後、初期侵害から2時間以内にパスワードハッシュとMFAの秘密情報へ到達した事例を報告しました。公開Webサーバーの復旧だけで対応を閉じると、侵入後に得られたアクセスを見落とすおそれがあります。

Unit 42のPHP2Shellに関する原報告は、10月23日12時30分PTに侵入後の活動とハンティング用クエリを追記しています。日本時間では10月24日4時30分です。本稿は同日確認した続報であり、被害がその追記時刻に発生したという意味ではありません。以下では調査元の観測と本サイトの対応提案を分けます。

新たに報告された到達と試行を分ける

Unit 42によると、欧州の政府組織を狙った事例では、パスワードハッシュとMFAの秘密情報へのアクセスに加え、Active Directoryへ向かうNTLMリレーのトンネルが確立されました。一方、Domain Admin権限への昇格について、同資料は試行として記載しています。ドメイン管理者権限の取得に成功したとは読み替えません。

この新事実は、脆弱性の再説明や別ベンダーの防御製品の紹介ではありません。Webサーバーから認証データへ到達し、その先の認証基盤へ進もうとした具体的な観測です。自社で侵害の可能性を調べている場合、PHPの更新確認だけでなく、読み取られ得る認証情報と周辺への通信を調査対象にする判断材料になります。

報告の2時間という値は、一つの事例で観測された時間です。すべての攻撃に共通する所要時間でも、安全に作業できる猶予でもありません。自社の調査では、その数字から検索期間を固定せず、露出していた期間、更新時刻、残っている記録を基に対象期間を定めます。

AI利用は調査元の分析として受け止める

Unit 42は、侵入後の活動にエージェント型AIの攻撃基盤が使われたと報告しています。根拠として、モデルが読み取りやすい区切りを持つコマンド出力や、短く連続したタスク、失敗後の素早い切り替えなどを挙げています。これらは同社の観測と分析であり、本サイトが独立して攻撃基盤やモデルを特定したものではありません。

区切り文字や実行間隔の特徴だけを探しても、通常の自動化を攻撃と誤認する可能性があります。反対に、その特徴がない攻撃も考えられます。本サイトの提案は、AI利用の判定を先に目指すより、Webプロセスが何を読み、どこへ接続し、どの認証情報が使われたかを優先して確認することです。

AIを使う攻撃かどうかで、必要な封じ込めの基本が逆転するわけではありません。今回の報告で対応を変える中心は、認証の秘密情報へのアクセスと、別の認証基盤への到達です。モデル名や完全自律という未確認の属性を補って、被害を大きく見せる必要はありません。

PHPの修正と秘密情報の失効は別の完了条件

PHP公式の2026年告知アーカイブにある10月21日のセキュリティ告知は、CVE-2026-109618とCVE-2026-109619の修正先として、8.5.12、8.4.27、8.3.36、8.2.35を案内しています。ディストリビューションのパッケージでは、提供元の修正情報も照合します。これらの更新を行っても、既に取得された秘密情報は自動的に無効にはなりません。

本サイトでは、作業票の完了条件を三つに分けることを勧めます。第一に脆弱な実行環境を修正すること、第二に侵害された環境を信頼できる状態へ戻すこと、第三に漏えいの可能性がある認証情報とアクセスを止めることです。更新担当とID管理担当が別でも、三つの進捗を対応させます。

新しい秘密情報を、まだ攻撃者が読み取れる可能性のあるホストへ入力すると、再び取得されるおそれがあります。封じ込め、記録の保全、信頼できる管理経路の確保を進め、その経路から再発行と配布を行います。機械的に全パスワードを変え始めるより、再取得を防げる状態と依存先を先に確認します。

認証情報の種類ごとに影響を確かめる

次の整理は、本サイトが提案する調査の観点です。今回の事例で、表のすべての情報が盗まれたと報告されたわけではありません。自社のWebアプリと実行ユーザーが読める範囲を基に、優先する確認先を決めます。

確認対象	判断すること
パスワードハッシュ	どの利用者の認証データか、方式と保護状態、再設定が必要な範囲
MFA関連の秘密	認証方式、秘密の所在、該当する認証器の取り消し・再登録の必要性
サービス用の資格情報	DB・LDAP・外部APIなどの権限と、別システムへの到達範囲
既存セッション・トークン	パスワードや認証器の変更後も使えるものが残らないか

パスワードハッシュへのアクセスは、すべての平文パスワードの取得成功と同じではありません。ただし、ハッシュだから影響がないとも言えません。保存方式や読まれた範囲を確認し、本人への案内と再設定の必要性を判断します。今回の報告にない解読率や被害人数を推測することは避けます。

MFAの秘密情報も、方式によって意味が違います。原報告の表現だけから、特定の認証アプリ、TOTPの共有秘密、復旧コードなどのどれが対象だったかを断定しません。自社では、どの方式の何が読めた可能性があるかを確認し、必要な取り消しと安全な再登録をID管理担当が判断します。

パスワードを変える操作と、認証器を登録し直す操作、既存のアクセスを失効する操作は同じではありません。復旧のためにMFAを外したままにしたり、身元確認の弱い窓口から再登録させたりすると、別の侵入経路を作りかねません。対象者の復旧手順と確認担当まで決めます。

Web側からID基盤側へ調査をつなぐ

仮想例として、公開Webアプリが社内のLDAPへサービスアカウントで接続している構成を考えます。Webホストでコードを実行された場合、アプリ設定に保存された接続情報や、その権限で到達できる範囲が問題になります。これは自社構成を点検する例であり、Unit 42の事例の内部構成を再現したものではありません。

Web側では、プロセスの親子関係、外向き通信、設定・認証データへのアクセス、不審なファイルや持続化を確認します。ID基盤側では、同じ時間帯の認証、通常と異なる送信元、サービスアカウントの利用、権限変更を照合します。片方のログだけで、別のシステムへの到達まで否定しないようにします。

Webアプリの保守担当がActive Directoryを直接操作できる必要はありません。ホスト名、対象アカウント、観測時刻とタイムゾーン、通信先、既に行った遮断をID管理担当へ渡せることが重要です。秘密情報そのものを共有資料へ貼り付けず、識別子と観測結果で調査をつなぎます。

Active Directoryを使わない構成で、この報告を理由に同じ被害があったと考える必要はありません。確認するのは、自社のWebホストから到達できるDB、クラウド、認証サービスなどの実際の依存先です。環境差を無視して、すべての認証基盤が侵害されたと扱うことは避けます。

公開クエリは検出結果の解釈まで含めて使う

Unit 42は、WebサーバーやPHPワーカーに関連する侵入後のコマンド実行を調べるXQLクエリも掲載しました。同社は、このクエリが今回のCVE専用ではなく、通常のWebアプリの動作でも誤検知し得ると明記しています。ヒットしたことだけでPHP2Shellの悪用が確定する検出器ではありません。

実務では、必要なテレメトリーと製品がそろうか、検索期間や除外条件が自社に合うかを確認します。Cortexのクエリを別製品へ文字だけ移して、同じ検出範囲を得られると考えません。データの種類や取得していないプロセスがあれば、その範囲は未確認として残します。

陽性結果は、デプロイ、監視、バックアップ、運用スクリプトなどの正常な作業と照合します。陰性でも、ログ保存期間の外や監視対象外のホストは除外できません。自社で実行していないクエリを検証済みと案内せず、本稿も公開クエリの検出性能を測定したものではありません。

復旧を閉じる前に古いアクセスの残存を見る

Microsoftの緊急時アクセス失効資料は、アクセストークン、更新トークン、アプリが独自に発行するセッションを区別しています。Entra IDはアプリ独自のセッションを直接失効できません。この資料は今回の侵害環境がEntra IDだったという根拠ではなく、利用者の認証とアプリ側のアクセスを別に確認するための参考です。

本サイトの提案は、変更した秘密とその利用先、旧値を失効した結果、復旧した実行環境、残るセッション、重点監視の担当を対応票へ残すことです。更新成功やログイン成功だけを復旧完了とせず、旧資格情報での利用や不審な通信が残っていないか確認します。

NIST SP 800-61 Rev.3は、インシデントの検知・対応・復旧を継続的なリスク管理に組み込む資料です。今回の続報を受けた優先事項は、既存の更新作業を繰り返すことではなく、観測された侵入後の到達先に合わせて調査と失効の範囲を見直すことです。

関連記事

JPCERTがPHP侵害調査の確認点を公開｜Cookieとワーカー異常を時系列で調べるは、10月22日の注意喚起を確認した調査記事です。本稿は、その後Unit 42が追記した認証秘密への到達と横展開の観測を補います。

更新しても侵害は消えない｜Webサーバーの証拠保全と再構築ランブックでは、侵害環境を信頼できる状態へ戻す共通手順を扱います。個別事例で確認された事実と、一般的な復旧手順は分けて参照してください。