Secure Server リポジトリをSecure

オンプレミスのSharePointユーザーや管理者がファイルをアップロードすると、そのファイルはサードパーティ製のウイルス対策ソフト、またはAMSI対応エンジン（Microsoft Defenderなど）によってスキャンされます。ファイルがこの初期スキャンを通過すれば、処理済みとみなされます。「一度クリーンになれば、永久にクリーン」という考え方です。まさにこの前提があるからこそ、マルウェアやランサムウェアのペイロードが、検出されることなくリポジトリ内に潜み続け、時には何年も放置されてしまうのです。

マイクロソフトもそのことを率直に認めています。SharePointのマルウェア対策機能は被害を最小限に抑えることはできますが、唯一の防御手段にはなり得ないのです。

BFSI（銀行・金融サービス・保険）、医療、政府機関、およびOT（運用技術）や重要インフラ環境において、リスクにさらされているデータとは、コンプライアンス関連書類、患者記録、案件ファイル、技術文書などを指します。これらはすべて、年々膨れ上がり続けるデータライブラリに保管されていますが、そこにすでに格納されている内容を再検討するために取り出すことは一切行われていません。

以下では、SharePointのウイルススキャンが実際にどのように機能するか、スキャンの対象外となる項目、そして多層的で効果的なSharePointファイルリポジトリのセキュリティ体制がどのようなものであるべきか、という3つの点について解説します。

Enlyftのテクノロジー導入データは、現在Microsoft SharePointを導入している256,295社を追跡しており、その業種はITサービスから銀行、医療、石油・ガス、政府機関まで多岐にわたります。これらの企業の従業員数は通常50～200名、売上高は100万～1,000万ドルです。

その規模こそが、攻撃者がSharePointリポジトリに注目し、それを高価値な標的として扱う理由なのです。

以上のことは、SharePointがサーバーのセキュリティ対策を講じていない、あるいはファイルのセキュリティを軽視しているという意味ではありません。マイクロソフトのドキュメントによると、SharePointServer は2つのスキャンインターフェースとServer 可能です。

• VSAPI（Virus ScanningAPI）は、SharePointのウイルス対策統合インターフェースであり、互換性のあるサードパーティ製ウイルス対策ソフトウェアが、アップロードやダウンロードなどの操作中にドキュメントをスキャンできるようにするものです。

• AMSI（Antimalware Scan Interface）は、Microsoft のマルウェア対策統合フレームワークであり、SharePointServer 、サポート対象のコンテンツ操作中に、AMSI 互換のウイルス対策エンジン（Microsoft Defender など）Server マルウェアスキャンServer ものです。

SharePointServer は、VSAPI、AMSI、または自動モードのいずれかを使用するように構成できます。どのオプションが設定されていても、一度にファイルを評価するのは 1 つのスキャン エンジンだけです。

スキャンはイベント駆動型であり、ユーザーがドキュメントをアップロードまたはダウンロードした際にトリガーされます。事後的に、あるいは定期的に実行されることはありません。ファイルの評価を行うのは、1つのエンジン（Microsoft Malware Protection Engine、通称 MpEngine.dll）のみです。

重要なポイント：ファイルは 、アップロード時またはダウンロード時に、単一のエンジンによって、そのエンジンが持つ最新のシグネチャと検知機能を用いてスキャンされます。

この手法は、その特定のエンジンの検知ロジックを回避するよう特別に設計されたファイル型脅威を検知することを目的としたものではありません。特に、高度で持続的な脅威（APT）は、しばしばまさにこの限界を悪用し、長期間にわたり検知されずに潜伏し続けます。

こうした脆弱性により、攻撃者が信頼されたSharePointコンテンツを悪用する道が開かれてしまいます。すでに、脅威アクターが侵害されたSharePointサイトを悪用し、フィッシング文書や悪意のあるリンクをホストした攻撃事例が報告されています。

ゼロデイ攻撃は、クリーンなファイルと同じようにスキャンを通過してしまいます。その理由は、単にまだそれを検知するエンジンが存在しないからです。また、SharePointは既存のコンテンツを後から再スキャンしないため、初日にスキャンを通過したゼロデイ攻撃ファイルは、たとえベンダーがそのファイルを検知できるシグネチャの更新をリリースした後であっても、200日目になっても再検査されることはありません。

未知の脅威も同様の仕組みで動作します。シグネチャが紐付けられていないため、静的解析（ウイルス対策エンジンが行う処理）では、その脅威を検出することができません。

注：これらは欠陥ではなく、対応範囲の不足です。SharePointServer標準搭載のウイルス対策機能は、特定の操作ポイントにおけるその時点でのチェックを行うために設計されており、拡大し続けるバージョン管理されたリポジトリを、絶えず変化する脅威の状況に対して継続的に再検証するためのものではありません。

2025年7月、マイクロソフトは、オンプレミスのSharePointServerを及ぼす、認証不要のリモートコード実行の脆弱性チェーン（CVE-2025-49706、CVE-2025-49704）が実際に悪用されていることを公表しました。その後、CVE-2025-53770および CVE-2025-53771もこのリストに加わりました。 このエクスプロイトは、動作するために認証情報やログインを必要としませんでした。

その後、マイクロソフトがパッチを適用し、このエクスプロイトチェーンには「ToolShell」という名称が付けられた。

『Infosecurity Magazine』が引用したEye Securityの分析によると、41カ国の145の組織において、396台のシステムが侵害されていたことが判明した。政府機関が最も大きな打撃を受け、確認された感染事例の30％を占めており、そのうち米国だけで全体の31％を占めていた。 これとは別に、Shadowserver Foundationは、数百の組織を侵害したこの脆弱性が公表された後も、10,700件以上のSharePointインスタンスが依然として公開されたままであり、同じエクスプロイトチェーンを実行する者なら誰でもアクセス可能であったと報告した。このエクスプロイトの背後にいるグループの一つであるStorm-2603は、この公開状態を利用して「Warlock」ランサムウェアのペイロードを配布した。

侵入に成功すると、Storm-2603は盗んだ認証情報と正規の管理ツールを使用して、システム間を横方向に移動した。この移動は、本来そのシステムに存在すべきツールを利用していたため、警報は発せられなかった。Storm-2603はWebシェルをインストールし、重要なデータを外部へ持ち出した。攻撃者は、有効な認証トークンを偽造するために必要な鍵をすでに盗み出していたため、脆弱性が修正された後もアクセスを維持し続けた。

ToolShellは、4つのCVEを連鎖させて構築されており、当初からパッチ回避機能が組み込まれていました。CVE-2025-53770および-53771が存在するのは、CVE-2025-49704および-49706に対する当初の修正を迂回することが可能だったためです。

本当に重要なのは、攻撃者がパッチの適用サイクルよりも速く対応し、同じ標的に対して、わずか数週間の間に2度も攻撃を仕掛けたという点だ。

単一のアンチウイルスソフトが、あるベンダーの署名と照合してファイルを一度だけチェックするような静的な防御手段は、そもそもサーバーサイドのエクスプロイトチェーンを検知するようには設計されていません。また、パッチ適用後に、そのパッチを迂回する手法を持って再び攻撃を仕掛けてくる攻撃者に対しては、防御することができません。

ToolShellは、現在SharePointサーバーを特に標的とした攻撃がいかに高度化しているかを如実に示しています。このようなエクスプロイトが今回で最後だったと想定する理由はありません。これらのサーバー上に保存されているデータは、最新の脅威に対応できるよう設計された仕組みによって保護されているのでしょうか、それとも、一度スキャンして「完了」とするだけの対策で済まされているのでしょうか？

公平を期すために言えば、ToolShellはアップロードスキャンをすり抜けた悪意のあるドキュメントというわけではありませんでした。しかし、攻撃者が配置したWebシェル（spinstall0.aspxおよびその名前が変更された亜種）についてはどうでしょうか？ あれはファイルです。それはサーバー上に残っており、検出されるかどうかは、前述したのと同じ制限、つまり「1つのエンジンによる、1回限りの、特定の時点でのチェック」に左右されるものでした。

これが、今回のインシデントをより広範な議論へと結びつける仕組みです。パッチを適用しても、具体的にはToolShellのエクスプロイトチェーンを封じ込めるだけであり、リポジトリ内にすでに存在している、スキャン対象外の次のファイルに対しては何の対策にもなりません。

2023年以来一度も変更されていないコンテンツについては、実際にスキャンされない限り、上記のいずれの点もそれほど重要ではありません。

これは、SharePoint のネイティブウイルス対策機能では対応できない領域です。つまり、アップロードやダウンロード時だけでなく、定期的または継続的に、バージョン履歴を通じて保持されている古いバージョンを含む保存済みコンテンツを再検査することです。リアルタイム、スケジュール、およびオンデマンドでの再スキャンにより、このギャップが解消され、データベースの更新に合わせてファイルが定期的に検査されます。

これらの対策は、それぞれ個別に、前述した特定の脆弱性を1つずつ解消します。これらが組み合わさることで、マイクロソフト自身のドキュメントで「組み込みのウイルス対策機能は、単一の防御手段として設計されていない」と指摘されているような、多層的な防御体制が形成されます。

MetaDefender Storage Security は、ハードウェアへの直接インストール用の物理サーバー、仮想化プラットフォーム（VMware、Hyper-V、XenServer に対応）、主要なクラウドプロバイダーが提供する IaaS（Infrastructure as a Service）、あるいは Kubernetes クラスター内でのコンテナ化された展開など、さまざまなモデルを通じて導入可能です。

このチェックリストは、ToolShellのエクスプロイトに関するCISAのガイダンスに基づいています。

1. パッチの適用状況を確認する。

悪用されたすべてのCVEについてはセキュリティ更新プログラムが提供されていますが、パッチを適用していないサーバーは依然としてToolShellの攻撃にさらされたままです。影響を受けるすべてのSharePointServer に対して、マイクロソフトのセキュリティ更新プログラムを適用してください。

2. AMSI が設定されていることを確認します。

AMSIは導入されていても設定が誤っていると、AMSIがまったく導入されていない場合と同じ脆弱性が残ります。AMSIの統合が有効になっていること、およびすべてのSharePointサーバーにウイルス対策ソリューションが導入されていることを確認してください。

3. ASP.NETのマシンキーをローテーションする

マシンキーが盗まれると、サーバーにパッチを適用した後でも、攻撃者が有効な認証トークンを偽造できるようになります。パッチの適用だけでは、すでに盗まれたキーを無効にすることはできません。マシンキーを更新し、セキュリティ更新プログラムを適用してから、再度マシンキーを更新してください。更新のたびに iisreset.exe を使用して IIS を再起動し、applicationHost.config および web.config から悪意のあるエントリを削除してください。

4. 過去に侵害された形跡がないか、手動で確認する。

CISAは、このキャンペーンで使用されている.dllペイロードが、マシンの鍵を取得するために利用される可能性があると指摘しています。パッチを適用しても、サーバーにすでにドロップされているペイロードは削除されません。脆弱性そのものだけでなく、システムや特定のファイルについて、IOC（侵害の兆候）がないか確認してください。

5.サポート終了または提供終了のバージョンがないか確認してください。

一部のSharePointインスタンスはサポート終了（EOL）となっており、悪用活動があるかどうかに関わらず、これ以上のセキュリティ更新プログラムは提供されません。御社で使用しているバージョンが引き続きサポートされているかどうかを確認してください。サポート対象外の場合は、必要な措置を講じてください。

6. 既知の指標についてログを確認する

CISAは、このキャンペーンに関連する特定のリクエストパターンとIPアドレスを特定しています。CISAの参照情報に一致するリクエストについて、検索ログを確認してください。

7. 管理者権限およびレイアウト権限を監査する。

被害の範囲を最小限に抑えるため、SharePoint におけるレイアウトおよび管理権限を誰が保有しているかを確認し、現在必要とされていないアクセス権を削除してください。

8. 現在表示されているものだけでなく、すでに保存されているものも評価する

上記のすべては、エクスプロイトチェーンそのものに対処するものです。これらのパッチの適用以前に作成されたファイルを含め、ドキュメント ライブラリにすでに存在するコンテンツを検証するものは、いずれも含まれていません。

関連するパッチやシグネチャの更新以降、既存のリポジトリコンテンツが再スキャンされているか、あるいは依然として元の（古くなっている可能性がある）スキャン判定がそのまま残っているかを確認します。