Vectơ tấn công ban đầu

Phương thức tấn công ban đầu bao gồm các email lừa đảo có tệp đính kèm độc hại. Các email này được ngụy trang thành thông tin liên lạc hợp pháp từ các công ty nhà nước lớn, đặc biệt là trong lĩnh vực dầu khí và công nghệ thông tin. Kẻ tấn công tạo một vỏ bọc hoàn hảo khi có vẻ như quan tâm đến sản phẩm và dịch vụ của nạn nhân, để khiến nạn nhân tránh nghi ngờ và tăng khả năng họ mở tệp đính kèm độc hại.

Hình 1. Mẫu email lừa đảo

Tất cả các tệp đính kèm mà Kaspersky phân tích đều là tệp lưu trữ RAR có cấu trúc như sau: Hai tệp Company profile[.]pdf và List of requirements[.]pdf là các tệp mồi được thiết kế để bổ sung thông tin trong email. Thư mục Требования\Требования chứa các tệp thực thi có tên Company[.]pdf và Requirements[.]pdf, với mục đích để mô phỏng các tài liệu PDF bảo mật. Bản thân thư mục này được ẩn, mặc định không hiển thị với người dùng.

Ngoài ra, trong tệp lưu trữ RAR còn có tệp Требования[.]lnk. Nếu được mở, các tệp trong Требования\Требования sẽ được sao chép vào thư mục %public%\Downloads\ và đổi tên như sau: Company[.]pdf trở thành nau[.]exe và Requires[.]pdf thành BugSplatRc64[.]dll. Ngay sau đó, nau.exe sẽ được thực thi.

Hình 2. Quy trình thực thi của tệp Требования[.]lnk

Agent độc hại

Trong chiến dịch tấn công này, kẻ tấn công đã sử dụng một kỹ thuật phổ biến là DLL Hijacking. Để triển khai payload độc hại, chúng đã khai thác tiện ích Send Reporting Crash hợp pháp (tên tệp gốc: BsSndRpt[.]exe).

Công cụ này là một phần của BugSplat, giúp các nhà phát triển nhận được báo cáo sự cố chi tiết, theo thời gian thực cho ứng dụng của họ. Đây chính là tiện ích mà kẻ tấn công đã đổi tên từ Company[.]pdf thành nau[.]exe .

Hình 3. Sơ đồ quy trình hoạt động của nau[.]exe

Để BsSndRpt[.]exe hoạt động bình thường, nó cần có BugSplatRc64[.]dll. Kẻ tấn công đã lưu tệp độc hại của chúng với tên đó, buộc tiện ích phải tải tệp này thay vì tệp hợp lệ.

Sau đó, nhằm tiếp tục tránh bị phát hiện, thư viện BugSplatRc64[.]dll độc hại sử dụng Dynamic API Resolution. Kỹ thuật này bao gồm việc che giấu các hàm API trong code, chỉ xử lý chúng động trong quá trình thực thi. Trong trường hợp cụ thể này, các hàm được che giấu thông qua một thuật toán băm tùy chỉnh, có điểm tương đồng với CRC (Cyclic Redundancy Check).

Hình 4. Thuật toán băm

Đáng chú ý, một phần đáng kể các hàm băm trong mẫu độc hại được mã hóa XOR. Ngoài ra, sau mỗi lần gọi, địa chỉ sẽ bị xóa khỏi bộ nhớ và các hàm API được tải lại nếu cần gọi tiếp theo.

Hàm MessageBoxW

Mục đích chính của BugSplatRc64[.]dll là chặn các lệnh gọi API trong không gian địa chỉ tiến trình của tiện ích hợp pháp nhằm thực thi mã độc hại. Thay vì một trong các hàm API mà tiến trình yêu cầu, một lệnh gọi được thực hiện đến một hàm (các nhà nghiên cứu gọi là NewMessageBox) nằm trong không gian địa chỉ của thư viện độc hại.

Kỹ thuật này gây khó khăn cho việc phát hiện phần mềm độc hại trong môi trường sandbox, vì thư viện sẽ không khởi chạy nếu không có tệp thực thi cụ thể. Trong hầu hết các mẫu phân tích, lệnh gọi hàm MessageBoxW đã bị sửa đổi, mặc dù các nhà nghiên cứu cũng phát hiện ra các mẫu đã thay đổi các lệnh gọi API khác. Sau khi sửa đổi hàm bị chặn, thư viện trả lại quyền điều khiển cho tiến trình nau[.]exe hợp lệ.

Hàm NewMessageBox

Sau đó, bất cứ khi nào MessageBoxW (hoặc một hàm đã sửa đổi khác) được gọi trong tiến trình hợp lệ, NewMessageBox sẽ được thực thi. Vai trò chính của nó là chạy shellcode, được tải theo hai giai đoạn.

Đầu tiên, mã độc truy xuất nội dung HTML từ một trang web nằm tại một trong các địa chỉ được mã hóa trong thư viện độc hại. Trong mẫu phân tích, các địa chỉ này là https://techcommunity.microsoft[.]com/t5/user/viewprofilepage/user-id/2631 và https://www.quora[.]com/profile/Marieformach. Thông tin được tìm thấy tại cả hai địa chỉ này là giống hệt nhau. Địa chỉ thứ hai sẽ đóng vai trò là bản sao lưu nếu địa chỉ đầu tiên không hoạt động.

NewMessageBox tìm kiếm mã HTML được lấy từ các địa chỉ này để tìm một chuỗi có mẫu bắt đầu và kết thúc trùng khớp với các ký tự được định nghĩa trong mã code, bao gồm các ký tự số, chữ thường và viết hoa. Kỹ thuật này cho phép kẻ tấn công lợi dụng nhiều trang web phổ biến để lưu trữ các chuỗi này. Kaspersky đã tìm thấy thông tin độc hại ẩn trong các hồ sơ trên GitHub, Microsoft Learn Challenge, các trang web Hỏi - Đáp, thậm chí cả các nền tảng mạng xã hội của Nga.

Hình 5. Hồ sơ thông tin độc hại trên các nền tảng trực tuyến phổ biến

Mặc dù không tìm thấy bằng chứng nào cho thấy kẻ tấn công sử dụng tài khoản mạng xã hội thật, vì tất cả các tài khoản đều được tạo riêng cho cuộc tấn công này, nhưng Kaspersky cho rằng không có gì ngăn cản kẻ tấn công lợi dụng các cơ chế khác nhau mà các nền tảng này cung cấp. Ví dụ, các chuỗi nội dung độc hại có thể được đăng trong bình luận trên bài đăng của người dùng hợp pháp.

Payload được trích xuất là một chuỗi mã hóa base64 với dữ liệu mã hóa XOR. Sau khi giải mã, dữ liệu này sẽ hiển thị URL https://raw[.]githubusercontent[.]com/Mariew14/kong/master/spec/fixtures/verify-prs, sau đó tải xuống một shellcode khác được mã hóa XOR.

Ban đầu, các nhà nghiên cứu dự kiến NewMessageBox sẽ thực thi shellcode ngay sau khi giải mã. Tuy nhiên, nau[.]exe lại khởi chạy một tiến trình con có cùng tên và tham số “qstt”, trong đó tất cả các hành động trên được lặp lại một lần nữa, cuối cùng dẫn đến việc thực thi shellcode.

Shellcode

Phân tích shellcode cho thấy một trình tải reflective loader đã nhúng Cobalt Strike Beacon vào bộ nhớ tiến trình. Mẫu Cobalt được quan sát giao tiếp với máy chủ điều khiển và ra lệnh (C2) tại địa chỉ moeodincovo[.]com/divide/mail/SUVVJRQO8QRC.

Điều đáng chú ý là mặc dù hầu hết các cuộc tấn công nhắm vào các công ty Nga, các nhà nghiên cứu cũng tìm thấy bằng chứng về hoạt động độc hại ở Trung Quốc, Nhật Bản, Malaysia và Peru. Phần lớn nạn nhân là các doanh nghiệp vừa và lớn.

Đánh giá và kết luận

Phương pháp được sử dụng để truy xuất địa chỉ tải xuống shellcode tương tự như mô hình thu thập C2 mà các nhà nghiên cứu đã phân tích trong chiến dịch tấn công EastWind. Trong cả hai trường hợp, URL được lưu trữ trong một hồ sơ được thiết kế đặc biệt trên một nền tảng trực tuyến hợp pháp. Đồng thời, nó cũng được mã hóa bằng thuật toán XOR. Hơn nữa, mục tiêu của hai chiến dịch có phần trùng lặp, đó là cả hai nhóm tấn công đều thể hiện sự quan tâm đến các công ty công nghệ thông tin của Nga.

Các tác nhân đe dọa đang sử dụng các phương pháp ngày càng phức tạp và tinh vi để che giấu các công cụ đã được biết đến từ trước. Chiến dịch được phân tích đã sử dụng các kỹ thuật như DLL Hijacking, một kỹ thuật ngày càng phổ biến, cũng như che giấu các lệnh gọi API trong thư viện độc hại và sử dụng các tài nguyên hợp pháp như Quora, GitHub và Microsoft Learn Challenge để lưu trữ các địa chỉ C2.