Vào cuối tháng XNUMX, chúng tôi đã phát hiện ra một chiến dịch phân phối phần mềm độc hại Remote Access Trojan (RAT)—các chương trình cho phép kẻ tấn công điều khiển từ xa một hệ thống bị nhiễm.
Nhóm mà chúng tôi kiểm tra khác biệt ở chỗ nó không chọn bất kỳ họ RAT cụ thể nào để lây nhiễm. Một số Trojan đã được phát hiện trong các cuộc tấn công trong chiến dịch (tất cả đều được phổ biến rộng rãi). Với đặc điểm này, nhóm khiến chúng tôi liên tưởng đến vua chuột - một loài động vật thần thoại bao gồm các loài gặm nhấm có đuôi đan vào nhau.
Nguyên bản được lấy từ chuyên khảo của K. N. Rossikov “Chuột và loài gặm nhấm giống chuột nhắt, quan trọng nhất về mặt kinh tế” (1908)
Để vinh danh sinh vật này, chúng tôi đã đặt tên cho nhóm mà chúng tôi đang xem xét RATKing. Trong bài đăng này, chúng tôi sẽ đi sâu vào chi tiết về cách những kẻ tấn công thực hiện cuộc tấn công, chúng đã sử dụng công cụ gì và cũng chia sẻ suy nghĩ của chúng tôi về việc phân bổ cho chiến dịch này.
Diễn biến cuộc tấn công
Tất cả các cuộc tấn công trong chiến dịch này đều diễn ra theo thuật toán sau:
Người dùng đã nhận được email lừa đảo có liên kết tới Google Drive.
Bằng cách sử dụng liên kết, nạn nhân đã tải xuống tập lệnh VBS độc hại chỉ định thư viện DLL để tải trọng tải cuối cùng vào sổ đăng ký Windows và khởi chạy PowerShell để thực thi nó.
Thư viện DLL đã chèn tải trọng cuối cùng - trên thực tế, một trong những RAT được kẻ tấn công sử dụng - vào quy trình hệ thống và đăng ký tập lệnh VBS trong chế độ tự động chạy để có được chỗ đứng trong máy bị nhiễm.
Tải trọng cuối cùng được thực thi trong một quy trình hệ thống và cung cấp cho kẻ tấn công khả năng kiểm soát máy tính bị nhiễm.
Về mặt sơ đồ nó có thể được biểu diễn như thế này:
Tiếp theo, chúng tôi sẽ tập trung vào ba giai đoạn đầu tiên vì chúng tôi quan tâm đến cơ chế phân phối phần mềm độc hại. Chúng tôi sẽ không mô tả chi tiết cơ chế hoạt động của phần mềm độc hại. Chúng có sẵn rộng rãi - được bán trên các diễn đàn chuyên biệt hoặc thậm chí được phân phối dưới dạng các dự án nguồn mở - và do đó không phải là duy nhất của nhóm RATKing.
Phân tích các giai đoạn tấn công
Giai đoạn 1. Email lừa đảo
Cuộc tấn công bắt đầu bằng việc nạn nhân nhận được một lá thư độc hại (những kẻ tấn công đã sử dụng các mẫu văn bản khác nhau; ảnh chụp màn hình bên dưới hiển thị một ví dụ). Tin nhắn chứa liên kết đến kho lưu trữ hợp pháp drive.google.com, được cho là đã dẫn đến trang tải xuống tài liệu PDF.
Ví dụ về email lừa đảo
Tuy nhiên, trên thực tế, nó hoàn toàn không phải là một tài liệu PDF mà được tải mà là một tập lệnh VBS.
Khi bạn nhấp vào liên kết từ email trong ảnh chụp màn hình ở trên, một tệp có tên Cargo Flight Details.vbs. Trong trường hợp này, những kẻ tấn công thậm chí không cố gắng ngụy trang tệp đó thành tài liệu hợp pháp.
Đồng thời, là một phần của chiến dịch này, chúng tôi đã phát hiện ra một tập lệnh có tên Cargo Trip Detail.pdf.vbs. Nó có thể đã được chuyển sang dạng PDF hợp pháp vì Windows ẩn phần mở rộng tệp theo mặc định. Đúng, trong trường hợp này, sự nghi ngờ vẫn có thể bị khơi dậy bởi biểu tượng của nó, tương ứng với tập lệnh VBS.
Ở giai đoạn này, nạn nhân có thể nhận ra hành vi lừa dối: chỉ cần xem kỹ hơn các tệp đã tải xuống trong giây lát. Tuy nhiên, trong các chiến dịch lừa đảo như vậy, những kẻ tấn công thường dựa vào người dùng thiếu chú ý hoặc vội vàng.
Giai đoạn 2. Thao tác tập lệnh VBS
Tập lệnh VBS mà người dùng có thể vô tình mở đã đăng ký thư viện DLL trong sổ đăng ký Windows. Tập lệnh bị xáo trộn: các dòng trong đó được viết dưới dạng byte được phân tách bằng một ký tự tùy ý.
Ví dụ về tập lệnh bị xáo trộn
Thuật toán giải mã khá đơn giản: mỗi ký tự thứ ba được loại trừ khỏi chuỗi bị xáo trộn, sau đó kết quả được giải mã từ base16 thành chuỗi gốc. Ví dụ, từ giá trị 57Q53s63t72s69J70r74e2El53v68m65j6CH6Ct (được đánh dấu trong ảnh chụp màn hình ở trên) dòng kết quả là WScript.Shell.
Để giải mã chuỗi, chúng tôi đã sử dụng hàm Python:
def decode_str(data_enc):
return binascii.unhexlify(''.join([data_enc[i:i+2] for i in range(0, len(data_enc), 3)]))
Bên dưới, trên các dòng 9–10, chúng tôi đánh dấu giá trị mà quá trình giải mã của nó dẫn đến tệp DLL. Chính anh ấy là người đã khởi động giai đoạn tiếp theo bằng cách sử dụng PowerShell.
Chuỗi có DLL bị xáo trộn
Mỗi chức năng trong tập lệnh VBS được thực thi khi các chuỗi được giải mã.
Sau khi chạy tập lệnh, hàm được gọi wscript.sleep — nó được sử dụng để thực hiện việc thực thi bị trì hoãn.
Tiếp theo, tập lệnh hoạt động với sổ đăng ký Windows. Anh ấy đã sử dụng công nghệ WMI cho việc này. Với sự trợ giúp của nó, một khóa duy nhất đã được tạo và phần nội dung của tệp thực thi được ghi vào tham số của nó. Sổ đăng ký được truy cập thông qua WMI bằng lệnh sau:
Một mục được tạo trong sổ đăng ký bằng tập lệnh VBS
Giai đoạn 3. Hoạt động của thư viện DLL
Ở giai đoạn thứ ba, DLL độc hại tải trọng tải cuối cùng, đưa nó vào quy trình hệ thống và đảm bảo rằng tập lệnh VBS tự động khởi động khi người dùng đăng nhập.
đã nhận được dữ liệu giá trị đăng ký có tên rnd_value_name - dữ liệu này là tệp DLL được viết trên nền tảng .Net;
đã tải mô-đun .Net kết quả vào bộ nhớ tiến trình powershell.exe sử dụng chức năng [System.Threading.Thread]::GetDomain().Load()(mô tả chi tiết hàm Load() có sẵn trên trang web của Microsoft);
đã thực hiện chức năng GUyyvmzVhebFCw]::EhwwK() - việc thực thi thư viện DLL bắt đầu với nó - với các tham số vbsScriptPath, xorKey, vbsScriptName... Tham số xorKey đã lưu trữ khóa để giải mã tải trọng cuối cùng và các tham số vbsScriptPath и vbsScriptName đã được chuyển để đăng ký tập lệnh VBS trong autorun.
Mô tả thư viện DLL
Ở dạng dịch ngược, bộ nạp khởi động trông như thế này:
Trình tải ở dạng dịch ngược (chức năng bắt đầu thực thi thư viện DLL được gạch chân màu đỏ)
Bộ nạp khởi động được bảo vệ bởi bộ bảo vệ .Net Reactor. Tiện ích de4dot thực hiện rất tốt công việc loại bỏ trình bảo vệ này.
Trình tải này:
đã đưa tải trọng vào tiến trình hệ thống (trong ví dụ này nó svchost.exe);
Tôi đã thêm tập lệnh VBS vào autorun.
Tiêm tải trọng
Hãy xem hàm mà tập lệnh PowerShell gọi.
Hàm được gọi bởi tập lệnh PowerShell
Chức năng này đã thực hiện các hành động sau:
đã giải mã hai bộ dữ liệu (array и array2 trong ảnh chụp màn hình). Ban đầu chúng được nén bằng gzip và được mã hóa bằng thuật toán XOR bằng khóa xorKey;
sao chép dữ liệu vào vùng nhớ được phân bổ. Dữ liệu từ array - tới vùng nhớ được trỏ tới intPtr (payload pointer trong ảnh chụp màn hình); dữ liệu từ array2 - tới vùng nhớ được trỏ tới intPtr2 (shellcode pointer trong ảnh chụp màn hình);
gọi là hàm CallWindowProcA(описание Chức năng này có sẵn trên trang web của Microsoft) với các tham số sau (tên của các tham số được liệt kê bên dưới, trong ảnh chụp màn hình, chúng theo cùng thứ tự nhưng có giá trị hoạt động):
lpPrevWndFunc - con trỏ tới dữ liệu từ array2;
hWnd — con trỏ tới một chuỗi chứa đường dẫn tới tập tin thực thi svchost.exe;
Msg - con trỏ tới dữ liệu từ array;
wParam, lParam — tham số thông báo (trong trường hợp này, các tham số này không được sử dụng và có giá trị bằng 0);
đã tạo một tập tin %AppData%MicrosoftWindowsStart MenuProgramsStartup<name>.urlĐâu <name> - đây là 4 ký tự đầu tiên của tham số vbsScriptName (trong ảnh chụp màn hình, đoạn mã có hành động này bắt đầu bằng lệnh File.Copy). Bằng cách này, phần mềm độc hại đã thêm một tệp URL vào danh sách các tệp tự động chạy khi người dùng đăng nhập và do đó được đính kèm vào máy tính bị nhiễm. Tệp URL chứa liên kết đến tập lệnh:
Để hiểu cách thực hiện việc tiêm, chúng tôi đã giải mã các mảng dữ liệu array и array2. Để làm điều này, chúng tôi đã sử dụng hàm Python sau:
def decrypt(data, key):
return gzip.decompress(
bytearray([data[i] ^ key[i % len(key)] for i in range(len(data))])[4:])
Kết quả là chúng tôi phát hiện ra rằng:
array là tệp PE - đây là tải trọng cuối cùng;
array2 là shellcode cần thiết để thực hiện việc tiêm.
Shellcode từ một mảng array2 được truyền dưới dạng giá trị hàm lpPrevWndFunc thành một hàm CallWindowProcA. lpPrevWndFunc — hàm gọi lại, nguyên mẫu của nó trông như thế này:
Vì vậy khi bạn chạy hàm CallWindowProcA với các thông số hWnd, Msg, wParam, lParam shellcode từ mảng được thực thi array2 với những lý lẽ hWnd и Msg. hWnd là một con trỏ tới một chuỗi chứa đường dẫn đến tệp thực thi svchost.exeVà Msg - con trỏ tới tải trọng cuối cùng.
Shellcode nhận địa chỉ hàm từ kernel32.dll и ntdll32.dll dựa trên các giá trị băm từ tên của chúng và đưa tải trọng cuối cùng vào bộ nhớ tiến trình svchost.exesử dụng kỹ thuật Process Hollowing (bạn có thể đọc thêm về nó trong phần này Bài viết). Khi tiêm shellcode:
đã tạo ra một quy trình svchost.exe ở trạng thái treo bằng cách sử dụng chức năng CreateProcessW;
sau đó ẩn phần hiển thị của phần đó trong không gian địa chỉ của tiến trình svchost.exe sử dụng chức năng NtUnmapViewOfSection. Như vậy, chương trình đã giải phóng bộ nhớ của tiến trình ban đầu svchost.exesau đó phân bổ bộ nhớ cho tải trọng tại địa chỉ này;
bộ nhớ được phân bổ cho tải trọng trong không gian địa chỉ tiến trình svchost.exe sử dụng chức năng VirtualAllocEx;
Bắt đầu quá trình tiêm
đã ghi nội dung của tải trọng vào không gian địa chỉ tiến trình svchost.exe sử dụng chức năng WriteProcessMemory (như trong ảnh chụp màn hình bên dưới);
đã tiếp tục lại quá trình svchost.exe sử dụng chức năng ResumeThread.
Hoàn tất quá trình tiêm
Phần mềm độc hại có thể tải xuống
Kết quả của các hành động được mô tả là một trong số phần mềm độc hại loại RAT đã được cài đặt trên hệ thống bị nhiễm. Bảng bên dưới liệt kê phần mềm độc hại được sử dụng trong cuộc tấn công mà chúng tôi có thể tự tin quy cho một nhóm kẻ tấn công vì các mẫu này truy cập vào cùng một máy chủ ra lệnh và kiểm soát.
Ví dụ về phần mềm độc hại được phân phối trên cùng một máy chủ điều khiển
Có hai điều đáng chú ý ở đây.
Thứ nhất, thực tế là những kẻ tấn công đã sử dụng nhiều họ RAT khác nhau cùng một lúc. Hành vi này không phải là điển hình đối với các nhóm mạng nổi tiếng, những nhóm này thường sử dụng gần như cùng một bộ công cụ quen thuộc với họ.
Thứ hai, RATKing đã sử dụng phần mềm độc hại được bán trên các diễn đàn chuyên biệt với giá thấp hoặc thậm chí là một dự án nguồn mở.
Danh sách phần mềm độc hại đầy đủ hơn được sử dụng trong chiến dịch—với một lưu ý quan trọng—được cung cấp ở cuối bài viết.
Về nhóm
Chúng tôi không thể quy kết chiến dịch độc hại được mô tả cho bất kỳ kẻ tấn công đã biết nào. Hiện tại, chúng tôi tin rằng những cuộc tấn công này về cơ bản được thực hiện bởi một nhóm mới. Như chúng tôi đã viết lúc đầu, chúng tôi gọi nó là RATKing.
Để tạo script VBS chắc nhóm đã sử dụng công cụ tương tự như tiện ích VBS-Crypter từ nhà phát triển NYAN-x-CAT. Điều này được biểu thị bằng sự giống nhau của tập lệnh mà chương trình này tạo ra với tập lệnh của kẻ tấn công. Cụ thể, cả hai đều:
thực hiện trì hoãn việc thực hiện bằng cách sử dụng hàm Sleep;
sử dụng WMI;
đăng ký phần thân của tệp thực thi làm tham số khóa đăng ký;
thực thi tệp này bằng PowerShell trong không gian địa chỉ của chính nó.
Để rõ ràng, hãy so sánh lệnh PowerShell để chạy một tệp từ sổ đăng ký, được sử dụng bởi tập lệnh được tạo bằng VBS-Crypter:
Lưu ý rằng những kẻ tấn công đã sử dụng một tiện ích khác từ NYAN-x-CAT làm một trong các trọng tải - VôiRAT.
Địa chỉ của máy chủ C&C cho thấy một tính năng đặc biệt khác của RATKing: nhóm thích các dịch vụ DNS động hơn (xem danh sách C&C trong bảng IoC).
IOC
Bảng bên dưới cung cấp danh sách đầy đủ các tập lệnh VBS có nhiều khả năng được quy cho chiến dịch được mô tả. Tất cả các tập lệnh này đều giống nhau và thực hiện gần như cùng một chuỗi hành động. Tất cả chúng đều đưa phần mềm độc hại lớp RAT vào một quy trình Windows đáng tin cậy. Tất cả đều có địa chỉ C&C được đăng ký bằng dịch vụ DNS động.
Tuy nhiên, chúng tôi không thể khẳng định rằng tất cả các tập lệnh này đều được phân phối bởi cùng một kẻ tấn công, ngoại trừ các mẫu có cùng địa chỉ C&C (ví dụ: kimjoy007.dyndns.org).