PHÂN TÍCH KỸ THUẬT

Nội dung này mô tả chức năng của TransferLoader cũng như các payload được nhúng trong phần mềm độc hại. Các payload này có khả năng được phát triển bởi cùng một tác nhân đe dọa và có chung điểm tương đồng về code. Zscaler đã xác định các mẫu TransferLoader có các payload được nhúng sau:

- Downloader (Trình tải xuống): Tải và thực thi một phần mềm từ máy chủ điều khiển và ra lệnh (C2).

- Backdoor loader: Thực thi mô-đun backdoor và quản lý dữ liệu cấu hình của nó.

- Backdoor: thực thi các lệnh được chỉ định bởi C2.

Một payload khác được phát hiện trong TransferLoader là họ mã độc tống tiền được gọi là Morpheus. Mặc dù code của Morpheus có một số điểm tương đồng với các payload đã đề cập ở trên (ví dụ như các quy trình giải mã chuỗi), nhưng mối liên hệ giữa chúng không rõ ràng.

Chống phân tích

Chống VM/chống gỡ lỗi

TransferLoader và các phần payload của nó có các phương pháp chống phân tích sau:

- Loader sẽ lấy tên tệp của chính nó và kiểm tra xem có bao gồm chuỗi con được mã hóa cứng đã chỉ định hay không (ví dụ: chuỗi substring ess) theo sau là ký tự “_”.

- Một số biến thể của loader yêu cầu hai hoặc nhiều tham số dòng lệnh để tiến hành thực thi.

- Tất cả các thành phần đều sử dụng trường BeingDebugged trong Process Environment Block (PEB) để phát hiện phiên gỡ lỗi.

- Windows API được xử lý động bằng thuật toán băm. Windows API là các chức năng giúp mã độc tương tác với các thư viện của Microsoft. Windows API trong các thư viện rất đầy đủ nên hầu hết các nhà phát triển ứng dụng rất ít khi phải sử dụng các thư viện của bên thứ ba.

- Có các khối junk code trong một số chức năng của trình tải (Hình 1). Khối inserted code không bao giờ thực thi, nhưng phần bổ sung này đủ để phá vỡ quá trình dịch ngược của IDA.

Hình 1. Ví dụ về khối junk code TransferLoader

Mã hóa chuỗi

Mỗi thành phần TransferLoader giải mã chuỗi khi runtime bằng thao tác bitwise-XOR. Mỗi chuỗi được ghép nối với một khóa 8 byte duy nhất để giải mã. Dữ liệu chuỗi được mã hóa được đẩy vào ngăn xếp và giải mã (Hình 2).

Hình 2. Ví dụ giải mã chuỗi runtime TransferLoader

Code obfuscation

Code obfuscation là kỹ thuật làm rối code. Tất cả thành phần được các nhà nghiên cứu phân tích đề sử dụng kỹ thuật này bằng 2 phương pháp dưới đây.

Phương pháp obfuscation 1

Phương pháp đầu tiên đọc địa chỉ hiện tại của khối và trừ một offset được mã hóa cứng khỏi địa chỉ này. Kết quả là địa chỉ khối tiếp theo để nhảy/thực thi (jump/execute) như Hình 3.

Hình 3. Luồng điều khiển được làm rối của TransferLoader

Các nhà nghiên cứu chỉ quan sát phương pháp đầu tiên này trong TransferLoader (không phải các thành phần nhúng của nó) và luồng điều khiển có thể được khôi phục bằng cách sử dụng tập lệnh IDAPython có trong kho lưu trữ GitHub của Zscaler.

Phương pháp obfuscation 1

Phương pháp thứ hai sử dụng cách tiếp cận tiên tiến hơn và các nhà phát triển sử dụng phương pháp này trong các payload nhúng trong TransferLoader (không giống như phương pháp đầu tiên chỉ được sử dụng trong chính TransferLoader).

Quá trình obfuscation bắt đầu bằng cách lưu tất cả các thanh ghi (bao gồm các thanh ghi RFLAGS và SIMD) và sau đó phân bổ không gian ngăn xếp cho các hoạt động/lưu trữ tiếp theo. Sau đó, bất kỳ biến và tham số hàm cục bộ nào được lưu trữ trong các thanh ghi SIMD và các lệnh obfuscation được thực thi. Mỗi lệnh obfuscation có handler riêng (handler đơn giản là tham chiếu đến một đối tượng, giúp Windows API xử lý đối tượng đó).

Ví dụ, khối code trong Hình 4 cho thấy obfuscation lấy giá trị hằng số 0x1000 và sau đó lưu trữ giá trị đó trong thanh ghi SIMD XMM4. Giá trị được lưu trữ được sử dụng ở giai đoạn sau của quá trình thực thi dưới dạng tham số function. Hơn nữa, các lệnh để chèn giá trị vào thanh ghi SIMD chứa các lệnh junk để cản trở việc phân tích. Ngoài ra, điều quan trọng cần lưu ý là trước khi thực thi handler, obfuscation sẽ lưu offset của địa chỉ khối tiếp theo để thực thi ngay sau khi handler đã thực thi.

Hình 4. TransferLoader obfuscation handler

Sau khi thực hiện các obfuscation handler được che giấu, obfuscation sẽ đặt lại trạng thái của các thanh ghi. Ở giai đoạn này, bất kỳ giá trị nào được đẩy từ các obfuscation handler đều được đặt vào các thanh ghi. Mặc dù obfuscation handler xử lý một tập hợp nhỏ các lệnh (ví dụ: lệnh XOR, REG không được xử lý), nhưng kẻ tấn công vẫn có thể che giấu việc sửa đổi hoặc gán các biến cục bộ và cấu trúc code.

TransferLoader

Zscaler đã quan sát thấy các biến thể khác nhau của TransferLoader với các khác biệt nhỏ về chức năng. TransferLoader giải mã và thực thi một payload nhúng bằng quy trình giải mã đơn giản, được tóm tắt như sau:

1. TransferLoader lấy dữ liệu từ phần PE với payload được mã hóa. Tên của phần này có thể thay đổi tùy theo từng mẫu. Ví dụ, các nhà nghiên cứu đã quan sát tên section là .dbg và .secenc .

2. Tiếp theo, TransferLoader giải mã hai chuỗi: khóa AES 16 byte và bộ mã hóa Base32 tùy chỉnh.

3. TransferLoader tính toán khóa 1 byte từ bộ mã hóa Base32 tùy chỉnh và thêm khóa đã tính toán vào mỗi byte được mã hóa của section mục tiêu.

4. Đầu ra của thao tác trước là chuỗi Base32, sau đó được giải mã bằng Base32 với bộ ký tự Base32 tùy chỉnh.

5. Cuối cùng, TransferLoader thực hiện thao tác bitwise-XOR với khóa AES 16 byte và dữ liệu đã giải mã. Sau đó, kết quả được giải mã bằng thuật toán AES-CBC (với khóa AES đã đề cập ở trên).

Lưu ý rằng các phiên bản cũ hơn của TransferLoader sử dụng giải mã Base32 hoặc AES cho dữ liệu cuối cùng, nhưng không sử dụng cả hai cùng một lúc.

Downloader

Thành phần downloader là payload nhúng phổ biến nhất của TransferLoader mà Zscaler đã quan sát cho đến nay. Mục tiêu chính của downloader là tải xuống một payload bổ sung từ máy chủ C2 và thực thi một tệp mồi nhử. Downloader gửi request HTTPS GET đến máy chủ để lấy dữ liệu. Request HTTP sử dụng các header HTTP sau:

- User-Agent: Microsoft Edge/1.0

- X-Custom-Header: xxx

Downloader giải mã payload đã nhận bằng cách sử dụng thao tác bitwise-XOR với khóa 4 byte được mã hóa cứng 0xFFFFFFFF. Sau khi thực thi payload đã giải mã, downloader sẽ cố gắng xử lý một lệnh xuất từ ​​payload đã tải bằng thuật toán băm tùy chỉnh của nó. Lệnh DLL trích xuất phải khớp với giá trị băm 0xF78B59DF7AED203F.

Sau khi hoàn tất thao tác trên, downloader sẽ mở tệp PDF giả mạo. Nếu chức năng xuất tệp đã tải xuống được thực hiện thành công nhưng không trả về bất kỳ dữ liệu nào, thì downloader sẽ khởi động lại phiên bản Windows Explorer hiện tại (explorer[.]exe). Tài liệu giả mạo được nhúng trong tệp nhị phân hoặc downloader sẽ tạo tệp PDF không hợp lệ bao gồm 8 byte dữ liệu junk.

Backdoor loader

Mô-đun backdoor có loader riêng, xử lý mọi yêu cầu đọc hoặc sửa đổi dữ liệu cấu hình. Backdoor loader dự kiến ​​sẽ nằm trong không gian bộ nhớ của phiên bản Explorer (explorer[.]exe) hoặc WordPad (wordpad[.]exe). Trong trường hợp thứ hai (WordPad), Backdoor loader thực hiện các hành động bổ sung bao gồm:

- Hook Windows API ShowWindow. Hook code sẽ đi vào vòng lặp sleep vô hạn.

- Xóa key registry CSLID  SOFTWARE\Classes\CLSID\{F5078F32-C551-11D3-89B9-0000F81FE221}, đây là đối tượng XML DOM Document 3.0.

- Sử dụng key registry  SOFTWARE\Classes\CLSID\{1BAC8681-2965-4FFC-92D1-170CA4099E01}, đại diện cho đối tượng Windows[.]System[.]User[.]ProxyStubFactory, để thêm tính bền bỉ vào máy chủ bị xâm phạm. Phương pháp này còn được gọi là Component Object Model (COM) hijacking.

Theo các nhà nghiên cứu, backdoor loader sau cố gắng tạo tệp defender[.]user[.]tmp trong thư mục tạm thời của Windows. Nếu backdoor loader không thực hiện được điều này, quá trình thực thi sẽ dừng lại. Các nhà nghiên cứu không thể xác nhận mục đích của hoạt động này. Để mô-đun backdoor loader cập nhật hoặc truy xuất thông tin cấu hình, nó sẽ tạo một pipe có tên bằng cách sử dụng tên được mã hóa cứng (trong các mẫu phân tích, tên được đặt thành nice).

Giao tiếp pipe được mã hóa bằng phép toán bitwise-XOR với khóa XOR được mã hóa cứng 4 byte (ví dụ: 0x534110E6) như Hình 5.

Hình 5. Giao tiếp pipe được mã hóa

Bước cuối cùng, backdoor loader thực thi backdoor từ key registry SOFTWARE\Microsoft\Phone\Config\md sau khi giải mã bằng cùng thuật toán XOR ở trên.

Backdoor

Mô-đun Backdoor là bộ điều phối cốt lõi để tiếp nhận và thực thi các lệnh từ máy chủ C2 cũng như để cập nhật dữ liệu cấu hình của chính nó.

Trong giai đoạn khởi tạo, backdoor yêu cầu dữ liệu cấu hình từ loader của nó. Nếu dữ liệu cấu hình không có, quá trình thực thi sẽ không tiếp tục và phần mềm độc hại sẽ thoát. Sau khi đọc và thiết lập thông tin cấu hình, backdoor sẽ cố gắng bắt đầu giao tiếp ban đầu với máy chủ C2 độc hại.

Điều thú vị là, backdoor sử dụng InterPlanetary File System - IPFS (một hệ thống tệp tin phân tán ngang hàng) nếu không thể thiết lập kết nối thành công với máy chủ C2. Cụ thể, backdoor gửi yêu cầu đến URL IPFS và mong đợi một máy chủ C2 mới để đáp lại. Sử dụng tính năng này, các tác nhân đe dọa có thể chuyển hướng các máy chủ bị xâm phạm đến một máy chủ C2 mới trong trường hợp máy chủ bị dừng hoạt động.

Mô-đun backdoor hỗ trợ cả phương thức giao tiếp HTTPS và TCP raw. TCP chỉ được sử dụng khi backdoor không thể khởi tạo phiên HTTP với máy chủ. Đối với request header HTTP, backdoor sử dụng user agent My Agent/1.0 cùng với header tùy chỉnh X-Edge-key: none. Hơn nữa, backdoor lưu trữ cả thông tin phiên và dữ liệu cấu hình theo cấu trúc như Hình 6.

Hình 6. Cấu trúc lưu trữ của backdoor

Ngay khi kết nối với máy chủ được thiết lập, backdoor sẽ yêu cầu một lệnh. Mỗi gói tin nhận được có header riêng với kích thước 43 byte theo sau là các tham số lệnh có kích thước lên đến 4.058 byte. Trước khi phân tích gói tin mạng đến, backdoor sẽ xác minh tính toàn vẹn của gói tin, bằng cách tính toán giá trị checksum của header. Nếu gói tin nhận được vượt qua xác thực checksum, thì backdoor sẽ giải mã nó bằng mã hóa luồng tùy chỉnh,

Khi backdoor gửi yêu cầu đến máy chủ, trước tiên nó mã hóa phần header của gói tin và sau đó là dữ liệu tham số của lệnh (nếu không có dữ liệu, thì mã hóa được áp dụng cho các byte rỗng). Theo các nhà nghiên cứu, backdoor sử dụng các offset sau trong gói mạng để ghi lại mã lỗi và thông báo:

- 0x2b: Bao gồm chuỗi lỗi có kích thước tối đa là 256 byte.

- 0x27: Giá trị DWORD có mã lỗi lấy từ hàm GetLastError của API Windows.

Hơn nữa, trước khi gửi gói báo cáo, backdoor sẽ áp dụng một lớp mã hóa bổ sung bằng cách mã hóa lại toàn bộ gói tin.

KẾT LUẬN

TransferLoader là một trình tải phần mềm độc hại mới đã hoạt động ít nhất từ ​​tháng 02/2025. Mã độc này bao gồm nhiều thành phần nhúng khác nhau, đáng chú ý là downloader, backdoor và backdoor loader, tất cả đều sử dụng các kỹ thuật chống phân tích để tránh bị phát hiện và kiểm tra.

Dựa trên sự tương đồng về code và việc sử dụng chung các phương pháp trốn tránh được quan sát thấy trong các tệp nhị phân, các nhà nghiên cứu tin rằng các phát triển TransferLoader cũng giống như những người đứng sau các thành phần nhúng của nó. Xem xét việc TransferLoader được sử dụng nhất quán trong việc triển khai các payload bổ sung, bao gồm cả mã độc tống tiền, các nhà nghiên cứu dự đoán rằng các tác nhân đe dọa sẽ tiếp tục dựa vào nó trong các cuộc tấn công trong tương lai.