Tiếp tục chuỗi chủ đề phân tích mã độc, ở bài viết phân tích mã độc LAB 06 chuyên gia Bùi Đình Cường đã gửi đến các bạn 4 ví dụ tương đương với 4 cấu trúc của mã độc Lab 06. Trong bài viết này là các cấu trúc trong phân tích mã độc Lab 07.

Mục tiêu của các bài phân tích cũng như mục tiêu của chương 7 trong cuốn “Practical Malware Analysis” nhằm giới thiệu và giúp bạn đọc làm quen với các khái niệm: Processes, Threads, Network…Các khái niệm này đặc biệt quan trọng trong quá trình phân tích tĩnh các mã độc. Các bài Lab sau đây sẽ sử dụng các kiến thức trong chương 7 vào quá trình phân tích, đưa đến cho bạn đọc cách tiếp cận thực tiễn các kiến thức đã đọc.

Với cấu trúc Lab 7 – 1 chúng ta cần giải quyết các vấn đề sau: Chương trình làm như thế nào để đảm bảo nó tiếp tục chạy khi máy tính khởi động lại? Tại sao chương trình sử dụng một mutex? Đâu là chữ kí dạng host-based tốt để nhận diện chương trình này? Đâu là chữ kí dạng network-based sử dụng phát hiện mã độc? Mục đích của chương trình là gì? Khi nào chương trình kết thúc?

Qua các string thu thập được, nhận định nhiều khả năng mã độc cài đặt tự khởi động cùng hệ thống bằng cách cài đặt một service.

Hàm main:

Hàm main thực hiện tạo một service bằng cách gọi hàm API StartServiceCtrlDispatcher với tham số là một ServiceStartTable gồm service name là MalService và service main function là hàm sub_401040. Ta rút ra được kết luận này từ dòng 0x401003 đến 0x401028

https://msdn.microsoft.com/en-us/library/windows/desktop/ms686324(v=vs.85).aspx

https://msdn.microsoft.com/en-us/library/windows/desktop/ms686001(v=vs.85).aspx

Xét hàm sub_401040:

Đầu tiên, mã độc cố truy cập một mutex với tên HGL345, nếu mutex này chưa tồn tại, lệnh test tại 0x401058 sẽ set cờ zero với giá trị 1 và code sẽ nhảy tới bước tiếp theo (short loc_401064); nếu mutex đã tồn tại, mã độc sẽ kết thúc bằng lời gọi hàm ExitProcess tại 0x40105E.

Trong trường hợp mutex HGL345 chưa tồn tại và mã độc nhảy tới hàm short loc_401064, nó sẽ tạo mutex HGL345 (từ 0x401065 đến 0x40106E). Như vậy, việc kiểm tra sự tồn tại của mutex HGL345 là nhằm chắc chắn rằng tại một thời điểm chỉ có một bản của mã độc được thực thi trong hệ thống.

Sau khi tạo mutex HGL345 để đánh dấu sự tồn tại tiến trình của mình trong hệ thống, mã độc tạo một kết nối tới cơ sở dữ liệu mặc định của Service Control Manager trên chính máy local bằng lời gọi hàm OpenSCManager tại 0x40107A (nhìn vào giá trị lpDatabaseName và lpMachineName đều được set bằng 0 – https://msdn.microsoft.com/en-us/library/windows/desktop/ms684323(v=vs.85).aspx). Handle của SCM trả về được lưu vào ESI (0x401080).

Ngay sau đó, mã độc lấy handle tiến trình của chính nó bằng hàm GetCurrentProcess tại 0x401082, hàm này được gọi mà không cần tham số đầu vào.  Handle trả về lưu trong EAX???

Tiếp theo, mã độc thực hiện lấy ModuleFileName của chính process nó đang thực thi bằng lời gọi hàm GetModuleFileName với tham số hModule = 0 (https://msdn.microsoft.com/en-us/library/windows/desktop/ms683197(v=vs.85).aspx)

Như vậy, sau hai hàm GetCurrentProcess và GetModuleFileName trên, mã độc lấy được đường dẫn đầy đủ tới file thực thi của chính nó. Đường dẫn này được truyền vào thành ghi ECX tại dòng 0x4010A2.

Mã độc truyền đường dẫn file thực thi (nhị phân) của mình vào hàm CreateService (0x4010BC) như giá trị tham số lpBinaryPathName; các tham số đáng chú ý khác của hàm này là:

• hSCManager: là giá trị của ESI, handle của SCM trả về từ hàm OpenSCManager.
• lpServiceName: Không được hiển thị trong comment của IDA Pro nhưng dựa vào thứ tự tham số đầu vào của hàm CreateService (MSDN) và thứ tự push tham số vào stack, ta thấy giá trị lpServiceName = lpDisplayName = “Malservice” (0x4010B1 và 0x4010B6).
• dwDesiredAccess: giá trị bằng 2, là giá trị quyền truy cập yêu cầu để thực hiện hàm CreateService (https://msdn.microsoft.com/en-us/library/windows/desktop/ms685981(v=vs.85).aspx)
• dwServiceType: 10h, tương ứng service loại SERVICE_WIN32_OWN_PROCESS (https://msdn.microsoft.com/en-us/library/windows/desktop/ms682450(v=vs.85).aspx )
• dwStartType: 2, tương ứng SERVICE_AUTO_START.
• dwErrorControl: 0, SERVICE_ERROR_IGNORE
• lpBinaryPathName: là đường dẫn đầy đủ tới file thực thi của mã độc.
• lpLoadOrderGroup: 0, service không thuộc group nào.

Như vậy, mã độc cài đặt service mới với tên Malservice để thiết lập chính nó tự khởi động cùng hệ thống.

Với lệnh xor tại 0x4010C2, edx được set giá trị 0, sau đó, giá trị của nó được truyền vào các SystemTime.wYear/wDayOfWeek/wHour/w.Second -> các giá trị này được set về 0. Sau đó, tại dòng 0x4010DE, giá trị SystemTime.wYear lại được set bằng 2100 (convert từ 834h). Cuối cùng, các giá trị thời gian này được truyền vào các hàm SystemTimeToFileTime, CreateWaitableTimer và SetWaitableTimer. WaitableTimer này như một đồng hồ hẹn giờ tới thời điểm 0h00 ngày 1/1/2100.

Hàm WaitForSingleObject là thủ tục khóa handle tiến trình của mã độc trong thời gian tối đa (khoảng 50 ngày – từ 0FFFFFFFFh, dòng 0x40110D). Mã độc sau đó thực hiện ngủ trong thời gian tối đa (khoảng 50 ngày). Cộng 400h vào đỉnh stack làm clgv?????? Và kết thúc hàm. (https://msdn.microsoft.com/en-us/library/windows/desktop/ms687032(v=vs.85).aspx )

Đến đúng thời điểm 0h00 ngày 1/1/2100, mã độc thực hiện tạo một luồng mới (0x40111B). Mỗi luồng được tạo mới thực hiện hàm StartAddress, ta biết được điều này qua tham số đầu vào lpStartAddress của hàm CreateThread tại dòng 0x40112C. Mã độc sử dụng thanh ghi ESI với giá trị ban đầu là 20 (convert từ 14h tại dòng 0x401121) thay cho một biến đếm, cứ mỗi lần tạo một thread mới thành công, giá trị ESI được trừ đi 1, vòng lặp thực hiện lại short loc_401126, tức là lặp lại thao tác tạo mới một thread rồi giảm ESI đi 1. Vòng lặp kết thúc khi ESI bằng 0, tức là khi đó mã độc đã tạo được 20 thread thực hiện hàm StartAddress.

Xem xét hàm StartAddress:

Hàm StartAddress thực hiện mở một kết nối Internet thông qua hàm InternetOpen, tham số đầu vào cần lưu ý là dwAccessType = 1 và szAgent sử dụng là “Internet Explorer 8.0”. Mã độc không có thủ tục kiểm tra có kết nối Internet thành công hay không.

Sau khi thực hiện mở một kết nối Internet, mã độc thực hiện lặp vô tận thao tác kết nối tới URL “http://www.malwareanalysisbook.com”  với tham số dwFlags là 80000000h. Ta kết luận thao tác kết nối tới URL kể trên được lặp vô tận vì mã độc không thực hiện một phép so sánh điều kiện nào mà nhảy trực tiếp về đầu thao tác bằng lệnh jmp tại 0x401180.

Như vậy: Mã độc tự cài đặt service cho chính nó để tự khởi động cùng hệ thống, nó cũng có cơ chế kiểm tra xem đã có một instance nào của mình đang thực thi trên hệ thống chưa để đảm bảo tại  một thời điểm chỉ có một instance được chạy, tránh gây bất thường dễ phát hiện. Mã độc chỉ tự kết thúc trong trường hợp phát hiện đã có instance khác được thực thi. Vượt qua tất cả các bước kiểm tra trên, mã độc set một đồng hồ đếm ngược rồi ngủ. Tới thời điểm 0h00 ngày 1/1/2100, mã độc tạo 20 thread, mỗi thread thực hiện lặp vô tận kết nối Internet tới URL “http://www.malwareanalysisbook.com“. Kết luận mã độc là một bot phục vụ một cuộc tấn công DoS/DDoS.

Trên cơ sở các phân tích trên, chúng ta có thể kết luận các vấn đề trong Lab 7 – 1 như sau:

1. Chương trình làm như thế nào để đảm bảo nó tiếp tục chạy khi máy tính khởi động lại?

Mã độc tự cài đặt service cho chính nó để tự khởi động cùng hệ thống.

2. Tại sao chương trình sử dụng một mutex?

Mã độc sử dụng mutex để kiểm tra và chắc chắn rằng tại một thời điểm chỉ có một instance của mình được chạy trên hệ thống.

3. Đâu là chữ kí dạng host-based tốt để nhận diện chương trình này?

Các dấu hiệu host

• Service với tên và tên hiển thị là Malservice.
• Mutex với tên “HGL345”.
• Một file nhị phân với thời gian được set vào 0h00 ngày 1/1/2100.

4. Đâu là chữ kí dạng network-based sử dụng phát hiện mã độc?

Các dấu hiệu mạng:

• URL “http://www.malwareanalysisbook.com“
• UA: Internet Explorer 8.0

5. Mục đích của chương trình là gì?

Mục đích của mã độc: Chạy liên tục và thực hiện kết nối liên tục tới địa chỉ “http://www.malwareanalysisbook.com” phục vụ tấn công DoS/DDoS

6. Khi nào chương trình kết thúc?

Mã độc chỉ kết thúc thực thi khi phát hiện có một instance khác của nó đang chạy trên hệ thống. Chính xác hơn, mã độc kết thúc thực thi khi trong hệ thống đã tồn tại một mutex với tên “HGL345”. Nếu ta lợi dụng được đặc tính này và tạo một mutex với tên “HGL345”, duy trì nó trong hệ thống thì đoạn code độc hại của mã độc sẽ không bao giờ được thực thi.

XEM THÊM: Phân Tích Mã Độc Sử Dụng IDA PRO (Phần 1)