Thực hiện kiểm thử hệthống đối với mãđộc cụ thể

Một phần của tài liệu Xây dựng hệ thống tự động phân tích mã độc (Trang 75 - 108)

5. Phương pháp nghiên cứu

4.5.3 Thực hiện kiểm thử hệthống đối với mãđộc cụ thể

Đối với mỗi mẫu mã độc, hệ thống được chạy qua những thành phần sau:

Hình 12: Sơ đồ của kịch bản thử nghiệm với mã độc 1. Khi bắt đầu chạy Cuckoo SandBox, ta thực hiện lệnh:

$./cuckoo.py

Lúc đó đầu ra từ terminal sẽ giống như hình bên dưới:

2. Giờ thì Sandbox đã bắt đầu chạy và chờ đợi để phân tích. Ta có thể submitmalware sample hoặc các URL độc hại. Ta phải chuyển sang đường dẫn/cuckoo/utils / và sau đó sử dụng các file submit.py để thực hiện một phân tích phần mềm độc hại:

Khi đó kết quả đầu ra sẽ được như hình sau:

Như vậy chúng ta đã thiết lập xong cho Host OS và Guest OS trong VirtualBox và sau đó cài đặt Cuckoo Sandbox. Việc quan trọng nhất của quá trình này là đảm bảo rằng tất cả các dependencies cần thiết trong Host OS cùng với pydeep và Yara được cài đặt đầy đủ. Đối với Guest OS, thì tắt luôn các thành phần bảo vệ(Self-defend) , Windows Firewall và sử dụng bất kỳ phần mềm nào mà mã độc thường được thường tương tác với, ví dụ, Adobe Reader 9.5, Internet Explorer 6, Microsoft Office 2003.

Chúng ta cần cấu hình trong file <machinemanager>.conf phải chính xác giống như n phần mềm ảo hóa mà ta đang sử dụng. Ví dụ, nếu ta muốn sử dụng KVM, ta phải thiết lập KVM trong machinemanager.conf. Vì chúng ta đang sử dụng VirtualBox, nên ta phải đặt VirtualBox trong cấu hình.Tên của GuestOS trong VirtualBox được để trong fie cuckoo.conf. Tiếp theo là cần phải tạo một bản backup của toàn bộ hệ thống và cấu hình.

Sau đây, chúng ta sẽ sử dụng SandBox này để phân tích một số loại mã độc phổ biến. Ở đây, chúng ta sẽ chọn một mẫu virus ở dạng worm có tên là Mydoom.

- MyDoom là mẫu worm khuếch tán qua email gây thiệt hại hơn $38 million và lây nhiễm hơn 2 triệu máy trên toàn thế giới

Quá trình phân tích mẫu virus này bằng hệ thống tự động phân tích mã độc: - Ban đầu ta cần upload mẫu virus này vào hệ thống:

- Nếu mẫu được upload đúng cách thì hệ thống sẽ hiển thị lên thông tin đang xử lý mẫu này.

- Khi mẫu virus được hệ thống xác nhận thì máy ảo tự động phân tích sẽ được bật lên để chạy mâu virus này trong môi trường ảo:

Ta có thể thấy trong quá trình chạy thì hệ thống được chạy trong một môi trường cô lập, tất cả các thao tác của mã độc trên hệ thống đều được theo dõi và kiểm soát.

- Ở bên ngoài, hệ thống Host ta có thể thấy các quá trình này, và khi quá trình đó kết thúc thì máy ảo dùng để phân tích sẽ được tự động tắt để tiến hành phân tích các dữ liệu mà mã độc sinh ra.

- Đây là các pluggin được viết để phân tích vùng nhớ được dump ra từ hệ thống máy ảo.

Chúng ta có thể thấy quá trình này diễn ra khá lâu ( còn tùy thuộc vào dung lượng bộ nhớ cấp phát cho môi trường ảo ).

- Khi quá trình phân tích kết thúc, ở hệ thống host sẽ hiện ra thông báo như sau để chúng ta biết được quá trình phần tích đã thành công.

- Sau khi quá trình phân tích kết thúc, ta có thể bật trình duyệt, vào địa chỉ sau: 127.0.0.1:8080/submit

Chúng ta sẽ chọn vào Task ID ứng với mẫu mã độc đang phân tích để xem kết quả phân tích.

- Đây là tổng quan về hệ thống mà chúng ta sử dụng để phân tích.

Ở đây chúng ta có thể thấy thời gian bắt đầu, kết thúc của quá trình phân tích. Ngoài ra, còn có phiên bản hệ điều hành sử dụng ( ở đây chúng ta sử dụng Windows XP3 cho môi trường máy ảo ). Trình quản lý máy ảo ở đây là VirtualBox.

- Đây là một số thông tin về mã độc mà chúng ta đang phân tích, được hệ thống cung cấp

Ở đây có một số thông tin như tên file, kích thước, kiểu file. Ngoài ra, còn có các loại mã băm như MD5, SHA1, SHA256, SHA512, SSDEEP.

Trong hệ thống còn có cài đặt PEiD để xác định kiểu nén mà mã độc đang sử dụng. Ở đây là kiểu nén: UPX 2.90 [LZMA] -> Markus Oberhumer, Laszlo Molnar & John Reiser.

Chúng ta không thấy thông tin gì về Yara, vì ta chưa viết chương trình nhận diện cho loại mã độc này. Đối với phần VirusTotal, tính năng này sẽ được sử dụng ở phần sau.

- Phần tiếp theo, hệ thống sẽ tự chụp lại ảnh màn hình để chúng ta có thể xem qua quá trình hoạt động của mã độc

Đối với mẫu worm này thì chương trình chỉ hoạt động ngầm nên chúng ta chưa thấy có gì đặc biệt trong phần chụp lại ảnh màn hình này.\

- Thông tin về các section của file mã độc.

Trong phần này, ta thấy 2 section mang tên là UPX. Đây là điều khá đặc trưng đối với mỗi file được nén lại bằng trình nén UPX.

- Thông tin về các hàm được mã độc import từ những DLL thông dụng.

- Tiếp theo là phần ghi lại những xâu được sử dụng trong file mã độc.

Trong phần này, ta có thể thấy dòng đầu tiên là một xâu đặc trưng cho một file PE thông thường. Đối với phần này, dựa vào một số xâu đặc biệt, ta cũng có thể biết được nhiều thông tin về các chủng loại virus nói chung.

- Đây là những file mà mã độc đã sinh ra trong quá trình hoạt động của nó.

Ta có thể thấy trong này có 2 tập tin log zincite.log và dbbvqv8oil.log.

2 file này đều có kiểu file là dữ liệu. Như vậy, chúng ta có thể đoán được mã độc này đã ghi log lại trong quá trình hoạt động.

Ngoài ra, ta còn thấy 2 file khác đó là java.exe và services.exe.

Ta thấy file java.exe có kích thước bằng không, như vậy file này mới được tạo ra và mã độc chưa tiến hành ghi ra nội dung file hoặc thời gian phân tích chưa đủ nên cần tăng thời gian phân tích để biết được chính xác thông tin về file này. File còn lại là file services.exe, có thể mã độc muốn sử dụng file này đóng giả một dịch vụ trong Windows, và với cái tên như vậy thì nó sẽ tránh được sự nghi ngờ từ phía người dùng.

- Về phần phân tích về mạng, ta có thể thấy các host với địa chỉ IP mà mã độc muốn kết nối đến.

Dựa vào danh sách địa chỉ IP này, chúng ta có thể kiểm tra xem chúng có thuộc vào danh sach địa chỉ C&C ( Command & Control IP list ) hay không. Để biết được mã độc có nhận lệnh từ những server điều khiển nào hay không.

- Phần tiếp theo, hệ thống sẽ tóm lược những hành vi hoạt động của mã độc trong môi trường được kiểm soát.

Trong phần này, ta có thể thấy được đường dẫn của những file được mã độc sinh ra. Ví dụ như file services.exe trong đường dẫn C:\WINDOWS. Ngoài ra còn có những đường dẫn file mà mã độc thao tác tới để tìm file hoặc tạo ra để sử dụng.

- Đây là những Mutex được tạo trong hệ thống.

Mutex được tạo ra và sử dụng để xử lý một tài nguyên được chia sẻ giữa nhiều các tiến trình hoặc chương trình khác nhau. Do vậy, dựa vào tên của một mutex đặc trưng, ta có thể biết được hệ thống đang bị nhiễm loại mã độc như thế nào.

- Về registry, hệ thống cũng thống kê lại những thao tác của mã độc trên phần này.

Registry là một thành phần để lưu trữ các thông số kỹ thuật của Windowsvà lưu lại những thông tin cũng như những thiết lập của những chương trình được sử dụng trên hệ thống này. Như vậy, theo dõi registry cũng là một thành phần quan trọng của hệ thống tự động phân tích mã độc.

- Phần tiếp theo, sẽ là process tree hay là quá trình theo dõi mã độc từ chương trình chính.

Ở đây, ta có thể thấy services.exe là chương trình được tạo ra từ mydoom.exe ( file mã độc chính mà ta đang phân tích ) qua Parent PID.

+ Đối với mã độc chính là mydoom.exe, ta có thể thấy các hàm mà mã độc này gọi.

Như chúng ta thấy ở hình trên thì file java.exe thực chất cũng chính là file mydoom.exe của chúng ta. Nó được ghi vào thư mục C:\WINDOWS và được tạo 1 ghi một registry vào hệ thống với tên là JavaVM. Như vây, loại mã đọc này muốn giả danh một chương trình của Java để tránh sự nghi ngờ từ người dùng.

File services.exe cũng được mã độc sao chép vào đường dẫn C:\WINDOWS nhưng dược khởi tạo bằng một hàm API của Windows là hàm CreateProcessInternalW.

+ Đối với file services.exe, ta có thể thấy một số hàm được mã độc này sử dụng như sau.

File này được ghi vào registry( cụ thể ở đây là key Run ) để tự động chạy lên khi người dùng khởi động lại máy

- Malfind là một plugin của Volatility giúp phát hiện mã lệnh ẩn hoặc được bị lây nhiễm vào vùng nhớ trên User Mode dựa vào đặc tính của trang nhớ.

Ở đây, ta có thể thấy chương trình csrss.exe bị inject vào địa chỉ tại 0x7f6f0000. Còn chương trình winlogon.exe bị lây nhiễm vào nhiều vùng địa chỉ trên vùng nhớ. Để biết rõ mã độc đã lây nhiễm vào từng trường hợp cụ thể như thế nào thì ta phải lấy được vùng nhớ ứng với từng dải địa chỉ thích hợp, rồi phân tích làm rõ.

- Để tìm ra các API bị mã độc hook trên User Mode hoặc Kernel Mode, hệ thống sử dụng Apihooks plugin. Dưới đây là một số hàm đó.

Đối với kiểu hook inlines, Apihooks sẽ tiến hành tìm kiếm các lệnh CALL và lệnh JMP cả trực tiếp lẫn gián tiếp và nó cũng có thể phát hiện các lệnh PUSH/ RET được thêm vào 1 cách đồng thời với nhau cho việc thực hiện hook.

- Để thống kê các chương trình hoạt động trong lúc mã độc đang hoạt động, ta sử dụng PSList.

Để lấy được danh sách các chương trình này, PSList rà soát qua một lượt danh sách liên kết đôi được trỏ bởi PsActiveProcessHead. Ví dụ như hình sau:

Khi duyệt trên danh sách này, chúng ta sẽ lấy được tên của chương trình, process ID, số lượng tiến trình, số lượng handles, ngày và thời gian bắt đầu và kết thúc của mỗi process. Nếu chương trình nào đang chưa có thời gian kết thúc có nghĩa là nó vẫn đang hoạt động trên hệ thống lúc chúng ta thu thập thông tin.

- Vì một số chương trình có thể bị mã độc che giấu, không thể phát hiện ra được bằng PSList, nên hệ thống cũng cung cấp một plugin khác để tiến hành lọc ra những chương trình này. Đó là PSXView.

PSXViewxác định các chương trình chạy trên hệ thống bằng nhiều cách khác nhau. Plugin này dùng cả PSList, sau đó dùng PSScan. Sau đó, liệt kê các chương trình một cách gián tiếp bằng cách sử dụng phương pháp ETHREAD scanning ( công cụ check_thrdproc ). Hoặc duyệt qua PspCidTable ( PspCidTable chứa handle của tất cả các chương trình và tiến trình tồn tại trong hệ thống, nó được sử dụng bởi Thread Scheduler để giữ cho các tiến trình đó luôn hoạt động đúng chuẩn ). Chúng ta cũng có thể kiểm tra bằng cách sử dụng bảng csrss.exe handle.

- Muốn biết list các thư việc liên kết động ( DLL )được tải lên trong lúc mã độc hoạt động ta có thể dùng DllList plugin.

Plugin này thực chất là duyệt qua cấu trúc PEB ( Process Environment Block - cấu trúc này chứa nhiều thông tin về chương trình được hệ điều hành quản lý). Từ cấu trúc này, ta tìm tới cấu trúc:

typedef struct LDR_DATA_ENTRY {

LIST_ENTRY InMemoryOrderModuleList; PVOID BaseAddress; PVOID EntryPoint; ULONG SizeOfImage; UNICODE_STRING FullDllName; UNICODE_STRING BaseDllName; ULONG Flags; SHORT LoadCount; SHORT TlsIndex; LIST_ENTRY HashTableEntry; ULONG TimeDateStamp; } LDR_DATA_ENTRY, *PLDR_DATA_ENTRY;

Và từ đây dễ dàng tìm được tên cũng như kích thước của mỗi DLL được tải lên.

- Ngoài ra, đối với các Handles được mở bởi mã độc, ta có thể dựa vào Process ID ( PID ) của nó và plugin Handles của Volatility.

- Tiếp theo, chúng ta có thể lọc ra những hàm callback ( một đoạn chương trình hoạt động lặp lại theo thời gian ) có trên hệ thống bằng plugin Callbacks. Điều này rất có ích vì sẽ hỗ trợ cho chúng ta biết hệ thống ngoài ra có bị kiểm soát bởi những chương trình bị nghi ngờ nào hay không.

- Để xem được Security Identifiers ( SIDs ) gắn với một chương trình trong hệ thống chúng ta sử dụng plugin GetSids.

Dựa vào thông tin này, chúng sẽ giúp ta biết được chương trình nào có khả năng leo thang về quyền và chương trình đó thuộc về user cụ thể nào.

- Để tìm hiểu thêm về quyền của mỗi chương trình chạy trong hệ thống, đặc biệt là mã độc đang theo dõi, ta có thể dùng Privs plugin.

Từ đây, chẳng hạn với mẫu mydoom.exe mà chúng ta đang điều tra, chúng ta có thể dễ dàng thấy được mã độc này đang có những quyền gì trên hệ thống.

- Cuối cùng, cũng rất quan trọng đó là việc để biết được các chương trình nào đang hoạt động dưới dạng dịch vụ ( services ) của hệ điều hành thì chúng ta sẽ sử dụng plugin Svcscan.

Dựa vào những thông tin ở đây, chúng ta sẽ biết được service nào đang hoạt động trên hệ thống và trạng thái hoạt động của chúng.

Một phần của tài liệu Xây dựng hệ thống tự động phân tích mã độc (Trang 75 - 108)

Tải bản đầy đủ (PDF)

(110 trang)