Khi phân tích malware, những gì chúng ta nhìn thấy trên đĩa (disk) đôi khi không biểu diễn chính xác những gì thực sự đang xảy ra trong bộ nhớ.
Ngày nay malware có một cách độc đáo để ẩn và bẻ gãy các luật mà hầu hết các máy tính tuân theo. Bất kể nó là gì, đó là một thứ gì đó đặc biệt làm cho một malware trở nên độc đáo và làm cho nó trở thành một phần của một chương trình bình thường.
Mục đích của bài viết này là cung cấp đến người đọc hiểu biết cách malware hoạt động bên trong bộ nhớ. Bởi vì bạn cần biết một vài thuật ngữ cơ bản về bộ nhớ trước khi cố để hiểu cách chúng liên hệ với malware như thế nào, chúng tôi sẽ giải thích một vài khái niệm trước.
Process Memory
Nào hãy bắt đầu từ điểm xuất phát: running một chương trình. Khi một chương trình lần được tiên được thực thi, một bản sao của nó được nạp vào trong bộ nhớ, và sau đó trở thành một process. Chương trình sống trong không gian địa chỉ ảo sở hữu bởi process của nó (VAS) cùng với các thư viện phần mềm chương trình cần đến để thực thi một cách chính xác. Có những thứ khác sống trong process VAS, như là heap và stack memory, nhưng chúng tôi không đi sâu vào những thứ đó bây giờ.
Quá trình nạp (loading) các thư viện phần mềm yêu cầu tại lúc khởi động (start-up ) được gọi là liên kết động (dynamic linking). Các thư viện được liên kết được gọi là các thư viện liên kết động (Dynamic-Link libraries) hoặc DLLs. DLLs chứa các hàm (functions) được các chương trình sử dụng và được đặt trong các thư mục hệ thống của hệ điều hành.
Khi sử dụng một debugger - một công cụ được sử dụng để duyệt qua một process mỗi lần một lệnh - chúng ta có thể nhìn thấy một bức tranh sống động về memory process của chúng ta và hiểu rõ hơn về những gì đang diễn ra. Công cụ này được sử dụng bởi software developers để tìm bugs hay là errors trong code của họ, nhưng nó cũng là một công cụ cực mạnh cho phân tích malware. OllyDbg là một user-mode debugger tuyệt vời và phổ biến.
Nếu bạn mới sử dụng debuggers, chúng tôi khuyên bạn nên sử dụng OllyDbg vì tính dễ dàng để học của nó. Bài viết này không phải là hướng dẫn sử dụng OllyDbg vì thế bạn nên tìm hiểu về nó thông qua internet, tìm những bài hướng dẫn về cách debug và hiểu về Assembly language.
Bạn sẽ cần nạp một chương trình vào debugger để nhìn thấy bộ nhớ của nó. Trong bài viết này tôi sử dụng một malware có tên là new-sirefef.exe, đây là một thể loại ZeroAccess Trojan. Malware này là một rootkit, một kiểu malware đặc biệt có thể phá vỡ hệ điều hành của nó, và do đó có rất nhiều khó khăn trong việc phát hiện và loại bỏ. Dưới đây là file properties của new-sirefef.exe.
Mỗi khi bạn nạp new-sirefef.exe vào trong OllyDbg, chúng ta có thể sử dụng công cụ memory map để quan sát file thực thi và các thư viện phụ thuộc của chúng ta trong bộ nhớ. Chý ý cách chúng được phân bổ vào các mảnh bên trong process VAS. Quan sát hình phía dưới trông giống như new-sirefef.exe program trong một dải bộ nhớ ảo 0×00400000-0x00443000
Mỗi một trong các files trong memory map được chia thành các mảnh (pieces) được gọi là memory sections hay là memory segments. Tại sao lại có điều đó ? bởi vì những file này là Windows Portable Excutable (PE) files và do đó nó tuân thủ theo các định dạng PE. Do độ dài bài viết có hạn, chúng tôi sẽ không đi vào chi tiết các đặc điểm kĩ thuật của PE file, nhưng bạn có thể tìm hiểu thêm về nó tại Microsoft. Cách tốt nhất là bạn nên quen dần với định dạng file này nếu bạn muốn phân tích Windows files.
Imported Functions
Hiện tại, bởi vì chúng ta có hàng trăm DLL files trong Windows, process của chúng ta cần một một cách nào đó để biết những DLLs nào phải được nạp vào trong bộ nhớ lúc start-up. Các DLL functions yêu cầu được đặt trong PE header, nằm tại bảng Import Address Table (IAT). Import Address Table là một danh sách các hàm mà chương trình phải thực thi. Những hàm này có thể cho chúng ta biết chương trình làm gì, mặc dù nó có thể dễ dàng bị giả mạo, chúng ta sẽ nhìn thấy điều này sau.
Phía dưới là hình ảnh của IAT của new-sirefef.exe được nhìn thấy trong IDA Pro. IDA Pro là một disassembler và debugger. Như bạn có thể thấy có ít nhất 4 DLL files được nạp vào trong bộ nhớ lúc start-up: advapi32.dll, gdi32.dll, kernel32.dll, và user32.dll. Tuy nhiên, nhiều DLL files sẽ được nạp, như là một vài DLL functions phụ thuộc vào DLL functions khác.
Trong suốt quá trình thực thi process, dòng chảy chương trình (program flow) sẽ thay đổi thường xuyên từ new-sirefef.exe đến một DLL khi gọi các hàm bên trong các DLLs đó. Bởi vì các files DLL được yêu cầu đã được nạp vào trong bộ nhớ lúc process start-up, tuy nhiên vẫn có một sự chuyển đổi giữa chúng.
Malware in Memory
Malware như new-sirefef.exe làm việc giống như một chương trình bình thường mỗi khi nó truy cập bộ nhớ. Malware thường thay đổi chính nó, sử dụng các phương thức khác nhau trước khi run như một chương trình bình thường. Quá trình làm thay đổi code đó được thực hiện bằng cách sử dụng software packer, một kiểu chương trình sử dụng để obfuscate và/ hoặc compress chương trình ban đầu để gây bất lợi cho việc phân tích và reverse engineering. Một software packer thường có một "stub" program, chương trình này run lúc start-up và unpacks chương trình ban đầu vào trong bộ nhớ. Packers thỉnh thoảng còn được gọi là crytors, protectors, etc.
Packing giúp ngăn cản việc phân tích tĩnh (static analysis) , phân tích tỉnh là phân tích malware mà không run nó. Ngược lại phân tích động (dynamic analysis) phân tích malware trong khi malware đang running trong bộ nhớ. Nếu bạn muốn thực hiện phân tích tĩnh trên một packed program, bạn phải có được phiên bản ban đầu của chúng khi chưa bị packed (unpacked version). Quá trình unpacking malware khác nhau đối với từng file và có thể tốn một khoảng thời gian nếu thực hiện nó một cách thủ công.
Khi nói về unpacking, thực sự có vô số cách để làm nó; sự thực thì, rất khó khăn để theo kịp với tất cả các cách. Đó là lí do tại sao tồn tại các chương trình giúp bạn thực hiện điều đó. Chương trình yêu thích nhất của tôi là Exeinfo PE, bởi A.S.L Tôi thích chương trình này bởi vì nó không chỉ thực hiện tốt các công việc của phát hiện packers và crytors mà nó còn cung cấp các tips cho việc unpacking, điều đó rất tốt cho những người mới bắt đầu.
Bây giờ, bạn đã hiểu về cách IAT làm việc, biết về new-sirefef.exe như là nhiều hàm sẽ "unpack" như là process thực thi. Trong khi các hàm được hiện diện trong IAT thực sự được gọi, hầu hết trong số chúng chỉ là "filters" để đưa đến cho phân tích. Chúng ta đang bỏ quên một kĩ thuật quan trọng được sử dụng rất nhiều bởi malware để đạt được các hàm quan trọng, đó là runtime linking.
Trong suốt runtime linking, các hàm thư viện được lấy như khi process thực thi, và do đó danh sách các hàm được imported sẽ lớn dần. Hai hàm từ kernel32, LoadLibrary và GetProcAddress có thể được sử dụng để lấy bất cứ hàm nào đặt tại bất cứ thư viện nào trên hệ thống. Chú ý cách mà cả 2 hàm này đều được đặt trong IAT cho new-sirefef.exe. Do đó, nếu bạn nhìn thấy một chương trình với một IAT với chỉ có 2 hàm này, đây là một gợi ý cho bạn rằng có một vài thứ gì đó được ẩn đi (thông thường là malicious).
process new-sirefef.exe sử dụng runtime linking để xác định vị trí nhiều hàm cho IAT của nó. Một trong những hàm rất quan trọng nằm trong kernel32 là : VirtualAlloc. Hàm VirtualAlloc tạo một section mới của bộ nhớ ảo trong process VAS. Địa chỉ cơ sở (base address) của memory section mới trong newsirefef.exe là 0x003B0000.
Trong suốt quá trình thực thi, encrypted code được di chuyển từ .rsc (resource) segment của new-sirefef.exe và đặt trong bộ nhớ ảo mới của chúng ta. Code sẽ được decrypted và thực thi bên trong bộ nhớ mới tại 0x003B0000.
Đó là kĩ thuật rất phổ biến được sử dụng bởi malware, và nhất là packed programs. Vấn đề là code này không nhìn thấy được trên đĩa và chỉ có sẵn trên bộ nhớ tạm thời (ephemeral memory) . Do đó nếu chúng ta quyết định đóng debugger của chúng ta đi, mọi thứ trong memory segment có thể bị hủy bỏ, và có thể không phân tích được malware này.
Tiếp theo là gì?
Để phân tích malware sâu hơn, bạn nên tìm một cách đế sao chép new memory lên đĩa cho việc phân tích tĩnh. Hãy đón chờ phần 2, nơi chúng tôi thực hiện các công việc này và cho bạn một cái nhìn về các tricks mà rootkit này sử dụng trong khi unpacking.
Còn tiếp...
References:1. Michael Sikorski and Andrew Honig, Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software (San Francisco: No Starch Press, 2012), 13–15.
Không có nhận xét nào:
Đăng nhận xét