Phân tích động Rootkit bằng WinDbg.
Đặt vấn đề:
Cũng giống như malware ở user mode. Ta có thể phân tích bằng phân tích tĩnh (tham khảo http://whitehat.vn/threads/12169-Hu...uc-nhan-he-dieu-hanh-Kernel-Mode-Rootkit.html ).
Tuy nhiên không phải bất kỳ mẫu rootkit nào cũng “phơi bày thân hình” của mình ra trước mắt người khác mà chúng thường có rất nhiều “mảnh giáp che thân” đó chính là sử dụng các kỹ thuật anti-reverse, ví dụ như là tự giải mã code, tự thay đổi code ngay lúc thực thi. Đối với loại tự bảo vệ mình như thế thì phân tích tĩnh thường “bó tay”. Vì thế ta cần phải phân tích động để giải quyết vấn đề này.
Nội dung bài viết:
1. Cách dựng môi trường và tool cần thiết để debug động rootkit
2. Phân tích chi tiết một mẫu rootkit cụ thể
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
1. Dựng môi trường và tool cần thiết
Rootkit malware chạy ở mức nhân hệ điều hành (kernel). Không phải cứ doub-click là chạy mà rootkit phải load lên đúng cách như các driver của hệ thống được load. Vì thế việc thực thi một mẫu rootkit bất kỳ khó khăn hơn so với việc chạy một mẫu virus ở User Mode. Điều này gây cản trở cho ai muốn phân tích hành vi của rootkit, nhất là muốn monitor như malware ở UserMode thì rất khó khăn. Sau đây là hướng dẫn tạo dựng môi trường debug động rootkit:
Nguyên lý: ta có một máy ảo chạy rootkit gọi là target, trên môi trường máy thật (host) ta sử dụng WinDbg kết nối đến máy target để debug.
- WinDbg cài đặt trên môi trường máy host (máy làm việc của ta), windbg tích hợp trong gói WDK có thể download và cài đặt WDK 7.1 ở đây http://www.microsoft.com/en-us/download/details.aspx?id=11800
- Môi trường chạy mẫu: ta không chạy trực tiếp mẫu trên môi trường host mà phải tạo môi trường máy ảo cho nó chạy ở trong đó. Ở đây dùng VirtualBox. Download và tài liệu sử dụng máy ảo ở đây: https://www.virtualbox.org/wiki/Downloads Trong bài này, cài windows xp trong virtual box. Cho mẫu rootkit chạy trong máy windows xp ảo này.
- Để kết nối WinDbg tới máy ảo chạy mẫu, ta cần thiết lập “con đường”giao tiếp giữa 2 phần mềm này. Ta có thể thiết lập bằng tay. Tuy nhiên, để đơn giản ta sử dụng virtualKD, download và hướng dẫn cài đặt tại đây: http://virtualkd.sysprogs.org/tutorials/install/
2. Phân tích chi tiết một mẫu rootkit cụ thể
Thông tin mẫu
Tên mẫu: bak1en.sys
Md5: A2E7965C33EF25C98C75CFBF0C742F7E
Trước hết ta kéo mẫu vào IDA xem thử mẫu DriverEntry của mẫu:
Ở trên ta thấy code không “đẹp” như code chuẩn C/C++ mà trông rất “lộn xộn” rất khó hiểu, không thấy gì liên quan tới khởi tạo các hàm MJ hay Unload, đặc biệt xuất hiện một vòng lặp trong đó có toán tử xor “^”. Tađoán đó có thể là đoạn giải mã code của rootkit. Kỹ thuật này gọi là self-modify code.
Tới đây chuyển sang phân tích động:
Ta tạo một service mới để lần sau khởi động sẽ load mẫu rootkit này lên, cách tạo và load service có thể tham khảo ở MSDN. Ở mẫu này chọn giá trị như sau:
Sau khi WinDbg attach vào máy ảo targetdebug mẫu.Gõ “g” trong dòng lệnh của WinDbg, mục địch khởi động windows xong hết. Lúc này ta break WinDbg và kiểm tra lại xem mẫu bak1en có được load không:
Tiếp theo, ta kiểm tra Driver Object của mẫu bak1en
Từ kết quả trên cho ta thấy là hàm IRP_MJ_CREATE và IRP_MJ_CLOSE có cùng địa chỉ bak1en+0x1180, các hàm MJ còn lại có địa chỉ bak1en+0x11a0. Nhận xét do dùng 1 hàm cho nhiều hàm như thế thì đoán được hàm này có thể không làm gì cả, chỉ thực hiện các nhiệm vụ defaul như là chuyển tiếp hoặc return!
Vậy tacó 3 vấn đề cần xem xét:
- Driver entry ở địa chỉ f89b3000 (bak1en+1000)
- Hàmcreate_close ở địa chỉ bak1en+0x1180
- Hàm defaul còn lại ở địa chỉ bak1en+0x11a0
Trong bài này tập trung phân tích động ở DriverEntry
Ghi chú: ở trên tôi đã cho mẫu load xong hẳn mà chưa vội debug từ đầu từng lệnh từng lệnh. Ta xét một quá trình: bắt đầu -> quá trình giữa chững -> kết thúc. Nếu ta biết trạng thái lúc bắt đầu. Trạng thái lúc kết thúc. Ta có thể đoán được phần nào quá trình giữa chừng như thế nào. Đó là lý do cho mẫu load hẳn lên. Như thế sau một quá trình giải mã code của mẫu, thì cuối cùng mẫu cũng phải đăng ký với kernel một driver object. Chính từ driver object cuối cùng ở “gia đoạn kết thúc” này của mẫu cho ta thêm thông tin để phân tích “quá trình thực hiện” của mẫu.
Phân tích Driver Entry:
Reset lại máy ảo target để cho mẫu được load lại. ta đặt break point ở bak1en+1000(bak1en!DriverEntry tìm được từ bước trên). Gõ lệnh g chờ đến lúc WinDbg dừng lại ở Driver entry ở trên. Debug chạy từng bước (F10) một lúc ta gặp ngay đoạn code giải mã như sau:
- Địa chỉ bắt đầu giải mã làbak1en+0x1025
- Kích thước vùng giải mã tỷ lệ với số vòng loop. Số vòng loop quy định trong thanh ghi ECX = bak1en + 0x1066 - bak1en+0x1025 = 41hbyte.
- Sau khi chạy xong vòng loop giải mã là lệnh jmp tới bak1en+0x1025chính là đoạn vừa giải mã xong. Vậy đây chính là đoạn làm code “động” đã cản trở chúng ta khi phân tích động bằng IDA như ở trên.
Tiếp tục F10 cho WinDbg giải mã xong và nhảy tới vùng vừa giải mã xong là bak1en+0x1025sẽ thấy luôn đoạn mã thực hiện gán địa chỉ các hàm MJ cho DriverObject. Chú ý DriverObject trong hàm DriverEntry là tham số thứ nhất vì thế nó nằm ở[ebp+8].
Vậy mẫu bak1en đã mã hóa đoạn thực hiện khởi tạo các hàm MJ. Khi được load lên mới tiến hành giải mã code để thực thi!
Ta tiếp tục F10 đi tiếp đoạn nữa sẽ gặp đoạn code như sau:
ở đoạn code trên ta thấy bak1en đã xóa bit thứ 16 trong thanh ghi Cr0. Mà bit thứ 16 trong thanh ghi cr0 là bit WP.
Để ýEAX ở đoạn code trên.Ta xem giá trị lúc chạy “runtime” của eax lúc đó là bao nhiêu và mang ý nghĩa gì:
Nt!KiServiceTablehay còn gọi là bảngSSDT. Bảng này được export bởi kernel, cực kỳ quan trọng vì nó lưu toàn bộ con trỏ hàm tớ các hàm Ntxxx mà thông qua bảng này kernel sẽ tìm được đại chỉ các hàm Ntxxx. Bảng SSDT nằm ở vùng page readonly, nhưng khi bit WriteProtect ở thanh ghi CR0 bị xóa thì có thể write vào bảng này.
Tóm lại đoạn code trên Disable WriteProtect trong thanh ghi CR0 và thay đổi một số giá trị trong bảng SSDT suy ra đây chính là kỹ thuật của bak1en sử dụng: Hook SSDT. Một kỹ thuật rất cơ bản và có thừ lâu, chi tiết về kỹ thuật hook SSDT có thể tham khảo http://resources.infosecinstitute.com/hooking-system-service-dispatch-table-ssdt/ ở đây không đề cập tới ở đây nữa.
Vậy ta đã biết mẫu thực hiện hook SSDT. Làm sao để biết mẫu hook hàm gì và thực hiện những gì trong hàm hook đó? Ở đây sẽ giới thiệu 2 cách để thực hiện điều này:
(1) Đi theo quá trình: Tiếp tục debug step by step bằng WinDbg tức là nhấn F10 cho chạy từng lệnh từng lệnh. Bằng cách này ta cùng thấy luôn là tiếp sau đoạn này sẽ hook 3 hàm trong SSDT và kết thúc DriverEntry.
(2) Ta chỉ cần xem kết quả cuối cùng:ở đây ta có nhận xét hook SSDT sẽ để lộ đặc điểm làbảng SSDT bị thay đổi, vậy chỉ cần cho mẫu chạy xong sau đó xem lại bảng SSDT ta có thể thấy SSDT thay đổi như thế nào và lần ra hàm hook được thay thế.
Chú ý kỹ thuật “xem kết quả cuối cùng” trong bài viết này đã sử dụng lần thứ 2. Đây là một kỹ thuật rất quan trọng khi ta debug động. Bây giờ ta áp dụng kỹ thuật này và kết quả như sau:
Đã rõ ra 3 hàm mà mẫu hook đó là NtCreateKey, NtEnumerateKey và NtOpenKey, 3 hàm này làm việc với regedit từ đây ta có thể đoán được phần nào trong hàm hook xử lý gì, cùng xem tiếp trong hàm hook:
Đối với hàmhook_NtCreateKey ta vừa xem,dễ dàng thấy được hành vi đó là chặn những truy vấn nào đến key có tên key là“bak1en”. Phân tích đối vớihook_NtOpenKey vàhook_NtEnumerateKeycũng cho ta kết quả tương tự.
Vậy là ta đã hoàn thành phân tích động mẫu rootkit bak1en tổng kết hành vi kỹ thuật như sau:
- Self modify codeđể biến code thành code động, chống dịch ngược bằng các công cụ phân tích tĩnh
- Hook SSDT các hàm NtCreateKey, NtEnumerateKey, NtOpenKey va chặn những truy vấn tới key có tên là“bak1en”
Xem thực tế khi chạy mẫu: key bak1en hoàn toàn biến mất trên regedit của windows, phải sử dụng tool đặc biệt mới có thể nhìn thấy được.
Ta thử tạo key với tên key là “bak1en” cũng sẽ bị nhìn thấy thông báo lỗi key đã tồn tại.
Trên đây là bài viết phân tích động mẫu rootkit bằng WinDbg hướng dẫn sử dụng môi trường + tool cần thiết để debug động ở mức kernel và hướng dẫn debug mẫu cụ thể rootkit bak1en. Bài viết có thể mắc nhiều thiếu sót, rất mong nhận được góp ý, đóng góp từ bạn đọc
Cũng giống như malware ở user mode. Ta có thể phân tích bằng phân tích tĩnh (tham khảo http://whitehat.vn/threads/12169-Hu...uc-nhan-he-dieu-hanh-Kernel-Mode-Rootkit.html ).
Tuy nhiên không phải bất kỳ mẫu rootkit nào cũng “phơi bày thân hình” của mình ra trước mắt người khác mà chúng thường có rất nhiều “mảnh giáp che thân” đó chính là sử dụng các kỹ thuật anti-reverse, ví dụ như là tự giải mã code, tự thay đổi code ngay lúc thực thi. Đối với loại tự bảo vệ mình như thế thì phân tích tĩnh thường “bó tay”. Vì thế ta cần phải phân tích động để giải quyết vấn đề này.
Nội dung bài viết:
1. Cách dựng môi trường và tool cần thiết để debug động rootkit
2. Phân tích chi tiết một mẫu rootkit cụ thể
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
1. Dựng môi trường và tool cần thiết
Rootkit malware chạy ở mức nhân hệ điều hành (kernel). Không phải cứ doub-click là chạy mà rootkit phải load lên đúng cách như các driver của hệ thống được load. Vì thế việc thực thi một mẫu rootkit bất kỳ khó khăn hơn so với việc chạy một mẫu virus ở User Mode. Điều này gây cản trở cho ai muốn phân tích hành vi của rootkit, nhất là muốn monitor như malware ở UserMode thì rất khó khăn. Sau đây là hướng dẫn tạo dựng môi trường debug động rootkit:
Nguyên lý: ta có một máy ảo chạy rootkit gọi là target, trên môi trường máy thật (host) ta sử dụng WinDbg kết nối đến máy target để debug.
- WinDbg cài đặt trên môi trường máy host (máy làm việc của ta), windbg tích hợp trong gói WDK có thể download và cài đặt WDK 7.1 ở đây http://www.microsoft.com/en-us/download/details.aspx?id=11800
- Môi trường chạy mẫu: ta không chạy trực tiếp mẫu trên môi trường host mà phải tạo môi trường máy ảo cho nó chạy ở trong đó. Ở đây dùng VirtualBox. Download và tài liệu sử dụng máy ảo ở đây: https://www.virtualbox.org/wiki/Downloads Trong bài này, cài windows xp trong virtual box. Cho mẫu rootkit chạy trong máy windows xp ảo này.
- Để kết nối WinDbg tới máy ảo chạy mẫu, ta cần thiết lập “con đường”giao tiếp giữa 2 phần mềm này. Ta có thể thiết lập bằng tay. Tuy nhiên, để đơn giản ta sử dụng virtualKD, download và hướng dẫn cài đặt tại đây: http://virtualkd.sysprogs.org/tutorials/install/
2. Phân tích chi tiết một mẫu rootkit cụ thể
Thông tin mẫu
Tên mẫu: bak1en.sys
Md5: A2E7965C33EF25C98C75CFBF0C742F7E
Trước hết ta kéo mẫu vào IDA xem thử mẫu DriverEntry của mẫu:
Ở trên ta thấy code không “đẹp” như code chuẩn C/C++ mà trông rất “lộn xộn” rất khó hiểu, không thấy gì liên quan tới khởi tạo các hàm MJ hay Unload, đặc biệt xuất hiện một vòng lặp trong đó có toán tử xor “^”. Tađoán đó có thể là đoạn giải mã code của rootkit. Kỹ thuật này gọi là self-modify code.
Tới đây chuyển sang phân tích động:
Ta tạo một service mới để lần sau khởi động sẽ load mẫu rootkit này lên, cách tạo và load service có thể tham khảo ở MSDN. Ở mẫu này chọn giá trị như sau:
Sau khi WinDbg attach vào máy ảo targetdebug mẫu.Gõ “g” trong dòng lệnh của WinDbg, mục địch khởi động windows xong hết. Lúc này ta break WinDbg và kiểm tra lại xem mẫu bak1en có được load không:
Tiếp theo, ta kiểm tra Driver Object của mẫu bak1en
Từ kết quả trên cho ta thấy là hàm IRP_MJ_CREATE và IRP_MJ_CLOSE có cùng địa chỉ bak1en+0x1180, các hàm MJ còn lại có địa chỉ bak1en+0x11a0. Nhận xét do dùng 1 hàm cho nhiều hàm như thế thì đoán được hàm này có thể không làm gì cả, chỉ thực hiện các nhiệm vụ defaul như là chuyển tiếp hoặc return!
Vậy tacó 3 vấn đề cần xem xét:
- Driver entry ở địa chỉ f89b3000 (bak1en+1000)
- Hàmcreate_close ở địa chỉ bak1en+0x1180
- Hàm defaul còn lại ở địa chỉ bak1en+0x11a0
Trong bài này tập trung phân tích động ở DriverEntry
Ghi chú: ở trên tôi đã cho mẫu load xong hẳn mà chưa vội debug từ đầu từng lệnh từng lệnh. Ta xét một quá trình: bắt đầu -> quá trình giữa chững -> kết thúc. Nếu ta biết trạng thái lúc bắt đầu. Trạng thái lúc kết thúc. Ta có thể đoán được phần nào quá trình giữa chừng như thế nào. Đó là lý do cho mẫu load hẳn lên. Như thế sau một quá trình giải mã code của mẫu, thì cuối cùng mẫu cũng phải đăng ký với kernel một driver object. Chính từ driver object cuối cùng ở “gia đoạn kết thúc” này của mẫu cho ta thêm thông tin để phân tích “quá trình thực hiện” của mẫu.
Phân tích Driver Entry:
Reset lại máy ảo target để cho mẫu được load lại. ta đặt break point ở bak1en+1000(bak1en!DriverEntry tìm được từ bước trên). Gõ lệnh g chờ đến lúc WinDbg dừng lại ở Driver entry ở trên. Debug chạy từng bước (F10) một lúc ta gặp ngay đoạn code giải mã như sau:
- Địa chỉ bắt đầu giải mã làbak1en+0x1025
- Kích thước vùng giải mã tỷ lệ với số vòng loop. Số vòng loop quy định trong thanh ghi ECX = bak1en + 0x1066 - bak1en+0x1025 = 41hbyte.
- Sau khi chạy xong vòng loop giải mã là lệnh jmp tới bak1en+0x1025chính là đoạn vừa giải mã xong. Vậy đây chính là đoạn làm code “động” đã cản trở chúng ta khi phân tích động bằng IDA như ở trên.
Tiếp tục F10 cho WinDbg giải mã xong và nhảy tới vùng vừa giải mã xong là bak1en+0x1025sẽ thấy luôn đoạn mã thực hiện gán địa chỉ các hàm MJ cho DriverObject. Chú ý DriverObject trong hàm DriverEntry là tham số thứ nhất vì thế nó nằm ở[ebp+8].
Vậy mẫu bak1en đã mã hóa đoạn thực hiện khởi tạo các hàm MJ. Khi được load lên mới tiến hành giải mã code để thực thi!
Ta tiếp tục F10 đi tiếp đoạn nữa sẽ gặp đoạn code như sau:
ở đoạn code trên ta thấy bak1en đã xóa bit thứ 16 trong thanh ghi Cr0. Mà bit thứ 16 trong thanh ghi cr0 là bit WP.
Để ýEAX ở đoạn code trên.Ta xem giá trị lúc chạy “runtime” của eax lúc đó là bao nhiêu và mang ý nghĩa gì:
Nt!KiServiceTablehay còn gọi là bảngSSDT. Bảng này được export bởi kernel, cực kỳ quan trọng vì nó lưu toàn bộ con trỏ hàm tớ các hàm Ntxxx mà thông qua bảng này kernel sẽ tìm được đại chỉ các hàm Ntxxx. Bảng SSDT nằm ở vùng page readonly, nhưng khi bit WriteProtect ở thanh ghi CR0 bị xóa thì có thể write vào bảng này.
Tóm lại đoạn code trên Disable WriteProtect trong thanh ghi CR0 và thay đổi một số giá trị trong bảng SSDT suy ra đây chính là kỹ thuật của bak1en sử dụng: Hook SSDT. Một kỹ thuật rất cơ bản và có thừ lâu, chi tiết về kỹ thuật hook SSDT có thể tham khảo http://resources.infosecinstitute.com/hooking-system-service-dispatch-table-ssdt/ ở đây không đề cập tới ở đây nữa.
Vậy ta đã biết mẫu thực hiện hook SSDT. Làm sao để biết mẫu hook hàm gì và thực hiện những gì trong hàm hook đó? Ở đây sẽ giới thiệu 2 cách để thực hiện điều này:
(1) Đi theo quá trình: Tiếp tục debug step by step bằng WinDbg tức là nhấn F10 cho chạy từng lệnh từng lệnh. Bằng cách này ta cùng thấy luôn là tiếp sau đoạn này sẽ hook 3 hàm trong SSDT và kết thúc DriverEntry.
(2) Ta chỉ cần xem kết quả cuối cùng:ở đây ta có nhận xét hook SSDT sẽ để lộ đặc điểm làbảng SSDT bị thay đổi, vậy chỉ cần cho mẫu chạy xong sau đó xem lại bảng SSDT ta có thể thấy SSDT thay đổi như thế nào và lần ra hàm hook được thay thế.
Chú ý kỹ thuật “xem kết quả cuối cùng” trong bài viết này đã sử dụng lần thứ 2. Đây là một kỹ thuật rất quan trọng khi ta debug động. Bây giờ ta áp dụng kỹ thuật này và kết quả như sau:
Đã rõ ra 3 hàm mà mẫu hook đó là NtCreateKey, NtEnumerateKey và NtOpenKey, 3 hàm này làm việc với regedit từ đây ta có thể đoán được phần nào trong hàm hook xử lý gì, cùng xem tiếp trong hàm hook:
Đối với hàmhook_NtCreateKey ta vừa xem,dễ dàng thấy được hành vi đó là chặn những truy vấn nào đến key có tên key là“bak1en”. Phân tích đối vớihook_NtOpenKey vàhook_NtEnumerateKeycũng cho ta kết quả tương tự.
Vậy là ta đã hoàn thành phân tích động mẫu rootkit bak1en tổng kết hành vi kỹ thuật như sau:
- Self modify codeđể biến code thành code động, chống dịch ngược bằng các công cụ phân tích tĩnh
- Hook SSDT các hàm NtCreateKey, NtEnumerateKey, NtOpenKey va chặn những truy vấn tới key có tên là“bak1en”
Xem thực tế khi chạy mẫu: key bak1en hoàn toàn biến mất trên regedit của windows, phải sử dụng tool đặc biệt mới có thể nhìn thấy được.
Ta thử tạo key với tên key là “bak1en” cũng sẽ bị nhìn thấy thông báo lỗi key đã tồn tại.
Trên đây là bài viết phân tích động mẫu rootkit bằng WinDbg hướng dẫn sử dụng môi trường + tool cần thiết để debug động ở mức kernel và hướng dẫn debug mẫu cụ thể rootkit bak1en. Bài viết có thể mắc nhiều thiếu sót, rất mong nhận được góp ý, đóng góp từ bạn đọc
((