總結
CVE-2025-50154 是 Windows 檔案總管的一項漏洞，可能導致敏感驗證資料透過網路外洩。微軟將此問題歸類為「偽造」，其根本弱點對應於CWE-200（敏感資訊外洩）。
在受影響的設定中，Windows 檔案總管於處理捷徑相關元資料時，可能觸發網路驗證程序。若所參照的遠端目標由攻擊者掌控，攻擊者便能擷取 NTLM 挑戰-回應資料。根據組織的安全管控措施，此類資料可能導致後續濫用行為，例如 NTLM 中繼攻擊或離線密碼猜測攻擊。
在本篇部落格中，我們基於參與OPSWAT 研究員計畫之研究生所進行的研究，深入探討 CVE-2025-50154 漏洞，並提供實用緩解措施指引，以降低遭強制執行 NTLM 驗證的風險。
影響與風險
CVE-2025-50154 於 2025 年 8 月 12 日公開披露，影響多個受支援的 Windows 客戶端與伺服器版本（Windows 10/11 及 WindowsServer ），範圍涵蓋未修復的建置版本。此漏洞經 CVSS v3.1 評定為 6.5 分（中度）。
主要的安全後果是憑證外洩：攻擊者可透過誘使 Explorer 對其控制的終端點進行驗證，從而取得 NTLM 挑戰回應資料。根據環境差異，此類資料可用於：
•NTLM 中繼攻擊（偽造）：當中繼防護機制缺失或設定錯誤時，冒用受害者身分向其他服務進行驗證。
•離線密碼猜測/破解：嘗試從擷取的挑戰-回應資料中恢復弱密碼。
可行性在很大程度上取決於企業控制措施，例如 SMB 簽署、NTLM 限制、網路分段以及服務端強化。
攻擊場景
CVE-2025-50154 為一項強制驗證問題。當 Windows 檔案總管處理指向遠端 SMB/UNC 位置的捷徑時，可能在正常渲染或路徑驗證過程中建立 SMB 連線。此舉將導致遠端端點接收於連線建立期間產生的 NTLM 驗證交換資料。
一個典型的攻擊情境如下：
- 攻擊者佈置階段：攻擊者控制一台SMB伺服器，並準備好由捷徑所引用的共用資料夾。
- 捷徑放置：透過常見管道（例如釣魚郵件附件、同步資料夾、共享檔案儲存庫或現有立足點），將指向攻擊者控制之SMB路徑的.lnk檔案傳遞至受害者環境。
- 探索器觸發存取：當受害者瀏覽包含捷徑的目錄時，Windows 檔案總管會解析捷徑的元資料，並可能在例行使用者介面處理過程中嘗試解析遠端目標。
- 隱式驗證：在建立SMB連線期間，Windows會以使用者環境進行驗證（通常透過NTLM）。受害者無需執行捷徑目標即可觸發驗證交換流程。
- 擒獲後的結果（取決於環境）：根據環境的管控措施，擒獲的NTLM資料可能被用於NTLM中繼攻擊或離線密碼破解。其實際可行性受多種因素影響，例如SMB簽署機制、NTLM限制條件以及網路分段策略。
技術背景
Windows 檔案總管與捷徑顯示
Windows 檔案總管（explorer.exe）是 Windows 殼層程序，負責枚舉目錄內容並渲染檔案總管使用者介面，同時調用殼層元件（例如圖示/覆蓋層/縮圖處理程式）以取得並顯示圖示、覆蓋層及縮圖。
Windows 快捷方式 (.lnk) 並非簡單的文字指標；它是一種結構化元數據格式，可儲存目標路徑（本地路徑或 UNC/SMB 路徑）、可選參數與工作目錄，以及獨立的圖示參照。在正常瀏覽資料夾時，檔案總管會解析快捷方式的元數據以在使用者介面呈現快捷方式（例如解析圖示並驗證目標）。 根據所引用的目標及相關元資料，此處理過程可能導致資源管理器在例行渲染或路徑驗證時嘗試進行網路存取。
透過SMB進行NTLM驗證
在 Windows 檔案共用中，SMB 驗證機制於網域環境中通常優先採用 Kerberos，但當 Kerberos 不可用或未被選取時，仍可能協商使用 NTLM。NTLM 屬於挑戰-回應式驗證協議：客戶端首先宣告其能力，伺服器隨後返回挑戰值（隨機數），客戶端則以挑戰值與使用者私密金鑰推導出的驗證訊息回應——過程中不會傳送明文密碼。
NTLM 變體與安全態勢（NTLMv1 與 NTLMv2 之比較）
NTLM 具有多種變體。現代 Windows 環境通常依賴 NTLMv2，並應盡可能避免使用舊式的 LM/NTLMv1。
NTLMv1 因數個關鍵原因（弱加密、低熵金鑰、中繼漏洞、離線破解風險等）而被廣泛認定為不安全。
為改善此問題，微軟推出了NTLMv2，強化了回應計算機制。實際應用中，NTLMv2以基於HMAC-MD5的方案取代舊有的DES式回應構建方式，並將額外上下文資訊整合至回應中，使其相較於NTLMv1，在抵禦多類離線破解技術方面展現出顯著更強的韌性。
即使採用NTLMv2，組織仍應將NTLM視為比Kerberos風險更高的驗證協定，並實施深度防禦控制措施（例如SMB簽署與分段技術），以降低強制驗證情境的攻擊影響範圍。
為何NTLM仍頻繁成為攻擊目標
儘管NTLM屬於挑戰-回應式驗證協議，其驗證交換機制在惡意網路環境中仍可直接被利用，因而持續吸引攻擊者利用。 在SMB會話建立過程中，遠端終端點會接收驗證元資料及驗證客戶端所需的挑戰-回應值。若攻擊者能操控目標終端點（例如由攻擊者控制的SMB伺服器），或能在傳輸過程中攔截/終止連線，便可能擷取NTLM交換資料，並根據環境防護措施嘗試後續惡意行為，例如NTLM中繼攻擊或離線密碼猜測。
Windows 亦將 NTLM 整合至其單一登入 (SSO) 體驗中。 由使用者機密衍生的憑證資料由 LSASS 管理，可用於驗證網路資源（例如 SMB 共用）而無需反覆提示使用者。此機制雖提升使用便利性，卻擴大了強制驗證情境的攻擊面：當 .lnk 快捷方式參照遠端 SMB 路徑時，Windows 檔案總管可能在例行快捷方式處理過程中啟動 SMB 連線，並自動協商驗證流程。
在 CVE-2025-50154 的情境下，這意味著 NTLM 驗證交換資料可能被傳送至攻擊者控制的 SMB 端點，而無需受害者執行所引用的目標程式，從而於正常瀏覽資料夾時建立無聲的憑證外洩途徑。
技術分析
資源管理器圖示渲染與捷徑處理
當在檔案總管中開啟資料夾時，總管會枚舉目錄內容，並根據其註冊的檔案關聯（通常由檔案副檔名驅動）來判定每個項目的類型。接著，Windows 會使用對應的殼層類別註冊（例如透過登錄檔中的關聯 CLSID/ProgID 映射）來定位適當的殼層處理程序——通常是負責圖示擷取與渲染的 COM 元件。總管會呼叫相關介面來擷取並顯示圖示。
對於 .lnk（殼層連結）檔案，檔案總管通常不會預設顯示通用捷徑圖示。相反地，它會解析捷徑的元資料，嘗試解析所參照的目標（及相關圖示資訊），然後渲染與該解析目標關聯的圖示。
當檔案總管渲染 .lnk 檔案時，會透過呼叫CShellLink::GetIconLocation 來決定圖示來源，該函式會識別圖示應從何處載入（例如目標二進位檔、明確的圖示路徑或預設系統圖示）。 在此流程中，Explorer 會先初始化圖示提取機制（_InitExtractIcon），接著執行核心解析邏輯（_GetExtractIcon），該邏輯會透過_CheckExtractLocation 函式評估圖示來源。
• 若捷徑指定了本機圖示位置（例如磁碟上的可執行檔或 DLL），Explorer 會直接從該資源載入圖示。
• 若圖示位置為遠端網址，Explorer 可能會將圖示下載至其本機快取（例如使用URLDownloadToCacheFileW），然後從快取副本載入圖示。
• 若無有效圖示來源可用，檔案總管將回退至系統處理程序提供的預設圖示。
在解析圖示相關元資料後，檔案總管會透過CShellLink::Extract 處理捷徑目標，並完成提取工作流程。在此路徑中，當捷徑指向遠端位置時，檔案總管會調用CShellLink::_ShortNetTimeout來縮短網路超時設定，若網路目標速度緩慢或無法連線，此舉可減少使用者介面延遲。
當目標被識別為網路（UNC）路徑時，檔案總管會以非同步方式執行目標驗證。它會啟動一個工作執行緒來執行CShellLink::_VerifyPathThreadProc，該程序會檢查所參照的目標是否存在。
在此例程中，Explorer 會呼叫PathFileExistsAndAttributesW來查詢目標是否存在及其基本屬性（例如檔案與目錄的區別），而針對 SMB/UNC 目標的查詢則需要嘗試進行網路存取。
漏洞根本原因
在上述捷徑渲染流程中，有兩項外向操作相關：
• 透過URLDownloadToCacheFileW取得圖示（當捷徑的圖示來源為遠端網址時）。
• 透過PathFileExistsAndAttributesW驗證目標（當捷徑的目標為 UNC/SMB 路徑時）。
為驗證URLDownloadToCacheFileW 的行為，我們API 一個最簡化的獨立測試API 執行此API 。
該網路活動僅包含常規的HTTP抓取操作，根據我們的觀察，其並未洩露與此漏洞相關的憑證資料。
當評估的路徑為 UNC/SMB 目標時，PathFileExistsAndAttributesW會觸發更關鍵的行為。在除錯過程中，我們觀察到此檢查可能在當前使用者環境下啟動 SMB 連線建立並進行驗證協商。
由於 Explorer 在處理 .lnk 檔案時可能自動觸發此驗證機制，攻擊者控制的 SMB 端點無需受害者執行參照檔案，即可接收 NTLM 驗證交換資料，在常規資料夾瀏覽過程中形成無聲的憑證洩露途徑。
概念驗證
在隔離實驗室中OPSWAT 研究員透過引用遠端SMB/UNC路徑的捷徑(.lnk)驗證了CVE-2025-50154漏洞。在存在漏洞的Windows系統上，僅需透過Windows資源管理器瀏覽該資料夾，便會在常規捷徑處理過程中觸發SMB連線，導致NTLM驗證資料被傳送至遠端終端點——且無需受害者實際執行捷徑目標。
修復
組織必須確保其作業系統與應用程式定期套用修補程式並保持最新狀態，以減輕已知漏洞的風險。這包括安裝所有相關的微軟安全更新，並確認所有終端裝置皆運行修正後的最新Windows版本。同時，組織應透過適當強化外發SMB存取權限，並依據自身環境加強NTLM/SMB防護措施，從而縮小攻擊面。
MetaDefender 透過提供清晰的風險暴露與修補程式準備狀態可視性，支援這些防護措施並協助大規模運作化。憑藉支援超過 1,100 款應用程式的強大漏洞與修補程式管理能力MetaDefender Endpoint 識別運行未修補或過時 Windows 版本的端點裝置，以及第三方應用程式，並提供建議的修復方案。
此外，透過My OPSWAT Central Management 的管理控制台，管理員可獲得集中式、統一化的端點安全狀態、漏洞暴露及修補程式管理視圖，所有功能皆整合於單一平台，用於定義並執行組織範圍內的安全政策。 管理員還可在Endpoint MetaDefender Endpoint 的終端設備上建立並部署自訂腳本，自動執行與 SMB 存取及 NTLM 使用相關的強化措施。此方法不僅簡化了安全執法流程，同時提供清晰的執行結果反饋，使管理員能迅速識別出可能需要進一步調查或人工干預的終端設備。
MetaDefender Endpoint 資安與 ITEndpoint 優先部署更新、加速修復流程、持續監控組織安全態勢，最終降低暴露於常見漏洞與暴露（CVE）的風險，例如CVE-2025-50154及類似終端設備威脅。
