Phân tích thành phần rootkit của mẫu sality
Nội dung bài viết:
1. Giới thiệu
2. Phân tích chi tiết thành phần rootkit của mẫu sality
a. Mã hóa các xâu liên quan đến AV
b. Xóa các hook-filter cũ và đăng ký một hook-filter mới để filter chặn các gói tin chứa xâu liên quan đến AV
c. Kill process dựa trên ProcessID gửi từ usermode
Yêu cầu người đọc:
- Có kiến thức cơ bản về kernel windows, Windows Drivers, Rootkit, Assembly
- Có kiến thức cơ bản về sử dụng WinDbg, IDA
1. Giới thiệu
Sality là một họ mã độc. Lần đầu tiên xuất hiện năm 2003, càng về sau càng xuất hiện nhiều biến thể, càng ngày Sality càng có nhiều đặc điểm mới, càng phức tạp và càng ngày càng nguy hiểm hơn. Một trong số đó là thành phần rootkit trợ giúp mạnh mẽ cho sality anti AV mà chúng ta sẽ tìm hiểu ở phần sau.
Qua bài viết này, tôi mong rằng sẽ đem đến cho bạn đọc một chút kiến thức, kinh nghiệm trong việc phân tích mã độc, đặc biệt là rootkit. Đồng thời rèn luyện kỹ năng sử dụng thành thạo các công cụ như IDA, Windbg…
Bài viết có đính kèm mẫu và file idp dành cho bạn đọc thực hành, mày mò để tìm hiểu thêm.
2. phân tích chi tiết thành phần rootkit của mẫu sality
Thông tin mẫu
Tên mẫu: nnqgn.sys; klplmq.sys…
Md5: BF31A8D79F704F488E3DBCB6EEA3B3E3
Chúng ta cùng đi vào phân tích để xem những kỹ thuật của sality, đầu tiên kéo mẫu vào IDA chúng ta xem xét hàm DriverEntry
DriverEntry của mẫu rootkit sality
Sality rootkit đã tạo một device mang tên là “amsint32” trong driver entry. Điều này đã để lộ ra cho ta dấu hiệu để phát hiện máy có bị nhiễm sality hay không: kiểm tra device mà thấy có “amsint32” thì chứng tỏ máy đã bị nhiễm. Vậy tại sao kẻ viết con sality này lại cố tình tạo device để lộ như vậy?
a. Mã hóa xâu chống reverse, anti-AV
Sality khởi tạo ba hàm MJ là IRP_MJ_CREATE, IRP_MJ_CLOSE, IRP_MJ_WRITE. Tiếp theo là một vòng lặp, trông đoạn code này ta phần nào đoán được đó là đoạn giải mã.
Mà để biết một malware giải mã cái gì, ở đâu thì như tôi đã giới thiệu trong bài phân tích động rootkit trước đó là ta phải cho mẫu chạy trong chế độ debug để xem. Các bạn có thể tham khảo lại bài “phân tích động rootkit bằng windbg” ở đây https://whitehat.vn/threads/12832-Phan-tich-dong-Rootkit-bang-WinDbg.html để xem lại kiến thức.
Ở đây tôi đã cho mẫu chạy và trong windbg tôi đã lấy ra được đoạn giải mã như sau:
Vậy đây là kỹ thuật cơ bản mã hóa xâu nhằm anti-av, anti-reverse của sality.
b. Set hook-filter callback vào ip filter driver để chặn các gói tin liên quan đến AV
Trước hết tôi sẽ giới thiệu cho các bạn về Set hook-filter callback. Kỹ thuật set hook-filter callback cho ip filter driver gồm 3 bước như sau:
- Tạo một hàm callback có signature như sau:
Int HookProc( unsigned char *PacketHeader, unsigned char *Packet, unsigned int PacketLength, unsigned int RecvInterfaceIndex, unsigned int SendInterfaceIndex, IPAddr RecvLinkNextHop, IPAddr SendLinkNextHop ); |
- Driver hook-filter sử dụng hàm IoBuildDeviceIoControlRequest tạo một IRP đặc biệt để truyền cho IP filter driver mục đích đăng ký hàm callback.
PIRP IoBuildDeviceIoControlRequest( _In_ ULONG IoControlCode, _In_ PDEVICE_OBJECT DeviceObject, _In_opt_ PVOID InputBuffer, _In_ ULONG InputBufferLength, _Out_opt_ PVOID OutputBuffer, _In_ ULONG OutputBufferLength, _In_ BOOLEAN InternalDeviceIoControl, _In_opt_ PKEVENT Event, _Out_ PIO_STATUS_BLOCK IoStatusBlock ); |
InputBuffer là địa chỉ hàm callback, nếu muốn xóa thì truyền NULL
- Cuối cùng ta gọi IoCallDriver để thực thi IRP trên
Bây giờ quay lại với IDA, ta so sánh với code của sality. Hàm RegisHookFilterCallback (lưu ý tên này dựa trên ý nghĩa hàm nên tôi đặt như thế chứ ko phải là API windows):
Và Sality_Thread_1 được tạo ở DriverEntry “chầy cối” set Ip hook-filter callback:
Để xem trong hàm hook, sality filter những gì ta xem tiếp trong hàm HookProc:
Vậy Sality đã filter những gói tin chứa xâu liên quan đến các AV thì sẽ trả về PF_DROP tức là gói tin sẽ bị hủy còn các gói tin khác thì sality trả về 0 tức là forward gói tin đi. Đấy là kỹ thuật Set hook-filter callback vào ip filter driver để chặn các gói tin liên quan đến AV.
c. Kill process dựa trên ProcessID gửi từ usermode
Với Sality_Thread_2 được tạo từ DriverEntry này Sality dùng để Kill Process có ProcessID được lưu sẵn trong biến g_dwProcessID. Hàm này sử dụng Event để đợi. Dựa vào Event hoặc g_dwProcessID ta dùng chức năng find ref của IDA ta dễ tìm được đoạn code set/reset signal cho event hoặc đoạn gán g_dwProcessID. Đó cũng là đoạn code cuối cùng cần xem xét trong code của sality. Hàm Sality_MJ_Create_Close_Write:
Với IRP_MJ_CREATE và IRP_MJ_CLOSE thì chỉ ko xử lý gì, chỉ cho IofCompletRequest, riêng khi sality được gọi với IRP_MJ_WRITE thì qua các bước xác thực, sality lấy ID process và lưu lại sau đó set signal cho event, Chính đoạn set signal cho event này là để luồng Sality_Thread_2 chạy và kill process có process ID.
Vậy nhờ rootkit mà thành phần của malware sality chạy trên user mode phát hiện process id của AV sẽ gửi yêu cầu xuống thành phần rootkit chạy ở kernel này kill process của AV. Tới đây ta cũng tự trả lời được câu hỏi đặt ra từ đầu, tại sao rootkit lại tạo device để lộ ra? Tại vì cần device để thực hiện giao tiếp từ usermode xuống rootkit ở kernel mode.
Trên đây là bài phân tích toàn bộ kỹ thuật thành phần rootkit của Sality. Những kỹ thuật này khá cơ bản nhưng hiện nay malware vẫn hay áp dụng. Vì thế nắm được những kỹ thuật này sẽ giúp các bạn có kinh nghiệm hơn trong việc phân tích rootkit khác.
Bài viết mong nhận được phản hồi từ bạn đọc ./.