Tổng quan về mẫu malware Virus.Win32.Virut.ce (Phần IV)

Chia sẻ: Eef Sff | Ngày: | Loại File: PDF | Số trang:7

Thêm vào BST

Báo xấu

64
lượt xem 3
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Tổng quan về mẫu malware Virus.Win32.Virut.ce (Phần IV) .Trước khi tiến hành xem xét cặn kẽ từng thành phần, hãy xem qua tổng thể toàn bộ phần body của virus và các phần có liên quan: Cấu trúc tổng thể phần body chính của Virut.ce Như trên hình đã chỉ ra, chúng ta có thể thấy rằng phần body chính được ghép tới tận cuối của mã sectin cuối cùng và 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ứa các đoạn mã nhằm thực thi...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Tổng quan về mẫu malware Virus.Win32.Virut.ce (Phần IV)

Tổng quan về mẫu malware Virus.Win32.Virut.ce (Phần IV)
Trước khi tiến hành xem xét cặn kẽ từng thành phần, hãy xem qua tổng thể toàn bộ phần body của virus và các phần có liên quan: Cấu trúc tổng thể phần body chính của Virut.ce Như trên hình đã chỉ ra, chúng ta có thể thấy rằng phần body chính được ghép tới tận cuối của mã sectin cuối cùng và 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ứa cá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ải mã toàn bộ phần body tĩnh. Những phần này nằm rải rác trên toàn bộ thân hoặc có thể cố định tại phần đầu hoặc cuối, hoặc được chia làm 2. Cũng thật may mắn rằng phần có thể thực thi được che phủ khá kỹ càng. Điều này sẽ làm cho việc phát hiện hoặc nhận dạng trở nên phức tạp hơn rất nhiều: Đoạn mã có chứa thành phần chính của Virus.Win32.Virut.ce Hình ảnh trên miêu tả các đoạn mã có chứa thành phần chính của 1 file bất kỳ bị lây nhiễm bởi Virus.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ự byte rỗ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 logic nà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 độ sai lệch nhỏ) - Khôi phục lại nội dung ban đầu của dữ liệu với trình quả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ục gọ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 4 Lư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ện thông qua các “cuộc gọi” từ mã vận hành 0x15FF hoặc 0xE8, 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ủa hàm được thay thế từ kernel32.dll trong trình quản lý EBX register. 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ưu trữ 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ông nghệ 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 ứng với API-function, mặt khác, tại đây còn lưu trữ địa chỉ của entry point nguyên bản. Nếu quá trình obfuscation được loại trừ, thì cách đơn giản nhấ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 đã được thay thế): CALL $ + 5 PUSHAD MOV 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àn bộ khối dữ liệu. Tiếp theo, hãy cùng xem chúng thay đổi qua các giai đoạn khác nhau như thế nào.
Giai đoạn đầu tiên – CALL, không thay đổi nhiều lắm qua các giai đoạn. Về bản chất, nó trông giống như CALL $ + 5, sau đó là CALL $ + 6(7,8), và tiếp tục là CALL $ + 0xFFFFFFFx … với cơ chế giống những hàm gọi ngược. Có thể cho rằng quá trình hoạt động này không mấy quan trọng, và đối với những trường hợp nhất định sẽ áp dụng cơ chế loại bỏ, nhưng sự thực không phải như vậy. Thực chất, địa chỉ này được sử dụng để lưu trữ các hàm entry point/original cũng như khi trỏ tới địa chỉ của các key giải mã và là quá trình bắt đầu của các đoạn mã static. Tiếp theo là bước 3, thường xuyên thay đổi và chỉnh sửa nhiều hơn so với bước 1, nếu xem xét kỹ hơn nữa thì chúng ta có thể tiếp tục phân chia ra các cách khác nhau: - MOV EBX, [ApiFunc]/MOV EBX, [ESP + 24h]; - PUSH [ApiFunc]/[ESP + 24h]; POP EBX; - SUB ESP, xxh; PUSH [ESP + 24h + xx]; POP EBX; - LEA EBX, [ESP + xxh]; MOV EBX, [EBX + 24h - xx]; - ADD ESP, 28h; XCHG [ESP – 4], EBX;
Danh sách ví dụ trên có thể giúp chúng ta hình dung dễ hơn về giai đoạn này phát triển theo thời gian như thế nào. Bên cạnh đó, còn có các tác động trung gian của trình quản lý register ESP và EBX. Sau khi hàm PUSHAD được gọi ra, trình quản lý ESP register – được chỉ định trỏ tới các stack – sẽ được giảm bằng giá trị 0x20, sau đó ESP + 20h sẽ chuyển sang lưu trữ giá trị được cung cấp bởi hàm CALL được gọi ra cuối cùng. Một toán tử hoạt động hợp lý sẽ được áp dụng vào giá trị này và yêu cầu thêm các con số được thu thập. Dưới đây là 1 số trình tự hoạt động theo trật tự mô tả các hành động bên trên: - XOR/AND/OR/ADD/SUB [ESP + 20h], const; - MOV [ESP + 20h], const; - LEA EBP, [ESP + x]; MOV/OR/ADD/SUB/XOR EBP, const; XCHG [EBX + 20h – x], EBP; - MOV EBX, ESP; PUSH const; POP [EBX + 20h]; - PUSH const; POP [ESP + 20h].