[실전 악성코드와 멀웨어 분석] 실습 문제 3-1

[실전 악성코드와 멀웨어 분석] 책의 실습 문제3-1(Lab03_01.exe)를 분석한다. 분석 환경은 윈도우XP이다.

 

기초 정적 분석

 

그림 1 바이러스 토탈 분석 1

 

그림 2 바이러스 토탈 분석 2

 

바이러스 토탈(www.virustotal.com)로 Lab03_01.exe를 분석하면 59개의 백신이 해당 파일은 악성 코드임을 판별했다 (그림1 참조). 그리고 그림2에서 해당 악성 코드는 백도어로 추정된다.

 

다음은 PEID로 패킹 여부를 확인한다.

 

그림 3 PEID

 

그림3에서 해당 프로그램은 PEncrypt로 패킹된 것을 발견했다.

 

다음은 dependency walker로 사용된 dll 함수를 확인한다.

 

그림 4 dependency walker

 

그림4에서 단 하나의 모듈인 KERNDEL32.DLL을 발견했다. 그리고 해당 모듈은 ExitProcess 함수만 사용한다. 어떻게 ExitProcess 함수만으로 프로그램이 작동을 하는 것일까? 그리고 패킹이 되어있으면 최소한 Loadlibrary와 GetProAddress는 있어야 된다. 의문점을 가지고 일단 다음을 진행하자.

 

Stirngs.exe을 이용하여 문자열을 검사한다.

 

그림 5 Strings.exe

 

그림 6 의심스러운 문자열

 

그림6는 Lab03_01.exe의 의심스러운 문자열이다. 1번은 시스템 dll 파일의 이름이다. 아마 런타임 중에 시스템 dll 파일을 불러올 것 같다. 2번은 어떤 사이트의 도메인이다. 해당 도메인은 나중에 와이어샤크로 살펴본다. 3번의 vmx32to64.exe은 아직 정확한 정보를 모르니까 해당 파일을 주의하면서 다음 단계 분석을 하도록 하자. 4번은 "SOFTWARE\Microsfot\Windows\CurrentVersion\Run" 레지스트리다. 해당 레지스트리는 부팅 시 자동으로 실행할 파일을 설정한다.

 

 

기초 동적 분석

 

기초 동적 분석에서는 Procexp , Procmon를 사용하겠다. 기초 동적 분석을 할 때는 모든 분석 프로그램을 실행 후에 악성 코드를 실행해야 한다.

 

먼저 Procexp로 프로세스 리스트를 확인한다.

 

그림 7 Procexp

 

그림7에서 Lab03-01.exe의 핸들 리스트를 보면 WinVMX32라는 이름을 가진 뮤턴트(Mutant)를 발견했다 (핸들 리스트는 주황 네모 박스를 클릭하면 보인다). 뮤턴트는 중복 실행을 막기 위해 사용되는데, 일반적으로 악성 코드에 자주 사용된다.

 

다음은 Procmon 프로그램을 이용하여 프로세스가 하는 모든 행위를 확인하자.

 

그림 8 필터링 적용 (Filter -> Filter... 클릭)

 

그림 9 procmon

 

먼저 그림8처럼 필터링을 적용하자. 그 후에 그림9의 빨간 박스를 주목하길 바란다. Lab03_01.exe는 C:\\WINDOWS\system32\vmx32to64.exe 파일에 무언가를 저장한다. 그리고 HKLM\SOFTWARE\Microsoft\Windows\CurretnVersion\Run 레지스트리의 VideoDriver 키가 보인다. 해당 부분을 더블클릭 하자.

 

그림 10

 

그림10에서 VideoDriver 키에 등록된 데이터는 C:\WINDOWS\system32\vmx32to64.exe이다. 즉 부팅 시 자동으로 vmx32to64.exe은 실행된다.

 

 

고급 동적 분석

 

Lab03_01.exe은 패킹됐기 때문에 고급 정적 분석으로 정보를 얻기 힘들다. 그래서 바로 고급 동적 분석으로 넘어간다.

 

고급 동적 분석을 위해 올리 디버거를 사용한다. 먼저 Lab03_01.exe을 올리 디버거로 열자.

그림 11 EP

 

Lab03_01.exe의 EP에 CALL EAX가 보인다 (그림11 참조). F7를 눌러 해당 함수에 들어가자.

 

그림 12 CALL EAX

 

 

CALL EAX 함수의 내부에서 계속 트레이싱 하다 보면 004011FA 주소부터 명령어가 보이지 않는다 (그림12 참조). 004011FA 주소가 텍스트 섹션(.text)의 마지막 이기 때문이다. 004011FA 주소를 실행하면 데이터 섹션(.data)으로 넘어간다.

 

그림 13 데이터 섹션 시작 : 00401200 주소

 

00401200 주소부터 데이터 섹션이 시작된다 (그림 13 참조). 여기서 004011FA 주소부터 00401207 주소까지의 코드를 주목하길 바란다.

 

그림 14 kernel32.dll의 시작 주소를 얻음

 

그림14의 코드는 kernel32.dll의 시작 주소를 얻는다. 해당 코드를 이해하기 위해서는 PEB 구조체의 0xC 번째 필드인 _PEB_LDR_DATA 구조체를 알아야 한다. 이 부분은 독자 여러분이 구글링을 통해서 스스로 공부해보자 (_PEB_LDR_DATA 구조체의 설명이 매우 깁니다).

 

그림 15 0012EFC8 : 7C800000 (kernel32.dll 주소)

 

그림14의 코드를 실행하게 되면 0012EFC8 주소에 kernel32.dll의 주소가 저장된다 (그림15 참조). 그리고 7C800000 주소는 CALL 00400A70의 인자 이다. 일단 CALL 00400A70를 실행하여 어떤 변화가 일어나는지 확인하자.

 

그림 16

 

그림16에서 CALL 00400A70을 호출하면 EAX 레지스터에 kernel32.dll의 LoadLibraryA 함수 주소가 저장된다. 즉 CALL 00400A70은 dll의 특정한 함수 주소를 얻어오는 GetProcAddress와 같다. 그리고 00401228 주소의 CALL 00401236을 주목하자. 뭔가 이상하지 않는가? 00401236 주소는 함수 프롤로그 코드가 아니다. 즉 CALL 00401236은 함수 호출을 위해서가 아니라 00401236 주소로 점프하기 위해서다. 00401346 주소부터 분석하려면 F7을 누르면 된다.

 

그림 17

 

그림17에서 00401236 주소는 LoadiLibraryA를 호출하는데 뭔가 이상하다. LoadiLibraryA는 한 개의 인자 값이 필요한데, PUSH 명령어가 안보이기 때문이다. 스택의 최상단을 보면 0040122D 값이 저장되어 있다. 그런데 0040122D는 바로 그림16의 CALL 00401236의 복귀 주소이다 (CALL 명령어는 복귀 주소를 스택에 PUSH한다). 그러므로 LoadiLibraryA의 인자 값을 확인하기 위해서는 0040122D 주소를 확인해야 한다.

 

그림 18 advapi32 문자열 발견

 

그림18에서 0040122D 주소에 시스템 모듈인 advapi32을 발견했다. 리버싱을 어렵게 하기 위한 목적으로 상당한 특이하게LoadLibraryA를 호출했다. 그리고 00401242 주소의 CALL 0040124D도 마찬가지로 함수 호출을 위한 CALL 명령어가 아니다. 또 F7을 눌러 0040124D 주소를 확인해야 한다.

 

그림 19 CALL 0040124D

 

그림19에서 또 LoadLibraryA를 발견했다. 해당 인자 값은 그림 17의 CALL 0040124D의 복귀 주소(00401247)이다. 그러므로 00401247 주소를 확인하면 ntdll 문자열이 보인다 (그림 20 참조).

 

그림 20 ntdll 문자열 발견

위와 같은 방법으로 계속 리버싱해서 Lab03_01.exe을 분석하면 된다. 나머지 부분은 독자 여러분이 스스로 해보길 바란다.