YOMEDIA
Tổng quan về mẫu malware Virus.Win32.Virut.ce- Phần 3
Chia sẻ: Cong Thanh
| Ngày:
| Loại File: PDF
| Số trang:10
134
lượt xem
14
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 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...
AMBIENT/
Chủ đề:
Nội dung Text: 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 dấu.
Hình ảnh bên dưới hiển thị các đoạn mã disassembled của
cô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 đầy
bởi các hành động push / pop liên tục và được giải mã bởi
adc. Tuy nhiên, các quá trình này không phải lúc nào cũng
- giố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 virus
ghi 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 đầu
Về mặt lý thuyết, toàn bộ mã nguồn của phần body chính
có 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ủa
quá trình payload.
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].
Ảnh chụp màn hình file bị lây nhiễm bởi
Virus.Win32.Virut.ce, với các đoạn mã đảm nhiệm chức
năng khôi phục tới các entry point gốc được đánh dấu hình
oval đỏ
Để phân biệt rõ ràng hơn, toàn bộ các đoạn mã ví dụ trên
đều không bao gồm quá trình obfuscation. Tuy nhiên, giai
đoạn đó lại được sử dụng trong tất cả các section của file đã
được ghép thêm vào bởi virus, có bao gồm trình giải mã
Init và toàn bộ phần mã thực thi trong phần body chính. Và
quá trình này hoàn toàn ngăn chặn các dấu hiệu nhận dạng
virus từ các chương trình an ninh bảo mật, bằng cách thay
đổi toàn bộ bề ngoài của mã dữ liệu mà không làm ảnh
- hưởng đến hoạt động chung. Dưới đây là 1 số ví dụ cụ thể,
trong đó chúng được sử dụng để che giấu quá trình nhận
dạng mà không ảnh hưởng đến các hoạt động chức năng:
- XCHG reg1, reg2; XCHG reg2, reg1; (được sử dụng
cùng nhau)
- SUB reg1, reg2; ADD reg1, reg2; (sử dụng cùng nhau)
- MOV reg, reg; OR reg, reg; AND reg, reg; XCHG reg,
reg; LEA reg, [REG];
- CLD, CLC, STC, CMC, etc.
Trong đó, ‘reg1’ và ‘reg2’ đại diện cho các trình đăng ký –
register khác nhau, còn ‘reg’ để chỉ quá trình register giống
nhau trong cùng 1 biểu thức đơn.
Các toán tử logic đi liền với toán tử hạng hai tùy biến.
Ngoài ra còn có ADC reg, const; SBB reg, const; XOR reg,
const …
Các thành phần của quá trình obfuscation được đánh dấu
bằng hình oval đỏ
Hình bên trái chỉ ra rất rõ rằng các chỉ dẫn theo kiểu junk
chiếm tới 70 - 80% toàn bộ mã của file dữ liệu.
Thêm tài liệu vào bộ sưu tập có sẵn:
Báo xấu
LAVA
ERROR:connection to 10.20.1.100:9315 failed (errno=111, msg=Connection refused)
ERROR:connection to 10.20.1.100:9315 failed (errno=111, msg=Connection refused)
Đang xử lý...
Thêm vào BST
Báo xấu
