-
09/04/2020
-
115
-
1.147 bài viết
PlugX và Bookworm tái xuất trong chiến dịch APT mới nhắm vào hạ tầng viễn thông ASEAN
Trong những tháng gần đây, các chuyên gia an ninh mạng ghi nhận một chiến dịch tinh vi và kéo dài nhắm vào hạ tầng viễn thông cùng một số ngành sản xuất tại Trung Á, Nam Á và khu vực ASEAN. Chiến dịch này nổi bật với sự xuất hiện của một biến thể mới của PlugX đồng thời có các hoạt động triển khai Bookworm chạy song song, với nhiều dấu hiệu kỹ thuật trùng lặp với các nhóm APT Trung Quốc, làm nổi bật tính phối hợp và đầu tư kỹ thuật của kẻ tấn công.
Phân tích kỹ thuật cho thấy biến thể PlugX hiện tại không chỉ lặp lại những đặc điểm truyền thống mà còn mang nhiều dấu ấn trùng lặp với RainyDay và Turian, bao gồm việc lợi dụng các chương trình hợp pháp để thực hiện DLL side-loading và chuỗi xử lý payload theo dạng XOR → RC4 → RtlDecompressBuffer. Một ví dụ thực tế được nêu trong báo cáo là một sự cố nhắm vào một nhà mạng ở Kazakhstan, minh họa cho xu hướng nhắm tới các tổ chức viễn thông trong khu vực.
Những trùng lặp về kỹ thuật và đối tượng mục tiêu gợi mở hai khả năng: hoặc những cluster được gán tên khác nhau thực chất là cùng một tác nhân, hoặc các nhóm này đang sử dụng chung công cụ hoặc nhà cung cấp phần mềm độc hại. Tuy vậy, các chuyên gia lưu ý rằng cần thêm bằng chứng để khẳng định attribution cuối cùng; các nhà nghiên cứu đánh giá mức độ liên hệ là “trung bình”, nghĩa là có nhiều chỉ báo kỹ thuật hỗ trợ mối liên hệ song vẫn cần dữ liệu bổ sung để khẳng định nguồn gốc duy nhất của mối đe dọa.
Mô tả kỹ thuật chuỗi tấn công thể hiện một quy trình khởi phát điển hình: kẻ tấn công lợi dụng một thực thi hợp pháp để side-load một DLL độc hại thông qua cơ chế tìm kiếm DLL của Windows. DLL giả này chứa logic giải mã xử lý một blob payload được lưu trong resource hoặc cấu hình. Thứ tự giải mã thường gồm thao tác XOR ban đầu để giảm khả năng phát hiện tĩnh, tiếp theo là giải mã RC4 và cuối cùng là gọi API RtlDecompressBuffer để giải nén payload vào bộ nhớ. Kết quả là payload thực thi trực tiếp trong bộ nhớ, hạn chế dấu vết trên đĩa và làm phân tích tĩnh trở nên kém hiệu quả.
Khi payload đã ở trong bộ nhớ, các kỹ thuật thực thi phổ biến bao gồm cấp phát vùng nhớ bằng VirtualAlloc, ghi shellcode vào vùng nhớ, điều chỉnh quyền trang bằng VirtualProtect và tạo luồng thực thi thông qua CreateThread, hoặc nạp module bằng Reflective DLL loading. PlugX trong các biến thể gần đây còn hỗ trợ nạp plugin động như keylogger theo cấu hình, cho phép kẻ tấn công mở rộng chức năng tùy theo mục tiêu. Do tính fileless và thực thi trong bộ nhớ cao, phát hiện dựa trên chữ ký tĩnh không còn phù hợp; thay vào đó cần tập trung phát hiện hành vi như chuỗi gọi API bất thường, nạp module trong tiến trình hợp pháp và các pattern kết nối tới máy chủ điều khiển.
Bookworm, công cụ gắn với Mustang Panda, có kiến trúc mô-đun rõ ràng với một loader đảm nhiệm kết nối C2 và tải xuống module chức năng như truyền tải file, thực thi lệnh, thu thập tình báo và rút dữ liệu. Để né tầm nhìn, Bookworm sử dụng tên miền hợp pháp hoặc hạ tầng bị chiếm quyền làm kênh C2. Một số biến thể hiện đại còn nhúng shellcode dưới dạng chuỗi UUID; khi ghép và giải mã, chuỗi này chuyển thành blob nhị phân được cấp phát và thực thi trong bộ nhớ. Kiến trúc mô-đun khiến phân tích tĩnh chỉ lột được phần loader, còn phần chức năng thực sự xuất hiện sau khi module được tải xuống từ C2.
Những chỉ báo dễ quan sát gồm nhật ký nạp DLL từ thư mục bất thường kèm theo tiến trình hợp pháp, chuỗi gọi API liên quan tới cấp phát và ghi vùng nhớ, lời gọi đến API nén/giải nén như RtlDecompressBuffer, sự xuất hiện của chuỗi UUID dài trong cấu hình hoặc registry, cùng các mẫu DNS/HTTP(S) tới tên miền trông hợp lệ nhưng có lịch sử đăng ký bất thường. Việc tái sử dụng khóa RC4 hoặc hằng số XOR giữa nhiều mẫu cũng là chỉ báo mạnh để liên kết các sự kiện. Vì đặc tính thực thi trong bộ nhớ, việc thu thập memory dump ngay khi phát hiện hành vi đáng ngờ và phân tích lưu lượng DNS/Netflow để xác định C2 là bước then chốt trong điều tra.
Để ứng phó hiệu quả, cần kết hợp kiểm soát cả endpoint và mạng. Trên endpoint, rà soát các ứng dụng có nguy cơ bị side-loading và áp dụng SetDefaultDllDirectories cùng AddDllDirectory, buộc sử dụng đường dẫn tuyệt đối cho thư viện nội bộ, kích hoạt AppLocker hoặc Windows Defender Application Control để chặn DLL không ký số, và cấu hình EDR để ghi lại chi tiết các API liên quan đến cấp phát và ghi bộ nhớ. Trên mạng, tăng cường giám sát DNS và HTTP(S) để phát hiện pattern C2, sử dụng sinkhole hoặc firewall để chặn tên miền độc hại đã xác định và phân tích các kết nối phát sinh từ tiến trình nghi ngờ. Trong quá trình triage, ưu tiên cô lập tiến trình, lấy memory dump, thu thập danh sách DLL đã được load và các key/cấu hình trong registry để phục hồi module và cấu hình đã tải xuống.
Bối cảnh chiến lược chỉ ra đây là một nỗ lực kéo dài, có chọn mục tiêu và có đầu tư kỹ thuật, tập trung vào các tổ chức viễn thông, cơ sở hạ tầng và các đơn vị trong khu vực ASEAN. Thực tế này đòi hỏi các đội SOC và IR duy trì cảnh giác lâu dài, cập nhật playbook xử lý các mối đe dọa thực thi trong bộ nhớ, chuẩn hoá quy trình thu thập memory dump an toàn, củng cố chính sách quản trị DLL và đẩy mạnh chia sẻ chỉ báo giữa các tổ chức trong khu vực để phát hiện sớm và ngăn chặn lây lan.
Những trùng lặp về kỹ thuật và đối tượng mục tiêu gợi mở hai khả năng: hoặc những cluster được gán tên khác nhau thực chất là cùng một tác nhân, hoặc các nhóm này đang sử dụng chung công cụ hoặc nhà cung cấp phần mềm độc hại. Tuy vậy, các chuyên gia lưu ý rằng cần thêm bằng chứng để khẳng định attribution cuối cùng; các nhà nghiên cứu đánh giá mức độ liên hệ là “trung bình”, nghĩa là có nhiều chỉ báo kỹ thuật hỗ trợ mối liên hệ song vẫn cần dữ liệu bổ sung để khẳng định nguồn gốc duy nhất của mối đe dọa.
Mô tả kỹ thuật chuỗi tấn công thể hiện một quy trình khởi phát điển hình: kẻ tấn công lợi dụng một thực thi hợp pháp để side-load một DLL độc hại thông qua cơ chế tìm kiếm DLL của Windows. DLL giả này chứa logic giải mã xử lý một blob payload được lưu trong resource hoặc cấu hình. Thứ tự giải mã thường gồm thao tác XOR ban đầu để giảm khả năng phát hiện tĩnh, tiếp theo là giải mã RC4 và cuối cùng là gọi API RtlDecompressBuffer để giải nén payload vào bộ nhớ. Kết quả là payload thực thi trực tiếp trong bộ nhớ, hạn chế dấu vết trên đĩa và làm phân tích tĩnh trở nên kém hiệu quả.
Khi payload đã ở trong bộ nhớ, các kỹ thuật thực thi phổ biến bao gồm cấp phát vùng nhớ bằng VirtualAlloc, ghi shellcode vào vùng nhớ, điều chỉnh quyền trang bằng VirtualProtect và tạo luồng thực thi thông qua CreateThread, hoặc nạp module bằng Reflective DLL loading. PlugX trong các biến thể gần đây còn hỗ trợ nạp plugin động như keylogger theo cấu hình, cho phép kẻ tấn công mở rộng chức năng tùy theo mục tiêu. Do tính fileless và thực thi trong bộ nhớ cao, phát hiện dựa trên chữ ký tĩnh không còn phù hợp; thay vào đó cần tập trung phát hiện hành vi như chuỗi gọi API bất thường, nạp module trong tiến trình hợp pháp và các pattern kết nối tới máy chủ điều khiển.
Bookworm, công cụ gắn với Mustang Panda, có kiến trúc mô-đun rõ ràng với một loader đảm nhiệm kết nối C2 và tải xuống module chức năng như truyền tải file, thực thi lệnh, thu thập tình báo và rút dữ liệu. Để né tầm nhìn, Bookworm sử dụng tên miền hợp pháp hoặc hạ tầng bị chiếm quyền làm kênh C2. Một số biến thể hiện đại còn nhúng shellcode dưới dạng chuỗi UUID; khi ghép và giải mã, chuỗi này chuyển thành blob nhị phân được cấp phát và thực thi trong bộ nhớ. Kiến trúc mô-đun khiến phân tích tĩnh chỉ lột được phần loader, còn phần chức năng thực sự xuất hiện sau khi module được tải xuống từ C2.
Những chỉ báo dễ quan sát gồm nhật ký nạp DLL từ thư mục bất thường kèm theo tiến trình hợp pháp, chuỗi gọi API liên quan tới cấp phát và ghi vùng nhớ, lời gọi đến API nén/giải nén như RtlDecompressBuffer, sự xuất hiện của chuỗi UUID dài trong cấu hình hoặc registry, cùng các mẫu DNS/HTTP(S) tới tên miền trông hợp lệ nhưng có lịch sử đăng ký bất thường. Việc tái sử dụng khóa RC4 hoặc hằng số XOR giữa nhiều mẫu cũng là chỉ báo mạnh để liên kết các sự kiện. Vì đặc tính thực thi trong bộ nhớ, việc thu thập memory dump ngay khi phát hiện hành vi đáng ngờ và phân tích lưu lượng DNS/Netflow để xác định C2 là bước then chốt trong điều tra.
Để ứng phó hiệu quả, cần kết hợp kiểm soát cả endpoint và mạng. Trên endpoint, rà soát các ứng dụng có nguy cơ bị side-loading và áp dụng SetDefaultDllDirectories cùng AddDllDirectory, buộc sử dụng đường dẫn tuyệt đối cho thư viện nội bộ, kích hoạt AppLocker hoặc Windows Defender Application Control để chặn DLL không ký số, và cấu hình EDR để ghi lại chi tiết các API liên quan đến cấp phát và ghi bộ nhớ. Trên mạng, tăng cường giám sát DNS và HTTP(S) để phát hiện pattern C2, sử dụng sinkhole hoặc firewall để chặn tên miền độc hại đã xác định và phân tích các kết nối phát sinh từ tiến trình nghi ngờ. Trong quá trình triage, ưu tiên cô lập tiến trình, lấy memory dump, thu thập danh sách DLL đã được load và các key/cấu hình trong registry để phục hồi module và cấu hình đã tải xuống.
Bối cảnh chiến lược chỉ ra đây là một nỗ lực kéo dài, có chọn mục tiêu và có đầu tư kỹ thuật, tập trung vào các tổ chức viễn thông, cơ sở hạ tầng và các đơn vị trong khu vực ASEAN. Thực tế này đòi hỏi các đội SOC và IR duy trì cảnh giác lâu dài, cập nhật playbook xử lý các mối đe dọa thực thi trong bộ nhớ, chuẩn hoá quy trình thu thập memory dump an toàn, củng cố chính sách quản trị DLL và đẩy mạnh chia sẻ chỉ báo giữa các tổ chức trong khu vực để phát hiện sớm và ngăn chặn lây lan.
Theo The Hacker News