포포포포렌식 #3

#1. 메모리 분석

#1-1. 운영체제 버전?

보통 침해사고가 터졌을 때 따로 해당 pc의 ip주소와 운영체제 버전 정보 등을 따로 가져오는 것이 일반적이다.

하지만 이 정보를 얻지 못한 경우, 메모리 덤프에서도 운영체제의 버전 획득이 가능하다.

< imageinfo 옵션 >

< kdbgscan 옵션 >

inp : volatility -f 메모리덤프 imageinfo

inp : volatility -f 메모리덤프 kdbgscan

volatility의 imageinfo, kdbgscan 옵션을 이용하여 운영체제 정보를 획득할 수 있다.

Win7SP0x86, Win7SP1x86을 확인할 수 있다.

#1-2. 메모리 사본 확보 시간(한국 시간)은?

지금까지는 파일의 변경 시간을 가지고 판단하였다.

< 메모리 덤프 속성 정보 >

보면 마지막 수정 시간을 확인할 수 있다. 하지만 마지막 수정 시간 즉, 덤프가 끝난 시간의 정보만 있을 뿐 시작 시간은 없다.

이는 volatility의 프로세스 정보 확인을 통해 알 수 있다.

< psscan 옵션 >

inp : volatility -f 메모리덤프 --profile=Win7SP0x86 psscan

volatility의 psscan의 결과를 조금 보기 좋게 변경한 그림이다.

보면 DumpIt.exe 라는 프로세스가 목록에 올라와 있는데 이 프로세스가 메모리 덤프를 만든 프로세스이다.

보면 Timecreated 시간이 2014-02-03 12:31:34 UTC+0000으로 되어있다. 한국 시간은 UTC+09이다.

파일 시간상으로는 2014-02-03_07:33:12인데 프로세스 시작 시간은 2014-02-03_21:31:34이다.

피해 PC의 시간정보를 확인해봐야 명확히 할 수 있을 것 같다.

#1-3. 메모리 사본시 사용한 사용자 이름은?

확인 방법은 여러 가지가 있을 법 한데 여기서 사용한 방법은

DumpIt 경로 파악, 현재 레지스트리 유저 파악 등이 있다.

< userassist 옵션 >

inp : volatility -f 메모리덤프 --profile=Win7SP0x86 usrassist

userassist의 일부분이다. 이전 과제에서 userassist는 프리패치와 함께 사용자가 주로사용하거나 최근 사용한 프로그램을 알 수 있다고 했다. 보면 메모리 덤프를 획득할 때 사용한 DumpIt.exe가 Users하위의 Tek Defense경로 하위 바탕화면에 존재한다.

보통 Users 경로 하위에는 사용자의 계정이 존재하므로 Tek Defense라는 사용자로 획득을 한 것을 알 수 있으며 아래 ntuser.dat을 보았을 때도 같은 Tek Defense라는 계정을 확인할 수 있다.

#1-4. 메모리 사본에 사용한 도구와 버전은?

DumpIt이라는 프로그램이 메모리 사본에 이용되었다는 것을 안 것은 이번 침해사고 대응 덕분에 알게 되었다.

일단 DumpIt이라는 프로그램을 사용하여 메모리 사본을 획득 하였다고 해도 버전을 알기 위해서는 해당 프로그램을 얻어야 한다.

메모리에서 프로세스목록에 있는 DumpIt을 직접 획득하여 프로그램화 하고 버전을 확인하면 된다.

< pslist - DumpIt PID 확인 >

inp : volatility -f 메모리덤프 --profile=Win7SP0x86 pslist

먼저 불필요한 프로세스는 획득할 필요가 없으므로 획득에 필요한 DumpIt의 PID를 확인한다.

pslist 옵션에서 확인을 하면 되며 DumpIt의 PID는 3060이다.

< procdump 명령 >

inp : volatility -f 메모리덤프 --profile=Win7SP0x86 -D 저장경로 -p PID

먼저 procdump 명령을 준다.

volatility -f 덤프파일 --profile=운영체제정보 procdump -D 저장경로 -p pid

이런식으로 해주면 된다. DumpIt은 윈도우 계열이므로 윈도우에서 확인을 해 보았다.

< 생성된 파일 & DumpIt 실행화면 >

procdump로 DumpIt을 프로그램화 시키면 위에처럼 'execute.PID번호.exe' 형태로 파일이 추출된다.

그런데 이상하게 실행이 되지 않아 버전확인을 하지 못하였다.

그 아래 사진은 보유하고 있던 DumpIt을 실행시킨 화면이다. 보면 DumpIt 버전을 바로 확인할 수 있다.

아무래도 그냥 프로세스만을 가져오는 것이 아니라 다른 추가적인 설정이 필요하지 않나 싶다. (추후 수정..)

#1-5 a. 네트워크 연결 상태를 확인하라

volatility에서 확인할 수 있는 네트워크 관련 기능은 connections, connscan, netscan, sockets, sockscan이 있는데 이 중에 netscan을 제외한 다른 기능들은 win7에서는 지원을 하지 않는다. 따라서 netscan을 이용하였다.

< netscan 옵션 >

inp : volatilty -f 메모리덤프 --profile=Win7SP0x86 netscan

netscan을 통해 나온 결과물을 보기 좋게 수정한 화면이다.

보면 대부분 system이나 windows에서 기본적으로 이행되는 svchost, services등의 프로세스가 가지는 네트워크인데 제일 아래줄을 보 연결이 끊어진 tcp연결이 하나 있다. 연결이 끊어져서 다른 정보는 확인할 수 없지만 외부로 연결한 아이피 주소가 176.106.48.182라는 것을 확인할 수 있다.

#1-5 b. 여러 후킹 상태를 확인하라

후킹 정보를 확인할 수 있는 volatility의 기능은 apihook이다. user, kernel모드에서 api hooking 정보를 확인할 수 있다.

< apihooks 결과 일부 >

inp : volatility -f 메모리덤프 --profile=Win7SP0x86 apihooks

보면 후킹에 이용된 프로세스명과 이용된 모듈이 victim module로 나온다. 위처럼 svchost, explorer등이 있었는데 아래에서 악성 프로세스라고 의심을 했던 runddl32.exe에도 여러 dll들을 후킹한 흔적을 확인할 수 있었다.

< runddl32.exe의 후킹 >

runddl32.exe와 관련된 후킹은 총 19가지로 나오며 일부를 보기 좋게 수정한 화면이다. 보면 Victim module은 URLMON.DLL로 이 dll파일을 후킹한 것으로 파악되며 사용한 function이 다양하게 나온다. 이외에도 iertutil.dll, WININET.dll이 사용된 것으로 파악된다.

#1-5 c. 프로세스 인젝션 상태를 확인하라

후킹 정보와 마찬가지로 volatility의 기능 중 malfind를 사용하면 된다. 아니면 dllist, dlldump, ldrmodules등을 이용하여 악성코드로 의심되는 프로세스와 관련된 dll들을 분석하면 된다.

< malfind 옵션 >

inp : volatility -f 메모리덤프 --profile=Win7SP0x86 maflind  -p 1524 -D 저장경로

pid값을 1524로 주고 mafind를 시행한 화면이다. pid 1524는 runddl32.exe의 pid이다. 또 -D 옵션으로 저장경로를 주게되면 injected된 바이너리를 얻을 수 있다. 여기서는 process.0x84536030.0x220000.dmp라는 이름으로 생성되었다.

만약 injected된 dll이나 기타 데이터가 패킹이 되어 있다고 하더라도 여기서 나오는 데이터의 경우 메모리에 상주된 후의 데이터 이기 때문에 패킹이 풀린 바이너리 값을 얻을 수 있다.

#1-6. 수상하게 생각하는 프로세스와 그 이유는?

< pslist - runddl32.exe >

보면 runddl32.exe라는 프로세스가 목록에 올라와있다. 작업 관리자를 보면 주로 올라와있는 rundll32.exe를 가장한 프로세스가 아닌가 싶다. 그 이외에 프로세스 목록에서 알 수 있는 특이한 프로세스는 없었다.

#1-7. 수상한 프로세스의 핸들과 뮤턴트를 살펴보고 특이사항은?

핸들과 뮤턴트를 확인하기 전에 프로세스에서 핸들이란 무엇일까?

핸들은 파일, 레지스트리 키, 뮤텍스 프로세스 또는 스레드와 같은 커널 객체의 열린 인스턴스에 대한 참조라고 한다.

(ref 메모리 포렌식:혜지원)

뮤턴트는 위에서 사용된 메모리에서 KMUTANT 객체를 확인하는 것인데 KMUTANT는 윈도우 커널에서 뮤텍스를 관리하는 구조체이다. 각자의 뮤텍스는 고유의 이름을 가지는 뮤텍스를 만들 수 있고 이 목록이 있는 곳이 KMUTANT일 것이다.

먼저 프로세스 핸들을 확인해 보았다.

< runddl32.exe handles 일부 >

inp : volatility -f 메모리덤프 --profile=Win7SP0x86 handles -p 1524

runddl32.exe의 핸들을 보기위해 -p 옵션에 1524를 넣어준다.

일단 이상하게 생각되는 것은 Thread이벤트로 TID XX PID 1896, TID XX PID 1316이 확인되었다. PID 1896, 1316은 각각 notepad.exe, svchost.exe였다. runddl32.exe가 notepad와 svchost에 어떠한 관여를 하지 않나 싶다.

< runddl32.exe의 handles와 mutantscan 일부 >

inp : volatility -f 메모리덤프 --profile=Win7SP0x86 mutantscan

runddl32.exe의 핸들중에 mutant 이벤트로 위처럼 DC_MUTEX-KHNEW06을 확인할 수 있고 mutantscan을 통해 해당 뮤텍스 offset과 사용횟수를 파악할 수 있다. DC_MUTEX-KHNEW06은 그냥 여기서 사용한 뮤텍스 이름이라고 한다.

실제 악성코드의 경우 사용된 뮤텍스를 가지고 판단을 하는 경우도 있다고 한다.

#1-8. 악성코드의 종류에 대해 알아보아라.

프로세스의 덤프가 제대로 이루어 지지 않아서 분석을 하지 못하였다. 여기까지 확인한 정보를 바탕으로 보면 프로세스가 실행되면 notepad에 어떠한 처리를 하며 dllinjection을 하고 네트워크를 이용한다.

#1-9. 악성코드의 생성일자는?

procdump로 프로세스를 가져와도 생성일자 확인은 하지 못한다.

< pslist >

따라서 pslist를 통해 확인한 시간정보밖에 파악하지 못하였다. pslist에 나온 시간으로는 2014-02-03_12:31:34 UTC+0000 이다.

#1-10. 악성코드 감염일자를 추정해보고, 그 이유를 말하라.

#1-11. 악성코드의 설정(옵션) 상태에 대하여 말하라.

#1-12. 악성코드가 연결하는 서버가 있다면 서버 주소를 말하라.

#1-13. 악성코드가 감염상태 유지를 위해 사용한 방법을 말하라.

#1-14. 악성코드 존재를 감추기 위해 사용한 방법은?

#1-15. 악성코드의 감염 경로는?

#2. 오픈소스 혹은 상업적 이용에 제한이 없는 포렌식 도구 아무거나 하나 잡고 조사해오기.

옛날부터 여러 부분에서 유용하게 사용하는 FTK Imager를 조사하였다.

AccessData사에서 제공을 해주며 설치 등은 무료이므로 생략.

전체 기능은 매우 방대하기 때문에 물리 이미지, 덤프 사용등에 관련한 내용을 소개하도록 한다.

< FTK Imager 메인 >

간단하다. 왼쪽에 Evidence Tree는 윈도우 탐색기처럼 디렉토리들을 트리 형식으로 나타내준다. 우상단은 윈도우 탐색기의 상세부분과 비슷하다. 좌하단은 직접 물리 디스크에서 원하는 데이터만을 뽑아서 새로운 증거물로 목록을 만들 수 있다.

위에 메뉴아이콘 5가지를 빨간 박스로 체크했는데 왼쪽부터 차례대로 다음과 같다.

1. 1개의 물리 디스크 가져오기

2. 모든 물리 디스크 가져오기

3. 이미지 덤프 마운팅

4. 1개의 Evidence 제거

5. 모든 Evidence 제거

Encase와 같이 포렌식을 중점으로 만든 프로그램이므로 Evidence라는 단어가 들어가 있다.

위 화면은 2번 메뉴를 통해 현재 연결된 모든 물리 디스크를 증거물로 올려 놓은 화면이다.

PHSICALDRIVE0,1은 디스크 자체를 증거물로 올려놓은 것이고 아래 C,D,E,F는 디스크 0,1을 논리적으로 나뉜 파티션단위로 읽어오는 것이다. 데이터 복구나 파일 추출에서는 논리적으로 읽어오는 것이 일반적이다.

< Add Evidence 메뉴 >

1번의 아이콘을 클릭하거나 File - Add Evidence Item 메뉴를 사용하면 위처럼 나오게 된다. 물리 드라이브, 논리 드라이브, 이미지, 폴더 등으로 나뉘어서 증거물로 올려놓고 확인할 수 있다.

< 실제 사용 화면 >

USB 디스크를 읽었으며 /새 폴더 를 읽어들인 화면이다. [root]폴더가 해당 디스크의 최상위경로이다.

좌상단을 보면 경로들이 트리 구조로 나온 것을 확인할 수 있다.

우상단을 보면 현재 선택한 '새 폴더' 하위의 목록을 확인할 수 있다.

그 중에 'Downloads - 복사본.zip', 'DumpIt - 복사본.exe'에는 아이콘에 X표시가 되어있다. 이는 파일이 삭제 되었다는 의미이다.

FTK Imager는 윈도우에서 파일을 제거 하였더라도 이처럼 디스크에는 남아있으므로 복구가 가능하다.

원하는 파일을 오른쪽 클릭하면 위처럼 나오게 되는데 'Export Files...' 항목을 선택하면 현재 디스크에 파일을 추출할 수 있다.

'Downloads - 복사본.zip'은 일반적은 Delete를 이용하여 휴지통으로 간 경우.

'DumpIt - 복사본.exe'는 휴지통으로 가지 않는 Shift + Delete를 이용한 경우이지만 상관없이 복구 가능하다.

좌하단을 보면 두개의 항목이 새로 생겼는데 이는 직접 우상단에서 원하는 데이터만을 'Add to Custom Content Image' 항목을 이용하여 새로운 증거물로 만들기 위해 선택한 것이다.

ref 

http://www.codeengn.com/archive/Forensic/Volatility%20command%202.1%20%5B%EB%B3%B4%EC%95%88%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8,%20%EC%9D%B4%EC%8A%B9%EC%A4%80%5D.pdf

http://www.codeengn.com/archive/Forensic/Volatility%20Plugin%20%EC%9D%84%20%EC%9D%B4%EC%9A%A9%ED%95%9C%20Windows%20Memory%20Dump%20%EB%B6%84%EC%84%9D%20%5BDeok9%5D.pdf

http://apollo89.com/wordpress/?p=6989

http://ucs.dongguk.edu/jiwon_choi/Memory%20Forensic%20Analysis.pdf