Hacker không cần mang driver độc hại: Kỹ thuật mới mượn chính Microsoft Defender để chạm vào kernel

Trong một cuộc tấn công Windows kiểu BYOVD, kẻ xâm nhập thường phải mang theo một kernel driver hợp pháp nhưng có lỗ hổng, tải nó vào hệ thống rồi lợi dụng quyền Ring 0 của driver để vô hiệu hóa antivirus hoặc EDR. Một nghiên cứu mới của Check Point Research cho thấy có thể bỏ luôn phần “mang theo” đó: Microsoft Defender đã chứa sẵn một driver đủ quyền lực để làm nhiều thao tác mà attacker cần.

Driver này có tên BTR.sys, viết tắt của Boot Time Removal Tool. Nó là thành phần remediation hợp pháp của Defender, được Microsoft ký số và dùng khi phần mềm bảo mật cần xóa hoặc di chuyển một đối tượng mà Windows đang khóa. Jiří Vinopal của Check Point đã reverse-engineer giao thức nội bộ của BTR.sys và chứng minh rằng, nếu attacker đã có quyền tải driver, họ có thể đưa cho nó một danh sách thao tác do mình tạo để xóa, di chuyển file hoặc sửa Registry từ kernel mode.

Điểm đáng chú ý là nhóm không khai thác buffer overflow, use-after-free hay một CVE mới. Họ sử dụng chức năng mà BTR.sys vốn được thiết kế để có. Chính vì vậy, đây gần với một Living-off-the-Land driver hơn là BYOVD truyền thống: công cụ phòng thủ của Windows trở thành primitive hậu khai thác.

BTR.sys được tạo ra để làm việc mà Defender bình thường không làm được

Defender đôi khi phát hiện một file cần xóa nhưng không thể xử lý ngay vì file đang bị khóa hoặc vì thao tác cần diễn ra trước khi các dịch vụ user mode khởi động. BTR.sys giải quyết trường hợp này bằng cách chạy rất sớm trong quá trình boot.

Driver không nằm thường trực dưới tên BTR.sys trong thư mục drivers. Check Point phát hiện nó được nhúng dưới dạng resource bên trong MpEngine.dll. Khi một remediation hợp pháp cần reboot, Defender trích driver ra System32\drivers với một tên ngẫu nhiên, tạo một service tạm thời và đặt danh sách công việc trong một Alternate Data Stream có hậu tố :changelist. Sau khi chạy xong, driver tự unload và dọn dấu vết của chính nó.

Những đặc điểm này ban đầu thậm chí khiến nhóm nghiên cứu tưởng họ đang nhìn thấy malware: driver tên ngẫu nhiên, service ngắn hạn, cấu hình được mã hóa, dữ liệu nằm trong ADS và cơ chế tự xóa. Sau khi phân tích sâu hơn, họ xác nhận đó là logic remediation hợp pháp của Defender.

Chính phát hiện đó dẫn tới câu hỏi quan trọng hơn: nếu một thành phần tin cậy có thể nhận một danh sách thao tác và thực hiện chúng từ Ring 0, liệu một chương trình khác có thể nói đúng “ngôn ngữ” của nó và yêu cầu nó làm việc khác hay không?

Check Point không tìm bug memory — họ học cách nói chuyện với driver

BTR.sys không nhận lệnh qua một IOCTL thông thường. Nó đọc một cấu trúc nhị phân được mã hóa trong Alternate Data Stream mà service entry chỉ tới. Check Point reverse-engineer định dạng transaction, cơ chế kiểm tra tính toàn vẹn và cách driver giải mã cấu hình.

Nhóm phát hiện khóa RC4 dùng cho cấu hình được hard-code trong driver và giữ nguyên trên các build mà họ phân tích. Cấu trúc transaction cũng tương thích ngược qua nhiều thế hệ Windows. Thay vì tìm cách làm hỏng bộ nhớ của BTR.sys, proof of concept của nhóm tạo ra một cấu hình hợp lệ mà driver chấp nhận như một công việc remediation bình thường.

Khi nhận cấu hình đó, BTR.sys có thể thực hiện các primitive vốn có của nó: xóa file và thư mục, di chuyển file, xóa key hoặc value trong Registry, và tạo hoặc sửa Registry value. Vì thao tác xảy ra trong kernel mode dưới một driver Microsoft-signed, một số hàng rào vốn ngăn process user mode sửa thành phần bảo mật không còn hoạt động theo cùng cách.

Đây là khác biệt cốt lõi với BYOVD. Trong BYOVD, attacker thường đưa một driver bên thứ ba đã có lỗ hổng lên máy nạn nhân rồi lợi dụng lỗi đó để đạt primitive đọc/ghi kernel. Với BTR Reforged, proof of concept có thể trích bản BTR.sys tương ứng ngay từ MpEngine.dll trên máy. Trong các thử nghiệm của Check Point, fallback driver đi kèm công cụ không cần được sử dụng.

Không mang driver từ ngoài không có nghĩa attacker tự nhiên có quyền kernel

Đây không phải một lỗ hổng giúp tài khoản user thông thường leo thẳng lên SYSTEM. Điều kiện quan trọng nhất là attacker phải có SeLoadDriverPrivilege — quyền cho phép một process tải hoặc gỡ device driver. Microsoft mô tả đây chính là privilege cần thiết để đưa driver hay code tương ứng vào kernel mode.

Vì vậy, kỹ thuật phù hợp với giai đoạn post-exploitation: kẻ tấn công đã có quyền quản trị hoặc một token đủ mạnh, sau đó muốn vô hiệu hóa lớp phòng thủ của endpoint để tiếp tục triển khai payload, persistence hoặc ransomware. Nó không giải quyết bước initial access và cũng không thay thế một privilege-escalation exploit khi attacker mới chỉ có quyền thấp.

Điểm này cũng giải thích phản hồi của Microsoft Security Response Center. Theo Check Point, MSRC xác nhận phát hiện không đạt tiêu chí để được servicing ngay vì kỹ thuật phụ thuộc vào quyền quản trị có sẵn, cụ thể là SeLoadDriverPrivilege. Nghiên cứu không có một CVE mới cho cơ chế này.

“Golden Window”: file system đã sẵn sàng, phần lớn lớp bảo vệ chưa thức dậy

BTR.sys đặc biệt hữu ích cho remediation vì vị trí của nó trong boot sequence. Driver không thể chạy ở giai đoạn sớm nhất, vì lúc đó file system và một số object Windows mà nó cần chưa sẵn sàng. Thay vào đó, Defender cấu hình nó như một System Start driver thuộc nhóm Boot Bus Extender.

Vị trí này tạo ra khoảng thời gian mà Check Point gọi là “Golden Window”: NTFS đã hoạt động và driver có thể thao tác với file, nhưng nhiều dịch vụ antivirus/EDR ở user mode vẫn chưa khởi động đầy đủ.

Trong một thử nghiệm trên Windows 11 25H2 đã cập nhật, BTR.sys thực thi khoảng 34 giây trước khi MsMpEng.exe, dịch vụ chính của Microsoft Defender, bắt đầu chạy. Network Inspection Driver xuất hiện muộn hơn gần bốn phút. Khoảng cách đó đủ để proof of concept xóa một số binary của Defender trước khi các service tương ứng có cơ hội khởi động và tự bảo vệ.

Nhóm cũng cho thấy thao tác Registry từ BTR.sys có thể vượt qua Tamper Protection trong kịch bản thử nghiệm. Điều này không có nghĩa mọi EDR đều chắc chắn bị vô hiệu hóa theo cùng cách; thứ tự load, self-protection và kiến trúc kernel của từng sản phẩm khác nhau. Check Point mô tả khả năng ảnh hưởng tới sản phẩm bên thứ ba như một nguy cơ cần đánh giá, còn demo đầy đủ được thực hiện với Defender.

Vì sao blocklist driver không giải quyết được bài toán này?

Microsoft Vulnerable Driver Blocklist được xây dựng để chặn các driver bên thứ ba có lỗ hổng hoặc hành vi có thể bị lợi dụng để phá mô hình bảo mật Windows. Đây là một lớp phòng thủ quan trọng đối với BYOVD.

BTR.sys không khớp mô hình đó. Nó không phải một driver cũ của hãng phần cứng mà Windows có thể đơn giản đưa vào danh sách cấm; nó là thành phần Microsoft-signed cần cho chính chức năng remediation của Defender. Chặn theo hash hoặc chữ ký vì thế có nguy cơ phá chức năng hợp pháp mà Windows dựa vào.

Điều này cũng làm nổi bật hạn chế của mô hình “signed = trusted”. Chữ ký số trả lời ai phát hành binary và liệu binary có bị sửa sau khi ký hay không. Nó không trả lời binary đang được gọi trong đúng bối cảnh hay đang thực hiện một intent hợp pháp.

Phòng thủ phải nhìn vào hành vi, không chỉ nhìn driver

Check Point đề xuất kiểm soát chặt SeLoadDriverPrivilege như biện pháp hardening quan trọng nhất. Trong môi trường doanh nghiệp, quyền này nên chỉ được cấp cho những account và workload thực sự cần tải driver, đồng thời việc sử dụng nó cần được giám sát.

Về detection, nhóm đưa ra một số dấu hiệu có thể phân biệt lạm dụng với remediation bình thường. Một ví dụ là việc tạo Alternate Data Stream .sys:changelist cho driver ngẫu nhiên, hoặc tạo service thuộc nhóm Boot Bus Extender nhưng không đi qua Service Control Manager theo cách Defender bình thường thực hiện. Việc BootClean.log xuất hiện rồi bị xóa rất nhanh bởi process System cũng là một tín hiệu đáng theo dõi.

Những dấu hiệu này có ý nghĩa hơn hash của BTR.sys, bởi binary được sử dụng trong demo vẫn là thành phần Microsoft hợp pháp. Một rule chỉ hỏi “driver này có chữ ký Microsoft không?” sẽ không phân biệt được remediation và abuse.

Chưa có bằng chứng kỹ thuật này đang được hacker dùng ngoài thực tế

Check Point cho biết họ chưa quan sát thấy BTR.sys bị lạm dụng theo cách BTR Reforged trong các mẫu và telemetry đã thu thập. Nghiên cứu bắt đầu từ một incident response thật, nhưng hoạt động BTR.sys đáng ngờ trong sự cố đó cuối cùng được xác định là hành vi Defender hợp pháp, không phải thao tác của threat actor.

Điểm phân biệt này quan trọng. BTR Reforged hiện là một kỹ thuật đã được chứng minh bằng proof of concept, không phải một chiến dịch tấn công đang được ghi nhận rộng rãi. Việc mã nghiên cứu đã tồn tại có thể làm kỹ thuật dễ được tái hiện hơn, nhưng từ đó không thể suy ra rằng ransomware hay APT đã bắt đầu sử dụng nó.

Phát hiện đáng chú ý hơn nằm ở mô hình tin cậy: Windows có những thành phần bảo mật được trao quyền rất mạnh chính vì chúng cần sửa hệ thống ở những thời điểm mà phần mềm khác không thể làm được. Một khi giao thức điều khiển của những thành phần đó có thể được tái tạo bởi attacker đã có đặc quyền, ranh giới giữa “driver phòng thủ” và “kernel primitive” trở nên phụ thuộc vào ngữ cảnh sử dụng, chứ không còn chỉ phụ thuộc vào chữ ký số.

Nguồn chính: Check Point Research — BTR Reforged: Weaponizing Defender’s Remediation Driver as a Kernel Operation Primitive; Microsoft Learn — Microsoft recommended driver block rules; Microsoft Learn — SeLoadDriverPrivilege.