Một mã độc tinh vi mới đã được phát hiện, sử dụng hình ảnh ISO độc hại để triển khai các kỹ thuật tấn công phức tạp bao gồm DLL side-loading và payload injection trong bộ nhớ. Sự việc bắt đầu khi một tệp ISO độc hại, có tên Servicenow-BNM-Verify.iso, được tải lên VirusTotal từ Malaysia, với tỷ lệ phát hiện ban đầu rất thấp. Phân tích chuyên sâu đã hé lộ một mã độc được thiết kế để vượt qua các biện pháp an ninh truyền thống.

Kỹ thuật Khai thác Ban đầu: Tệp ISO và Side-loading DLL

Tệp ISO này chứa bốn tệp con, trong đó hai tệp hiển thị công khai và hai tệp ẩn. Các tệp hiển thị bao gồm một shortcut của Windows, servicenow-bnm-verify.lnk, được thiết kế để khởi chạy tệp thực thi hợp lệ của Palo Alto Networks, PanGpHip.exe.

Ẩn trong cùng tệp ISO là libeay32.dll, một thư viện OpenSSL chính hãng, và libwaapi.dll, một thư viện DLL độc hại. Thư viện độc hại này được side-load một cách chiến thuật bởi tệp thực thi Palo Alto hợp pháp, tạo điều kiện cho quá trình lây nhiễm ban đầu của mã độc.

Chuỗi Khai thác Qua Tệp LNK

Phân tích tệp servicenow-bnm-verify.lnk đã hé lộ các siêu dữ liệu pháp y quan trọng. Thông tin này bao gồm tên máy của tác nhân (desktop-rbg1pik), tên người dùng (john.GIB) và dấu thời gian tạo liên kết vào ngày 25 tháng 8 năm 2025. Chi tiết này cung cấp cái nhìn về môi trường phát triển của kẻ tấn công, như đã được báo cáo bởi các nhà nghiên cứu.

Mặc dù đường dẫn đích của shortcut trỏ đến một thư mục “excluded” không tồn tại trên máy nạn nhân, tệp LNK này vẫn tự động chuyển về thư mục chứa nó. Cơ chế dự phòng này đảm bảo PanGpHip.exe sẽ được thực thi bất cứ khi nào tệp ISO được gắn kết, mở đường cho việc triển khai mã độc.

Cơ chế DLL Side-loading

Trọng tâm của cuộc tấn công mạng này nằm ở libwaapi.dll. Thư viện này chỉ xuất một hàm mang mã duy nhất, wa_api_setup. Hàm này trước tiên ẩn cửa sổ console bằng cách gọi các API GUI của Windows, một kỹ thuật nhằm che giấu hoạt động độc hại.

Sau đó, nó kiểm tra sự tồn tại của một mutex có tên 47c32025. Nếu mutex này không có mặt (cho thấy đây có thể là lần lây nhiễm đầu tiên hoặc chưa có phiên bản mã độc nào đang chạy), wa_api_setup sẽ gọi một hàm được đổi tên thành fn_payload_injection. Hàm này chịu trách nhiệm thực hiện việc tiêm payload trực tiếp vào bộ nhớ, một kỹ thuật khó bị phát hiện xâm nhập bởi các giải pháp an ninh dựa trên tệp.

Phân tích Chuyên sâu về Cơ chế Hoạt động của Mã Độc

Hàm fn_payload_injection tính toán giá trị băm SHA-256 của chuỗi “rdfY*&689uuaijs” và sử dụng kết quả này làm khóa RC4. Đây là bước đầu tiên và quan trọng trong quy trình giải mã phức tạp của mã độc, chuẩn bị cho việc tải và thực thi payload chính.

Tiếp theo, nó giải mã chuỗi “chakra.dll” và tải thư viện DLL hợp lệ này của Windows từ C:WindowsSystem32. Hàm này sau đó định vị phần thực thi đầu tiên của thư viện, thay đổi quyền thành ghi, xóa nội dung của nó, và giải mã Base64 một payload ẩn được lưu trữ trong phần .data của DLL. Việc thao túng DLL hệ thống hợp pháp này là một thủ thuật khác để tránh bị phát hiện.

Giải mã và Xác thực Payload

Sau khi giải mã dữ liệu bằng RC4, mã độc sẽ xác thực tính toàn vẹn của payload dựa trên một giá trị SHA-256 được mã hóa cứng. Nếu kiểm tra thành công, các quyền bộ nhớ sẽ được khôi phục và quyền thực thi được chuyển giao cho payload đã được tiêm. Quy trình kiểm tra này đảm bảo payload không bị giả mạo hoặc hỏng hóc trong quá trình truyền tải hoặc giải mã.

Shellcode được tiêm này tiếp tục giải nén một DLL nhúng thông qua hàm RtlDecompressBuffer, sử dụng thuật toán LZNT1 với mức nén tối đa. DLL kết quả có dấu thời gian giả mạo là ngày 5 tháng 5 năm 1984, một chiến thuật chống phân tích bằng cách làm xáo trộn thông tin thời gian thực. Hành vi độc hại chính của DLL này được triển khai trong hàm export DllUnload, một điểm bất thường khác.

Payload Cuối Cùng và Cơ chế C2 qua Azure Functions

Phân tích ban đầu cho thấy cơ chế gỡ hook module (module unhooking) được sử dụng để trốn tránh các biện pháp phát hiện xâm nhập. Kỹ thuật này cho phép mã độc thay thế các hook được cài đặt bởi các giải pháp bảo mật, giúp nó hoạt động mà không bị giám sát. Payload cuối cùng này sau đó đi vào một vòng lặp, gửi dữ liệu của nạn nhân đến địa chỉ logsapi.azurewebsites[.]net/api/logs, sử dụng Azure Functions làm backend Command and Control (C2).

Bằng cách lạm dụng Azure Functions, tác nhân đe dọa tận dụng một môi trường không máy chủ có khả năng mở rộng, với các trình kích hoạt và liên kết dựa trên sự kiện. Điều này không chỉ cung cấp cho chúng một hạ tầng C2 linh hoạt và bền bỉ mà còn giúp che giấu nguồn gốc của các yêu cầu độc hại, làm phức tạp các nỗ lực phát hiện xâm nhập và phản ứng.

Thu thập Thông tin Hệ thống

Mã độc gửi một payload định dạng XML chứa siêu dữ liệu hệ thống chi tiết. Các thông tin này bao gồm: kiến trúc hệ thống (ví dụ: x64), thời gian hoạt động (uptime), phiên bản hệ điều hành (OS build), tên máy tính và tên người dùng, danh sách các tiến trình đang chạy và nhiều chi tiết cấu hình hệ thống khác.

Thông tin này được mã hóa trước khi truyền đi, nhưng có thể bị chặn ở dạng chưa mã hóa trước khi quá trình mã hóa diễn ra. Việc thu thập và phân tích dữ liệu này cho thấy ý định của kẻ tấn công là lập hồ sơ chi tiết các máy chủ bị xâm nhập, nhằm mục đích đánh giá giá trị của mục tiêu và chuẩn bị cho các giai đoạn tấn công tiếp theo hoặc khai thác dữ liệu.

Chỉ số Compromise (IOCs)

Để hỗ trợ các nỗ lực bảo mật mạng và phát hiện xâm nhập, dưới đây là các chỉ số thỏa hiệp liên quan đến mã độc này. Các tổ chức nên kiểm tra hệ thống của mình để tìm kiếm bất kỳ dấu hiệu nào của các IOC này:

• Tên tệp ISO độc hại:Servicenow-BNM-Verify.iso
• URL C2:logsapi.azurewebsites[.]net/api/logs
• Chuỗi băm RC4:rdfY*&689uuaijs (được sử dụng để tạo khóa RC4)
• Mutex được kiểm tra:47c32025
• Tên tệp LNK:servicenow-bnm-verify.lnk
• Tên DLL độc hại:libwaapi.dll

Dấu hiệu Chiến dịch và Các biện pháp Phát hiện Xâm nhập

Một DLL tương tự, có cùng imphash, đã xuất hiện trên VirusTotal từ Singapore vào ngày 5 tháng 9 năm 2025. Điều này cho thấy chiến dịch sử dụng mã độc này đang lan rộng trên nhiều khu vực địa lý, không chỉ giới hạn ở Malaysia, và có khả năng là một phần của một chiến dịch phức tạp hơn.

Các nỗ lực giải mã liên tục đang được tiến hành để hé lộ thêm các khả năng của payload, bao gồm cả các chiến thuật phòng thủ chống lại phát hiện xâm nhập. Một phân tích tiếp theo sẽ khám phá các cơ chế duy trì quyền truy cập (persistence mechanisms) và bất kỳ quy trình di chuyển ngang (lateral movement routines) nào được phát hiện trong hạ tầng tinh vi được hỗ trợ bởi Azure Functions này. Để biết thêm chi tiết về phân tích ban đầu, bạn có thể tham khảo báo cáo của nhà nghiên cứu.