Phân tích Bootkit BlackX: Kỹ thuật vượt qua Secure Boot trên hệ thống đã vá lỗi

• Mối đe dọa mới: Bootkit BlackX nhắm vào các tổ chức ngoại giao tại khu vực Trung Á, sử dụng kỹ thuật can thiệp vào quy trình khởi động UEFI.
• Cơ chế tấn công: Lợi dụng lỗ hổng CVE-2022-21894 (Baton Drop) để nạp các tệp EFI độc hại trước khi hệ điều hành khởi động.
• Sai lầm phổ biến: Việc cài đặt bản cập nhật Windows không đồng nghĩa với việc các chính sách bảo mật Secure Boot đã được áp dụng đầy đủ.
• Khuyến nghị: Quản trị viên cần kiểm tra trạng thái thu hồi chứng chỉ (revocation list) và cấu hình firmware thay vì chỉ dựa vào trạng thái cập nhật của Windows.

Một chiến dịch gián điệp mạng tinh vi vừa được phát hiện, nhắm mục tiêu vào các tổ chức ngoại giao tại Tajikistan, Uzbekistan và Turkmenistan. Các nhà nghiên cứu bảo mật đã xác định sự hiện diện của một bootkit UEFI mới có tên gọi BlackX. Mã độc này được thiết kế để vượt qua cơ chế Secure Boot – một tính năng bảo mật quan trọng được thiết kế để ngăn chặn các phần mềm không tin cậy thực thi trước khi Windows khởi động.

Cơ chế vận hành của Bootkit BlackX

Theo báo cáo từ các chuyên gia an ninh mạng, BlackX chia sẻ nhiều đặc điểm thiết kế với bootkit khét tiếng BlackLotus. Mã độc này sử dụng lỗ hổng CVE-2022-21894, còn được biết đến với tên gọi Baton Drop, để nạp các tệp EFI do kẻ tấn công kiểm soát. Bằng cách chiếm quyền điều khiển trong chuỗi khởi động sớm, BlackX có thể vô hiệu hóa các công cụ bảo mật của hệ điều hành trước khi chúng kịp khởi tạo.

Quá trình lây nhiễm thường bắt đầu sau khi kẻ tấn công đã chiếm được quyền quản trị (Administrator) trên mạng nội bộ của nạn nhân. Trình cài đặt inst.exe phối hợp với tệp mã hóa PVMDIJGKAX2 để giải nén các thành phần cần thiết. Thiết kế này gây khó khăn đáng kể cho các đội ngũ ứng cứu sự cố (Incident Response) trong việc khôi phục toàn bộ các thành phần của bootkit từ tệp cài đặt gốc.

Kỹ thuật né tránh và duy trì sự hiện diện

Bootkit này triển khai một driver kernel nhằm làm suy yếu các công cụ bảo mật bằng cách can thiệp vào các tiến trình, luồng (thread) và registry callbacks. Đặc biệt, nó còn can thiệp vào Event Tracing for Windows (ETW) để che giấu hoạt động hệ thống. Một kỹ thuật đáng chú ý là khi có yêu cầu truy cập tệp tin, driver này sẽ trả về một handle đến tiến trình hợp lệ calc.exe thay vì tệp tin độc hại thực sự.

Ngoài ra, BlackX còn phân phối các payload ở chế độ người dùng (user-mode) phục vụ mục đích gián điệp, bao gồm một Trojan truy cập từ xa (RAT) có khả năng tải thêm mã .NET và sử dụng các dịch vụ lưu trữ đám mây như Google Drive, OneDrive hoặc Yandex.Disk để thực hiện liên lạc với máy chủ điều khiển (C2).

Tại sao hệ thống đã vá lỗi vẫn gặp rủi ro?

Một điểm gây tranh cãi trong báo cáo là việc các máy tính bị nhiễm đã nhận được các bản cập nhật Windows nhưng vẫn bị tấn công. Nguyên nhân gốc rễ nằm ở chỗ, việc bảo vệ chống lại CVE-2022-21894 không chỉ dừng lại ở việc cài đặt bản vá, mà còn phụ thuộc vào việc thu hồi sự tin tưởng đối với chứng chỉ Windows Production PCA 2011 được sử dụng để ký các thành phần UEFI dễ bị tổn thương.

⚠️ Cảnh báo quan trọng: Việc cài đặt bản cập nhật Windows không tự động áp dụng các thay đổi trong danh sách thu hồi chữ ký (forbidden-signature list) của firmware. Quản trị viên cần tuân thủ hướng dẫn của Microsoft liên quan đến CVE-2023-24932 để đảm bảo các chính sách bảo mật Secure Boot được kích hoạt hoàn toàn.

Việc không cập nhật danh sách thu hồi (revocation list) khiến các tệp nhị phân dễ bị tổn thương vẫn có thể được nạp vào hệ thống. Do đó, các tổ chức cần kiểm tra cấu hình Secure Boot trong firmware thay vì chỉ dựa vào trạng thái cập nhật của Windows.

Bảng tổng hợp các chỉ số IOCs

Khuyến nghị phòng thủ và săn tìm mối đe dọa

Để đối phó với các mối đe dọa như BlackX, các đội ngũ SOC cần tập trung vào việc giám sát các thay đổi liên quan đến khởi động và hoạt động quản trị bất thường. Việc rà soát các tệp tin khởi động và kiểm tra tính toàn vẹn của firmware là bước bắt buộc trong quy trình hardening hệ thống.

Các tổ chức nên tham khảo tài liệu hướng dẫn triển khai Secure Boot từ Microsoft để đảm bảo rằng các bản thu hồi cần thiết đã có hiệu lực. Ngoài ra, việc kiểm tra tính tương thích của các phương tiện khôi phục (recovery media) là cần thiết trước khi áp dụng các thay đổi chính sách bảo mật trên diện rộng.