パッチだけでは防げない：SharePointの脆弱性の悪用とIISモジュール永続化の隠れた脅威

2025年7月、サイバーセキュリティの世界で「最悪の事態」が発生しました。SharePointに存在する複数の重大な脆弱性が、IISモジュールを悪用した高度な永続化技術と結びつき、企業のセキュリティチームを悪夢のような状況に陥れたのです。SharePointの脆弱性(CVE-2025-53770、CVE-2025-53771、CVE-2025-49704、CVE-2025-49706)は、巧妙な攻撃者によって活発に悪用されていますが、真の危機は初期の侵入段階をはるかに超えて拡大します。

この攻撃がとりわけ悪質な点は、攻撃者が従来のようにWebシェル内にとどまらないことです。悪質なIISモジュールを活用することで、永続的なアクセスを確立して奥深く侵入し、パッチの適用や再起動、従来型のセキュリティスキャンを回避します。これはポストエクスプロイト(侵害後の攻撃)戦略における根本的な進化を意味します。この攻撃によりDLLがディスクに投下された後IISに読み込まれて、検知できないバックドアを作り出しても、ほとんどのセキュリティ製品は手を付けることができません。なぜなら、企業の重要なWebサービスをクラッシュさせてしまう可能性があるからです。

基本情報

主な脆弱性

• CVE-2025-53770：SharePointのToolShell認証バイパスとリモートコード実行(CVSS 9.8)
• CVE-2025-53771：SharePointのToolShellパストラバーサル
• CVE-2025-49704：SharePointのリモートコード実行
• CVE-2025-49706：SharePointの認証後リモートコード実行

影響を受けるシステム：オンプレミスのSharePoint Server 2016、2019、サブスクリプションエディション
攻撃ベクトル：ToolPaneエンドポイントへの認証されていないPOSTリクエスト
初期ペイロード：Webシェルのspinstall0.aspx (およびその亜種)によるマシンキーの窃取
永続化手法：カスタムIISモジュールをDLLとしてw3wp.exeに読み込み
状況：CISAが既知の悪用された脆弱性カタログに追加、パッチが入手可能

SharePointの悪用チェーン

この攻撃は、SharePointのToolPaneエンドポイントにPOSTリクエストを送信するという、一見すると単純な活動から始まります。しかし、この後には高度な多段階の侵害が続き、そのことは攻撃者の手法の進化を示しています。

初期アクセスと偵察

攻撃者は、ToolPaneエンドポイントにPOSTリクエストを送信して偵察を行い、脆弱なSharePointサーバーを調べます。そして認証メカニズムを完全に回避して侵入し、ターゲット環境への即時アクセスを獲得します。

Webシェルの展開

侵入に成功すると、攻撃者はspinstall0.aspxという悪質なスクリプトを展開します(spinstall.aspx、spinstall1.aspx、spinstall2.aspxなどの亜種を含む)。このスクリプトには、MachineKeyデータを取得し、GETリクエストを介して結果を返すコマンドが含まれています。これを布石に、認証情報の窃取やラテラルムーブメントを実行していきます。

実際、その週のうちに、さまざまなspinstallや名前を改変した亜種がリクエスト内で確認されるようになりました。

このWebシェルの主な目的は、ASP.NETのマシンキー(ビューステート、認証Cookie、その他の機密データの復号化に使用できる暗号鍵)を盗み出すことです。盗み出したマシンキーを使うことで、最初の脆弱性にパッチが適用された後でも、永続的なアクセスを維持できるようになります。

WebシェルからIISモジュールへ：永続的アクセスの進化

セキュリティチームがSharePointの脆弱性の修正やWebシェルの検出に取り組む中、水面下ではさらに高度な脅威が出現しています。サーバーへの秘密のバックドアとして、Internet Information Services (IIS)の拡張機能が活用される例が増えているのです。このバックドアはターゲット環境の奥深くに潜み、永続的な侵入経路を攻撃者に用意するものです。

IISのコンポーネントに関する当社の以前の調査で明らかなように、これらの拡張機能は完璧に近い隠蔽手段を攻撃者に提供します。IISのバックドアは検出が非常に困難です。ターゲットのアプリケーションで使用される正規のモジュールと同じ正常なコード構造で、同じディレクトリに配置できるためです。このように正規のモジュールと区別しにくいうえ、悪質なIIS拡張機能はスクリプト型のWebシェルに比べると観測頻度は低くなります。そのため、こうしたバックドアの検出率は相対的に低くなります。攻撃者はその隙を突くのです。

セキュリティソリューションの多くは、IISのワーカープロセス(w3wp.exe)によって読み込まれるDLLを、スキャンもブロックもしません。その理由は、サービスをクラッシュさせ、重要なWebアプリケーション(SharePointやExchangeなど)を停止させてしまうリスクが現実にあるからです。ここに重大な盲点が生じることになります。巧妙な攻撃者はこれを分かったうえで悪用します。とりわけ危険なのは、IISモジュールの緊密な統合性です。イベントハンドラーにリクエストへの完全な読み書きアクセス権が付与されるため、悪質なモジュールがWebリクエストのあらゆる部分に通信を隠蔽できます。その結果、存在するページもしないページも、すべてを潜在的なWebシェルに変えられるようになります。

技術的な仕組み

IISモジュールはWebリクエストのパイプラインの中枢部分で動作し、トラフィックがWebアプリケーションに届く前、およびレスポンスが生成された後に通信を受信します。攻撃者は、BeginRequest、EndRequest、Errorなどのイベントトリガーにイベントハンドラーを設定することで、Webサービスが処理を行う前と、レスポンスがクライアントに送信される前に、すべてのリクエストを傍受できます。

この仕組みを利用して、悪質なモジュールを以下のために使用できます。

• HTTPリクエストやレスポンスを傍受し改ざんする
• 悪質なコマンドを正規のWebトラフィックに隠蔽する
• 不審な子プロセスを作成せずにコードを実行する
• 認証の試行を監視して認証情報を窃取する
• システムの再起動やパッチの適用後も永続的なアクセスを維持する

SharePoint + IISモジュール：最悪の事態

SharePointの脆弱性とIISモジュールによる永続化が組み合わさることで、極めて危険な状況が生じます。攻撃者は通常、まず、ホストされているアプリケーションの重大な脆弱性を悪用して初期アクセスを獲得し、第1段階のペイロードとしてスクリプト型のWebシェルをドロップします。その後さらにIISバックドアを仕掛けることで、秘匿性の極めて高い永続的なアクセスを確保します。

観測された攻撃パターン

Microsoft社の調査と当社の分析によると、この攻撃は一般に、予測可能でありながら高度なパターンをたどります。攻撃者はまず、SharePointの脆弱性を悪用して、認証なしでアクセスします。その後すぐにWebシェルのspinstall0.aspxを展開し、即座に制御を獲得してマシンキーを窃取します。偵察段階では、これらのWebシェルを利用して環境を列挙し、認証情報を収集します。その後、カスタムIISモジュールを展開して長期にわたり持続するアクセスを確立します。最終段階では、埋め込まれたIISモジュールを介して秘密のアクセスを維持しながら、見つかりやすいWebシェルを削除します。

検出の課題

悪質なIISモジュールを検出するには、従来のWebシェル検出とは根本的に異なるアプローチが必要です。通常の手法では高頻度のページリクエストやURIパターンからWebシェルを検出しますが、これでは太刀打ちできません。悪質なIISモジュールに対しては、その代わりに新しい検出手法と詳細なIISログの活用が欠かせません。以降のセクションでは、モジュールの特定に役立つログ取得戦略について、当社の過去の調査をもとに取り上げます。

IISログの有効化とモジュールの収集

Microsoft社は最新のブログで、Webシェルを検出するために詳細なIISログを有効にすることを推奨しています。Microsoft-IIS-Configuration/Operationalログには、サイトやアプリケーションプールによって追加された新しいモジュールの詳細が記録されます。

• IISで利用可能な追加のログを一覧表示：'wevtutil el |findstr -i IIS'
• 選択したログの構成：'wevtutil gl Microsoft-IIS-Configuration/Operational'
• 選択したログを有効化：'wevtutil sl /e:true Microsoft-IIS-Configuration/Operational'

有効にしたら、データを収集するために、inputs.confに以下を追加する必要があります。

[WinEventLog://Microsoft-IIS-Configuration/Operational]
index=win
sourcetype=IIS:Configuration:Operational
disabled = false

Splunkで収集されたデータは、以下のように表示されます。

詳細なIISログは非常に有用なソースですが、Splunk Universal Forwarderを用いたもう1つの手法として、PowerShellスクリプト入力があります。この場合、IISサーバー群にインストールされているすべてのモジュールが収集の対象です。こちらでご説明しているように、inputs.confを介してスクリプトやコマンドを渡し、その出力結果をSplunkに取り込むことができます。ご利用中の環境に適したinputs.confを新しく展開し、モジュール情報を取り込んでください。また、必要に応じて実行予定の時間を変更してください。

[powershell://IISModules]
script = Get-WebGlobalModule
schedule = */1 * * * *
#schedule = 0 0 * * *
sourcetype = Pwsh:InstalledIISModules
index=iis

最新のSplunk Add-On for Microsoft IISには、このスクリプト入力が含まれています。

Splunkでは、以下のように表示されます。

最後の3つのモジュールが、標準ではないパスに存在していることに注目してください。

Splunkでは、IISのログ設定方法もこちらで詳しくご説明しています。特に大切なのは、以下の入力によって主なIISログを収集することです。

[monitor://C:\inetpub\logs\LogFiles]
disabled = false
sourcetype = ms:iis:auto
index = 

次に、ハンティングについて詳しくご説明します。

自社環境内でのハンティング

IISに新しく追加されたモジュールは、w3wp.exe (IISプロセス)に読み込まれます。w3wp.exeに読み込まれたすべてのモジュールを確認するには、EDR製品やSysmonを使えます。

読み込まれたすべてのモジュール

`sysmon` EventCode=7 parent_process_name=w3wp.exe | stats values(ImageLoaded)

通常のモジュールは、一定のパターンで読み込まれます。したがって、一般的なパスを除外して対象を絞り込むこともできます。ただし、絞り込んでも、モジュールの読み込み情報の収集は作業負荷が高く、必ずしも大きな成果が得られるとは限りません。

`sysmon` EventCode=7 parent_process_name=w3wp.exe NOT (process_path IN ("*\\inetsrv\\*", "*\\windows\\system32\\*")) | stats values(ImageLoaded)

当社がモジュールの読み込み方法を検証した際には、モジュールの形式が不正であったことを示すエラーや、IISへの読み込みが正しく行われなかったことを示すエラーが表示されました。その結果、イベントコード2282が生成されました。このコードは、モジュールがIISワーカープロセスに読み込まれなかった場合に表示されます。

永続化の問題

SharePointのパッチを適用した後にもIISモジュールが永続的に残ることがあります。これはセキュリティチームを悩ませる重大な問題です。Webシェルであれば、パッチの適用やシステムの更新によって除去できるかもしれません。ところが悪質なIISモジュールは、Webサーバーのコア機能と一体化してしまいます。

パッチだけでは不十分な理由

永続化の問題は、IISモジュールとWebサーバーインフラの統合の仕組みに起因します。applicationHost.configやweb.configファイルに登録されたモジュールは、パッチの適用やシステムの再起動が行われた後でも、自動で読み込まれ続けます。セキュリティ製品には、IIS DLLの削除を避ける傾向があります。安定性を損なう恐れが当然あるうえ、悪質なIISモジュールが正規のモジュールを装い、周囲に溶け込んでしまうためです。何より厄介なのは、これらのモジュールがw3wp.exeのメモリ空間内で動作し、ほとんどのセキュリティ製品で採用されているプロセスベースの検出メカニズムを巧妙に回避することです。

クリーンアップの課題

悪質なIISモジュールを検出した組織は、難しい決断を迫られます。

• 削除に伴うリスク：モジュールを誤って削除すると、IISがクラッシュし、重要なWebサービスが停止する恐れがあります。
• 検出の難しさ：悪質なモジュールを特定するには、詳細な分析が必要です。
• 永続性の検証：すべてのアプリケーションプールやサイトでモジュールが完全に削除されたことを確認する必要があります。

セキュリティコンテンツ

ここでご紹介する分析は、セキュリティチームが複数のログソースを活用して、IIS Webサーバー上の不審または悪質な挙動を特定できるように作成されています。さらに、CVE-2025-53770に関連したSharePointの侵害を特定するためのセキュリティコンテンツも追加されています。

分析ストーリー：Microsoft SharePointの脆弱性

W3WPからのシェルの生成

以下の分析では、IISワーカープロセスであるw3wp.exeからシェル(powershell.exeやcmd.exeなど)が生成された事例を特定します。

Windows SharePointのToolPaneエンドポイントに対する攻撃の試行

以下の分析では、Microsoft SharePoint Serverの脆弱性CVE-2025-53770 (別名「ToolShell」)に対する潜在的な攻撃の試行を検出します。この検出では、特定のDisplayModeパラメーターを含むToolPane.aspxエンドポイントへのPOSTリクエストを監視します。このパラメーターは攻撃の重要な指標となります。

Windows SharePoint spinstall0 GETリクエスト

以下の分析では、Microsoft SharePointの脆弱性CVE-2025-53770に関連する潜在的なポストエクスプロイトを検出します。攻撃者は通常、ToolPane.aspxエンドポイントを介した侵害に成功すると、「spinstall0.aspx」という名前のWebシェルをSharePointのlayoutsディレクトリに展開します。

分析ストーリー：IISのコンポーネント

データソース：

• PowerShellスクリプトブロックログ(4104)
• Windows Sysmon、プロセス監視
• Microsoft-IIS-Configuration/Operational
• Windowsアプリケーション
• PowerShellスクリプト入力(Get-WebGlobalModule)

Windows：Windowsイベントログの無効化によるHTTPログの無効化

appcmd.exeによるHTTPログの無効化を特定します。

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
as lastTime from datamodel=Endpoint.Processes where NOT (Processes.parent_process_name IN ("msiexec.exe", "iissetup.exe")) Processes.process_name=appcmd.exe
Processes.process IN ("*set config*", "*httplogging*","*dontlog:true*") by Processes.dest Processes.user Processes.parent_process_name Processes.process_name Processes.original_file_name
Processes.process Processes.process_id Processes.parent_process_id
| `drop_dm_object_name(Processes)`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`

Windows IISコンポーネント：新しいモジュールの追加

appcmd.exeによる新しいモジュールの追加を特定します。

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
as lastTime from datamodel=Endpoint.Processes where NOT (Processes.parent_process_name IN ("msiexec.exe", "iissetup.exe")) Processes.process_name=appcmd.exe
Processes.process IN ("*install *", "*module *") AND Processes.process="*image*" by Processes.dest Processes.user Processes.parent_process_name Processes.process_name Processes.original_file_name
Processes.process Processes.process_id Processes.parent_process_id
| `drop_dm_object_name(Processes)`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`

Windows IISコンポーネント：Get-WebGlobalModuleによるモジュール情報の収集

PowerShellスクリプト入力を使用して、すべてのインストール済みIISモジュールの情報を収集し、Splunkに出力します。

`iis_get_webglobalmodule` | stats count min(_time) as firstTime max(_time) as lastTime by host name image | rename host as dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

Windows IISコンポーネント：モジュールの読み込み失敗

モジュールの読み込みが失敗すると、イベントID 2282が生成されます。

`wineventlog_application` EventCode=2282 | stats count min(_time) as firstTime max(_time) as lastTime by EventCode dest Name ModuleDll | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

Windows IISコンポーネント：新しいモジュールの追加

IISのOperationalログのEventCode 29を利用して、新しくインストールされたモジュールを特定します。

`iis_operational_logs` EventCode=29
| stats count min(_time) as firstTime max(_time) as lastTime by OpCode EventCode ComputerName Message | rename ComputerName AS dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

Windows：PowerShellによるHTTPログの無効化

PowerShellスクリプトブロックログを利用して、HTTPログが無効化された時期を特定します。

`powershell` EventCode=4104 ScriptBlockText IN("*get-WebConfigurationProperty*","*Set-ItemProperty*") AND ScriptBlockText IN ("*httpLogging*","*Logfile.enabled*") AND ScriptBlockText IN ("*dontLog*", "*false*") | stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer user_id
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`

Windows PowerShell IISコンポーネント：WebGlobalModuleの使用

PowerShellスクリプトブロックログを利用して、新しいモジュールの追加、有効化、または変更が行われた操作を特定します。

`powershell` EventCode=4104 ScriptBlockText IN("*New-WebGlobalModule*","*Enable-WebGlobalModule*","*Set-WebGlobalModule*")
| stats count min(_time) as firstTime max(_time) as lastTime by EventCode ScriptBlockText Computer user_id
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`

緩和策と対応戦略

すぐに取るべき対策

何よりもまず、SharePointの最新のセキュリティアップデートを、すべての対象バージョンで即座に適用してください。同時に、保護を最適化するために、SharePointでAntimalware Scan Interface (AMSI)統合を構成し、フルモードを有効にすることも重要です。パッチの適用後は、Set-SPMachineKeyコマンドレットを使用して、SharePointサーバーのASP.NETマシンキーをローテーションし、すべてのSharePointサーバーでIISを再起動する必要があります。最後に、すべてのWebサーバーでIISモジュールの包括的なインベントリを実行することで、継続的な監視に必要な基盤を構築できます。Microsoft社が紹介しているその他の緩和策については、こちらをご覧ください。

長期的な防御戦略

防御を効果的に行うには、IISの設定の変更(特にイベントID 29と50)を継続的に監視しつつ、w3wp.exeプロセスでのモジュール読み込みの異常を警戒する必要があります。また、行動分析を導入すべきです。その対象は、通常とは異なる認証パターン、異常なWebリクエスト動作、Webコンテキストからの疑わしいPowerShellの実行、IISプロセスから認証情報へのアクセスの試行です。さらに、ネットワークのセグメント化が欠かせません。具体的には、SharePointサーバーと重要な内部ネットワークとの分離、厳格な出口フィルタリングの導入によるコマンドアンドコントロール通信の阻止、Webサーバーからの異常なネットワークパターンの監視が挙げられます。

結論

SharePointの脆弱性とIISモジュールによる永続化を組み合わせた攻撃手法の登場により、Webサーバーのセキュリティに対するアプローチには根本からの見直しが必要となっています。攻撃者がアクセスを永続化して更新や再起動、従来型のセキュリティスキャンを回避する仕組みを構築できる状況において、パッチ適用だけでは不十分です。

組織では、影響を受けるSharePoint、IIS Webサーバー、システムに対して即座にパッチを適用するとともに、包括的なIISモジュール監査をすべてのWebサーバーで実施すべきです。IISの設定変更に対し詳細ログを有効にすることも不可欠です。併せて、Webプロセスの異常に対する行動検出の導入、モジュールのインストールと読み込みのアクティビティに対する継続的な監視の確立も行いましょう。

こうした高度な攻撃には、それに見合った高度な防御戦略が必要です。従来の「パッチを適用して願うだけ」というアプローチでは、数カ月から数年にわたって検出されずに持続する脅威に対抗できません。

高度な攻撃作戦や最近の脅威事例から明らかなように、攻撃者はIISを利用した永続化手法に多大な力を注いでいます。セキュリティチームには、攻撃者と渡り合える高度な検出と対応の能力が求められます。

事後対応型のセキュリティ対策の時代は終わりました。環境寄生型の手法やインフラの永続化が横行する現在、防御戦略のほうも、私たちが直面している脅威と同じくらい粘り強く高度である必要があります。

詳細情報

セキュリティ分析ストーリーの最新コンテンツは、research.splunk.comとSplunk ES Content Update Appでご覧いただけます。

Splunk脅威調査チームでは、Microsoft SharePointの脆弱性とIISコンポーネントに関する分析ストーリーをご用意し、こうした脆弱性や悪用パターンに対する包括的な検出を提供しています。

フィードバック

ご意見やご要望がございましたら、GitHubからご遠慮なくお寄せください。Splunk Slackチャネル「#security-research」にもご参加いただけます。

寄稿者

このブログ記事を執筆したMichael Haagと、検出内容と分析に協力したSplunk脅威調査チームのメンバー(Raven Tait、Nasreddine Bencherchali、Lou Stella、Bhavin Patel、AJ King、Rod Soto、Eric McGinnis、Teoderick Contreras、Patrick Bareiss)に感謝を申し上げます。