Máy đã vá đầy đủ vẫn dính bootkit: BlackX, bản sao của BlackLotus, và bản vá mà không ai bật
Tóm tắt
Đầu năm 2026, Kaspersky GReAT phát hiện một chiến dịch APT nhắm vào cơ quan ngoại giao của Tajikistan, Uzbekistan và Turkmenistan, trong đó có một bootkit UEFI được đặt tên BlackX. Phân tích cho thấy nó là một bản sao của BlackLotus, bootkit từng được rao bán 5.000 USD trên diễn đàn tội phạm mạng năm 2022.
BlackX khai thác Baton Drop (CVE-2022-21894) để vượt Secure Boot — một lỗ hổng đã được Microsoft vá từ năm 2023.
Và đây là điểm khiến báo cáo này đáng đọc: các máy bị nhiễm đã được vá đầy đủ. Kaspersky kiểm tra và loại trừ giả thuyết "nạn nhân lười vá". Vấn đề nằm ở chính bản vá: nó không tự kích hoạt. Quản trị viên phải thao tác thêm bằng tay sau khi cài update, và hầu như không ai làm việc đó.
Hành động ưu tiên:
- Kiểm tra xem cơ chế thu hồi Secure Boot đã thực sự được bật trên fleet của bạn chưa — cụ thể là registry flag dưới
HKLM\SYSTEM\CurrentControlSet\Control\Securebootvà scheduled taskSecure-Boot-Update. Có bản vá không đồng nghĩa với được bảo vệ. - Coi mọi bản vá yêu cầu thao tác thủ công là chưa được áp dụng cho tới khi có bằng chứng ngược lại. Đây không phải trường hợp duy nhất: Kaspersky nhắc lại bản vá ToolShell năm 2025 cũng cần bật bằng tay.
Từ BlackLotus tới BlackX
Tháng 10/2022, GReAT theo dõi một bài rao trên diễn đàn hacking: một bootkit UEFI vượt được Secure Boot, giá 5.000 USD, tên BlackLotus. Mức giá quá thấp so với năng lực được quảng cáo khiến cộng đồng bảo mật khi đó hoài nghi, và không ai tìm được mẫu nào ngoài thực địa để kiểm chứng.
Khoảng nửa năm sau, tháng 3/2023, ESET xác nhận bài rao là thật: họ tìm được mẫu và xác nhận bootkit này khai thác Baton Drop để vượt Secure Boot. Vì lỗ hổng vẫn khai thác được ở thời điểm đó, Microsoft phải phát hành nhiều bản cập nhật liên tiếp.
Sau loạt bản vá đó, BlackLotus im lặng. Không có vụ tấn công công khai nào dùng nó nữa — cho tới đầu 2026, khi GReAT bắt gặp một mẫu rất giống nó, lần này trong tay một nhóm APT.
Một chi tiết đáng dừng lại: mã nguồn BlackLotus chưa bao giờ được công bố. Kaspersky so sánh phần khai thác lỗ hổng của hai bootkit và thấy cách hiện thực "rất giống nhau" nhưng không trùng khít. Nghĩa là nhóm đứng sau BlackX hoặc đã dịch ngược BlackLotus, hoặc đã mua mã nguồn từ giới tội phạm mạng.
Theo đúng lời Kaspersky, đây là điều hiếm: "we rarely see APT actors borrow ideas or code from cybercrime actors".
Cách BlackX được triển khai
Bootkit không phải là cửa vào. Kẻ tấn công đã xâm nhập mạng và có quyền administrator trước khi cài nó — phương thức truy cập ban đầu không được xác định trong báo cáo.
Bộ cài gồm hai file:
inst.exe # bo cai
PVMDIJGKAX2 # file khong duoi, ma hoa RC4, chua toan bo file va chuoi can cho qua trinh cai
Dòng lệnh thực thi:
C:\ProgramData\Intel\inst.exe PVMDIJGKAX2 Q46F6MDLI3RX2KV1
Tham số cuối chính là khóa RC4 dùng để giải mã.
Chi tiết đáng chú ý cho đội ứng cứu: inst.exe không chứa chuỗi độc hại hay blob nhúng nào. Toàn bộ nằm trong PVMDIJGKAX2. Nếu chỉ thu được file thực thi mà không thu được file dữ liệu, bạn sẽ không khôi phục được các thành phần của bootkit.
Bộ cài thả file xuống cả phân vùng hệ thống lẫn phân vùng UEFI để khai thác Baton Drop. Mục tiêu của exploit giống hệt BlackLotus: cài Machine Owner Key (MOK) của kẻ tấn công, từ đó nạp được file EFI tùy ý và thao túng Secure Boot.
Driver kernel: mục tiêu là làm EDR im lặng
Payload UEFI nạp trong quá trình khai thác có mục tiêu kinh điển của bootkit — tiêm một driver độc hại vào kernel Windows.
Driver này khác với driver của BlackLotus, và được ký bằng chứng thư của một tổ chức tên 温江区明宇网络技术服务工作室 (Wenjiang District Mingyu Network Technology Service Studio), serial 0bcdf5e0da32d68900b8b7638459d072. Tại thời điểm Kaspersky công bố, chứng thư này đã bị nhà phát hành thu hồi.
Driver làm ba việc:
- Vô hiệu hóa các callback process, thread và registry của giải pháp bảo mật — tức là EDR mất nguồn dữ liệu, chứ không phải bị crash.
- Can thiệp vào ETW provider để sản phẩm bảo mật không đọc được output của chính mình.
- Bảo vệ file của bootkit: nó chặn các request mở file ở tầng kernel và trả về handle của
calc.exethay vì handle thật.
Thủ thuật thứ ba đáng chú ý ở chỗ nó không chặn truy cập một cách lộ liễu. Công cụ forensics mở file sẽ nhận được một handle hợp lệ — chỉ là trỏ nhầm chỗ.
Một điểm thú vị: một số thủ tục can thiệp chỉ chạy nếu máy có cài sản phẩm Kaspersky hoặc Avast. Nhưng khi phân tích động, Kaspersky xác nhận các thủ tục này vô tác dụng — chúng không can thiệp được gì vào sản phẩm của họ.
Hai payload user-mode
Ngoài việc phá giải pháp bảo mật, driver còn thả payload tầng người dùng. GReAT quan sát được hai loại, đều phục vụ gián điệp mạng.
RAT dùng cloud storage làm C2
Payload thứ nhất là một RAT có khả năng nạp tiếp các payload .NET. Nó dùng dịch vụ lưu trữ đám mây làm kênh C2 — các phiên bản quan sát được dùng Google Drive, OneDrive và Yandex.Disk.
Sau khi kết nối, RAT duyệt các file có trên tài khoản và diễn giải chúng theo hậu tố tên file:
| Hậu tố | Ý nghĩa | Chiều |
|---|---|---|
0X01 |
File .NET, nhiệm vụ là phân tích và chạy TEST.Class1.RunCMD(argument_array) |
Vào |
0X02 |
Kết quả của lời gọi TEST.Class1.RunCMD(argument_array) |
Ra |
0X03 |
Nhiệm vụ upload một file lên drive | Vào |
0X04 |
File đã upload | Ra |
0X05 |
Nhiệm vụ tải một file xuống máy nhiễm | Vào |
0X06 |
Trạng thái tải file | Ra |
SSSR |
Thông tin hệ thống ban đầu | Ra |
OxiDLLRunner
Payload thứ hai là một DLL độc hại được làm rối bằng OLLVM, Kaspersky đặt tên là OxiDLLRunner.
Chuỗi nạp:
googleupdate.exe # file sach, thuc chat la jcef_helper.exe
-> sideload OxiDLLRunner (DLL doc hai, obfuscate bang OLLVM)
-> giai ma v8_context_snapshot.bin trong cung thu muc
-> nhay vao dau noi dung da giai ma: shellcode, roi mot file PE
-> payload Rust, C2 www[.]archivetj[.]com
-> nhan ve cac DLL export ham create_plugin, chay trong thread rieng
Cả googleupdate.exe lẫn file dữ liệu đều do bootkit thả xuống. Tên file được chọn để trông như một tiến trình cập nhật bình thường của Google.
Vì sao các tổ chức đã vá vẫn bị nhiễm
Đây là phần quan trọng nhất của toàn bộ báo cáo, và nó không nói về malware.
Ban đầu GReAT cho rằng nạn nhân bị nhiễm vì cẩu thả: Baton Drop đã được công bố và vá từ 2023, nên hẳn là máy thiếu update. Điều tra cho thấy giả thuyết này sai — các máy bị nhắm đều đã vá đầy đủ.
Vấn đề nằm ở thiết kế của chính bản vá.
Bản vá cho Baton Drop hoạt động bằng cách thu hồi chứng thư "Windows Production PCA 2011" — chứng thư dùng để ký các thành phần UEFI có lỗ hổng. Nhưng việc thu hồi không diễn ra tự động khi cài bản vá. Người dùng phải tự kích hoạt, qua hai bước:
- Đặt một registry flag trong
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot - Một scheduled task tên
Secure-Boot-Updateđược tạo ra
Microsoft cố ý thiết kế như vậy, và lý do hoàn toàn chính đáng: áp dụng tự động có thể làm hỏng các hệ thống dual-boot phụ thuộc vào chứng thư "Windows Production PCA 2011" để khởi động.
Nhưng cách triển khai này tạo ra một vấn đề khác. Như Kaspersky viết, việc một quản trị viên phải làm thêm thao tác sau khi cài update là cực kỳ bất thường: thông thường, cài xong là xong, trừ khi có lỗi. Hướng dẫn kích hoạt thì nằm sâu trong tài liệu của Microsoft, và GReAT đánh giá là khó để một quản trị viên IT bình thường nhận ra.
Thêm hai chi tiết làm bức tranh xấu hơn:
- Kế hoạch triển khai của Microsoft có nhắc tới một "Enforcement Phase", giai đoạn sẽ thu hồi chứng thư tự động không cần người dùng can thiệp. Tới thời điểm Kaspersky công bố (22/10/2026), giai đoạn này vẫn chưa được triển khai.
- Ngày 19/10/2026, chứng thư "Windows Production PCA 2011" hết hạn. Nhưng hết hạn không ngăn được các binary có lỗ hổng tiếp tục nạp, trừ khi chứng thư được đưa vào danh sách chặn (DBX).
Kaspersky đánh giá rằng nhóm tấn công đã tính đến chuyện rất ít tổ chức nhận ra phải kích hoạt bản vá bằng tay, và chính vì vậy mới bỏ công tìm hiểu BlackLotus để dựng lại một bản sao.
Quy kết
Kaspersky quy kết chiến dịch này cho APT41 ở mức tin cậy trung bình (medium confidence), dựa trên ba căn cứ:
- Tháng 6/2026, ESET công bố bài viết về nhóm FishMonger (cộng đồng cho rằng có liên hệ với APT41), mô tả một kernel implant có đường dẫn PDB bắt đầu bằng
C:\Users\xdd\Desktop, và gợi ý khả năng có một thành phần bootkit UEFI chưa xác định, có thể khai thác CVE-2023-24932. Kaspersky quan sát thấy định danhxddxuất hiện nhiều lần trong các payload của BlackX, nên đánh giá BlackX chính là bootkit mà ESET nhắc tới. - Payload được nạp qua DLL sideloading từ một file thực thi hợp pháp cộng với một file mã hóa — mẫu hành vi phổ biến ở các nhóm nói tiếng Trung.
- OxiDLLRunner được làm rối bằng OLLVM, công cụ obfuscation hay gặp ở các nhóm này.
Theo The Hacker News, FishMonger — còn được theo dõi dưới tên Aquatic Panda và Earth Lusca — bị cho là hoạt động dưới ô APT41, và đã nhắm vào các cơ quan chính phủ tại Honduras, Đài Loan, Thái Lan và Pakistan trong giai đoạn 2023–2024. ESET khi đó nói họ chỉ có "limited indications" về thành phần bootkit, và nghi nó khai thác CVE-2023-24932, một bypass cho chính các biện pháp Microsoft đưa ra để vá CVE-2022-21894.
Nhận định
Bản vá cần thao tác tay là một dạng nợ bảo mật gần như vô hình. Mọi dashboard tuân thủ đều sẽ báo những máy này là "đã vá". Mọi báo cáo quản lý sẽ nói 100% compliance. Và tất cả đều đúng theo nghĩa đen. Khoảng cách giữa "đã cài bản vá" và "đã được bảo vệ" không xuất hiện ở bất kỳ chỉ số nào mà SOC thường theo dõi.
Quyết định của Microsoft không sai, nhưng hậu quả thì có thật. Tự động thu hồi chứng thư có thể làm hàng loạt máy dual-boot không khởi động được — đó là rủi ro vận hành nghiêm trọng hơn nhiều so với một lỗ hổng cần quyền admin để khai thác. Vấn đề là giai đoạn chuyển tiếp đã kéo dài từ 2023 tới nay, và "Enforcement Phase" vẫn chưa tới.
Bootkit là cơ chế duy trì, không phải cửa vào. Trích dẫn của Microsoft từ 2023 mà The Hacker News nhắc lại vẫn đúng với BlackX: nó chỉ triển khai được trên máy mà kẻ tấn công đã có quyền đặc quyền hoặc truy cập vật lý. Nói cách khác, nếu bạn phát hiện bootkit, sự cố đã diễn ra từ trước đó — và điều cần điều tra là bước truy cập ban đầu mà báo cáo này không xác định được.
Mục tiêu của driver là làm EDR im lặng, không phải làm nó sập. Tắt callback và phá ETW nghĩa là console bảo mật vẫn xanh, agent vẫn báo online, chỉ là không còn gì để báo. Đây là dạng thất bại nguy hiểm nhất của một hệ thống giám sát: nó không báo lỗi.
C2 qua Google Drive, OneDrive và Yandex.Disk là lựa chọn khó chặn nhất hiện nay. Trong một tổ chức đã dùng M365, lưu lượng tới OneDrive là lưu lượng bình thường. Việc phát hiện phải dựa vào hành vi tiến trình — tiến trình nào đang nói chuyện với cloud storage và nó có lý do gì để làm vậy — chứ không dựa vào đích đến.
Chi tiết "driver cố đánh Kaspersky nhưng không ăn thua" nói lên khá nhiều. Nhóm tấn công đủ năng lực để dựng lại một bootkit UEFI từ con số không, nhưng phần chống sản phẩm bảo mật lại không được kiểm thử tới nơi. Đây là mẫu hay gặp: năng lực không đồng đều giữa các thành phần của cùng một bộ công cụ, thường là dấu hiệu của nhiều người hoặc nhiều nguồn code khác nhau.
Liên hệ Việt Nam
- Danh sách nạn nhân Kaspersky công bố không bao gồm Việt Nam — chỉ có Tajikistan, Uzbekistan và Turkmenistan. Tuy nhiên hồ sơ mục tiêu của APT41/FishMonger, theo ESET và The Hacker News, bao phủ cả cơ quan chính phủ ở Đông Nam Á (Thái Lan nằm trong danh sách 2023–2024), nên đây là chủ đề đáng theo dõi chứ không phải tin tức xa.
- Gần như chắc chắn cơ chế thu hồi Secure Boot chưa được bật trên phần lớn fleet Windows tại Việt Nam. Đây là việc kiểm tra được ngay bằng script, và kết quả thường gây bất ngờ. Nếu bạn chỉ làm một việc sau khi đọc bài này, hãy làm việc đó.
- Nếu EDR bị tắt callback, bạn sẽ không nhận được alert báo lỗi. Đội vận hành nên có cách kiểm tra chủ động tính toàn vẹn của agent (telemetry heartbeat theo loại sự kiện, không chỉ heartbeat của agent), vì kỹ thuật này không chỉ BlackX dùng.
- C2 qua OneDrive và Google Drive hòa lẫn hoàn toàn vào lưu lượng doanh nghiệp VN vốn đã dùng M365 và Google Workspace rộng rãi. Hướng phát hiện khả thi là theo tiến trình nguồn, không theo domain đích.
- Mẫu
googleupdate.exechạy ngoài thư mục Google thật là một chỉ dấu rẻ tiền và hiệu quả, áp dụng được cho rất nhiều chiến dịch sideloading khác, không riêng BlackX.
Khuyến nghị
- Kiểm tra trạng thái thu hồi Secure Boot trên toàn bộ fleet, không chỉ trạng thái bản vá: registry flag dưới
HKLM\SYSTEM\CurrentControlSet\Control\Secureboot, sự tồn tại và kết quả chạy của scheduled taskSecure-Boot-Update, và quan trọng nhất là chứng thư "Windows Production PCA 2011" đã nằm trong DBX của UEFI chưa. Hướng dẫn chính thức của Microsoft nằm ở KB5025885. - Lên kế hoạch kích hoạt có kiểm soát, không bật đại trà. Khoanh trước các máy dual-boot, máy có boot media cũ, thiết bị đặc thù và máy ảo được tạo từ template cũ — đó chính là nhóm Microsoft lo ngại khi quyết định không tự động hóa.
- Giám sát ghi file vào EFI System Partition. Việc mount ESP và ghi file EFI gần như không bao giờ xảy ra trong vận hành bình thường, nên đây là một tín hiệu có tỉ lệ nhiễu rất thấp.
- Cảnh báo khi có driver được ký bằng chứng thư đã bị thu hồi hoặc hết hạn được nạp, và đối chiếu với danh sách driver chặn của Microsoft. Serial trong bài này là một mục cụ thể để thêm vào.
- Theo dõi tiến trình mang tên quen thuộc nhưng chạy sai đường dẫn, đặc biệt
googleupdate.exengoài thư mục cài đặt Google, và các tiến trình nạp DLL từ cùng thư mục với một file dữ liệu lạ. - Xây dựng cách kiểm tra chủ động rằng EDR vẫn còn nhận dữ liệu, theo từng loại telemetry (process, thread, registry, ETW) chứ không chỉ theo trạng thái online của agent.
- Rà lại toàn bộ danh mục bản vá cần thao tác thủ công trong tổ chức. Baton Drop không phải trường hợp duy nhất — Kaspersky nhắc lại bản vá ToolShell năm 2025 cũng thuộc nhóm này. Mỗi mục trong danh sách đó cần một người chịu trách nhiệm và một kết quả xác minh, không chỉ một dòng "đã cài".
IOC
Trích từ báo cáo Kaspersky GReAT. Báo cáo không công bố bảng IOC đầy đủ; các chỉ dấu dưới đây lấy từ phần mô tả kỹ thuật.
Hạ tầng C2
www[.]archivetj[.]com # C2 cua payload Rust do OxiDLLRunner nap
Google Drive / OneDrive / Yandex.Disk # C2 cua RAT .NET (dich vu hop phap, khong chan theo domain)
Chứng thư ký driver
To chuc: Wenjiang District Mingyu Network Technology Service Studio
Serial: 0bcdf5e0da32d68900b8b7638459d072
Trang thai: da bi thu hoi
File và đường dẫn
C:\ProgramData\Intel\inst.exe # bo cai, khong chua chuoi doc hai
C:\ProgramData\Intel\PVMDIJGKAX2 # file khong duoi, ma hoa RC4
googleupdate.exe # file sach bi lam dung (goc: jcef_helper.exe)
# MD5 AF8A983B9ADA07EAE1259BF2953ABD40
v8_context_snapshot.bin # chua shellcode + PE payload Rust, da ma hoa
Chuỗi và mẫu hành vi
Dong lenh: inst.exe <file_ma_hoa> <khoa_RC4> # khoa RC4 nam trong command line
Khoa mau: Q46F6MDLI3RX2KV1
Chuoi: xdd # trung voi PDB path C:\Users\xdd\Desktop (ESET/FishMonger)
Hau to C2: 0X01 0X02 0X03 0X04 0X05 0X06 SSSR # ten file tren cloud storage
Ham export: create_plugin # trong cac DLL plugin nhan ve tu C2
Hanh vi: mo file bootkit tra ve handle cua calc.exe
Mục cần kiểm tra trên máy của bạn (không phải IOC, nhưng quan trọng hơn)
HKLM\SYSTEM\CurrentControlSet\Control\Secureboot # registry flag kich hoat thu hoi
Scheduled task: Secure-Boot-Update # tac vu thuc hien thu hoi
DBX: "Windows Production PCA 2011" # da nam trong danh sach chan chua
Tài liệu tham khảo
- Kaspersky GReAT (Georgy Kucherin, Vladimir Nestor, Vasily Berdnikov) — New BlackX UEFI bootkit exploiting Baton Drop (22/10/2026): https://securelist.com/uefi-bootkit-blackx/121539/
- The Hacker News — BlackX UEFI Bootkit Bypasses Secure Boot on Patched Windows Systems Missing Revocations: https://thehackernews.com/2026/10/blackx-uefi-bootkit-bypasses-secure.html
- Microsoft — KB5025885: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932: https://support.microsoft.com/help/5025885
- ESET (3/2023) — xác nhận và phân tích bootkit BlackLotus
- ESET (6/2026) — báo cáo chiến dịch FishMonger, nguồn của chỉ dấu
xddvà nghi vấn thành phần bootkit UEFI
Comments
Join the discussionNo comments yet. Be the first to comment.
