要約

  • Microsoft および複数の国の当局は、2025年7月、ToolShell に関連する脆弱性がオンプレミスの SharePoint Server に対して悪用されていると警告した。Microsoft は、Microsoft 365の SharePoint Online には影響がないと述べた。
  • 技術的記録は、CVE-2025-49704、CVE-2025-49706、CVE-2025-53770、CVE-2025-53771 を区別している。アップデートは必要であったが、Microsoft のガイダンスでは、サポートされているバージョン、防御的統合、ASP.NET マシンキーのローテーション、IIS の再起動、緩和策が利用できない場合の分離、および侵害の評価も求めていた。
  • この記録は、最終的な世界的な被害者数を確定しておらず、露出したサーバーのうち侵害された割合を明らかにしておらず、Microsoft の攻撃者属性を独自に検証しておらず、個々の組織が一貫して修復シーケンスを完了したかどうかを示していない。

オンプレミス管理は運用上の選択

組織は SharePoint Server を、コラボレーションプラットフォーム、ドキュメントリポジトリ、イントラネット、アプリケーションホスト、または継承されすぐに置き換えるのが困難になったシステムと表現することができる。それぞれの説明は異なるビジネス用途を強調する。しかし、いずれも運用上の事実を変えるものではない。サービスがオンプレミスに残っている場合、組織はその可用性を維持するためのサーバー、製品バージョン、ネットワーク露出、認証情報、セキュリティ制御、変更ウィンドウ、復旧決定について責任を負う。その責任は2025年の ToolShell 事件で特に顕著になった。公的な時系列は、Microsoft のホスティングされたコラボレーションサービスの一般的な停止に関するものではなかった。Microsoft は繰り返し、オンプレミスの SharePoint Server に境界を設定し、Microsoft 365の SharePoint Online は影響を受けないと述べた。この区別は、運用管理がどこにあるかを特定するため重要である。ホスティングサービスの顧客は、SharePoint ファームを特定し、製品固有のサーバーアップデートを適用し、ローカルの ASP.NET マシンキーをローテーションし、自己管理システム全体で IIS

を再起動するよう求められていなかった。オンプレミス環境の運用者は求められていた。これは、すべての組織が2025年7月までにホスティングサービスに移行すべきだったという議論ではない。オンプレミス展開は、カスタマイズ、データ処理、統合、主権、レイテンシ、調達、移行の理由で継続する可能性がある。公的証拠は、特定の組織が環境を維持した理由を示していない。しかし、能動的悪用が開示された後に保持に伴う義務を示している。それらの義務はパッチのダウンロードを超える。管理者はまず信頼できるインベントリを必要とする。どのエディションとビルドが実行されているか、各サーバーがサポートされているか、どのシステムがインターネットから到達可能か、どの依存関係が分離を妨げるか、修復後に認証情報がどのように更新されるかを知る必要がある。悪用が進行している場合、通常の変更スケジュールを中断する権限が必要である。また、パッチ適用後のシステムを信頼できるか、調査して再構築する必要があるかを判断する方法も必要である。ToolShell

はしたがって、脆弱性の話というよりも、パッチ準備責任のテストとなった。引き金となったイベントは、既知のクラスのオンプレミスコラボレーションシステムに対する悪意ある悪用であった。任意の環境での結果の重大度は、公開記録では再構築できない条件（露出、バージョン、パッチ状態、防御構成、キー管理、監視、対応速度）に依存していた。ガバナンスの問題は、緊急事態が始まる前にそれらの条件が把握され制御されていたかどうかである。

2025年5月：チェーンが公的技術記録に登場

Microsoft のその後の時系列によると、CVE-2025-49706 と CVE-2025-49704 を組み合わせたエクスプロイトチェーンが、2025年5月の Pwn2Own Berlin で実証されていた。このイベントはタイムラインの最初の方に属する。なぜなら、問題が単に脆弱性データベースの抽象的なエントリではないことを確立したからである。公開デモとその後のベンダーの作業は、7月の緊急事態に先立つ歴史の一部を形成した。2つの以前の識別子は別々にしておく必要がある。CVE-2025-49704 は、CVE レコードでは、Microsoft Office SharePoint に影響するコード生成制御またはコードインジェクションの弱点として説明されている。CVE-2025-49706 は、ネットワーク経由のスプーフィングを可能にする不適切な認証の弱点として説明されている。チェーンは、異なる弱点を1つの欠陥に変えることなく、別々の弱点を接続することができる。それらを単一の「ToolShell バグ」に平らにすると、各レコードが説明する条件とそれらに対処するために必要な制御の違いが消えてしまう。Microsoft はこれらの以前の問題に対して2025年7月のセキュリティアップデートをリリースした。その後の能動的悪用対応は、関連する脆弱性 CVE-2025-53770 と CVE-2025-53771

に対処した。この順序は重要である。なぜなら、キャンペーン名を認識するだけで脆弱性対応を管理できない理由を示しているからである。ToolShell は、関連する悪用活動と脆弱性チェーンの履歴のための便利な公開ラベルであった。パッチ準備には、管理者が個々の CVE を識別し、該当する製品バージョンとパッケージを決定し、以前のアップデートが後のすべての条件を解決したと想定するのではなく、現在の修復手順に従う必要があった。公開記録は、5月のデモ、Microsoft のエンジニアリング作業、7月のアップデート、能動的悪用の観測の間の完全な非公開のタイムラインを開示していない。各時点で各顧客が何を知っていたかは確立していない。より狭い結論を支持している。7月までに、管理者は関連するが異なる一連のレコードに直面し、対応の質は資産と変更情報を迅速に行動に移せるかどうかに依存していた。それが最初の説明責任の境界である。脆弱性研究コミュニティ、ベンダー、公的機関はリスクを特定し説明できた。特定の SharePoint 環境の運用者だけが、その環境が存在するか、到達可能か、サポートされているか、該当するアップデートが正しくインストールされたか、ビジネスオーナーが即時の分離やダウンタイムを許可するかを判断できた。外部の警告はローカルの責任を排除しなかった。それを活性化した。

7月20日から22日：警告が緊急対応に

CISA の7月20日の警告は、公に ToolShell として知られる脆弱性チェーンの能動的悪用について説明していた。攻撃者がオンプレミスの SharePoint Server にアクセスし、コンテンツと内部設定に到達し、ネットワーク経由でコードを実行する可能性があると警告した。同日、CISA は CVE-2025-53770 を既知の悪用された脆弱性カタログに追加した。米国連邦政府民事執行部局にとって、この措置は、Binding Operational Directive 22-01の修復義務と期限構造を対応に持ち込んだ。CISA はまた、その義務的範囲外の組織に対しても、タイムリーな修復を優先するよう促した。Microsoft Threat Intelligence は2025年7月22日に能動的悪用の説明を公開し、その後、追加分析、インジケータ、緩和ガイダンス、ランサムウェアコンテキストで資料を拡張した。Microsoft は、この活動はオンプレミスの SharePoint Server に影響し、Microsoft 365の SharePoint Online には影響しないと述べた。サポートされている SharePoint Server

バージョンを使用し、最新のセキュリティアップデートをインストールするよう顧客に促した。タイミングは複数の作業を圧縮した。セキュリティチームは能動的悪用の警告を解釈する必要があった。インフラチームは影響を受けるシステムを見つけ、バージョンを確認する必要があった。SharePoint 管理者はファームを製品固有のアップデートと前提条件に一致させる必要があった。ネットワークチームはインターネット露出と分離を評価する必要があった。ID とアプリケーションの所有者はマシンキーのローテーションとサービスの再起動を計画する必要があった。ビジネスリーダーは、潜在的に脆弱なコラボレーションサービスをオンラインに保つことと、制御を適用している間に中断することのどちらが継続性をより保護するかを決定する必要があった。記録は、すべての組織が同じ時間または同じチャネルで警告を受け取ったことを確立していない。また、インターネットに面したサーバーのうち悪用可能または侵害された割合を明らかにしていない。確立しているのは、証拠のエスカレーションである。脆弱性エントリは技術的可能性を説明する。ベンダーの能動的悪用通知と CISA KEV

への追加は、悪用がもはや仮説ではないことを示している。その変更は、パッチの優先順位、変更権限、監視、経営陣の注意を変えるべきである。緊急対応はパッチが存在しても失敗する可能性がある。インベントリがサーバーを見落とす可能性がある。ファームがサポートされていない製品バージョンに依存する可能性がある。メンテナンスウィンドウが能動的悪用には遅すぎる可能性がある。チームがキーローテーションや侵害評価を完了せずにアップデートをインストールする可能性がある。サービスがインターネットから分離されていても、内部システムを露出させる可能性がある。これらは選択された証拠において名前の付いた組織での確認された失敗ではない。修復シーケンスによって可視化された管理ポイントである。

4つの CVE、1つのスーパー脆弱性ではない

CVE-2025-53770 は公的時系列において中心的な悪用されたレコードである。CVE プログラムの説明は、オンプレミスの Microsoft SharePoint Server における信頼できないデータのデシリアライゼーションを特定し、認証されていない攻撃者がネットワーク経由でコードを実行することを可能にする。Microsoft は悪用が実際に行われていることに言及した。NVD と MSRC のレコードは、脆弱性の並行する公開参照を提供する。その組み合わせは、オンプレミスの SharePoint Server に影響する能動的に悪用されるリモートコード実行リスクとして説明することを支持する。CVE-2025-53771 は別のレコードである。公開脆弱性レコードは、不適切な認証とスプーフィングの問題として説明している。CVE-2025-53770 に統合したり、同じリモートコード実行条件の別名として使用すべきではない。対応履歴におけるその存在は、オペレーターが複数の関連アップデートを追跡する必要があったことを示しているが、53770の特性を53771に割り当てることを正当化しない。CVE-2025-49704 は公開チェーン履歴において53770レコードに先行する。その CVE 説明は、Microsoft Office SharePoint におけるコード生成制御またはコードインジェクションに関するものである。CVE-2025-49706

も以前のチェーン履歴の一部であり、不適切な認証とネットワークスプーフィングに関するものである。Microsoft はこのペアを Pwn2Own Berlin のデモと関連付け、後の関連識別子が能動的悪用対応の一部となる前に、それらに対処する7月のアップデートをリリースした。区別は操作的であり、意味論的ではない。異なる CVE は異なるアップデートパッケージ、検出、前提条件、検証手順に対応する可能性がある。「ToolShell パッチ適用済み」のみを記録するチームは、どの脆弱性、製品、サーバーがカバーされたかを証明せずにラベルを作成した可能性がある。信頼できる変更記録は、影響を受ける製品エディション、インストールされたアップデート、結果のビルド、インストール結果、前提条件または既知の注意事項、現在のガイダンスで要求されるインストール後のアクションを特定する。同じ規律が因果関係の言語にも適用される。証拠は関連する脆弱性と悪用チェーンを示している。SharePoint の開発プロセス、Microsoft

の内部テスト、または各被害者に対して使用されたすべての技術の完全な根本原因分析を提供していない。信頼できないデータのデシリアライゼーション、コードインジェクション、不適切な認証などの説明は脆弱性クラスを特定する。それ自体では、ベンダー内の予防制御がなぜ失敗したか、特定の顧客環境で悪用がなぜ成功したかを確立しない。説明責任の目的では、4レコード構造は2つのエラーを防ぐ。1つ目は誇張であり、すべての特性を備えた1つの全能の欠陥を主張すること。2つ目は誤った終了であり、1つのインストールパッケージまたは1つの成功したスキャナー結果が緊急事態全体を解決したと想定すること。より防御可能なアプローチは、各識別子を保持し、現在のベンダーガイダンスに従い、資産レベルでカバレッジを証明することである。

SharePoint Online は影響範囲外

Microsoft、カナダの Cyber Centre、CERT-EU、その他の当局は、影響を受ける製品はオンプレミスの SharePoint Server であり、SharePoint Online は影響を受けないと強調した。これは単なる製品の明確化ではない。責任モデルを変更する。ホスティングサービスでは、プロバイダーがサービスインフラを運用し、その基盤となるパッチ展開を制御する。顧客は依然としてアカウント、設定、データ、統合、インシデント対応に関する責任を保持するが、Microsoft のサービスに SharePoint Server セキュリティパッケージをインストールする必要はない。オンプレミス展開では、顧客またはそのサービスプロバイダーが運用環境を制御する。その制御には、サーバーの特定、露出の制限、変更のスケジュール、サポートされているバージョンの維持、ローカルに保持されたシークレットのローテーション、サーバーをサービスに戻す安全なタイミングの決定の能力と負担が含まれる。公開された境界はまた、このインシデントが Microsoft 365クラウドの侵害として説明されることを防ぐ。選択された証拠にはその結論を支持するものは何もない。関連する継続性の問題は、独自の SharePoint Server 環境を運用する組織に関するものであった。一部は Microsoft

365も使用していた可能性があるが、記録は影響範囲をオンプレミスサーバーからホスティングプラットフォームに拡大することを支持していない。この区別は経営陣へのコミュニケーションにおいて可視であるべきである。「SharePoint が影響を受ける」は広すぎる。「オンプレミスの SharePoint Server の脆弱性が能動的に悪用されている」は、技術、運用モデル、緊急性をより正確に特定する。精度はリーダーが適切な質問をするのに役立つ。影響を受けるサーバー製品を実行しているか？外部から到達可能か？バージョンはサポートされているか？現在のアップデートとインストール後のアクションは完了しているか？侵害評価が必要か？間違った範囲は、不必要な警報または危険な安心を生み出す可能性がある。

パッチはダウンロードではなくシーケンス

Microsoft の顧客ガイダンスは、修復を順序付けられた運用シーケンスに変えた。顧客は即時のセキュリティアップデートとサポートされている SharePoint Server バージョンに向けられた。ガイダンスはまた、Microsoft Defender Antivirus または同等の制御との AMSI 統合、アップデートまたは緩和後の SharePoint Server ASP.NET マシンキーのローテーション、IIS の再起動に対応した。保護統合が有効にできない場合、Microsoft は緩和策が利用可能になるまで SharePoint Server をインターネットから切断することを説明した。各ステップはリスクの異なる部分に対処した。セキュリティアップデートは脆弱なソフトウェアを変更した。AMSI とアンチマルウェアの統合は防御的な検査と検出層を追加した。インターネット切断は、より強力な緩和策が利用できない場合に外部からの到達可能性を低減した。マシンキーのローテーションは、もはや信頼できない可能性のある認証情報を置き換えた。IIS

の再起動は、新しいキーの状態とサービスの変更を適用するのに役立った。これらのアクションを交換可能として扱うとギャップが生じる。順序も重要である。脆弱な状態を修正せずにキーをローテーションすると、新しい素材が露出する可能性がある。キーをローテーションせずにアップデートをインストールすると、以前に露出した認証情報が使用され続ける可能性がある。ファームの一部のみを再起動すると、一貫性のない状態が生じる可能性がある。フロントエンドを分離しながら別のルートを残すと、露出が維持される可能性がある。選択された証拠は、これらの失敗が特定の環境で発生したことを確立していない。ガイダンスはそれらを合理的な検証質問にする。緊急作業はまた、変更管理の緊張を生み出す。通常のガバナンスは、テスト、承認、計画されたダウンタイム、バックアップ、ビジネスオーナーの承認を必要とする場合がある。能動的悪用は利用可能な時間を圧縮するが、それらの制御を無関係にはしない。より迅速な行動を可能にしながら、重要な証拠を保持する緊急経路が必要である。組織は、誰が分離を承認できるか、誰がサービス中断を受け入れるか、誰がパッケージを検証するか、誰が変更を記録するか、誰がシステムを運用に戻すかを決定するかを知っているべきである。パッチ準備ができている組織は、インシデント中にその権限を発明しない。維持されたインベントリ、現在の所有権、サポートされているバージョン、テストされた展開手順、バックアップと復旧の取り決め、シークレットローテーシ

ョン機能、定義された緊急変更ルートを持っている。また、成功したインストールをリスクの終了と区別する。アップデートは必要な技術的イベントである。終了には、正しい資産がカバーされ、周辺のアクションが完了したことの証明が必要である。

7月21日：製品固有のパッケージがインベントリを決定的に

Microsoft のサポートページは、2025年7月21日の SharePoint Server 2016、SharePoint Server 2019、SharePoint Server Subscription Edition のセキュリティアップデートを文書化している。別々のページとパッケージの存在は、「SharePoint にパッチを適用する」が単一の普遍的な指示ではなかった証拠である。管理者は製品バージョンと展開状態を該当するアップデートに一致させる必要があった。サポート記録は、SharePoint Server のリモートコード実行脆弱性と SharePoint Server のスプーフィング脆弱性の修正について説明していた。また、パッチ適用をインフラ運用にする実用的な詳細（パッケージ

ID、ビルド情報、前提条件、インストールの期待値、インストール後の注意事項）も含まれていた。選択された証拠はすべてのビルド番号を再現することを正当化せず、静的番号はガイダンスが変更されると誤解を招く可能性がある。説明責任のポイントは、バージョン固有の情報を理解し文書化する必要があったことである。「SharePoint」とだけ言うインベントリはそのタスクには不十分である。すべてのサーバーの役割とファーム、製品エディション、サポート状況、インストールされたビルド、露出、所有者、ビジネス依存関係、復旧の取り決めを特定する必要がある。また、一時的にオフライン、テストまたは災害復旧に使用、中央運用チームの外部で維持されているシステムも考慮する必要がある。休眠サーバーは、応答から欠落していた場合、再接続時に問題になる可能性がある。バージョン知識はまた、パッチパスが存在するかどうかを決定する。Microsoft は顧客にサポートされているリリースを使用するよう促した。CERT-EU は、以前のサポートされていないバージョンは Microsoft パッチなしでは脆弱と見なされるべきであり、CERT-FR は SharePoint

2010および2013からの移行を強調した。サポートされていないシステムは、緊急事態を通常のアップデートから移行、分離、交換、廃止の決定に変える。それは技術的負債が継続リスクになることである。公開記録は、どの組織がサポートされていないリリースを実行していたか、またはその理由を特定していない。アップグレードを妨げたレガシー統合があったかどうかを示していない。サポートされているバージョンの計画が防御境界の一部であることを確立している。組織がサポートされていないコラボレーションシステムを保持することを選択した場合、補完的制御、分離、交換日、責任ある所有者、リスク受容を説明できるべきである。そうでなければ、ベンダーパッチの欠如は予見可能な運用上の罠になる。

検出の失敗は想定できないが、検出準備はテスト可能

能動的悪用は、影響を受けるすべての組織が検出に失敗したことを証明しない。選択されたソースは、初期アクセス、警告、トリアージ、封じ込め、根絶のための普遍的なタイムラインを提供していない。どの環境が AMSI を有効にしていたか、どのセキュリティツールが有用なシグナルを生成したか、どのオペレーターが公開警告の前に証拠を見つけたかを開示していない。その不確実性は、検出失敗の包括的な発見を防ぐ。検出準備の調査を妨げない。組織は、関連する SharePoint ログ、エンドポイントテレメトリ、ネットワークシグナル、アンチマルウェア統合、管理イベントが収集され保持されているかどうかを特定できるべきである。誰がシグナルをレビューするか、インターネットに面したコラボレーションサーバーがどのように優先順位付けされるか、アラートがどのようにインフラアクションになるかを知っているべきである。AMSI 統合とアンチウイルス制御に関する Microsoft のガイダンスは、防止と検出がリンクしていたことを示している。制御は悪意のあるコンテンツをブロックまたは識別できるが、有効で、正常で、適切に構成され、監視されている場合のみである。「Defender あり」というコンプライアンスフィールドは、SharePoint 統合が影響を受けるファーム全体で動作したという証拠と同じではない。同等のサードパーティ制御は、同じカバレッジと応答の証明を必要とする。CISA

の後のマルウェア分析は、悪用後の次元を追加する。8月6日、同局は CVE-2025-49704、CVE-2025-49706、CVE-2025-53770、CVE-2025-53771 に関連する活動に関連する6つのファイルをカバーする分析をリリースした。その防御資料は、最初の緊急変更の後のハンティングと検証を支援する。ペイロードや侵入手順を公開することを正当化せず、同じファイルがすべての侵害に現れたことを証明しない。パッチ適用チームとインシデント対応チームの違いはここで重要になる。パッチ適用は、修正された条件のさらなる悪用を減らすことができる。インシデント対応は、修正前にアクセスがあったかどうか、何が変更されたか、どの資格情報やキーが露出したか、攻撃者がどこに移動できるか、復旧を支持する証拠を尋ねる。悪用が進行している場合、成功したインストーラーログだけではこれらの質問に答えられない。

キーローテーションはパッチが復旧ではない理由を示す

Microsoft がアップデートまたは緩和措置を適用した後に SharePoint Server ASP.NET マシンキーをローテーションするように指示したことは、時系列における最も重要な説明責任マーカーの1つである。それは、脆弱なコードの修正だけでは十分ではないと見なされたことを示している。環境に関連する認証情報も潜在的に露出しているとして扱い、更新する必要があった。マシンキーはアプリケーションデータの保護と検証に関与する。選択された証拠は、ローテーションと IIS 再起動の必要性を支持している。詳細なエクスプロイトチュートリアルは支持しない。運用上の含意で十分である。攻撃者がソフトウェアアップデート後も有用な素材を入手できた可能性がある場合、復旧はその素材を無効にし、新しい信頼できる状態を確立することに依存する。キーローテーションはチェックリストに含めるのは簡単だが、確実に実行するのは難しい。SharePoint

ファームは複数のサーバーを含むことができる。ローテーションは、環境が意図された新しい値を使用するように調整されなければならない。組織は、安全な生成、配布、アクセス制御、確認、ロールバック計画を必要とする。また、指示に従ってサービスを再起動し、アプリケーションと統合が引き続き動作することを確認する必要がある。部分的なローテーションは、セキュリティの不確実性とサービスの不安定性の両方を生み出す可能性がある。これは復旧失敗の境界である。組織はパッケージをインストールすることで迅速に対応できるが、露出したシークレットを変更せず、サーバーを見落とし、評価なしに侵害された可能性のあるホストを通常のサービスに戻すと、信頼を回復できない。公開記録は、どの組織が各ステップを完了したかを示していない。ベンダーの修復シーケンスがパッチ適用済みか未適用かのバイナリ状態を超えていることを示している。同じ論理が他の資格情報と信頼関係にも適用されるが、選択されたソースはすべての環境の普遍的なローテーションリストを列挙していない。侵害評価は、どの素材に到達できたか、どの依存システムが注意を必要とするかを決定する必要がある。その分析は証拠主導であるべきである。接続されたすべてのシステムがアクセスされたと想定すべきではなく、パッチのインストールが以前のアクセスを消去したと想定すべきでもない。したがって、復旧には宣言された終了状態が必要である。関連サーバーがインベントリされている。該当するアップデートがインストールさ

れ、確認されている。サポートされていないシステムは分離または削除されている。必要なキーがローテーションされている。IIS

とファームサービスが指示に従って再起動されている。防御制御が有効で正常である。利用可能なインジケータとテレメトリがレビューされている。侵害の証拠が封じ込められ、調査されている。ビジネスオーナーは残存する不確実性を理解している。これらの結果がなければ、「パッチ適用済み」はアクションを説明するかもしれないが、「復旧済み」は証明されないままである。

公共部門の継続性がガバナンスの重要性を高めた

SharePoint Server は、内部ポータル、ドキュメントワークフロー、記録、運用調整、組織的知識へのアクセスをサポートできる。公共部門の環境では、混乱は従業員の便利さ以上に影響を与える可能性がある。選択されたソースは、ToolShell のために公共サービスが失敗した特定の機関を特定していないため、そのような結果を発明すべきではない。CISA の KEV 行動と国際的な政府の警告は、それにもかかわらず、当局が修復を緊急の継続性とセキュリティ問題として扱ったことを確立している。米国連邦民事機関にとって、KEV への含めることは、技術的リスクを BOD 22-01に基づく正式な修復プログラムに接続する。指令構造は期限を割り当て、機関がカタログ脆弱性に対処することを期待する。これはガバナンスの証拠である。資産の可視性、修復追跡、例外処理、説明責任のある完了は、脆弱性がカタログに入る場合、任意の管理上の追加要素ではない。他の組織はその連邦指令に拘束されなかったが、CISA

はすべての組織にカタログ脆弱性を優先するよう促した。理由は実用的である。既知の悪用はリスクの確率側を変える。内部コンテンツと設定を保持するインターネットに面したコラボレーションサーバーは、より広範な運用へのルートになる可能性がある。長い通常のパッチサイクルは脅威状態と互換性がない可能性がある。公共部門の継続性はまた、分離を複雑にする。ポータルをオフラインにすると作業が中断される。適切な緩和なしにオンラインに保つと、悪用のルートが維持される可能性がある。正しい決定は、サービス、露出、代替手段、侵害の証拠、修復に必要な時間に依存する。これらのトレードオフはビジネス権限を必要とする。セキュリティチームは、実行可能な所有者がいないために、公共サービス継続性の決定を暗黙のうちに行うべきではない。説明責任のある対応は選択を記録する。サービスが中断された場合、リーダーはその理由、存在する代替プロセス、復旧に必要な証拠を知っているべきである。サービスが利用可能なままの場合、その決定を正当化する保護措置と、それがいつ見直されるかを知っているべきである。緊急ガバナンスは制御の欠如ではなく、より迅速で明確な形態である。

国際的な勧告が運用境界を確認

カナダの Cyber Centre は、Microsoft SharePoint Server に影響する CVE-2025-53770 について警告し、Microsoft 365の SharePoint Online は影響を受けないと述べた。そのガイダンスは、Subscription Edition、SharePoint Server 2019、SharePoint Server 2016の緊急パッチに言及した。後の更新には、追加の関連コンテキストとして CVE-2025-49712 が含まれていた。その識別子は、ここで調査された4つのコア ToolShell レコードの1つではなく、それらに折りたたむべきではない。CERT-EU も影響範囲をオンプレミスの SharePoint Server に限定した。脆弱なシステムをインターネットおよび内部システムから分離することを推奨し、以前のサポートされていないバージョンは Microsoft パッチがない場合に脆弱と見なされるべきであると警告した。内部分離への言及は重要である。直接的なインターネットアクセスを削除すると、1つのルートを減らすことができるが、侵害されたまたは脆弱なサーバーを機密内部リソースに接続したままにする可能性がある。封じ込めには、エッジでのファイアウォール変更だけでなく、露出モデルが必要である。英国国立サイバーセキュリティセンターは、影響を受ける Microsoft Office SharePoint

Server 製品を使用する組織に即時の行動を促した。能動的攻撃には英国での限られた数が含まれると述べた。これは、完全な被害者リストや普遍的な侵害の主張を支持せずに、観測された国家的影響の証拠である。CERT-FR は影響を受けるバージョンをリストし、サポートされていない SharePoint 2010および2013リリースからの移行の必要性を強調した。その警告は、緊急脆弱性対応をライフサイクルガバナンスに接続する。運用上の理由で延期された移行は、悪用が行動を強制するとき、容易ではなく、より困難になる可能性がある。組織は最悪の組み合わせに直面する可能性がある。重要なコラボレーション依存、通常のベンダーパッチパスなし、慎重に段階的な交換のための時間が不十分。シンガポールのサイバーセキュリティ庁は地域の勧告カバレッジを提供した。その勧告は、2025年7月20日の時点で、54組織にわたる85以上のサーバーという Shadowserver の観測に言及した。その数字は、それがそのままであるべきである。勧告を通じて中継された時間に制限された観測であり、最終的なグローバルな被害者数ではない。後の発見、重複観測、方法論の限界、外部スキャンに見えない環境は、それを決定的な総数にすることを防ぐ。全体として、勧告はいくつかの点で国際的な一貫性を示している。影響範囲はオンプレミスの SharePoint Server

であった。能動的悪用は緊急行動を必要とした。サポートされているバージョンとパッチ状態が重要であった。分離が関連していた。ホスティングされた SharePoint Online サービスは記載された影響範囲外であった。同一の国家的露出を確立しておらず、すべてのオペレーターが同じ修復経路をたどったことを証明していない。

インベントリは最初の予防制御

組織は所有していることを知らないサーバーにパッチを適用できない。このおなじみの原則は、コラボレーションインフラではよりシャープになる。なぜなら、SharePoint は長年にわたってファーム、テストシステム、災害復旧インスタンス、部門展開、外部公開サイト、レガシー統合を蓄積する可能性があるからである。所有権はリスクが集中していても分散される可能性がある。有用なインベントリにはホスト名以上のものが必要である。製品エディション、ビルド、サポート状況、ファームメンバーシップ、サーバーの役割、インターネットおよび内部露出、ビジネスオーナー、技術オーナー、認証依存関係、データ機密性、バックアップ状況、復旧目標、メンテナンス権限、最後に確認されたセキュリティ状態を特定する必要がある。また、サーバーがアクティブか、休眠中か、復旧用に予約されているかを記録する必要がある。ToolShell の時系列は、不正確なインベントリが特定の侵害を引き起こしたことを証明していない。インベントリを遅延または不完全な対応の根本原因候補にする。組織が影響を受ける SharePoint

製品が存在するかどうかを迅速に回答できない場合、その検出間隔は修復ではなく資産管理調査から始まる。所有権が不明確な場合、分離またはサービス中断の決定が停滞する可能性がある。バージョンデータが古い場合、間違ったパッケージが選択されたり、サポートされていないシステムがサポートされていると誤認される可能性がある。露出マッピングはインベントリの2番目の部分である。Microsoft と国際当局はオンプレミスサーバーに焦点を当て、緩和策が利用できない場合はインターネット切断または分離を強調した。サーバーは、リバースプロキシ、ロードバランサー、アプリケーションゲートウェイ、VPN、またはローカル設定から明らかでない他のルートを介して公開される可能性がある。外部スキャンは役立つが、意図された経路と意図されていない経路の内部知識を置き換えることはできない。インベントリの品質は緊急事態の前にテストされるべきである。定期的な演習は、運用部門に製品ファミリーの完全な影響を受ける母集団を生成させ、サポートされていないバージョンを特定させ、外部ルートを特定させ、それらを変更する権限のある人を指名させることができる。結果は測定可能である。見つかった資産、欠落している資産、所有権のギャップ、バージョンの不確実性、防御可能な回答までの時間。これは、インベントリが正確でなければならないというポリシーよりも強力な証拠である。

トリガー、根本原因、貢献条件は分離すべき

公開時系列におけるトリガーイベントは、関連するオンプレミス SharePoint Server 脆弱性の能動的悪用であった。5月のデモと7月の脆弱性履歴が先行していたが、能動的悪用の警告は、要求される対応を予定されたリスク削減から緊急行動に変更した。選択された証拠は、単一の完全な根本原因を確立していない。Microsoft の完全なセキュア開発履歴、脆弱性発見からアップデートリリースまでの内部経路、影響を受ける組織内の制御障害を明らかにしていない。見逃されたパッチ、無視された警告、経営判断、または単一の技術的弱点がすべての侵害を引き起こしたと宣言することは支持されない。根本原因の候補は異なる層に存在する。製品層では、4つの CVE レコードが異なる脆弱性クラスを説明する。オペレーター層では、可能性のある候補には、未知の資産、サポートされていないバージョン、インターネット露出、遅れた緊急権限、不完全なアップデートカバレッジ、欠落した防御統合、ローテーションされていないキー、不適切な侵害評価が含まれる。これらは証拠のための質問であり、名前のない組織に関する発見ではない。貢献条件は構造的に特定しやすい。SharePoint Server

はビジネスプロセスに深く統合される可能性がある。ダウンタイムは高くつく可能性がある。ファームは複数のサーバーと依存関係を含むことができる。レガシーカスタマイズはアップグレードを困難にする可能性がある。セキュリティ責任はインフラ、アプリケーション、ID、ネットワーク、ビジネスチーム間で分割される可能性がある。公共部門の展開は調達と変更の制約の下で運用される可能性がある。これらの条件のいずれもそれ自体で悪用を生み出さない。それぞれが対応を遅らせたり複雑にしたりする可能性がある。検出、対応、復旧も別々の判断を必要とする。検出は、組織がいつ脆弱性または侵害について知り、どのようなシグナルを持っていたかを尋ねる。対応には、インベントリ、分離、パッチ適用、防御構成、通信、調査が含まれる。復旧には、信頼できる安定したエンド状態と継続性の復元が必要である。迅速なパッチは遅い検出と共存できる。タイムリーな対応は不完全な復旧と共存できる。段階を混同すると、説明責任が不正確になる。カテゴリが制限されたままの場合、証拠は最も強力である。確認された事実には、ベンダーと政府の警告、異なる CVE レコード、製品固有のアップデート、能動的悪用、記載された修復手順が含まれる。支持される推論は、オンプレミス制御をインベントリ、ライフサイクル、変更、キー、継続性の義務に接続する。未知のものには、最終的な被害者数、すべての環境の状態、完全な攻撃者の全体像、各対応の完了品質が含まれる。

責任はコントロールマップに従った

Microsoft は、製品開発、脆弱性記録、セキュリティアップデート、顧客ガイダンス、独自の脅威インテリジェンス属性を管理していた。選択された証拠は、その公開された修復トレイルの明確さとタイミングを評価することを支持するが、確定された法的失敗や完全な内部決定記録を確立しない。オペレーターは、オンプレミス環境の状態を管理していた。それには、インベントリ、サポートバージョン計画、ネットワーク露出、インストール、AMSI または同等の保護統合、マシンキーローテーション、IIS 再起動、監視、侵害評価、サービス復旧が含まれる。一部の組織は、その作業の一部を管理サービスプロバイダーまたはインテグレーターに委任している可能性がある。委任はタスクを移転できるが、完了と証拠について責任者が誰であるかを知る必要性を排除しない。ビジネスオーナーは継続性の優先順位を管理していた。彼らは、SharePoint

がどのように作業をサポートし、停止が何を中断するかを知っていた、または知る立場にあるべきだった。彼らの役割は技術パッケージを選択することではなかった。緊急ダウンタイムを承認し、残存リスクを受け入れ、代替プロセスをサポートし、依存関係が中断する権限を持つ者がいないためにオンラインのままにならないようにすることであった。上級リーダーシップはエスカレーションとリソースを管理していた。インターネットに面したコラボレーションプラットフォームの能動的悪用は、通常の予算とメンテナンススケジュール外の行動を必要とする場合がある。リーダーは簡潔な運用状況を受け取るべきである。影響を受ける資産数、サポートされているバージョンとされていないバージョン、外部露出、パッチ完了状況、分離状態、キーローテーション、侵害の兆候、サービス影響、未解決のブロッカー。それらのフィールドの背後に証拠のないダッシュボードは、外観を提供するが制御を提供しない。公的機関は、管轄区域内の警告、必須指示、共有防御分析、広範なリスクコミュニケーションを管理していた。CISA の KEV 追加とマルウェア分析は、各国の CERT ガイダンスとともに、公的対応を強化した。組織のファーム内でアップデートをインストールしたりキーをローテーションしたりすることはできなかった。最終的な運用マイルはローカルのままであった。

パッチ準備は次の緊急事態の前に測定される

重要な脆弱性は迅速にパッチ適用されると言うポリシーだけでは十分ではない。準備は演習と運用証拠を通じて実証されるべきである。最初の尺度は母集団までの時間である。影響を受けるすべてのサーバー、バージョン、所有者、露出ルートを特定するのにかかる時間。2番目は権限までの時間である。分離または緊急変更を承認するのにかかる時間。3番目は確認された制御までの時間である。該当するアップデートをインストールし、必要なインストール後のアクションを完了し、信頼できる状態を確立するのにかかる時間。カバレッジは速度と同じくらい重要である。組織は、クローズされたチケットの数ではなく、インベントリに対して展開結果を照合する必要がある。例外は、資産、理由、補完的制御、所有者、期限、承認を明示すべきである。サポートされていないシステムは、資金提供された終了パスを持つべきである。パッチがなく分離もないシステムは、運用バックログに隠れるのではなく、経営陣のリスクとして可視化されるべきである。シークレットローテーションには、それ自体の準備テストが必要である。チームは、ファーム全体で新しいマシンキーを生成、保護、配布、アクティブ化、検証、必要に応じて復旧する方法を知っているべきである。サービス中断とアプリケーション検証の要件を理解しているべきである。最初の試行は、能動的悪用がすでに進行している間に行われるべきではない。侵害評価も準備を必要とする。関連する期間のログとテレメトリが利用可能でなければならない。保持は、悪用が発

見されるまでにかかる時間と一致するべきである。セキュリティチームとアプリケーションチームは、調査を1つのファイルハッシュまたはスキャナー結果に縮小せずに、インジケータをレビューするための共通のプロセスを必要とする。既知のインジケータに対するクリーンチェックは有用な証拠であるが、他の活動がなかったことの証明ではない。継続性計画はループを閉じる。分離が必要な場合、ユーザーは重要なドキュメント、承認、運用情報にアクセスするための代替手段を必要とする。選択された証拠は、影響を受ける組織でどの

SharePoint 使用が重要であったかを特定していない。各オペレーターは、サービスがどれだけ利用不可になるか、どの最小限の機能を最初に復元する必要があるかを決定する前に、その依存関係を可視化しなければならない。取締役会レベルの質問は、取締役が SharePoint を設定できたかどうかではない。ガバナンスが経営陣に露出を把握し、サポート可能性を維持し、移行債務に資金を提供し、緊急権限を行使し、復旧の証拠を提出することを要求したかどうかである。ToolShell は、公開された修復経路が行われなければならない作業を指名したため、これらの制御を観察可能にした。

未知のもの

影響を受けた組織、サーバー、ユーザーの最終数は不明である。シンガポールの勧告によって中継された日付の数字は最終的なカウントではない。選択された証拠は完全なグローバルセンサスを提供しておらず、外部観測はそれが見るすべてのサーバーの内部影響を確立することはできない。個々の環境の状態は不明である。記録は、悪用の試みの前に7月のアップデートをインストールしたオペレーター、AMSI を有効にしたオペレーター、キーをローテーションしたオペレーター、サーバーを分離したオペレーター、以前のアクセスの証拠を見つけたオペレーターを示していない。名前の付いた組織を対応品質でランク付けすることを支持しない。Microsoft は活動を Storm-2603、Linen Typhoon、Violet Typhoon に帰属させた。その帰属は Microsoft のものとして残るべきである。利用可能な公開証拠は、完全な攻撃者の全体像を独立して検証しておらず、アクターの命名は、すべてのクラスターがすべてのターゲットに対して同じ方法を使用したことを確立しない。完全な技術的根本原因とベンダーの意思決定チェーンは確立されていない。CVE 説明は脆弱性クラスを特定し、Microsoft

と公的機関は対応を文書化している。完全な組織因果分析に必要なすべての開発、テスト、開示、リリース決定を開示していない。最終的なビジネスおよび公共サービスの結果も不明である。ソースは緊急性と継続性リスクを支持するが、普遍的な停止、最終的なランサムウェア影響総額、特定の財務損失、名前の付いた被害者でのサービス障害を確立していない。これらの境界はそのまま維持されるべきである。

説明責任テストは制御が準備できていたかどうか

ToolShell は単純だが要求の厳しい原則を露呈した。オンプレミス制御はオンプレミスの説明責任を伴う。SharePoint Server を維持した組織は、それがどこで実行されているか、サポートされているか、どのように露出しているか、誰がそれを中断できるか、どれだけ迅速に更新できるか、キーをどのようにローテーションするか、どの証拠が復旧を正当化するかを知る義務も維持した。公開時系列はその義務をテストするのに十分具体的である。5月のチェーン履歴は、明確な以前の脆弱性を確立した。7月20日は CISA の能動的悪用警告と KEV 追加をもたらした。Microsoft は拡張された脅威と修復ガイダンスを公開し、7月21日のサポートページは製品固有のアップデートを提供した。各国当局はオンプレミスの境界と緊急行動の必要性を強化した。8月の防御分析は、即時のパッチ適用から悪用後の評価へと作業を拡張した。トリガーは確認されている。普遍的な根本原因は確認されていない。貢献条件には、ライフサイクル債務、複雑なファーム、外部露出、分散所有権、継続性圧力が含まれる。対応は、アップデート、分離ガイダンス、防御統合、キーローテーション、再起動、公開アラートで可視化される。復旧は、それらのアクションが信頼できる安定した環境を生み出したかどうかに依存し、公開記録はすべてのオペレーターについてそれを確立することはできない。このケースは、影響範囲を SharePoint Online

に拡張せず、オンプレミスサーバーの普遍的な侵害を確立せず、すべてのイベントを1つの脅威アクターに割り当てない。エクスプロイトの指示を必要としない。それは制御の規律ある説明を必要とする。誰が資産を所有していたか、誰が依存関係を理解していたか、誰が緊急行動を承認できたか、誰がパッチ適用が復旧になったことを確認したか。次の能動的に悪用される脆弱性は、独自のスケジュールで到着する。組織はその日付を選択できない。在庫が最新であるか、バージョンがサポートされているか、分離が可能か、変更がリハーサルされているか、シークレットをローテーションできるか、証拠が保持されているか、リーダーが継続性が封じ込めにいつ譲らなければならないかを知っているかを選択できる。それが ToolShell が残したパッチ準備説明責任テストである。

ソース