sharepoint-2026-poc

SharePoint /_trust WS-Federation BinaryFormatter逆シリアル化チェーンのPoC、IOC、および検出ロジック。認証なしのRCE、プロセス内マシンキー窃取、および各バリアントが残すアーティファクトをカバーするラボ再構築。SharePoint 2016、2019、およびSubscription Edition。CVE-2026-50522、CVE-2026-45659、CVE-2026-56164、CVE-2026-58644。

1. 脆弱性

SharePoint は /_trust/default.aspx に WS-Federation パッシブサインインエンドポイントを公開しています。細工されたサインインレスポンス (wa=wsignin1.0 + wresult=<RequestSecurityTokenResponse>) には SecurityContextToken が埋め込まれ、その <Cookie> 要素は base64 で DEFLATE 圧縮された BinaryFormatter ストリームです。サーバー側では、その Cookie が展開され、型制限なしで逆シリアル化されるため、ガジェットチェーン (ysoserial.net 経由) によって w3wp.exe 内部で攻撃者が制御するコードが実行されます。

リクエストのスケルトン (認証不要):

2. 単一のプリミティブから生じる 2 つのチェーン

scripts/ にある (サニタイズ済みの) スクリプト: パラメータ化された OOB RCE と 2 段階のキーダンプ。ペイロードの配信には PowerShell の -EncodedCommand を使用しているため、複数ステートメントのペイロードが cmd.exe/転送レイヤーをそのまま通過します (;/&& のクォーティング破損なし)。

3. ラボ

単一の SharePoint SE ファーム (修正前のビルドに固定)、アプリプール ID LAB\sp_pool、PowerShell 5.1、クラウド保護を有効にした Microsoft Defender。テレメトリ (Windows イベントログ、SharePoint ログ、Defender for Endpoint) は、軽量なオープンソース SIEM である nano に送信しました。攻撃者ホストは ysoserial.net を実行し、interactsh クライアントが OOB リスナーを提供しました。アドレスとドメインは本文中で伏せ字にしています。§4 のスクリーンショット注記を参照してください。

4. 結果: 実行方法 → アーティファクトマトリクス

各行は実際の 1 回の実行 (デトネーション) です。アーティファクトは実行ごとに SIEM + OOB リスナーから取得しました。

スクリーンショットは未修正です。 ラボの実際のホスト名と NetBIOS 名が含まれており、これらは簡素で、本文全体で使用しているサニタイズ済みの SHAREPOINT01 / LAB とは異なります。同じ実行、同じイベントであり、演出されたものは一切ありません。業務上安全な相当物は artifacts/ にあります。

これらの結果は、デフォルトの AMSI 構成 (Balanced モード、/_trust はスキャン対象外) におけるものです。/_trust の AMSI リクエストボディスキャンを有効にすると (Full モードまたはターゲット指定)、各行は代わりにリクエストレイヤーでブロックされます。実行前に HTTP 400、Exploit:Script/SpCookieExec.A を返します (§5 参照)。

すべての RCE 実行を 1 つのクエリで

文書化された 4 回の実行すべて (15:01〜15:18 UTC) で、w3wp.exe のすべての子プロセスがプール ID として実行されています。4 件のうち 3 件は powershell.exe が直接生成されています。cmd.exe を経由したのは 15:03:34 の実行だけで、検知されたのもその実行だけでした。ウィンドウをこれより広げると、同日朝の以前の開発イテレーションも結果セットに含まれるため、この主張はこれら 4 回の実行に限定されます。

同じエクスプロイト、2 つのプロセスツリー

デフォルトの実行方法: w3wp.exe → cmd.exe → powershell.exe で、conhost.exe が並行して起動します。これが Behavior:Win32/WebshellLauncher.A が検知の鍵とするプロセス形状です。

-RawCmd 実行方法。同じプリミティブ、同じペイロードで、cmd.exe ホップを除去したものです。この実行では Defender は何も検知しませんでした。w3wp → cmd に基づく検知ではこれを完全に見逃します。

発動した検知と、見逃した 3 回の実行

4 回の実行を含む同じ 25 分間のウィンドウ内のすべての Defender イベントです。3 件すべてが単一の cmd.exe 実行に属しています。Severe の malware_detected が 2 件、その後アクション Remove の malware_action_taken が 1 件です。修復はビーコンに間に合わず、ビーコンが先に完了しました。

Security 4688 からそのまま復元された重要なコマンドライン (エンコーディングは回避策ではありません):

SIEM に表示されるエンコード済みコマンドラインです。これは UTF-16LE の base64 に過ぎません。base64 -d | iconv -f utf-16le -t utf-8 でコールバックを 1 ステップで復元できます。エンコーディングは難読化ではありません。

キーダンプは痕跡を残さない

以下の 2 つのフレームは、ファームのマシンキーが盗まれた同じ 90 秒間のウィンドウを対象としています。

フィルタなしでは、ウィンドウには 20 件のイベントがあります。ホストは稼働しており、テレメトリを送信しています。

w3wp.exe の子プロセスにフィルタすると、同じウィンドウは空です。プロセスも、Defender イベントも、ビーコンもありません。キーは HTTP レスポンスで持ち出され、ホスト側の唯一のアーティファクトは /_trust リクエスト自体であり、この SIEM はそれを収集していませんでした。パッチ適用では盗まれたキーは失効しません。ローテーションしてください。

OOB リスナーで取得された -Diag による情報開示 (URL デコード済み):

5. 検知とハンティング

すべての亜種に存在する唯一のシグネチャ。 まずこれをハンティングしてください:

• IIS / SharePoint ログ: ボディに wa=wsignin1.0 と、RequestSecurityTokenResponse + SecurityContextToken/<Cookie> を含む wresult を持つ POST /_trust/default.aspx。認証不要で、多くの場合異常な User-Agent。レスポンスステータスのベースライン: このエンドポイントへの正規の WS-Federation サインイントラフィックは主に HTTP 302 です。エクスプロイトは他のステータス (200、500、接続リセット、AMSI がブロックした場合は 400) を返します。このエンドポイントに実際のサインイン量がある場合は、POST /_trust/default.aspx への非 302 レスポンスを異常として扱ってください。ステータスだけではエクスプロイトの成功を確認できません。成功した実行では 200 とリセットの両方が返されました。

プロセスベース (RCE 亜種のみ):

• w3wp.exe が cmd.exe または powershell.exe を直接生成する。-RawCmd 亜種は cmd.exe ホップを除去して WebshellLauncher.A を回避するため、w3wp→cmd だけに依存しないでください。
• w3wp 配下の powershell.exe -EncodedCommand: 4688 から直接 blob をデコードしてください (保存時は難読化されていません)。
• w3wp.exe → whoami.exe (偵察)、または子プロセスの conhost.exe。

対応判断に影響する 2 つの発見:

1. 動作ベースの検知は防御を保証しません。 Defender がプロセスチェーンを Behavior:Win32/WebshellLauncher.A として検知して修復した際、少なくとも 1 回の実行では、外向きビーコンが修復完了前に完了することが観測されました。このような検知はコールバック成功の可能性があるものとして扱い、検知時刻前後の DNS、プロキシ、外向きログでコールバック宛先を確認してください。
2. マシンキー開示はプロセス、サービス、ネットワークのテレメトリを一切生成しません。 これは w3wp.exe 内部で実行され、HTTP レスポンスでキーを返すため、ホスト側の唯一の証拠は POST /_trust/default.aspx リクエストとそのレスポンスです。検知されるかどうかは AMSI リクエストボディスキャン構成に依存します。

MITRE ATT&CK: T1190 (公開アプリケーションの悪用) · T1059.001 (PowerShell) · T1552 (保護されていない資格情報: マシンキー) · T1550 (盗難後の偽造認証マテリアルの使用)。

AMSI リクエストボディスキャン

両方のチェーンは POST /_trust/default.aspx リクエストのボディでペイロードを配信します。Microsoft Defender がそのペイロードを検査するかどうかは、Web アプリケーションに対する SharePoint の AMSI リクエストボディスキャン構成によって決まります。このファーム (SharePoint Server Subscription Edition、Microsoft Defender) に対して 3 つの構成を直接テストしました:

デフォルト構成ではリクエストボディは検査されないため、RCE とマシンキー開示の両方が完了し、AMSI による検知は発生しません。どちらのスキャン構成でも、リクエストは逆シリアル化の前に HTTP 400 で拒否され、ワーカープロセスは作成されず、Defender は以下を記録します:

コードが実行される前にリクエストがブロックされるため、子プロセスは作成されず、どちらのチェーンでも Security 4688 のプロセス作成イベントは生成されません。powershell.exe を (中間の cmd.exe なしで) 直接生成する RCE 亜種も同様にブロックされます。

構成 (SharePoint Management Shell、Web アプリケーションごと):

6. 修復

1. 修正済みの SharePoint ビルドにパッチを適用します。
2. 攻撃された可能性のあるファームではマシンキーをローテーションします (Set-SPMachineKey / web.config の machineKey 更新 + IISReset)。パッチ適用は RCE を止めますが、すでに盗まれたキーは失効させません。ローテーションにより、攻撃者が永続化のために FedAuth / SecurityContextToken / __VIEWSTATE を偽造する能力を排除します。
3. 過去の IIS ログで POST /_trust/default.aspx をハンティングします。正規の WS-Federation サインインも wa=wsignin1.0 でこのエンドポイントをターゲットにするため、エンドポイント単独ではなく、エクスプロイト固有の構造に注目してください: トークンが base64 の <Cookie> を持つ <SecurityContextToken> である wresult (名前空間 http://schemas.microsoft.com/ws/2006/05/security。正規のサインインは代わりに署名付き SAML アサーションを運びます)、それに加えて非 302 レスポンス (200/500/400 またはリセット)、およびスクリプト化された/異常な User-Agent。キーダンプはこのような POST を連続して 2 回送信します。存在する場合は、キーの漏洩を前提としてください。
4. 初回検出日以降の偽造 __VIEWSTATE / 異常な認証をレビューします。
5. /_trust の AMSI リクエストボディスキャンを有効にします (Full モード、または Balanced のターゲットエンドポイントとして /_trust/default.aspx を追加。§5 参照)。これにより、RCE とキーダンプの両方が実行前にリクエストレイヤーでブロックされます。

7. 根本原因: 6月 → 7月のパッチ差分

ベンダーの修正プログラムの静的解析により、そのメカニズムが確認され、RCE に盗まれたマシンキーが必要かどうかが確定しました: 不要です。方法: 6月の CU (KB5002873, 16.0.19725.20384) と 7月の CU (KB5002882, 16.0.19725.20434) の間の Microsoft.SharePoint.IdentityModel.dll のバイナリパッチ差分。読み取り専用で逆コンパイルして比較しました。

悪用された読み取りパスは SPFederationAuthenticationModuleV2.OnAuthenticateRequest → SPSessionSecurityTokenHandlerV2 (System.IdentityModel.Tokens.SessionSecurityTokenHandler のサブクラス) です。変更内容:

解釈。 パッチ適用前の変換チェーンは deflate のみで、暗号化も、マシンキーに基づく MAC/署名変換もありませんでした。基底の ReadToken は変換を適用して Cookie 値を逆シリアル化するため、偽造トークンはマシンキーの検証ゲートなしに展開・逆シリアル化されます。ガジェットは ValidationKey/DecryptionKey なしで発火します (キー非依存)。修正プログラムは、署名/復号チェックを追加するのではなく、シンクを除去しており (変換と ReadToken がスロー)、修正すべきキーゲートが存在しなかったことを裏付けています。

結果。 マシンキー開示は、RCE の前提条件ではなく、別個の永続化目的 (FedAuth / SecurityContextToken / __VIEWSTATE の偽造) です。キーダンプ自体が同じパスを介した RCE であり、キーが盗まれる前に実行されます。

同じ 7月の CU には、関連性のない 2 つ目の強化も含まれています: SPJsonWebSecurityTokenHandlerV2 での JWT アクタートークンの署名検証 (RequireSignedTokens が false→true、新しい VerifyActorTokenSignature)。これは、ここで扱う WS-Federation セッショントークンパスではなく、別個の OAuth / サーバー間アクタートークンパスです。

修正プログラムの適用。 修正プログラムは 7月の CU (KB5002882) です。deflate のみの Cookie 変換を、スローする変換に置き換えてシンクを除去します。インストール後、ファーム設定によってこれが元に戻されたりバイパスされたりしないことを確認してください。SessionCookieTransformProtectionEnabled を false に設定すると、セッショントークン Cookie が脆弱な deflate のみの変換に戻り (RCE とキーダンプが再び可能になります)、DisableActorTokenSignatureValidation デバッグフラグは、同じ更新プログラムで強化された別個の JWT アクタートークン署名バイパスを再び開きます。

8. リポジトリ構成