SharePoint ToolShell 2025年 認証の回り込みと MachineKey の窃取

自社で動かす SharePoint Server の2つの弱点が、7月8日の更新で直されたはずだった。直しを回り込む形で、認証の無い要求からコードが走り、攻撃者は ASP.NET の MachineKey を盗んだ。署名の鍵を持たれると、更新を当てても、正しく署名された要求として入り直される。止める所は、更新を当てるだけでなく、鍵を入れ替え、IIS の設定に残された物を掃除し、認証の無い要求を入口で絞ることにある。

CVE-2025-53770 は信頼しないデータのデシリアライズで CVSS 3.1 の基本値9.8、CWE-502。CVE-2025-53771 は認証の不備で6.5、CWE-287[4][5]。それぞれ7月の CVE-2025-49704 と CVE-2025-49706 の直しの回り込みとされる[3]。対象は自社で動かす SharePoint Server の Subscription Edition、2019、2016 で、Microsoft 365 の SharePoint Online は対象外[1]。Microsoft は2025年7月21日までに、支持する全版の更新を出した[1]。CISA の注意喚起の最後の改訂は2025年8月6日[2]。2026年11月時点の公開資料で書いています。

要点

  • Microsoft の分析では、早くて7月7日から、CVE-2025-49706 と CVE-2025-49704 を使って入ろうとする動きがあった。7月8日の更新は、これらを一部しか直していなかった[1][6]。
  • 入った攻撃者は、レイアウトの置き場に aspx のファイルを置き、MachineKey を読み出して返させた[6]。MachineKey は ViewState の改ざんを見つける署名の鍵で、盗まれると、攻撃者が作った ViewState が正しい物として復元され、コードが走る[7]。
  • Microsoft は、更新か AMSI の有効化の後に、MachineKey を入れ替えて全部の SharePoint のサーバーで IIS を再起動するよう求めた[1]。CISA は、更新の前と後に2度入れ替え、再起動の前に IIS の設定から悪い部品の行を消すよう求めた[2]。
  • Microsoft は国家を背景とする2つの集団と、もう1つの集団を挙げ、その1つは7月18日からランサムウェアを配った[6]。
  • 根本の守りは、更新、AMSI の Full Mode、鍵の入れ替え、認証の無い要求を入口で止める公開の絞りの4つ。どれか1つでは足りない。

何が起きたか

7月7日の最初の動き、7月8日の一部の直し、7月19日の Microsoft の公表、7月21日までの全版の更新の4つの段 1 狙われ始める 早くて7月7日 49706 と 49704 で 入ろうとする 2 一部を直す 7月8日 月例の更新 回り込みが残る 3 公表する 7月19日 実際の攻撃を告げ 緩和策を示す 4 全版を直す 7月20日から21日 SE、2019、2016 鍵の入れ替えも 始まりは7月7日、Microsoft の公表は7月19日。どちらも2025年7月 公表から全版の更新まで2日。その間は AMSI と公開の絞りで守る
図1 一部の直しから、回り込みの公表と全版の更新まで
日付 2025年出来事
7月7日Microsoft の分析では、早くてこの日から、攻撃者が CVE-2025-49706 と CVE-2025-49704 を使って入ろうとしていた[6]
7月8日CVE-2025-49704 と CVE-2025-49706 が公開され、月例の更新が出る[8][9]。のちに Microsoft は、この更新は一部しか直していなかったと書く[1]
7月18日Microsoft が Storm-2603 と呼ぶ集団が、これらの弱点を使ってランサムウェアを配り始める[6]
7月19日MSRC が、自社で動かす SharePoint Server への実際の攻撃を公表し、緩和策を示す[1]
7月20日CVE-2025-53770 が NVD に載る[4]。CISA が注意喚起を出し[2]、既知の悪用された弱点の一覧に CVE-2025-53770 を足し、対応の期限を7月21日とする[3]。MSRC が CVE-2025-53771 を記し、直しの出し方を足す[1][5]
7月21日Subscription Edition と 2019 に続き、2016 の更新が出て、支持する全版がそろう[1]
7月22日Microsoft が攻撃の分析を出す[6]。CISA が一覧に CVE-2025-49704 と CVE-2025-49706 を足し、対応の期限を7月23日とする[3]
7月23日Microsoft が Storm-2603 による Warlock ランサムウェアの配布の分析を足し、IIS の再起動の手順を強調する[6]
7月24日から8月6日CISA が注意喚起を改め、ランサムウェアの配布、新しいウェブシェル、IIS の緩和、6つのファイルの解析を足す[2]
  • Microsoft が挙げた集団は、国家を背景とする Linen Typhoon と Violet Typhoon、中国を拠点とするとされる Storm-2603 である。ほかの集団の調べは続いていた[6]。
  • 侵害された組織の数は、Microsoft と CISA の発表には無い。
  • CVE-2025-53771 は、CISA の一覧には載っていない[3]。CISA の注意喚起も、実際に悪用されたとは報告されていないとする[2]。

通った道筋

外に開いた SharePoint に認証の無い要求が届き、認証の回り込みとデシリアライズでコードが走り、aspx が MachineKey を返し、鍵で署名した ViewState で更新の後も入り直せ、さらに資格情報とグループポリシーでランサムウェアを配る 攻撃者 認証の無い 細工した要求 外に開いた SharePoint Server の IIS の中 認証の回り込み ToolPane への POST 49706 と 53771 の系統 コードが走る デシリアライズ 49704 と 53770 の系統 aspx を置く LAYOUTS の下 MachineKey を返す 鍵を持ち出す 署名した ViewState で 更新の後も入り直せる 社内網。Storm-2603 の例 足場を残す 予定の処理、IIS の部品 資格情報を取る LSASS のメモリから 一斉に配る GPO でランサムウェア
図2 入口から鍵の持ち出し、社内網への広がりまで
段何があったか
入口Microsoft は、複数の攻撃者が ToolPane のエンドポイントへの POST の要求で、下調べと悪用を試みるのを見た[6]。CISA は、なりすましの弱点と遠隔のコードの実行の弱点の組み合わせが、認証の無い利用と、なりすましによる認証のある利用をもたらすと書く[2]。
弱点CVE-2025-53770 は、信頼しないデータのデシリアライズで、権限の無い攻撃者が網を通じてコードを実行できる[4]。CVE-2025-49704 はコードの注入で、権限のある攻撃者がコードを実行できる[8]。CVE-2025-49706 と CVE-2025-53771 は認証の不備によるなりすまし[9][5]。CISA は、53770 は 49704 の、53771 は 49706 の直しの回り込みで、新しい更新の方が守りが固いとする[3]。
鍵の窃取攻撃者は細工した POST で spinstall0.aspx という名のスクリプトを置いた。名前を変えた物もあった。このスクリプトは MachineKey のデータを読み、GET の要求の応答で返す[6]。CISA は、dll の形で置かれた悪い部品は見つけにくく、MachineKey を得るのに使えると書く[2]。
広がりStorm-2603 は、SharePoint を動かす w3wp.exe のプロセスから命令を走らせ、レジストリを書き換えて Microsoft Defender の守りを止め、予定の処理と IIS の部品で居残り、LSASS のメモリから資格情報を取り、PsExec と Impacket で横に広がり、グループポリシーを書き換えて Warlock ランサムウェアを配った[6]。

盗まれた鍵がなぜ残るか

サーバーは MachineKey で ViewState の署名を確かめる。鍵を持つ攻撃者が作った ViewState は正しい署名として通り、復元の時にコードが走る。鍵を入れ替えると通らなくなる 盗んだ鍵 K 悪い ViewState を作り K で署名する 署名を確かめる サーバーの鍵も K 正しいと判断する 復元する 作業プロセスの中で コードが走る 鍵を K2 に入れ替え K の署名は合わない 拒む 弱点の更新は、入口の 回り込みを塞ぐだけで 鍵 K を無効にしない 入れ替えても、置かれた 部品や足場は消えない 別に探して取り除く
図3 署名の鍵が漏れると、署名の確かめが攻撃者の側に付く

ASP.NET の Web Forms は、画面の状態を ViewState として隠しの欄に入れて往復させ、MachineKey の ValidationKey で付けた MAC で改ざんを見つける。鍵が攻撃者の手にあれば、攻撃者が作った ViewState は正しい鍵で確かめられて通り、作業プロセスのメモリに悪いコードが読み込まれて走る[7]。弱点の更新は入口を塞ぐが、盗まれた鍵で署名した要求は入口の弱点を使わない。だから Microsoft は更新の後の鍵の入れ替えを「決定的に重要」とし[1]、CISA は更新の前と後の2度の入れ替えを求めた[2]。

入れ替えだけでは片付かない

Microsoft は、公開された鍵で実際に悪用された場合、鍵の入れ替えだけでは、攻撃者が残した裏口や居残りの仕掛けに足りず、外に面したサーバーは入れ直しも強く考えるよう書く[7]。CISA は、applicationHost.config と web.config から悪い部品の行を消さずに IIS を再起動すると、その部品がまた読み込まれると警告する[2]。

クライアントに預けた状態に署名して確かめる作りの一般の形と、その限りは A08 ソフトウェアまたはデータの完全性の不備 の「署名の無いクライアントの状態」と「信頼しないデータのデシリアライズ」にある。署名は鍵が秘密である間だけ意味を持つ。

どこで止められたか

公開、更新、要求の中身の検査、鍵、サーバーの上の振る舞い、社内網の6つの段に止める所を置く 公開 更新 要求の中身 鍵 サーバーの上 社内網 1 認証の無い要求を入口で止める VPN、認証付きの中継。期限切れの版は外す 2 更新を当て、回り込みを待ち構える 一部の直しの後も、攻撃の報告を追う 3 AMSI の Full Mode で中身を見る 要求の本文を検査し、認証の無い悪用を止める 4 鍵を入れ替え、設定を掃除する 更新の後に入れ替え、IIS の部品の行を消す 5 w3wp の振る舞いを見る cmd と PowerShell の起動、LAYOUTS への書き込み 6 資格情報と GPO を守る LSA の保護、Credential Guard、変更の監視
図4 段ごとの止める所
止める所この件で限り
認証の無い要求を入口で止める狙われたのは外に開いた SharePoint だった[6]。Microsoft は、AMSI を使えないなら更新まで外から切り離し、切り離せないなら認証を求める VPN か中継で認証の無い通信を絞るよう求めた[1]。CISA は、2013 以前のような期限切れの版を外から切り離すよう求めた[3]外に開く理由がある業務では、認証付きの中継の側にも弱点の管理が要る
更新を当て、回り込みを待ち構える7月8日の更新を当てていても、回り込みで入られた[1][3]更新は入口を塞ぐだけで、すでに盗まれた鍵と残された部品を消さない
AMSI の Full ModeMicrosoft は、AMSI と Defender Antivirus を全部の SharePoint のサーバーに入れれば、認証の無い攻撃者の悪用を止めるとした。AMSI の連携は、2016 と 2019 では2023年9月の更新、Subscription Edition では 23H2 で既定で有効になった[1]連携を切っていた、古い版のままだった、検査の製品を入れていなかった所には効かない
鍵を入れ替え、設定を掃除する侵入の後に置かれたスクリプトが MachineKey を返した[6]入れ替えは鍵を無効にするだけで、裏口を消さない[7]
w3wp の振る舞いを見るw3wp.exe からの命令の実行と、Defender の守りを止めるレジストリの書き換えがあった[6]。Microsoft は、w3wp.exe が符号化した PowerShell を起動する形と、LAYOUTS の下の不審なファイルを探す問い合わせを示した[6]守りの製品そのものを止められる。改ざんの防止の設定が要る[6]
資格情報と GPO を守るLSASS のメモリから資格情報を取り、GPO でランサムウェアを配った[6]ここで止めても、SharePoint の中身と鍵はすでに取られている

1は入口に届かせない守り、2と3は届いても通さない守り、4は通された後に居残りを断つ守り、5と6は広がりを止める守りになる。7月8日の更新を当てた組織も、2だけに頼っていれば入られた。

守り方

根本の直し方
  • 支持の切れていない版を使い、最新の更新を当てる。SharePoint の更新は累積で、最新を当てれば前の更新は要らない。2016 と 2019 は本体と言語パックの2つを当てる[1]。
  • AMSI の連携を有効にし、HTTP の要求の本文を検査できるなら Full Mode にし、検査の製品を全部の SharePoint のサーバーに入れる[1]。
  • 更新か AMSI の有効化の後に、MachineKey を入れ替え、全部の SharePoint のサーバーで IIS を再起動する[1]。再起動の前に、IIS の設定から心当たりの無い部品の行を消す[2]。
  • 自社で動かす業務のサーバーは、外に開かず、認証を求める入口の後ろに置く。外に開いた物は台帳に載せ、期限切れの版を残さない[1][3]。

片付けの順。Microsoft と CISA の手順を並べた物

1  更新を当てる            累積の最新。2016 と 2019 は言語パックも
2  AMSI を有効にする       Full Mode と検査の製品
3  鍵を入れ替える          Set-SPMachineKey で作り、Update-SPMachineKey で群れに配る
4  IIS の設定を掃除する    applicationHost.config と web.config の不審な部品の行
5  IIS を再起動する        全部の SharePoint のサーバーで
6  侵害を調べる            LAYOUTS の下の aspx と dll、予定の処理、資格情報
  • 3の命令は MSRC の手順による[1]。CISA は、更新の前にも一度入れ替えるよう求める[2]。
  • 4を飛ばして5をすると、攻撃者が足した IIS の部品がまた読み込まれる[2]。
  • 6で痕跡が出たら、鍵の入れ替えで済ませず、入れ直しを考える[7]。その機械から取れた資格情報は全部回す。

架空の自社の業務アプリでの鍵の置き方。値は伏せている

<!-- 悪い例 公開の文書の例の鍵をそのまま使い、全部の環境で同じ -->
<machineKey validationKey="SAMPLE_FROM_DOCS" decryptionKey="SAMPLE_FROM_DOCS" />

<!-- 直した例 1台なら自動の生成に任せる。群れなら環境ごとに作り、定期に入れ替える -->
<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" />
  • Microsoft は2025年2月、文書やリポジトリに公開された3000を超える ASP.NET の鍵を見つけ、そのような鍵を使わず安全に作るよう求めた[7]。この件では鍵は盗まれたが、公開された鍵でも同じことが起きる。
  • 鍵が入った設定ファイルへの読み取りを監査し、IIS の作業プロセスや管理の口座以外が読んだら知らせる[7]。秘密の置き場所と、漏れた時の順は 秘密の鍵の扱い にある。
緩和の策
  • EDR を遮断の形で動かし、改ざんの防止を有効にする。LSA の保護と Credential Guard を有効にし、PsExec と WMI からのプロセスの起動を止める規則を使う[6]。
  • WAF と IPS の規則を更新し、ログを厚くし、レイアウトと管理の権限を絞る[2]。
  • 直しの回り込みは、一部の直しの直後によく出る。実際の攻撃が報じられた弱点は、更新を当てた後も、提供元の続報と CISA の一覧を追う。
  • 認証の回り込みの一般の型と、資格情報の宛先を確かめる守りは A07 認証の不備 にある。

参照

  1. Customer guidance for SharePoint vulnerability CVE-2025-53770 MSRC、2025年7月19日、7月23日の7.0版
  2. UPDATE: Microsoft Releases Guidance on Exploitation of SharePoint Vulnerabilities CISA、2025年7月20日、8月6日改訂
  3. Known Exploited Vulnerabilities Catalog の CVE-2025-53770、CVE-2025-49704、CVE-2025-49706 の項 CISA
  4. CVE-2025-53770 NIST NVD
  5. CVE-2025-53771 NIST NVD
  6. Disrupting active exploitation of on-premises SharePoint vulnerabilities Microsoft Threat Intelligence、2025年7月22日、7月23日更新
  7. Code injection attacks using publicly disclosed ASP.NET machine keys Microsoft Threat Intelligence、2025年2月6日
  8. CVE-2025-49704 NIST NVD
  9. CVE-2025-49706 NIST NVD