2 KB 초미니 백도어(?) 분석 과정

해킹 사건이 있었습니다.

-  The Plague" returns to deface EC Council website

http://blogs.csoonline.com/malwarecybercrime/3010/plague-returns-deface-ec-council-website

관련 악성코드가 알려졌습니다.

- md5 : fb0cafbd79778b50ae884af1164b9c2b

- filesize : 2,048

달랑 2 KB !

그래서 처음에는 다운로더가 아닐까 생각했습니다. 

(하지만 이런 예상은 빗나가곤 합니다.)

난이도가 낮고 일반적으로 쉽게 접하기는 어려운 형태의 샘플입니다.

그래서, 앞으로 신입 사원 교육 때 이 샘플을 사용할까 합니다. 

분석 결과가 인터넷에 있네라고 할 수 있지만 분석가에게는 단순 분석 능력 뿐 아니라 어디에 필요한 정보가 있는지 찾을 수 있는 능력도 필요합니다.

1. 외형 확인

2014년 2월 6일 12시 23분 43초에 빌드 되었습니다.

(참고로 시간은 충분히 조작 가능합니다.)

최근에 만들었나봅니다.

딱봐도 0x401160 부분에 IP 주소도 보이고 크기도 0x16F (367) 바이트 정도 밖에 안됩니다.

어셈블리로 제작했다는걸 알 수 있습니다.

쉽게 다운로더라고 예상하고 분석 들어갑니다.

(하지만... 결과적으로 예상은 틀렸습니다.)

2. IDA 그리고 Ollydbg

모니터가 2대인데 왼쪽 화면에는 IDA 그리고 오른쪽에는 Ollydbg를 띄웁니다.

Ollydbg로 따라가는 걸 IDA에 설명을 달기 시작합니다.

3. 디버깅 시작

Ollydbg로 디버깅을 시작합니다.

시작점은 0x00401000 입니다.

CLD 다음에 바로 CALL 명령입니다. [F7]로 차근차근 따라갑니다.

(F8로 따라가면 call 명령이 그냥 수행됩니다.)

0x0040108F으로 진입했는데 PUSH 로 이것저것 넣더니 CALL EBP 로 어딘가로 들어갑니다.

값만 봐서는 뭔지 모르겠습니다 @.@...

사실 이런 코드는 단순히 눈으로 따라가서는 주소를 알 수 없어 분석이 무척 어렵습니다.

그래서 Ollydbg로 따라가면서 얻은 내용을 IDA에 주석을 달아줘야 합니다.

디버거로 따라가보면 CALL EBP에서 EBP 값이 0x00401006 인걸 알 수 있습니다.

일단 0x004010A2에 BP 걸어 둡니다.

4. API 호출에 BP 걸기

0x00401006은 악성코드 앞부분에 존재합니다.

뭐하는 코드일까요 ?

이쯤 오면 경험 좀 있는 분석가라면 API 호출 코드라는걸 예상할 수 있습니다.

많은 어셈블리로 만들어진 바이러스나 Shellcode는 Win32 API 기능을 사용하기 위해 직접 주소를 호출하는 방식을 이용합니다.

(이부분은 그냥 생략합니다. 인터넷에 검색하면 다양한 자료 있습니다.)

이 백도어에서 API를 호출하는 코드는 0x00401086에서 JMP EAX로 진입합니다.

(EAX 값에 호출하려는 API 주소가 들어갑니다.)

따라서 여기에 [F2]로 BP 걸어두면 앞으로 사용되는 API 를 하나씩 볼 수 있습니다.

이렇게 [F9]로 달릴 때 마다 어떤 API를 호출하는지 알 수 있습니다.

첫번째 API는 kernel32.LoadLibraryA 이군요. 

한번 더 [F9]로 달리면 아까 BP 걸었던 곳에 도착합니다.

이렇게 코드를 하나하나 따라가다 보면 외부와 통신 하는 걸 알 수 있습니다.

5. 통신 

기본적으로 악성코드는 인터넷이 단절된 곳에서 이뤄집니다.

(인터넷 연결해두고 하는 사람들도 있지만요.)

그러다보니 통신 실패가 뜨면서 이런 백도어류는 더이상 디버거로 따라가기가 힘든 경우가 많습니다.

그 이후에는 코드상으로만 분석해야하는데 쉽지 않습니다.

(많은 경우 GG 칩니다.)

이제 외부와 통신하는 부분입니다.

그런데... 여기서 그냥 계속 따라가면 악성코드가 종료됩니다.

통신 다음에 TEST EAX, EAX 뭘까요 ?

바로 오류인지 검사하는 부분입니다.

코드를 유심히 보면 DEC EBX해서 0 이 되면 점프하는 부분도 있습니다. 이건 에러 횟수 검사인데 0x10 이니 대략 16번 정도 통신 시도하고 포기하겠죠. 예상할 수 있습니다.

Registers를 보면 EAX 값이 현재 0 입니다. 즉, 에러이죠.

EAX 값을 더블클릭해 다른 값으로 변경합니다. (여기서는 1)

(그냥 강제로 EIP를 바꿔도 됩니다.)

통신이 이뤄줬다는 가정하에 다음 코드 계속 진행됩니다.

(이 악성코드는 어셈블리로 만들어져서 간단히 우회 할 수 있지만 다른 악성코드는 실패하는 경우가 대부분입니다.)

6. 실제 백도어는 인터넷으로 전송

이제 코드가 얼마 안 남았습니다.

또... 뭔가 API를 호출합니다.

하지만, 우리는 이미 BP 걸어놨으니 ~

kernel32.VirtualAlloc 이군요.

0x00AE0000 에 priv 타입으로 읽기/쓰기/실행 가능한 RWE 로 메모리가 할당 되었습니다.

더 따라가 봅니다.

이번에는 wininet.InternetReadFile 입니다.

즉, 인터넷에서 어떤 데이터를 읽어 옵니다.

그리고, RETN 으로 0x0AE0000 으로 점프합니다.

물론 인터넷에 연결되지 않았고 받아온 데이터가 없으니 NULL 로 채워져 있습니다.

만약 접속해 받아오는 서버가 살아있었다면 여기에는 새로운 코드가 존재했을 겁니다.

따라서...

더 이상 분석은 불가능 합니다...

끝 !

7. 본체는 인터넷에...

결과적으로 이 악성코드의 본체는 인터넷에 숨겨져있습니다.

(아마 백도어 기능이겠지요.)

파일은 단순히 로더 혹은 다운로더라고도 할 수 있겠죠.

본체는 인터넷에 숨겨두는 악성코드라 ...

어셈블리로 작성된 녀석도 오랫만인데 이런 형태는 흔하지 않습니다.

사실 이 악성코드가 처음 사용한 기법은 아닙니다.

악명 높은 PoisonIvy도 실제 악성코드 본체는 인터넷 상에 있고 패킷으로 받아와 메모리 상에만 존재합니다