Tóm tắt nhanh
- SignDrop cho phép người dùng cục bộ thông thường leo thang lên quyền SYSTEM trên một số cấu hình Windows.
- Mã khai thác công khai lợi dụng Windows Defender và cơ chế xác thực log CLFS, thay vì mở đường tấn công trực tiếp từ Internet.
- Phạm vi thử nghiệm phụ thuộc phiên bản Windows và trạng thái CLFS; chưa thể coi mọi máy Windows đều bị ảnh hưởng.
- Không nên tắt xác thực CLFS để né SignDrop, vì có thể mở lại nguy cơ khai thác lỗi hỏng bộ nhớ.
Nhà nghiên cứu Abdelhamid Naceri, dùng tên MSNightmare, đã công bố SignDrop trên GitHub ngày 10/11/2026: một mã khai thác có thể đưa tài khoản Windows thông thường lên quyền SYSTEM. Nghịch lý nằm ở chỗ chuỗi khai thác lợi dụng chính cơ chế Microsoft bổ sung để bảo vệ Common Log File System (CLFS) khỏi các log bị can thiệp.
Với người dùng máy tính cá nhân lẫn quản trị viên, điều cần phân biệt là lỗi leo thang đặc quyền với lỗi xâm nhập từ xa. SignDrop cần kẻ tấn công đã có khả năng chạy mã cục bộ; nó có thể khiến một lần xâm nhập sẵn có nghiêm trọng hơn, nhưng riêng lỗ hổng này không cho phép người ngoài mạng tự chiếm máy chỉ bằng một yêu cầu gửi tới Windows.
Lớp bảo vệ log bị lợi dụng khi tiến trình mở tệp đổi danh tính
CLFS cung cấp dịch vụ ghi log cho phần mềm chạy ở chế độ người dùng và nhân Windows. Cơ chế xác thực được bổ sung từ tháng 10/2025 nhằm hạn chế việc trình điều khiển phân tích log bị sửa đổi, một bề mặt tấn công từng dẫn tới các lỗi hỏng bộ nhớ. Tệp đi kèm có đuôi .cnpf lưu dữ liệu phục hồi và kế thừa thuộc tính bảo mật của log ban đầu.
Vấn đề không đơn giản là Windows quên kiểm tra quyền. Khi người dùng thường chuẩn bị log, các thao tác tạo tệp ban đầu vẫn chịu kiểm tra truy cập; chỗ có thể bị lạm dụng xuất hiện khi một tiến trình đặc quyền mở lại log ấy. Nếu cần tạo tệp xác thực còn thiếu, CLFS thực hiện thao tác bằng quyền của tiến trình đang mở log, trong khi quyền truy cập trên tệp mới lại được lấy từ log ban đầu.
Vì vậy, một tệp được tạo trong ngữ cảnh SYSTEM vẫn có thể cho phép người dùng thường ghi vào. Chênh lệch giữa quyền của bên tạo tệp và quyền được gán cho tệp là mắt xích để chuỗi khai thác tiến tới leo thang đặc quyền. Cơ chế bảo vệ việc phân tích log không tự giải quyết được rủi ro này: kiểm tra tính xác thực của dữ liệu và kiểm soát ai có thể ghi vào tệp là hai việc khác nhau.
Mã công khai dùng giao diện cập nhật chữ ký của Windows Defender để khiến tiến trình chống mã độc mở container CLFS đã chuẩn bị. Liên kết tượng trưng được dùng để chuyển hướng thao tác; yêu cầu tạo tệp lúc ấy xuất phát từ một tiến trình bảo mật hợp lệ, chứ không mang danh tính tài khoản thường ban đầu. Đây là lý do một lớp tự bảo vệ chống can thiệp không mặc nhiên chặn được chuỗi khai thác.
Cấu hình thực tế quan trọng hơn tuổi của bản cài Windows
Kho mã SignDrop ghi nhận thử nghiệm trên Windows 11 26H2, Windows 11 26H2 Experimental và Windows Server 2025 Experimental. Phép thử độc lập của Will Dormann được Ars Technica ghi nhận cũng tái hiện được lỗi, nhưng điều kiện dường như cần một bản cài Windows 11 26H2 đã tồn tại hơn 90 ngày; chỉ cài mới rồi cập nhật chưa chắc tái hiện được.
Mốc 90 ngày liên quan giai đoạn tiếp nhận của cơ chế xác thực CLFS trước khi chuyển sang thực thi bắt buộc. Không nên biến mốc này thành quy tắc rằng cứ máy dùng lâu là chắc chắn bị khai thác. Trong cấu hình tác giả mô tả, giá trị Mode bằng 0 hoặc 1 tại HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CLFS\Authentication nằm trong phạm vi ảnh hưởng, nhưng phiên bản hệ điều hành và trạng thái tiến trình bảo mật vẫn cần được xét cùng.
Ước tính 80% số bản cài Windows bị ảnh hưởng là con số do tác giả đưa ra, chưa có kiểm chứng độc lập về mức phổ biến toàn cầu. Các thử nghiệm được công bố cũng ghi nhận giới hạn về độ ổn định của mã khai thác; bản công khai cần Defender hoạt động và có thể làm thay đổi hành vi hộp thoại UAC theo cách dễ nhận thấy. Thành công trong một môi trường thử nghiệm không đồng nghĩa chuỗi đó chạy ổn định trên mọi máy.
Với doanh nghiệp dùng nhiều phiên bản Windows, kết luận cả hệ thống an toàn hay bị ảnh hưởng chỉ từ tên phiên bản đều quá sớm. Việc kiểm kê phiên bản và trạng thái CLFS giúp khoanh vùng thiết bị cần theo dõi; chạy thử mã khai thác trên máy nhân viên lại có thể gây gián đoạn, nên không phải cách kiểm tra phù hợp cho máy đang làm việc.
Tắt xác thực CLFS không phải cách khắc phục an toàn
Chuyển Mode sang 2 hoặc 3 đưa hệ thống ra ngoài phạm vi SignDrop mà tác giả nêu, nhưng đồng thời vô hiệu hóa lớp xác thực log. Khi đó CLFS có thể trở lại việc xử lý log bị can thiệp, mở lại bề mặt tấn công từ các lỗi hỏng bộ nhớ mà cơ chế này vốn được tạo ra để giảm thiểu. Một số lỗi CLFS trước đây đã bị khai thác trong các chiến dịch mã độc tống tiền.
Đổi cấu hình để chặn một chuỗi khai thác mà làm mất lớp phòng thủ khác không phải bản vá. Người dùng nên giữ nguyên cơ chế bảo vệ, tránh chạy phần mềm không tin cậy và cài cập nhật Windows chính thức khi có; quản trị viên cần theo dõi hướng dẫn của Microsoft thay vì triển khai hàng loạt một thay đổi Registry chưa được hãng khuyến nghị cho SignDrop.
Tại thời điểm các nguồn công bố được đối chiếu, chưa có CVE hay bản vá SignDrop được công bố, và chưa có báo cáo xác nhận mã này được dùng trong tấn công thực tế. Điểm cần chờ tiếp là phản hồi cùng biện pháp xử lý chính thức của Microsoft, không phải một lời khẳng định rằng tắt Defender hoặc tắt xác thực CLFS sẽ làm máy an toàn hơn.
Nguồn tham khảo: Mô tả kỹ thuật SignDrop trên GitHub; Ars Technica; BleepingComputer; The Hacker News.
