[악성코드 분석]드롭퍼/다운로더(2)

 

[악성코드 분석] 드롭퍼/다운로더(1)

위 페이지에서 분석을 완료했지만

 

프로그램 시작부분에서 계속 삽입했던 shellcode부분에 대한 내용은 다루지 않아서 

 

이 페이지에서 적어볼까 합니다.

(사실 shellcode 부분을 이제서야 다루는 이유는

FS레지스터, TEB, PEB 등에 대한 이해도가 부족했기 때문입니다 하하)

 

원래 Entry Point부분부터 스택영역에 값을 삽입하고 있는 shellcode를

Entry Point에 그대로 복사를 해보도록 하겠습니다.

 

EP부분에 복사하는 이유는? 

IDA같은 정적분석툴도 함께 이용해보기위함입니다.

 

※ 참고사항: 이 프로그램은 32비트 프로그램입니다!

(64비트는 구조체 위치별로 가리키는 대상이 32비트와 다릅니다)

 

[그림1] EP부분에 shellcode 복사 

 

[그림2] 선택

 

[그림3] 실행파일로 복사

선택한 영역을 실행 파일로 복사할꺼냐구 묻는데 Copy all을 눌러줍니다.

 

[그림4] 파일로 저장

여기까지 했다면 이 프로그램이 스택에 한 바이트 한 바이트 삽입한 shellcode를 

파일로 만든 것 입니다.

 

아 혹시 파이썬으로 웹서버 여는방법이 궁금하면 클릭해보세요!

▶ pip install httpserver

▶ python -m http.server -p [포트번호] -d [경로]

[그림5] 클라이언트가 다운로드한 모습(서버에서 볼 때)

일단 다운로더가 127.0.0.1:8080/board/R4n50m3.exe로 요청을 했네요!

 

이제 shellcode를 볼게요

 

 

[그림6] fs 레지스터(TEB)

유저모드에서 FS레지스터에는 TEB에 대한 주소를 담고있어요

 

 TEB는 스레드 환경정보가 담겨있는 구조체죠!

 

즉, 이 프로그램을 메인함수를 실행시키는 스레드의 정보가 담겨있고?

 

fs레지스터의 0x30의 위치는 PEB의 주소를 담고있어요

 

[그림6]에서 확인이 가능하죠?

 

shellcode에서 시키는대로 PEB를 따라가보겠습니다.

 

 

[그림7] PEB 정보

 

PEB는 프로세스 환경정보가 담겨있는 구조체에요!

 

[PEB+0xC] 위치에는

_PEB_LDR_DATA라는 구조체가 있어요!

 

[그림8] _PEB_LDR_DATA

_PEB_LDR_DATA 구조체는

프로세스를 메모리에 로더시킨 정보를 가지고 있고

3개의 LIST_ENTRY를 가지고 있습니다

 

LIST_ENTRY는 이중연결리스트로 구성되어있어요

 

[그림9] 구조설명

[그림9]는 지금까지 분석한 shellcode를 풀어놓은 모습입니다.

 

현재 [_PEB_LDR_DATA+0x14] 위치에 있죠?

 

그림에 대한 설명을 더하면 

 

[_PEB_LDR_DATA+0x14]는 _LIST_ENTRY 형태로 Flink와 Blink로 구성되어 있어요

(F는 포워드겠고, B는 백이겠죠?)

 

즉, ntdll.dll의 InMemoryOrderModuleList를 가리키게 됩니다

 

한 번 더 가리키면 kernel32.dll의 InMemoryOrderModuleList를 가리키게 됩니다

 

 

[그림10] lods

lods [esi] 명령어란?

mov eax, [esi]

add esi, 4

lods [esi]  ;  [ntdll.dll의 LDR_DATA_TABLE_ENTRY + 0x8] = InMemoryOrderLinks.Flink

xchg eax, esi 

lods [esi] ;  [kernel32.dll의 LDR_DATA_TABLE_ENTRY + 0x8] = InMemoryOrderLinks.Flink

 

위 명령어의 역활은 kernel32.dll의 base주소를 얻기위한 이중포인터라는 것을 알 수 있죠!

 

 

 

[그림11] kernel32.dll의 Export Table 찾기

kernel32.dll의 BaseAddress + 0x3C는 NT헤더의 offset(0xE8)이 들어있죠?

 

BaseAddress + 0xE8 + 0x78 = Export Table(0x160)의 offset(0x91020)이 들어있네요

 

이 후 0x19fece주소에서 Export Table의 0x20의 offset을 찾아가네요!!

 

그럼 이제 Export Table을 볼까요?

 

[그림12] Export Table MSDN

Export Table의 0x20(32)에는 Name Pointer의 RVA가 들어있네요

 

Name Pointer를 반복/비교하면서 찾고싶은함수가 몇 번째에 있는지 알 수 있어요

 

 

[그림13] Export Table에서 GetProcAddress의 위치 찾기

GetProcAddress가 몇 번째에 있는지 ecx를 통해 찾고 있는 것 같죠?

 

[그림14] GetProcAddress의 원형

DLL의 핸들과, 찾고싶은 함수의 이름을 넣어주면

그 함수의 주소를 반환해주는 함수입니다!

 

계속 보게될 함수이니 잊지 않도록!!

 

[그림15] LoadLibrary

보통 DLL의 핸들을 얻기위해 사용하지만 여기서는 이미 얻었으니 사용할 필요가 없겠죠?

GetProcAddress와 LoadLibrary는 보통 세트로 활동하니 함께 알아두세요!!

 

[그림16] Export Table + 0x24

[그림12]에서 봤을 때 [Export Table + 0x24(36)]는 Ordinal Table RVA가 있네요

몇 번째인지 구해놓았던 cx에 2를 곱하네요

 

[그림17] Export Ordinal Table

Ordinal Table은 2바이트씩 구성되어있고 

이 2바이트에는 해당함수의 실제 offset 정보가 들어있어요!

 

[그림18] Export Ordinal Table에 접근

0x02ad를 cx에 저장 후 -1!

GetProcAddress는 0x02ac번째 떨어진 곳에 있네요

 

[그림19] PE View로 확인!

 

 

[그림20] Export Address Table

[그림12]에서 확인해보면

[Export Table+0x1C(28)]은 Export Address Table이네요.

 

Export Address Table은 실제 함수의 주소가 들어있죠!

 

결국 지금까지 GetProcAddress의 실제 주소를 찾기위해 이 짓?을 했다는 말입니다..

하하

 

이제는 단순한 코드의 반복이니 IDA에서 주석처리하면서 분석해봅시다!

 

[그림21] 분석

결국 WinExec로 자신이 다운로드 받은 악성파일을 실행시키는 shellcode네요!!

 

다운로드API처럼 간단하게 WinExec를 사용해도 되는데 구지 이렇게까지 하는 이유가 뭘까요?

 

바로 티나기 때문이죠..

 

여기까지 악성파일의 shellcode까지 분석을 완료했습니다!