Tổng quan về mẫu malware Virus.Win32.Virut.ce- Phần 3

Tổng quan về mẫu malware Virus.Win32.Virut.ce Phần 3 Đoạn giải mã chính của phần thân virus Virut.ce Trước khi đi vào phần chính thảo luận về phương thức payload của virus, chúng ta hãy cùng nhìn vào công cụ giải mã Init trong 1 file đã bị lây nhiễm:1 phần của file đã bị lây nhiễm bởi Virus.Win32.Virut.ce với Init decryptorĐoạn mã disassembled của Init decryptor Hình ảnh đầu tiên chỉ ra các phần mã đã bị lây nhiễm của file calc.exe. Phần ngoài rìa của các section mã được đánh dấu, đồng thời phần Init decryptor cũng được đánh...
Nội dung trích xuất từ tài liệu:
Tổng quan về mẫu malware Virus.Win32.Virut.ce- Phần 3 Tổng quan về mẫu malware Virus.Win32.Virut.ce Phần 3Đoạn giải mã chính của phần thân virus Virut.ceTrước khi đi vào phần chính thảo luận về phương thứcpayload của virus, chúng ta hãy cùng nhìn vào công cụ giảimã Init trong 1 file đã bị lây nhiễm: 1 phần của file đã bị lây nhiễm bởi Virus.Win32.Virut.ce với Init decryptor Đoạn mã disassembled của Init decryptorHình ảnh đầu tiên chỉ ra các phần mã đã bị lây nhiễm củafile calc.exe. Phần ngoài rìa của các section mã được đánhdấu, đồng thời phần Init decryptor cũng được đánh dấu.Hình ảnh bên dưới hiển thị các đoạn mã disassembled củacông cụ giải mã Init. 4 phương thức được đề cập bên trênđược khoanh trong hình oval đỏ.Trong ví dụ này, trình quản lý đăng ký ECX được lấp đầybởi các hành động push / pop liên tục và được giải mã bởiadc. Tuy nhiên, các quá trình này không phải lúc nào cũnggiống nhau. Virut.ce đã phát triển rất nhanh trong năm qua,bằng chứng là chúng đã tích hợp được công nghệ giải mãInit một cách dễ dàng. Nếu thông tin của phần body virusghi vào trong registry được chỉnh sửa 1 lần (mov reg,dword chuyển thành push dword; pop reg) thì các thủ tụcđể giải mã cũng thay đổi nhiều hơn 1 lần (sắp xếp theo thứtự): - ADD/SUB [mem], dword; - ROL/ROR [mem], byte; - ADC/SBB [mem], byte; - ADD/SUB [mem], byte; - ADD/SUB [mem], word; - ADC/SBB [mem], word; - ADC/SBB [mem], dword;Khôi phục lại đoạn mã ban đầuVề mặt lý thuyết, toàn bộ mã nguồn của phần body chínhcó thể được chia ra làm 3 nhóm, theo nhiệm vụ chính sau:quá trình khôi phục lại từ các điểm function / entry, quátrình giải mã của body theo dạng tĩnh, và tính thực thi củaquá trình payload.Trước khi tiến hành xem xét cặn kẽ từng thành phần, hãyxem qua tổng thể toàn bộ phần body của virus và các phầncó liên quan: Cấu trúc tổng thể phần body chính của Virut.ceNhư trên hình đã chỉ ra, chúng ta có thể thấy rằng phầnbody chính được ghép tới tận cuối của mã sectin cuối cùngvà tạo thành 2 phần: bộ phận giải mã phần body tĩnh và bộphận thực thi mã. Phần đảm nhiệm dịch vụ thực thi chứacác đoạn mã nhằm thực thi các chế độ chống lại việc môphỏng, khôi phục tham số entry point gốc, và cơ chế giảimã toàn bộ phần body tĩnh. Những phần này nằm rải ráctrên toàn bộ thân hoặc có thể cố định tại phần đầu hoặccuối, hoặc được chia làm 2. Cũng thật may mắn rằng phầncó thể thực thi được che phủ khá kỹ càng. Điều này sẽ làmcho việc phát hiện hoặc nhận dạng trở nên phức tạp hơn rấtnhiều: Đoạn mã có chứa thành phần chính của Virus.Win32.Virut.ceHình ảnh trên miêu tả các đoạn mã có chứa thành phầnchính của 1 file bất kỳ bị lây nhiễm bởiVirus.Win32.Virut.ce. Phần được khoanh vùng với dấu ovalđỏ là phần đảm nhận nhiệm vụ thực thi, hoặc cũng có thểdễ dàng nhận ra bởi tại đây có rất nhiều các ký tự byterỗng. Và trong phần này, virus chưa vội vàng sử dụng cơchế giải mã trong quá trình lây nhiễm, tất cả các sectionđều trông có vẻ giống nhau và được mã hóa cùng nhau.Tiếp theo, cùng nhìn vào các khối dữ liệu chuyên dùng đểkhôi phục lại phần nguyên bản của dữ liệu. Quá trình logicnày có thể được phân chia theo các bước sau: - Thực hiện thủ tục CALL (các địa chỉ cố định với độ sailệch nhỏ) - Khôi phục lại nội dung ban đầu của dữ liệu với trìnhquản lý register - Thêm các địa chỉ cụ thể để trỏ tới nhân kernel32.dll vàEBX register - Tính toán số lượng pointer tới các địa chỉ của các thủ tụcgọi hàm CALL ở bước 1 - Tiếp tục thực hiện các toán tử trên địa chỉ được gọi ra từbước 4Lưu ý thêm rằng virus sử dụng công nghệ EPO chỉ khi nónhận ra rằng các hàm API-function đang được gọi ra từkernel32.dll. Thủ tục gọi hàm này có thể được nhận diệnthông qua các “cuộc gọi” từ mã vận hành 0x15FF hoặc0xE8, với các chỉ dẫn JMP tiếp theo (0x25FF). Nếu bất cứhàm nào được nhận diện là sẽ được thay thế bởi JMP(0xE9) chỉ dẫn tới biểu đồ 1 (hình trên), sau đó địa chỉ củahàm được thay thế từ kernel32.dll trong trình quản lý EBXregister. Nếu các entry point vừa được sửa lại, thì các giá trịtại địa chỉ [ESP + 24] được thay thế trong EBX register –đây là địa chỉ của ứng dụng được chỉ định quay lại nhân hệthống kernel32.dll. Tiếp theo sau đó, các giá trị được lưutrữ trong register sẽ được dùng để ghi lại cac địa chỉ khi hệthống xuất ra các hành động tương ứng của DLL. Nếu côngnghệ EPO được áp dụng thì giá trị tại địa chỉ [ESP + 20] sẽlưu giữ nhiều thông tin của các hàm được gọi ra tương ứngvới API-function, mặt khác, tại đây còn lưu trữ địa chỉ củaentry point nguyên bản.Nếu quá trình obfuscation được loại trừ, thì cách đơn giảnnhất để khôi phục lại các entry point và các hàm khác sẽnhư sau (trong trường hợp GetModuleHandleA đã đượcthay thế):CALL $ + 5PUSHADMOV EBX, [GetModuleHandleA]XOR [ESP + 20h], KeyĐoạn mã này hoàn toàn phù hợp với logic chung của toànbộ khối dữ liệu. Tiếp theo, hãy cùng ...