SharePoint Server 2019 に CVE-2025-53770（ToolShell 関連）向けの 2025年7月の臨時（OOB）パッチを適用し、推奨対策も実施したのに、Microsoft Defender の「SuspSignoutReq」や「SharePoint サーバー脆弱性の悪用の可能性」が止まらない――この状況をどう捉え、何を確認すべきかを実運用目線で整理します。
結論：パッチ適用後でも「SuspSignoutReq」アラートが出続けることはあり得る
先に結論から言うと、パッチ適用と推奨対策（AMSI、Defender/EDR、MachineKey ローテーションなど）を正しく実施していても、Defender の検出（特に「SuspSignoutReq」や「Possible exploitation of SharePoint server vulnerabilities」）が継続するケースはあります。
これは多くの場合、「攻撃が成功している」のではなく「攻撃（またはスキャン）の試行が来ており、検知・ブロックできている」という状態です。つまり、アラートが出ること自体がただちに“侵害確定”を意味しません。
「SuspSignoutReq」とは何を見ているのか（なぜ SharePoint で出やすいのか）
「SuspSignoutReq」は、SharePoint/IIS の HTTP リクエストの典型的な悪用パターン（またはそれに似た挙動）をシグネチャ的に検知します。ToolShell 系の試行と関連付けられやすく、次のような特徴が重なるとアラートになりやすいです。
| 観測されがちな特徴 | 例 | 意味合い（運用上の解釈） |
|---|---|---|
| 不審な POST 先 | POST /_layouts/15/ToolPane.aspx?DisplayMode=Edit | ToolPane を絡めた悪用・検証・スキャンの試行で見えやすい。パッチ後も「狙い撃ち」アクセス自体は止まらない。 |
| 参照元（Referer）が SignOut を指す | Referer: /_layouts/SignOut.aspx | 典型パターンに一致しやすい条件。攻撃者だけでなく診断ツールでも“それっぽい”通信になることがある。 |
| 対象プロセス | w3wp.exe（IIS ワーカープロセス） | SharePoint は IIS 上で動作するため、入口は基本的に w3wp.exe。入口検知＝侵害ではなく“入口に来た”だけの可能性がある。 |
ポイントは、Defender が見ているのは「脆弱性の有無そのもの」ではなく「悪用に似た試行」であることです。よって、パッチを当てた後でも、インターネット上のスキャンや攻撃者の“当たり判定”が続けば、アラートは発生し得ます。
パッチを当ててもアラートが消えない主な理由
「パッチが正しく当たっていないのでは？」と疑いたくなりますが、現場では次のパターンが多いです。
| よくある原因 | 起きていること | 運用上の判断 |
|---|---|---|
| 外部からの継続スキャン | 攻撃者やボットが、パッチ適用済みかどうかに関係なく同じパスを叩き続ける | ブロックされているなら想定内。送信元 IP/頻度を見て FW/WAF 側で抑止を検討 |
| 社内・委託先の脆弱性診断（VDR） | 診断ツールが「実際に突く」方式で検査し、Defender が試行として検知 | “攻撃”ではなく“点検”でもアラートは出る。スキャン元の特定と合意形成が重要 |
| EDR/AMSI が正常に働いている | 入口で検知し、実行フェーズ（ポストエクスプロイト）へ進ませない | 「アラートが出る＝守れている」可能性がある。Blocked/Prevented の状態確認が第一 |
| ファーム内の適用ムラ | 一部の SharePoint サーバーだけ更新漏れ、再起動未実施、構成反映不足 | ここだけは要注意。全台の更新状況とバージョンを必ず棚卸し |
特に見落としがちな点として、脆弱性診断ツールは「URL にアクセスしてバナーを見る」だけではなく、“脆弱性を再現するようなリクエスト”を送って確認するものが少なくありません。これに対して Defender が正しく反応すると、ブロック済みでもアラートは残り続けることがあります。
最優先：侵害の有無を切り分ける（アラートの“質”を見る）
不安なときほど、アラートの件数よりも中身を見ます。運用の切り分けは次の順番が現実的です。
Defender 側でまず確認するポイント
- アラートが “Blocked / Prevented / Remediated” になっているか（少なくとも「許可して通してしまった」状態ではないか）
- 関連する端末（サーバー）のタイムラインで、w3wp.exe から不審な子プロセスが起動していないか
- 同時刻に別種のアラートが連鎖していないか（資格情報窃取、永続化、横展開、外部通信など）
「SuspSignoutReq」単体が出ていても、実行・永続化・横展開の兆候が一切ないなら、まずは“入口で止まった可能性が高い”と見立てられます。
サーバー側で確認するポイント（侵害サインの有無）
- IIS ログで該当リクエストが
200で通っていないか、異常に多い連続試行がないか - w3wp.exe の異常（見慣れないモジュール、急な CPU スパイク、普段と違う AppPool の挙動）
- 不審なプロセス起動（cmd.exe / powershell.exe / rundll32.exe などが w3wp.exe 配下で動いていないか）
- 外部宛て通信（SharePoint サーバーが普段出ない宛先へ通信していないか）
- SharePoint/Windows のログに、設定改変・権限昇格・不審な認証試行がないか
ここで重要なのは、「アラートが出た」ことの確認ではなく「侵害の痕跡があるか」を確認することです。攻撃者は成功した場合、入口の次に必ず“痕跡”を残します。逆に言えば、痕跡が出ないまま入口検知だけが続くのは、スキャンや攻撃試行がブロックされている典型像です。
パッチ適用と推奨対策を再点検するチェックリスト
「想定どおりの検知」か「適用漏れ/構成漏れ」かを短時間で切り分けるために、最低限ここは棚卸しします。
| 確認項目 | 見るべき観点 | 運用の勘所 |
|---|---|---|
| 2025年7月 OOB/セキュリティ更新の適用 | 全 SharePoint サーバーに更新が入っているか（適用ムラがないか） | ファーム構成だと“1台だけ漏れ”が一番危険。WSUS/手動/検証環境の差分も要確認 |
| AMSI の有効化 | SharePoint/IIS の実行経路で AMSI が実際に効いているか | 「設定したつもり」より「ブロックできた事実」が強い。Defender のイベント/検知から裏取り |
| Defender Antivirus の状態 | リアルタイム保護、クラウド保護、定義の鮮度 | 定義が古いと検知粒度が落ちる。更新できないネットワーク設計になっていないか注意 |
| Microsoft Defender for Endpoint（EDR） | ブロックモードやポリシーが意図どおりか | “検知だけ”と“阻止”は別。運用は阻止まで前提にして設計する |
| ASP.NET MachineKey のローテーション | 実施済みか、ファーム全体で整合が取れているか | ローテーション不足はリスクを残す。実施手順・影響範囲・ロールバックを準備してから行う |
| Defender 定義の下限 | 所定バージョン以上（例：1.431.525.0 以上）か | 「検知が弱い＝アラートが減る」ではない。弱いと気づけないだけになる |
Defender の定義バージョン確認コマンド例
Windows Defender の定義が古いと、同じ攻撃試行でも検知やブロックの精度が変わります。サーバー上で次のように確認できます。
Get-MpComputerStatus | Select-Object AMServiceEnabled, AntispywareEnabled, AntivirusEnabled, RealTimeProtectionEnabled, AntivirusSignatureVersion, NISEnabledEDR 側（Microsoft Defender for Endpoint）でイベントを追えるなら、サーバー単体のログよりもタイムラインで「実行に至っていない」ことを確認しやすくなります。
IIS ログで「試行」か「侵害の入口」かを見分ける
「SuspSignoutReq」は HTTP リクエストが起点になることが多いため、IIS ログが非常に有効です。見るべきポイントは次のとおりです。
| 見る項目 | 判断の目安 | 具体例 |
|---|---|---|
| ステータスコード | 401/403/404 が多いなら失敗/遮断の可能性が高い。200 が続く場合は要深掘り | POST ToolPane.aspx が常に 403 |
| 送信元 IP | 社内/VPN/診断基盤の IP か、未知の外部 IP か | 診断ツールの固定 IP から周期的に来る |
| User-Agent | スキャナー由来の UA（製品名/ライブラリ名）や、空/不自然な UA は手がかり | Mozilla/5.0 だけ、または特定製品名を含む |
| 頻度・時間帯 | 一定周期＝診断の可能性。ランダム大量＝外部攻撃の可能性 | 毎日深夜 2:00 に集中 |
もし送信元が自社/委託先の診断基盤だった場合、Defender の観点では“正しく検知している”状態でも、運用の観点では“アラートノイズ”になり得ます。次の章のように扱いを整理すると現場が回りやすくなります。
送信元が脆弱性診断ツールだった場合の現実的な落としどころ
脆弱性診断（VDR）や外部スキャンを止めるのが難しい環境では、次の考え方が実務的です。
アラートを「消す」より「意味づけ」する
- 診断ツールが叩く URL/パスが分かるなら、スキャン計画・対象範囲・実施時間を明文化して、アラート発生と突合できるようにする
- Defender 側の運用として、同一送信元・同一パターン・Blocked 継続を「想定内」に分類し、例外的な変化（別送信元、別アラート、実行兆候）だけを優先調査する
- 診断担当と合意できるなら、SharePoint 側で負荷対策（スキャン時間の分散、レート調整、対象の絞り込み）を検討する
それでも注意すべきポイント
診断ツールが原因であっても、「本物の攻撃」が混ざる可能性はゼロではありません。したがって、次の条件が混ざったら“想定内”扱いを一段引き締めます。
- 同時刻に、w3wp.exe からの不審な子プロセス起動が観測される
- 同一パターンのはずなのに、突然ステータスコードが変化（例：403 ばかりだったのが 200 が増えた）
- 送信元が診断 IP ではなく、未知の外部 IP が増える
- 「SuspSignoutReq」以外の、ポストエクスプロイト系のアラートが連鎖する
外部からの攻撃試行が多い場合に追加で効く対策
パッチ・AMSI・EDR が揃っていても、入口への“叩き”が多いほど監視負荷とリスク（別脆弱性の探索）も上がります。可能なら、アプリ層だけでなくネットワーク層でも圧をかけるのがおすすめです。
公開形態を見直す（最も効く）
- SharePoint をインターネットへ直接公開している場合、公開方式（リバースプロキシ/WAF 経由、VPN 経由、条件付きアクセス）を再評価する
- 管理系 URL や不要なエンドポイントは、公開しない/到達させない設計へ寄せる
FW/WAF/リバースプロキシでの抑止
- 送信元 IP が偏っているなら、レート制限やジオブロック、IP 制限を検討
- SharePoint 前段に WAF があるなら、ToolShell で狙われがちなパスへの異常 POST をルールで扱う（ただし誤検知に注意）
- ログ相関（WAF ログ × IIS ログ × Defender アラート）で、“どこで止めたか”を見える化する
重要なのは、アプリの防御（AMSI/EDR）だけに頼らず、入口のトラフィックを減らして運用コストも下げることです。
「想定どおりの動作」と判断できる条件
最終的に、“アラートは出るが問題ない”と判断するには、次の条件を満たしているかで整理するとブレません。
| 判断の軸 | 満たしている状態 | 満たしていない場合のリスク |
|---|---|---|
| 更新適用 | 全 SharePoint サーバーで 2025年7月の OOB/セキュリティ更新が適用済み | 一部未適用があると、その 1 台が突破口になり得る |
| ブロック可視化 | Defender/EDR の記録で Blocked/Prevented が確認できる | 検知だけで通していると、次段の侵害へ進む可能性 |
| 侵害痕跡 | 不審プロセス、外部通信、永続化の兆候がない | 痕跡があるなら即インシデント対応（封じ込め・調査） |
| 送信元の説明可能性 | 送信元 IP/時間帯/UA から、診断や既知スキャンと突合できる | 説明不能な大量アクセスは追加対策（WAF/FW）を検討 |
これらを満たす場合、「攻撃試行は来ているが、ブロックされている結果としてアラートが出る」という整理ができます。逆に、どれかが欠ける場合は「パッチ未完了」や「構成漏れ」「別経路の侵害」を疑って深掘りします。
現場でありがちな勘違いと、避けたい対応
「アラートが出る＝パッチが無意味」ではない
パッチは“脆弱性を塞ぐ”ものですが、Defender のアラートは“攻撃パターンの試行”にも反応します。パッチ適用後でも、攻撃者は同じ手口で叩いてきます。むしろ、叩かれている事実が可視化される点は、守りを強くする材料になります。
「うるさいから Defender を弱める」は逆効果
ノイズを減らしたい気持ちは分かりますが、Defender/EDR を緩めると、本当に危ない挙動まで見落とすリスクが上がります。やるべきは、検知を捨てることではなく、
- 送信元の特定（診断か外部か）
- Blocked の確認（止められているか）
- 入口トラフィックの抑止（WAF/FW/公開方式）
- アラートの運用ルール化（例外条件・エスカレーション条件）
といった運用の整流化です。
運用に落とし込むためのミニチェック（そのまま使える観点）
- 同じアラートが続く：送信元 IP は同じか、時間帯は規則的か。診断/スキャンの可能性を疑う
- Blocked が確認できる：入口で止まっているなら、次は「送信元対策」と「監視負荷の削減」へ
- 別アラートが増えた：横展開や実行兆候が混ざるなら、想定内扱いをやめて調査優先度を上げる
- 200 が増える：IIS ログで成功応答が増えたら、パッチ適用漏れ・構成漏れ・別経路を疑う
- 公開している：インターネット直公開なら、公開方式の見直しが最優先のコスパ施策
まとめ：アラートを“消す”のではなく、“意味のある監視”に変える
SharePoint Server 2019 の CVE-2025-53770 対策を実施しても、「SuspSignoutReq」などの Defender アラートが出続けることは珍しくありません。攻撃者やスキャナーはパッチ適用済みかどうかに関係なく叩いてくるため、アラート＝侵害成功とは限らず、ブロックできている証拠になっている場合もあります。
大切なのは、
- パッチと推奨対策が全台で揃っていること
- Blocked/Prevented を確認して「止められている」ことを裏取りすること
- IIS ログや送信元情報で、診断ツールか外部攻撃かを切り分けること
- 外部からの叩きを減らすために、公開方式や WAF/FW の対策も組み合わせること
この4点です。これらが揃っていれば、アラートが継続していても、運用としては「期待どおりの動作」として扱える場面が多くなります。一方で、挙動の変化（別種アラート、実行兆候、成功応答の増加）が出たときにすぐ深掘りできるよう、監視と棚卸しの型を作っておくことが、最終的に一番の防御力になります。
コメント