はじめに:きっかけは「ログイン画面が開かない」だった
前回の記事「「うちは大丈夫?」と聞かれたら」では、日ごろから脆弱性の情報にアンテナを張る、対応のルールを決めておく、といった平時の備えを書きました。
今回は、その続きです。実際に、緊急度の高い脆弱性が出たとき、現場で何が起きて、何を見て、何を決めたのか。 正直に言うと、後手を踏み、見込みも外しました。 その失敗も含めて、書きます。
この騒ぎに気づいたきっかけは、会社の業務ではありませんでした。ブログの記事を投稿しようとして、WordPressのログイン画面が開けなかったのです。
その週に起きたこと
公式の情報で、時系列を整理します(時刻は日本時間)。
| 日時 | 出来事 | 出典 |
|---|---|---|
| 10月20日 | PHP公式が、「重大なセキュリティリリース」を予告(CVSS 9.2が2件。10月21日23:00に公開予定。「今から準備を」) | PHP公式のニュース |
| 10月21日 16:00 | エックスサーバーが、管理画面などを予防的に一時停止(不正アクセスへの対応ではない) | エックスサーバー |
| 10月21日 22:30ごろ | 筆者が、管理画面に入れないことに気づく | 筆者 |
| 10月21日 夜 | PHPの修正版が公開される(「更新が唯一の安全な選択」) | PHP公式のアドバイザリ |
| 10月22日 朝 | 各社の停止がニュースで報じられ、筆者が全体像を知る | 筆者 |
| 10月22日 午前 | 公開サービスの切り分けを実施。 途中で上司から「うちは大丈夫?」 | 筆者 |
| 10月22日 10:00 | 保守ベンダーから、影響確認のメールが配信される(筆者の確認は、これより前) | 筆者 |
| 10月22日 | JPCERT/CCが、注意喚起を公開 | JPCERT-AT-2026-0033 |
| 10月23日 | 筆者が、見込みを外した件の対応を進める。PHP公式が、追加の情報アドバイザリを公開 | 筆者、PHP公式 |
気づいてから、やったこと
1日目の夜:ログイン画面が開けず、エックスサーバーのお知らせに飛びました。メンテナンス中だとわかり、「今日は投稿できない。明日にしよう」と、予定を止めました。 原因がPHPの脆弱性だとは、まだ知りませんでした。
2日目の朝:ニュースで、さまざまなサービスやサイトが停止している報道を見て、エックスサーバーの停止も、同じ件だったと、つながりました。
その日の午前中:インターネットに公開されている社内のサービスとホームページの影響を、切り分けていました。その途中で、上司から「うちは大丈夫?」と問い合わせが入りました。前回の記事のタイトルが、そのまま、現場で起きたのです。
ここで、優先度を最大にしました。 それまでの作業を止め、この件を最優先にしました。「自分の判断で進める調査」が、「会社として、答えを出す作業」に変わったからです。
切り分けの進め方は、次のとおりです。
- 範囲を絞る。 まず、インターネットに公開されているものに絞る。社内だけのものは後回し。
- 公式の情報を見る。 ベンダーの注意喚起を確認し、保守ベンダーにも問い合わせる。 自分で触れないものは、直接聞くのが確実。
- 触れるサーバーは、自分で調べる。 「PHPを使っているか、使っているならバージョンは何か」。保守の業務でAIを接続しているので、AIにPHPが入っているかを調べてもらいました。
- 答えを待つ間に、速報を出す。 確認が取れたものをまとめ、速報として上司に返信しました。
大事なのは、「全部が揃うまで答えない」にしなかったことです。「うちは大丈夫?」に、完全な答えをすぐ出すことはできません。確認できた範囲を先に出し、未確認は「確認中」と明示する。 上司は、判断に使える情報を、早く得られます。
正直に書くと、後手を踏んだ
筆者は、後手を踏みました。 PHP公式の予告は、10月20日に出ていました。それを、自分ではつかめておらず、気づいたのはサービスが止まってからです。
前回の記事で書いたJPCERT/CCの定期レポートも、この件では、検知の役に立ちませんでした。
| 情報 | 出た日 | 内容 |
|---|---|---|
| PHP公式の予告 | 10月20日 | 最も早い、公式の合図 |
| JPCERT/CC 定期レポート(10月21日号) | 10月21日 | 対象は10月11日〜17日分。PHPは、まだ載っていない |
| JPCERT/CC 注意喚起 | 10月22日 | PHP公式の予告から、約2日後 |
定期レポートは、1週間分を、まとめて後から伝えるものです。確認と棚卸しには役立ちますが、緊急の脆弱性を最初に知る手段としては、遅いのです。エックスサーバーは、「10月21日に、修正版が公開される予定であったことを受け」て、公開の約7時間前に、予防的に停止しています。先に動いたのは、一次情報を受け取っていた側でした。
今回、情報収集にいちばん役に立ったのは、X(旧Twitter)でした。 真偽の精査は必要ですが、とにかく情報が早い。 PHP2Shellを辿るうちに、eMudhraの件など、危なそうな情報が、枝葉として見つかりました。 ただし、Xの情報は、そのまま信じず、必ず一次情報で裏づけます。 この記事の事実も、PHP公式、ベンダー、JPCERT/CC、Mozillaなどの一次情報で確認したものだけです。
| 情報源 | 役割 |
|---|---|
| X(SNS) | 最初のレーダー。 速いが、真偽は不明 |
| 公式の告知(PHP公式、ベンダー、事業者) | 一次情報。 事実の裏づけと、対応の根拠 |
| JPCERT/CCの注意喚起・定期レポート | 後からの確認と、棚卸し |
次は、こう備えます。
- JPCERT/CCは、そのまま残す。 後から確認する道具として、引き続き役に立ちます。
- Xのセキュリティ関連の情報を、まとめてSlackなどに投稿する仕組みを作る。 速い情報が、向こうから流れてくる形にします。
- この仕組みは、AIエージェントで組み込めると考えています。情報を集め、要約し、一次情報へのリンクと、「一次で未確認」の印を添えて、Slackに流す。
(まだ構想の段階です。作ったら、実践記として書きたいと思います。)
見込みを外した:報告に、手落ちがあった
ベンダーの回答が揃ったタイミングで、結論を上司に報告しました。ところが、この報告に、誤りがありました。
AIに調べてもらったサーバーを、筆者は、当初「PHPを使っていない」と判断していました。 ところが、その後、アプリのベンダーから、PHP更新のお知らせが掲示され、見込みを外していたことがわかりました。手落ちです。
原因は、2つあります。
- AIの調査が、「標準のインストール」だけを対象にしていた。 アプリが独自に持つランタイムなどは、確認できていませんでした。
- 「ベンダーのサイトに、お知らせがない」ことを、根拠にしてしまった。 調査した時点では、ベンダーのサイトに、PHP2Shellのお知らせはありませんでした。
言い訳を、少しだけ。 保守ベンダーから影響確認のメールが配信されたのは、10月22日の10時。筆者の確認は、それより前でした。確認した時点では、ベンダー側にも、まだ情報が出ていなかったのです。それでも、ミスは、ミスです。 「お知らせがない」ことは、「該当しない」証拠にはなりません。初動の時間帯は、ベンダーの情報が遅れて出るのが普通で、この根拠は、弱かった、と反省しています。
誤りに気づいた経緯も、反省点です。調査と報告を終え、メールを確認していて、保守ベンダーの通知に気づき、見込み違いを知りました。自分で気づいたのではなく、通知で知らされたのです。
訂正の報告は、先の報告を、そのまま訂正する形で、上司に伝えました。内容は、次のとおりです。
- 影響を受ける可能性があるものが、見つかった(先の報告の訂正)。
- 即時の停止は、業務の進行に影響するため、難しい。
- 社内で利用するもので、一般のユーザーには周知していないため、標的型攻撃はないと推測している。
- ただし、現行の仕組みだけでは、不十分なので、予定していた対策を、速やかに実施し、やれるところから進める。
- この方針について、承認を依頼した。
意識したのは、「事実」「推測」「判断」「お願い」を、分けて書くことです。「標的型攻撃はない」は推測と明記し、「やれるところから進める」は判断、最後に承認を求める。訂正の報告でも、どこまでが事実で、どこからが推測かを、はっきりさせると、上司は判断しやすくなります。
ただし、「周知していないから、標的型攻撃はないだろう」という推測には、注意が必要です。今回の一連の攻撃は、特定の企業を狙ったものではなく、公開されているWebシステムに、手当たり次第に仕掛けている可能性が高い、とマクニカは見ています(マクニカ セキュリティ研究センター)。「周知していない」ことは、安心の根拠になりません。 優先度を決める材料にとどめ、対策を急ぎました。
学んだこと:
- 「見つからなかった」は、「ない」ではない。 調査の方法の範囲でしか、わかりません。何を、どこまで、どう調べたかを、報告に添える。
- 「ベンダーのお知らせが、まだない」は、「該当しない」の証拠ではない。 「お知らせなし」を根拠にするなら、「現時点では」と、時刻を添える。
- AIに調査を頼むときは、範囲を、広く、具体的に指示する。 標準のパッケージだけでなく、実行中のプロセス、待ち受けているサービス、アプリのインストール先、同梱されたランタイム、コンテナの中まで。そして、「入っていない」ではなく、「この範囲では、見つからなかった」と答えさせる。
- ベンダーの回答は、AIの調査より優先する。 AIの結果は仮説として扱い、ベンダーの回答で裏づける。
- 訂正は、早く、正直に。
AIは、調査を速く、広くしてくれます。ただし、結果を最終の結論にするのは、人間の仕事です。今回は、その線引きが甘かった、ということです。
更新して終わり、ではない
JPCERT/CCの注意喚起は、「速やかに対策の適用および侵害有無の調査を実施してください」としています。調査の観点として、次の3つが示されています。
- 異常に長い、または異常な形式のPHPSESSID Cookieが、レスポンスで設定されていないか。
- 不審なmultipart/form-dataのリクエストと、その前後の、メモリ上限のエラーやHTTP 500。
- PHPのワーカープロセスが、異常終了や、頻繁な再起動をしていないか。
「痕跡が確認されなくても、攻撃を受けていないと断定することはできない」とも述べています。更新はスタート地点です。しかも、情報は、その後も動きます。 10月23日には、PHP公式が、追加の情報アドバイザリを出しました。1回の更新では、終わらないのです。
筆者の侵害調査は、次のとおりでした。
- 対象:要対応となったサーバーの、アクセスログ。
- 手がかり:JPCERT/CCの注意喚起(JPCERT-AT-2026-0030、10月23日更新)には、今回の一連の攻撃で使われたIPアドレスが、25件開示されています。
- 絞り込みを、2段にした:「開示された25件のIP」と「海外からのIP」。開示されたIPだけでは、リストにない別の攻撃元を見落とします。海外からのアクセスという広い網も掛けることで、リストにないものを拾える可能性が上がります。
結果は、25件のIPは、記録なし。海外からのアクセスはあったが、ログインに成功した形跡は、なし。 調べた範囲では、侵害の兆候は見つかりませんでした。ただし、痕跡がないことは、攻撃がなかったことの証明ではありません。 JPCERT/CCも、リストのIPについて、「調査時点では、正規利用されている可能性もある」と注意しています。一致があっても、すぐに攻撃と断定せず、前後のリクエストとあわせて判断する。 調査は一度で終わらせず、継続して監視します。
経験が効いた場面
今回の対応で、「経験があったから、こう判断できた」と感じる場面が、2つあります。
1. 枝葉を広げて、周知しやすいものから、社内に知らせた。 eMudhraの件などへの対応は、基本、「OSやアプリを最新にしておく」ことで、個別の依頼は要りません。周知しやすい内容でした。そこで、社内の掲示板に、注意喚起を投稿しました。個別の対応が必要なもの(PHP2Shell)は、個別に動き、最新化するだけで済むものは、広く周知する。仕分けて、手間を、必要な所に集中させる判断です。
2. 予定していた作業を、組み替えた。 見込みを外した件への対応では、すでに予定していた別の作業の、順番を入れ替えて、今回の対応に充てました。詳しい内容は、実対応編(別の記事)で書きます。 判断の考え方は、こうです。
- もともと予定していた作業を、緊急の対応の手段として使う。 ゼロから準備するのではなく、すでに計画していたものの、順番を入れ替える。
- 手持ちの計画と、残り時間と、リスクを、頭の中で並べて決める。
この「既存の計画を、状況に合わせて組み替える」判断は、教科書には書いていません。そこに、経験が効きました。
持ち帰ってほしいこと
- 異変は、アラートより先に、「いつもの作業ができない」という形で来ることがある。違和感を放っておかない。
- 定期レポートは、後から確認する道具。 緊急の入口は、公式の告知、事業者のお知らせ、そしてX(要・裏取り)。
- 同じ週に、緊急度の高いものが複数出ることもある。公開されているか、持っているか、誰が直すかで、素早く切り分ける。
- 「うちは大丈夫?」と聞かれたら、優先度を切り替え、確認できた範囲を、速報で出す。
- 「見つからなかった」と「ない」は違う。 AIの調査は仮説として扱い、ベンダーの回答で裏づける。
- 更新して終わりにしない。 侵害の調査まで含めて、対応。
- 手持ちの計画を、緊急の対応に使う。周知で済むものは広く知らせ、個別対応が必要なものに手を集中する。
次のアクション
- 自分が管理している、インターネットに公開されているものを、一覧にする(前回の記事の、「機器とソフトの一覧」)。
- 各項目に、「誰が直すか(自分、事業者)」と、「ベンダーの告知の、受け取り方」を書き込む。
- 重大な脆弱性が出たときの、判断の流れを、自分の言葉で、メモしておく。
続編を公開しました。要対応となったサーバーの顛末は、こちらです: 重大な脆弱性が出た週、更新までの数日間をどう守ったか【「うちは大丈夫?」実践編・続き】
コメント